Re: Генератор правил файрвола
On Thu, Jun 05, 2008 at 11:26:07PM +0400, Artem Chuprina wrote:
> Eugene Berdnikov -> debian-russian@lists.debian.org @ Thu, 5 Jun 2008 21:50:52 +0400:
>
> >> А если у кого действительно сложные правила файрвола, то ему вынужденно
> >> придется пользоваться промежуточным языком.
>
> EB> Можно пример сложного правила?
>
> Любой набо правил, задействующий limit или TARPIT, если его надо
> одинаково применить к нескольким интерфейсам или тем более - к
> нескольким адресам и/или портам по отдельности.
Генетика ipchains даёт возможность строить довольно сложные переходы
между цепочками, в том числе включать в цепочки блоки с общими
правилами. Например, по интерфейсам можно объединить так:
iptables -N fw:int
iptables -N fw:dmz
iptables -N fw:ext
iptables -N fw::limit
...
iptables -A FORWARD -i int -j fw:int
iptables -A FORWARD -i dmz -j fw:dmz
iptables -A FORWARD -i ext -j fw:ext
...
iptables -A fw:int <какие-то условия> -j fw::limit
iptables -A fw:dmz <какие-то условия> -j fw::limit
iptables -A fw:ext <какие-то условия> -j fw::limit
...
iptables -A fw::limit <какое-то групповое ограничение лимитов>
...
Спасаем. Вуаля! Особых резонов писать скрипты я здесь не нахожу.
Другое дело, если интерфейсы динамические, например, vpn-сервер,
хотя в ряде случаев это решается шаблонами вида ppp+, tun+.
> И то же самое - с
> многоствольным роутингом, хотя это уже не файрвол.
Там где многостволка, так и файрвол обычно...
Хотя маршрутами да, приходится в up/down рулить.
> Т.е. когда на каждое содержательно одно правило приходится несколько
> строк iptables или ip, и это более чем в одном экземпляре.
>
> EB> Зато я могу сказать, чем плох любой скриптовый язык для fw: тем,
> EB> что невозможно текущую конфигурацию спасти в терминах этого языка,
>
> Это да. trade-off. Между "уметь спасти" и "уметь прочесть". Я в этой
> сделке "уметь прочесть" полагаю краевым условием. То бишь если я в
> сохраненном один хрен запутаюсь и нужного не найду, то уметь спасти уже
> не требуется. Все равно потом с нуля писать.
В качестве примера -- снимок с натуры:
# iptables -nvL INPUT
Chain INPUT (policy DROP 40993 packets, 3333K bytes)
pkts bytes target prot opt in out source destination
866K 5914M in:loop 0 -- lo * 0.0.0.0/0 0.0.0.0/0
20M 24G in:lmtp tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:24
91M 6651M in:ssh tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
45M 6119M in:imap tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
10M 1700M in:imaps tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
5105K 217M in:pop3 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
29460 1545K in:pop3s tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:995
2388 326K in:dns udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 in:dns tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
803 86564 in:seive tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2000
2981 346K in:icmp icmp -- * * 0.0.0.0/0 0.0.0.0/0
902 54120 in:ident tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113
1293 143K in:trace udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:33434:33534
51M 14G in:acct 0 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
11M 1369M in:alarm 0 -- * * 0.0.0.0/0 0.0.0.0/0
Вряд ли здесь можно запутаться. Конечно, боевой файрвол сложнее
почтового сервачка, но принцип тот же. У меня как-то сложилось FORWARD
во всех таблицах первым делом делить по интерфейсам, получается сверху
совсем короткая линейка. Возможно, кому-то будет удобнее другое деление.
Конечно, "уметь прочесть" из running такой подход требует обязательно.
--
Eugene Berdnikov
Reply to: