[Comm] Bridging firewall

[Comm] Bridging firewall

[Jury Levykin]

Создан bridging firewall на ALM 2.2
# uname -r
2.4.20-alt17-up

по статье опубликрванной здесь:
http://samag.ru/ru/articles/4-04/news_current.shtml?2003/11/20031106-50.html

Патчи на ядро не накладывал т.к. не смог найти патч для моего ядра.
Судя по тому что в мастере есть bridge-utils я предположил что ядро
уже пропатчено для создания моста.
Так это или нет?

Создаю мост так:
# brctl addbr bridge0
# brctl addif bridge0 eth0
# brctl addif bridge0 eth1
# ifconfig eth0 0.0.0.0 promisc
# ifconfig eth1 0.0.0.0 promisc
# brctl sethello bridge0 1
# brctl setmaxage bridge0 4
# brctl setfd bridge0 4
# ifconfig bridge0 xxx.xxx.xxx.xxx netmask 255.255.255.224 broadcast xxx.xxx.xxx.xxx up
# route add default gw xxx.xxx.xxx.xxx
# arp -f

Мост работает.
В одину карточку включен шлюз в другую наша сеть (с внешними IP).
Все машины работают в интернете - проблем нет.

Но кроме подключения нужно подсчитывать трафик.
Меня смущает, что через цепочку FORWARD (iptables) не идет трафик.
Я даже запретил прохождение через нее пакетов:
iptables -P FORWARD DROP
после этого доступ сети к интернету не ограничелся.

В статье идет речь о подсете трафика проходящего именно через эту цепочку.
Таким образом сказывается отсутствие патча или
так и должно быть и нужно считать трафик в INPUT / OUTPUT ?

Re: [Comm] Bridging firewall

[Nizamov Shavkat]

>
> Но кроме подключения нужно подсчитывать трафик.
> Меня смущает, что через цепочку FORWARD (iptables) не идет трафик.
> Я даже запретил прохождение через нее пакетов:
> iptables -P FORWARD DROP
> после этого доступ сети к интернету не ограничелся.
>
> В статье идет речь о подсете трафика проходящего именно через эту цепочку.
> Таким образом сказывается отсутствие патча или
> так и должно быть и нужно считать трафик в INPUT / OUTPUT ?

бриджинг осуществляется очень просто - сетевые пакеты приходящие на одну
карточку просто выкидываются на другую. поэтому никакой Iptables на них не
действует.

возможно указанный патч как-то работает по другому

Re: [Comm] Bridging firewall

[Eugene Prokopiev]

Nizamov Shavkat пишет:
>>Но кроме подключения нужно подсчитывать трафик.
>>Меня смущает, что через цепочку FORWARD (iptables) не идет трафик.
>>Я даже запретил прохождение через нее пакетов:
>>iptables -P FORWARD DROP
>>после этого доступ сети к интернету не ограничелся.
>>
>>В статье идет речь о подсете трафика проходящего именно через эту цепочку.
>>Таким образом сказывается отсутствие патча или
>>так и должно быть и нужно считать трафик в INPUT / OUTPUT ?
> 
> 
> бриджинг осуществляется очень просто - сетевые пакеты приходящие на одну
> карточку просто выкидываются на другую. поэтому никакой Iptables на них не
> действует.
> 
> возможно указанный патч как-то работает по другому

для того, чтоб устраивать firewall (а также что-то считать) на бридже, 
нужен ebtables (ebtables.sf.net). Я его даже собирал для ядра ALM 2.2 
около года назад - поищите мои письма на эту тему в архиве рассылки


-- 
С уважением, Прокопьев Евгений

Re: [Comm] Bridging firewall

[Jury Levykin]

Eugene Prokopiev пишет:

>
> для того, чтоб устраивать firewall (а также что-то считать) на бридже, 
> нужен ebtables (ebtables.sf.net). Я его даже собирал для ядра ALM 2.2 
> около года назад - поищите мои письма на эту тему в архиве рассылки

В прошлогодней рассылке я не смог найти писем от Prokopiev и
содержащих в теме "bridge" или "ebtables".
По каким ключевым словам искать те письма?

Поиск пакета в Сизифе по "ebtables" - тоже не дал результата.

Помогите найти этот пакет если он есть.

Re: [Comm] Bridging firewall

[Nizamov Shavkat]

> Eugene Prokopiev пишет:
>
>>
>> для того, чтоб устраивать firewall (а также что-то считать) на бридже,
>> нужен ebtables (ebtables.sf.net). Я его даже собирал для ядра ALM 2.2
>> около года назад - поищите мои письма на эту тему в архиве рассылки
>
> В прошлогодней рассылке я не смог найти писем от Prokopiev и
> содержащих в теме "bridge" или "ebtables".
> По каким ключевым словам искать те письма?
>
> Поиск пакета в Сизифе по "ebtables" - тоже не дал результата.
>
> Помогите найти этот пакет если он есть.
>


http://lists.altlinux.ru/pipermail/community/2003-September/098440.html

PS google rulez

Re: [Comm] Bridging firewall

[Nizamov Shavkat]

>> Eugene Prokopiev пишет:
>>
>>>
>>> для того, чтоб устраивать firewall (а также что-то считать) на бридже,
>>> нужен ebtables (ebtables.sf.net). Я его даже собирал для ядра ALM 2.2
>>> около года назад - поищите мои письма на эту тему в архиве рассылки
>>
>> В прошлогодней рассылке я не смог найти писем от Prokopiev и
>> содержащих в теме "bridge" или "ebtables".
>> По каким ключевым словам искать те письма?
>>
>> Поиск пакета в Сизифе по "ebtables" - тоже не дал результата.
>>
>> Помогите найти этот пакет если он есть.
>>
>
>
> http://lists.altlinux.ru/pipermail/community/2003-September/098440.html
>
> PS google rulez

http://lists.altlinux.ru/pipermail/community/2003-September/098912.html
>
> _______________________________________________
> Community mailing list
> Community@altlinux.ru
> https://lists.altlinux.ru/mailman/listinfo/community
>

Re: [Comm] Bridging firewall

[Dmytro O. Redchuk]

On Thu, Sep 16, 2004 at 01:46:17PM +0500, Nizamov Shavkat wrote:
> http://lists.altlinux.ru/pipermail/community/2003-September/098912.html
Кстати, ожидается ли ebtables в след. Мастере?

-- 
 Dmytro O. Redchuk

Re: [Comm] Bridging firewall

[Michael Shigorin]

On Fri, Sep 17, 2004 at 09:56:34AM +0300, Dmytro O. Redchuk wrote:
> > http://lists.altlinux.ru/pipermail/community/2003-September/098912.html
> Кстати, ожидается ли ebtables в след. Мастере?

В 2.4, насколько понимаю, нет.

Надо бы допинать Колю Федчика завернуть их Правильным Образом :-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Bridging firewall

[Dmytro O. Redchuk]

On Fri, Sep 17, 2004 at 12:19:41PM +0300, Michael Shigorin wrote:
> On Fri, Sep 17, 2004 at 09:56:34AM +0300, Dmytro O. Redchuk wrote:
> > > http://lists.altlinux.ru/pipermail/community/2003-September/098912.html
> > Кстати, ожидается ли ebtables в след. Мастере?
> 
> В 2.4, насколько понимаю, нет.
Так ведь модули уже есть в 2.6...

Почему не вставить в Мастер и утилитку?-)

> 
> Надо бы допинать Колю Федчика завернуть их Правильным Образом :-)
Хотца...

> 
> -- 
>  ---- WBR, Michael Shigorin <mike@altlinux.ru>
>   ------ Linux.Kiev http://www.linux.kiev.ua/
> _______________________________________________
> Community mailing list
> Community@altlinux.ru
> https://lists.altlinux.ru/mailman/listinfo/community

-- 
 Dmytro O. Redchuk

Re: [Comm] Bridging firewall

[Michael Shigorin]

On Fri, Sep 17, 2004 at 02:03:11PM +0300, Dmytro O. Redchuk wrote:
> > > > http://lists.altlinux.ru/pipermail/community/2003-September/098912.html
> > > Кстати, ожидается ли ebtables в след. Мастере?
> > В 2.4, насколько понимаю, нет.
> Так ведь модули уже есть в 2.6...
> Почему не вставить в Мастер и утилитку?-)

Судя по письму shrek@ рядом -- окончательно поздно.

В общем, да здравствуют контрибы, осталось их правильно
приготовить. :-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Bridging firewall

[Денис Смирнов]

On Fri, Sep 17, 2004 at 12:19:41PM +0300, Michael Shigorin wrote:

 MS> В 2.4, насколько понимаю, нет.
 MS> Надо бы допинать Колю Федчика завернуть их Правильным Образом :-)

Я всё думаю -- а может отдельные патчи для iptables (те, которые не ломают
совместимость) всё-таки накладывать? Очень уж без того же H.323 NAT и
прочих подобных рюшечек неуютно.

-- 
С уважением, Денис

http://freesource.info

Re: [Comm] Bridging firewall

[Michael Shigorin]

On Sat, Sep 18, 2004 at 09:03:12PM +0400, Денис Смирнов wrote:
> Я всё думаю -- а может отдельные патчи для iptables (те,
> которые не ломают совместимость) всё-таки накладывать?

mailto:devel-kernel@ ?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Bridging firewall

[РЦОК-Ростов]

Здравствуйте!

Eugene Prokopiev пишет:

> для того, чтоб устраивать firewall (а также что-то считать) на бридже, 
> нужен ebtables (ebtables.sf.net). Я его даже собирал для ядра ALM 2.2 
> около года назад - поищите мои письма на эту тему в архиве рассылки

Подскажите, пожалуйста, каковы преимущества работы шлюза в качестве 
бриджа? Верно ли я понимаю, что бридж интересен тем, что при наличии 
реальных ip-адресов он может работать "прозрачно" для сети, т.е. - даже 
не иметь ip-адреса на интерфейсе в сети откуда надо передавать пакеты? 
(Интерфейс переводится в promisc mode и пакеты предназначенные для 
другой сети сразу попадают на другой интерфейс). Но какой в этом смысл, 
если сейчас практически все испльзуют свитчи? И чем этот вариант лучше 
следующего:
  echo "1" > /proc/sys/net/ipv4/ip_forward
  iptables -t nat -A POSTROUTING -s xxx.xxx.x.x/xx -o ppp0 -j MASQUERADE

В простейшем виде - и уже работает. (Осталась настроить iptables).

Меня интересует при помощи чего лучше настроить шлюз для маленького 
офиса с маскарадингом и файрволом?

Варианты:
1. Бридж (с патчем ядра);
2. Сквид;
3. Маскарадинг (вариант описанный мной выше).
4. Что-то ещё?

Google не помог найти статейки сравнивающей разные способы создания 
роутера/шлюза/файрвола в одном лице. Я находил лишь статьи по настройке 
какого-то одного из вышеперечисленных методов.

Буду очень благодарен. (Даже, и особенно, за полезные ссылки по теме).

-- 
С уважением,  Виктор                        sibvaleo {at} aaanet.ru

Re: [Comm] Bridging firewall

[Nizamov Shavkat]

> Подскажите, пожалуйста, каковы преимущества работы шлюза в качестве
> бриджа? Верно ли я понимаю, что бридж интересен тем, что при наличии
> реальных ip-адресов он может работать "прозрачно" для сети, т.е. - даже
> не иметь ip-адреса на интерфейсе в сети откуда надо передавать пакеты?
> (Интерфейс переводится в promisc mode и пакеты предназначенные для
> другой сети сразу попадают на другой интерфейс).

да, так

> Но какой в этом смысл,
> если сейчас практически все испльзуют свитчи? И чем этот вариант лучше
> следующего:
>   echo "1" > /proc/sys/net/ipv4/ip_forward
>   iptables -t nat -A POSTROUTING -s xxx.xxx.x.x/xx -o ppp0 -j MASQUERADE
>
> В простейшем виде - и уже работает. (Осталась настроить iptables).

ну во первых у вас будет всего одна логическая сеть (при двух физических),
во вторых работать будет не только ip. бридж изначально был предназначен
только для расширения сети.

Re: [Comm] Bridging firewall

[Eugene Prokopiev]

РЦОК-Ростов пишет:
> Здравствуйте!

Здравствуй, земляк :)

> Eugene Prokopiev пишет:
> 
>> для того, чтоб устраивать firewall (а также что-то считать) на бридже, 
>> нужен ebtables (ebtables.sf.net). Я его даже собирал для ядра ALM 2.2 
>> около года назад - поищите мои письма на эту тему в архиве рассылки
> 
> 
> Подскажите, пожалуйста, каковы преимущества работы шлюза в качестве 
> бриджа? 

Бридж нужен для соединения разных сетевых сегментов в один (например, 
чтоб в нем мог работать NetBEUI или для аналогичных извращений). 
Соответственно, firewall на бридже нужен, чтобы пущать или не пущать 
пакеты по некоторым критериям из одной части уже единого сегмента в другую.

Мне он был нужен, чтобы пускать только некоторые машины из одной части 
сегмента только к некоторым Netware-серверам, но не пускать NetBIOS over 
IPX.

Т.е. шлюз для маленького офиса с маскарадингом и файрволом бридж 
совершенно не пригоден.

В качестве полезной ссылки по управлению небольшой сетью могу 
порекомендовать собственную статью - 
http://www.linux-os.ru/Members/john/NM :)

-- 
С уважением, Прокопьев Евгений

[Comm] Re: Bridging firewall

[Денис Смирнов]

On Thu, Sep 16, 2004 at 05:19:36PM +0400, РЦОК-Ростов wrote:
 РР>  echo "1" > /proc/sys/net/ipv4/ip_forward
 РР>  iptables -t nat -A POSTROUTING -s xxx.xxx.x.x/xx -o ppp0 -j MASQUERADE
 РР> В простейшем виде - и уже работает. (Осталась настроить iptables).

А pptp поверх NAT уже работает? А H.323? Нет? Лесом.

-- 
С уважением, Денис

http://freesource.info

Re: [Comm] Re: Bridging firewall

[Guest007]

В сообщении от Пятница 17 Сентябрь 2004 00:28 Денис Смирнов написал(a):
> On Thu, Sep 16, 2004 at 05:19:36PM +0400, РЦОК-Ростов wrote:
>  РР>  echo "1" > /proc/sys/net/ipv4/ip_forward
>  РР>  iptables -t nat -A POSTROUTING -s xxx.xxx.x.x/xx -o ppp0 -j
> MASQUERADE РР> В простейшем виде - и уже работает. (Осталась настроить
> iptables).
>
> А pptp поверх NAT уже работает? А H.323? Нет? Лесом.

Лес у меня вокруг :-)
А ViewStationEX вполне работает из-за NATа  именно по .323
Особых проблем не было.

-- 
WBR Guest007
JID: guest007@jabber.ru

[Comm] Re: Bridging firewall

[Denis Smirnov]

On Fri, Sep 17, 2004 at 09:46:14AM +0400, Guest007 wrote:

 G> Лес у меня вокруг :-
 G> А ViewStationEX вполне работает из-за NATа  именно по .323
 G> Особых проблем не было.

Я что-то проспал, и штатное ядор в Сизифе нынче умеет H.323 натить? 

-- 
С уважением, Денис

http://freesource.info

Re: [Comm] Re: Bridging firewall

[Guest007]

В сообщении от Пятница 17 Сентябрь 2004 13:17 Denis Smirnov написал(a):
> On Fri, Sep 17, 2004 at 09:46:14AM +0400, Guest007 wrote:
>
>  G> Лес у меня вокруг :-
>  G> А ViewStationEX вполне работает из-за NATа  именно по .323
>  G> Особых проблем не было.
>
> Я что-то проспал, и штатное ядор в Сизифе нынче умеет H.323 натить?
Денис!
Я -- человек тёмный (не в смысле Дарта Вейдера :-) ) и про то, что надо учить 
ядро этому -- не знал. Вообще-то я думал, что мы говорим о iptables. Я не 
пользовал ip для НАТа (только HTB в попытке сделать трафик-шейпер, но это к 
теме не относиться)
А в моей реальной ситуации всё было просто: мы ходим в Большой Мир через 
breezaccess и оконечное устройство, хотя и имеет ethernet, но работает только 
с одним МАК-адресом. Вот когда кроме роутера потребовалось дать реальный IP 
еще одному устройству (именно для .323), тогда я и выкинул ея наружу. 

Так что не ошибусь, если скажу, что, таки да, .323 через НАТ средствами 
iptables ходит без вопросов.


-- 
WBR Guest007
JID: guest007@jabber.ru

[Comm] Re: Bridging firewall

[Denis Smirnov]

On Fri, Sep 17, 2004 at 01:57:36PM +0400, Guest007 wrote:

 G> А в моей реальной ситуации всё было просто: мы ходим в Большой Мир через 
 G> breezaccess и оконечное устройство, хотя и имеет ethernet, но работает только 
 G> с одним МАК-адресом. Вот когда кроме роутера потребовалось дать реальный IP 
 G> еще одному устройству (именно для .323), тогда я и выкинул ея наружу. 
 G> Так что не ошибусь, если скажу, что, таки да, .323 через НАТ средствами 
 G> iptables ходит без вопросов.

Показывай настройки, версии и т.д. В общем делись "как это у тебя
получилось", ибо мне на днях как раз придётся страдать этим же
удовольствием.

-- 
С уважением, Денис

http://freesource.info

Re: [Comm] Re: Bridging firewall

[Guest007]

В сообщении от Суббота 18 Сентябрь 2004 20:57 Denis Smirnov написал(a):
> On Fri, Sep 17, 2004 at 01:57:36PM +0400, Guest007 wrote:
>
>  G> А в моей реальной ситуации всё было просто: мы ходим в Большой Мир
> через G> breezaccess и оконечное устройство, хотя и имеет ethernet, но
> работает только G> с одним МАК-адресом. Вот когда кроме роутера
> потребовалось дать реальный IP G> еще одному устройству (именно для .323),
> тогда я и выкинул ея наружу. G> Так что не ошибусь, если скажу, что, таки
> да, .323 через НАТ средствами G> iptables ходит без вопросов.
>
> Показывай настройки, версии и т.д. В общем делись "как это у тебя
> получилось", ибо мне на днях как раз придётся страдать этим же
> удовольствием.
Да, в общем-то, делиться и нечем. Почитал 
http://gazette.linux.ru.net/rus/ articles/iptables-tutorial.html  
взял тамошний пример rc.DMZ.firewall.txt (что-то типа этого). Только у меня 
вместо ДНС сервера -- ViewStation, соответственные порты и открыты (1720 и 
3230-3231 по TCP и 3230-3247 по UDP) Какие порты -- описано на сайте 
Поликома. В настройках ViewStation указал, что оно за НАТом.
Так что, по сути, всё решилось простым копи-пастом.


-- 
WBR Guest007
JID: guest007@jabber.ru

[Comm] Re: Bridging firewall

[Guest007]

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]

В сообщении от Суббота 18 Сентябрь 2004 20:57 Denis Smirnov написал(a):
> On Fri, Sep 17, 2004 at 01:57:36PM +0400, Guest007 wrote:
>
>  G> А в моей реальной ситуации всё было просто: мы ходим в Большой Мир
> через G> breezaccess и оконечное устройство, хотя и имеет ethernet, но
> работает только G> с одним МАК-адресом. Вот когда кроме роутера
> потребовалось дать реальный IP G> еще одному устройству (именно для .323),
> тогда я и выкинул ея наружу. G> Так что не ошибусь, если скажу, что, таки
> да, .323 через НАТ средствами G> iptables ходит без вопросов.
>
> Показывай настройки, версии и т.д. В общем делись "как это у тебя
> получилось", ибо мне на днях как раз придётся страдать этим же
> удовольствием.
Я там в конференцию ответил, но у меня есть еще пара вопросов, и, если ты 
сможешь, помогои, пожалуйста. 

Свой скрипт я приложил. Глянь, пожалуйста, что я там недоработал? 

1) Из локальной сети .323 устройство не пингуется. Почему? (вообще ничего не 
пингуется, кроме 192.168.6.100, значит ICMP пакеты не проходят цепочки, а 
где-то дропаются) Что я забыл прописать? 
2) по 80 порту могу зайти, пользуя локальный адрес (192.168.16.4), а НетМитинг 
сделать не могу. Значит из одного сегмента в другой не ходят УДП пакеты. Что 
еще подкрутить?

Заранее благодарен.

-- 
WBR Guest007
JID: guest007@jabber.ru

[-- Attachment #2: rc.DMZ.firewall.txt --]
[-- Type: text/plain, Size: 9310 bytes --]

#!/bin/sh
#
# rc.DMZ.firewall - DMZ IP Firewall script for Linux 2.4.x and iptables
#
# Copyright (C) 2001  Oskar Andreasson <bluefluxATkoffeinDOTnet>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; version 2 of the License.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program or from the site that you downloaded it
# from; if not, write to the Free Software Foundation, Inc., 59 Temple
# Place, Suite 330, Boston, MA  02111-1307   USA
#

###########################################################################
#
# 1. Configuration options.
#

#
# 1.1 Internet Configuration.
#

INET_IP="194.22x.xxx.1" #will be i-face (real ip)
VS_IP="194.22x.xxx.2" #will be viewstation (alias)
INET_IFACE="eth0"
INET_BROADCAST="194.22x.xxx.255"
#
# 1.1.1 DHCP
#

#
# 1.1.2 PPPoE
#

#
# 1.2 Local Area Network configuration.
#
# your LAN's IP range and localhost IP. /24 means to only use the first 24
# bits of the 32 bit IP address. the same as netmask 255.255.255.0
#

LAN_IP="192.168.6.100"
LAN_IFACE="eth1"

#
# 1.3 DMZ Configuration.
#

DMZ_VS_IP="192.168.16.4"
DMZ_IP="192.168.16.1"
DMZ_IFACE="eth2"

#
# 1.4 Localhost Configuration.
#

LO_IFACE="lo"
LO_IP="127.0.0.1"

#
# 1.5 IPTables Configuration.
#

IPTABLES="/sbin/iptables"

#
# 1.6 Other Configuration.
#

###########################################################################
#
# 2. Module loading.
#

#
# Needed to initially load modules
#
/sbin/depmod -a



#
# 2.1 Required modules
#

/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe iptable_filter
/sbin/modprobe iptable_mangle
/sbin/modprobe iptable_nat
/sbin/modprobe ipt_LOG
/sbin/modprobe ipt_limit
/sbin/modprobe ipt_state

#
# 2.2 Non-Required modules
#

#/sbin/modprobe ipt_owner
#/sbin/modprobe ipt_REJECT
#/sbin/modprobe ipt_MASQUERADE
#/sbin/modprobe ip_conntrack_ftp
#/sbin/modprobe ip_conntrack_irc
#/sbin/modprobe ip_nat_ftp
#/sbin/modprobe ip_nat_irc

###########################################################################
#
# 3. /proc set up.
#

#
# 3.1 Required proc configuration
#

echo "1" > /proc/sys/net/ipv4/ip_forward

#
# 3.2 Non-Required proc configuration
#

#echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
#echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr

###########################################################################
#
# 4. rules set up.
#

######
# 4.1 Filter table
#

#
# 4.1.1 Set policies
#

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP

#
# 4.1.2 Create userspecified chains
#

#
# Create chain for bad tcp packets
#

$IPTABLES -N bad_tcp_packets

#
# Create separate chains for ICMP, TCP and UDP to traverse
#

$IPTABLES -N allowed
$IPTABLES -N icmp_packets

#
# 4.1.3 Create content in userspecified chains
#

#
# bad_tcp_packets chain
#

$IPTABLES -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK \
-m state --state NEW -j REJECT --reject-with tcp-reset
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \
--log-prefix "New not syn:"
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

#
# allowed chain
#

$IPTABLES -A allowed -p TCP --syn -j ACCEPT
$IPTABLES -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A allowed -p TCP -j DROP

#
# ICMP rules
#

# Changed rules totally
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT
$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT

#
# 4.1.4 INPUT chain
#

#
# Bad TCP packets we don't want
#

$IPTABLES -A INPUT -p tcp -j bad_tcp_packets

#
# Packets from the Internet to this box
#

$IPTABLES -A INPUT -p ICMP -i $INET_IFACE -j icmp_packets
$IPTABLES -A INPUT -p TCP -s 192.168.6.77 --destination-port 22 \
-m state --state NEW -j ACCEPT
#
# Packets from LAN, DMZ or LOCALHOST
#

#
# From DMZ Interface to DMZ firewall IP
#

$IPTABLES -A INPUT -p ALL -i $DMZ_IFACE -d $DMZ_IP -j ACCEPT

#
# From LAN Interface to LAN firewall IP
#

$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -d $LAN_IP -j ACCEPT

#
# From Localhost interface to Localhost IP's
#

$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LO_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LAN_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $DMZ_IP -j ACCEPT
$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $INET_IP -j ACCEPT

#
# Special rule for DHCP requests from LAN, which are not caught properly
# otherwise.
#

#$IPTABLES -A INPUT -p UDP -i $LAN_IFACE --dport 67 --sport 68 -j ACCEPT

#$IPTABLES -A INPUT -p TCP -i $LAN_IFACE -j ACCEPT

#
# All established and related packets incoming from the internet to the
# firewall
#

$IPTABLES -A INPUT -p ALL -d $INET_IP -m state --state ESTABLISHED,RELATED \
-j ACCEPT

#
# In Microsoft Networks you will be swamped by broadcasts. These lines
# will prevent them from showing up in the logs.
#

#$IPTABLES -A INPUT -p UDP -i $INET_IFACE -d $INET_BROADCAST \
#--destination-port 135:139 -j DROP

#
# If we get DHCP requests from the Outside of our network, our logs will
# be swamped as well. This rule will block them from getting logged.
#

#$IPTABLES -A INPUT -p UDP -i $INET_IFACE -d 255.255.255.255 \
#--destination-port 67:68 -j DROP

#
# If you have a Microsoft Network on the outside of your firewall, you may
# also get flooded by Multicasts. We drop them so we do not get flooded by
# logs
#

#$IPTABLES -A INPUT -i $INET_IFACE -d 224.0.0.0/8 -j DROP

#
# Log weird packets that don't match the above.
#

$IPTABLES -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT INPUT packet died: "

#
# 4.1.5 FORWARD chain
#

#
# Bad TCP packets we don't want
#

$IPTABLES -A FORWARD -p tcp -j bad_tcp_packets


#
# DMZ section
#
# General rules
#

$IPTABLES -A FORWARD -i $DMZ_IFACE -o $INET_IFACE -j ACCEPT
$IPTABLES -A FORWARD -i $INET_IFACE -o $DMZ_IFACE -m state \
--state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $LAN_IFACE -o $DMZ_IFACE -j ACCEPT
$IPTABLES -A FORWARD -i $DMZ_IFACE -o $LAN_IFACE -m state \
--state ESTABLISHED,RELATED -j ACCEPT

#
# HTTP server
#

$IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_VS_IP \
--dport 80 -j allowed

#
# ViewStation
#
$IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_VS_IP \
--dport 1720 -j allowed
$IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_VS_IP \
--dport 1503 -j allowed
# б ЛН╦Л ЯКСВЮЕ ЩРНР ОНПР МЕ ЪБКЪЕРЯЪ МЕНАУНДХЛНЯРЭЧ.... 
# Guest007


$IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_VS_IP \
--dport 3230:3235 -j allowed

$IPTABLES -A FORWARD -p UDP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_VS_IP \
--dport 3230:3247 -j ACCEPT


$IPTABLES -A FORWARD -p ICMP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_VS_IP \
-j icmp_packets

#$IPTABLES -A FORWARD -p ICMP -i $LAN_IFACE -o $DMZ_IFACE -d $DMZ_VS_IP \
#-j icmp_packets

#
# LAN section
#

$IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

#
# Log weird packets that don't match the above.
#

$IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT FORWARD packet died: "

#
# 4.1.6 OUTPUT chain
#

#
# Bad TCP packets we don't want.
#

$IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets

#
# Special OUTPUT rules to decide which IP's to allow.
#

$IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT
$IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT

#
# Log weird packets that don't match the above.
#

$IPTABLES -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
--log-level DEBUG --log-prefix "IPT OUTPUT packet died: "

######
# 4.2 nat table
#

#
# 4.2.1 Set policies
#

#
# 4.2.2 Create user specified chains
#

#
# 4.2.3 Create content in user specified chains
#

#
# 4.2.4 PREROUTING chain
#

$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $VS_IP --dport 80 \
-j DNAT --to-destination $DMZ_VS_IP

$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $VS_IP --dport 1503 \
-j DNAT --to-destination $DMZ_VS_IP
$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $VS_IP --dport 1720 \
-j DNAT --to-destination $DMZ_VS_IP

$IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $VS_IP --dport 3230:3235 \
-j DNAT --to-destination $DMZ_VS_IP

$IPTABLES -t nat -A PREROUTING -p UDP -i $INET_IFACE -d $VS_IP --dport 3230:3247 \
-j DNAT --to-destination $DMZ_VS_IP

#
# 4.2.5 POSTROUTING chain
#

#
# Enable simple IP Forwarding and Network Address Translation
#

$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP

#
# 4.2.6 OUTPUT chain
#

######
# 4.3 mangle table
#

#
# 4.3.1 Set policies
#

#
# 4.3.2 Create user specified chains
#

#
# 4.3.3 Create content in user specified chains
#

#
# 4.3.4 PREROUTING chain
#

#
# 4.3.5 INPUT chain
#

#
# 4.3.6 FORWARD chain
#

#
# 4.3.7 OUTPUT chain
#

#
# 4.3.8 POSTROUTING chain
#

Re: [Comm] Re: Bridging firewall

[Guest007]

В сообщении от Вторник 21 Сентябрь 2004 10:31 Guest007 написал(a):

> пакеты. Что еще подкрутить?
>
> Заранее благодарен.

Прошу пардону, промазал слегка :-)


-- 
WBR Guest007
JID: guest007@jabber.ru

[Comm] ALT Linux 2.3 SOHO Server

[max]

Кто-нть знает что за  Traffic Accounting (Учёт трафика) включён в 
дистрибутив ALT Linux 2.3 SOHO Server, сертифицирован ли он?