Re: Генератор правил файрвола
Eugene Berdnikov -> debian-russian@lists.debian.org @ Fri, 6 Jun 2008 18:35:59 +0400:
>> >> А если у кого действительно сложные правила файрвола, то ему вынужденно
>> >> придется пользоваться промежуточным языком.
>>
>> EB> Можно пример сложного правила?
>>
>> Любой набо правил, задействующий limit или TARPIT, если его надо
>> одинаково применить к нескольким интерфейсам или тем более - к
>> нескольким адресам и/или портам по отдельности.
EB> Генетика ipchains даёт возможность строить довольно сложные переходы
EB> между цепочками, в том числе включать в цепочки блоки с общими
EB> правилами. Например, по интерфейсам можно объединить так:
EB> iptables -N fw:int
EB> iptables -N fw:dmz
EB> iptables -N fw:ext
EB> iptables -N fw::limit
EB> ...
EB> iptables -A FORWARD -i int -j fw:int
EB> iptables -A FORWARD -i dmz -j fw:dmz
EB> iptables -A FORWARD -i ext -j fw:ext
EB> ...
EB> iptables -A fw:int <какие-то условия> -j fw::limit
EB> iptables -A fw:dmz <какие-то условия> -j fw::limit
EB> iptables -A fw:ext <какие-то условия> -j fw::limit
EB> ...
EB> iptables -A fw::limit <какое-то групповое ограничение лимитов>
EB> ...
А это нам не свернет все лимиты в _одну_ группу? Насколько я понимаю
принцип работы линуксового файрвола, произойдет именно это - лимит будет
один на все пакеты, прошедшие по этой цепочке. А мне надо _несколько
одинаковых_. Местами даже не одинаковых - параметры limit для разных
пакетов различны.
EB> Другое дело, если интерфейсы динамические, например, vpn-сервер,
EB> хотя в ряде случаев это решается шаблонами вида ppp+, tun+.
А вот тут как раз у меня в норме статическая настройка файрвола даже на
динамических адресах. Ага, привязываемся к имени, а то и к типу
интерфейса. Собственно, динамических правил iptables у меня нет как
класса. Ни на машине, подключенной к стриму, который раз в сутки
сбрасывает соединение, ни на сервере с двумя аплинками.
>> Т.е. когда на каждое содержательно одно правило приходится несколько
>> строк iptables или ip, и это более чем в одном экземпляре.
>>
>> EB> Зато я могу сказать, чем плох любой скриптовый язык для fw: тем,
>> EB> что невозможно текущую конфигурацию спасти в терминах этого языка,
>>
>> Это да. trade-off. Между "уметь спасти" и "уметь прочесть". Я в этой
>> сделке "уметь прочесть" полагаю краевым условием. То бишь если я в
>> сохраненном один хрен запутаюсь и нужного не найду, то уметь спасти уже
>> не требуется. Все равно потом с нуля писать.
EB> В качестве примера -- снимок с натуры:
EB> # iptables -nvL INPUT
EB> Chain INPUT (policy DROP 40993 packets, 3333K bytes)
EB> pkts bytes target prot opt in out source destination
EB> 866K 5914M in:loop 0 -- lo * 0.0.0.0/0 0.0.0.0/0
EB> 20M 24G in:lmtp tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:24
EB> 91M 6651M in:ssh tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
EB> 45M 6119M in:imap tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
EB> 10M 1700M in:imaps tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
EB> 5105K 217M in:pop3 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
EB> 29460 1545K in:pop3s tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:995
EB> 2388 326K in:dns udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
EB> 0 0 in:dns tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
EB> 803 86564 in:seive tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2000
EB> 2981 346K in:icmp icmp -- * * 0.0.0.0/0 0.0.0.0/0
EB> 902 54120 in:ident tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113
EB> 1293 143K in:trace udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:33434:33534
EB> 51M 14G in:acct 0 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
EB> 11M 1369M in:alarm 0 -- * * 0.0.0.0/0 0.0.0.0/0
EB>
EB> Вряд ли здесь можно запутаться. Конечно, боевой файрвол сложнее
EB> почтового сервачка, но принцип тот же. У меня как-то сложилось FORWARD
EB> во всех таблицах первым делом делить по интерфейсам, получается сверху
EB> совсем короткая линейка. Возможно, кому-то будет удобнее другое деление.
В основном я делаю примерно так же, только не столь подробно делю
цепочки по сервисам. Более того, на рабочем файрволе (7 VLAN'ов, считая
DMZ, и два ствола наружу) подобное деление сделало бы вывод абсолютно
нечитаемым за время, сравнимое со временем жизни админа. Там и
максимально компактифицированная запись-то нечитаема просто по размеру и
невозможности запомнить, какой адрес какой подсети или машине в DMZ
соответствует. А вот скрипт, который генерирует набор правил, вполне
читаем.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
-- Phil Greenspun
"Including Common Lisp."
-- Robert Morris
Reply to: