Возможно будет полезно "укращающим" IPFW. ;-)

Сегодня получил письмо следующего содержания:

Наткнулся тут на форуме на твой конфиг rc.firewall, и возникли
вопросы:
>Тут есть одно и очень простое правило: располагать правила для IPFW в следующем порядке:
>1. сначала идут инструкции deny и reject (если есть)
>2. потом divert
>3. потом allow на внутреннюю сетку(и)
>4. потом allow все остальное
>5. потом deny все, что осталось.

Разве divert не должен идти самым первым правилом ipfw?
По идее, сколько я юзал ipfw и нат, divert, потом (если есть) fwd, а
потом уже deny/reject, allow и deny на остальное...

Сначала ответил отправителю по почте, но ответ не дошел и письмо вернулось.

По этому ответ размещаю здесь.

Примечания:
1. "сверхопытнейшим" сисадминам с нереализованным до конца творческим потенциалом читать сие не рекомендуется, чтобы не испортился сон;
2. я не считаю эту стратегию "абсолютно" правильной, но "достаточно хорошей" для домашней сетки назвать-таки отваживаюсь.

-----------

По существу:
divert совершенно не обязательно распологать первым правилом.
Даже более того, обычно, распологать его там вредно.

Дело в том, что не все пакеты, которые попадают на внешний интерфейс твоего роутера предназначены для внутренней сети, следовательно, необходимо отправлять в divert-socket, т.е. на растерзание natd, только те пакеты, которые внутренней сети предназначены.
Соответственно, пакеты, не предназначенные для внутренней сети отправлять в divert-socket смысла не имеет.

По этому, получается, что первым правилом распологать divert вредно.

В схеме

1. сначала идут инструкции deny и reject (если есть)
2. потом divert
3. потом allow на внутреннюю сетку(и)
4. потом allow все остальное
5. потом deny все, что осталось.

предложена упрощенная стратегия написания правил IPFW.

На самом деле, эффективнее, с точки зрения моего представления о безопасности, распологать правила так:

1. сначала идут инструкции deny и reject (если есть), чтобы погасить вредный трафик
2. потом count для внешнего трафика, если интересна полная статистика
3. потом forward, если нужен
4. потом allow на сервисы, доступные извне
5. потом divert
6. потом count для трафика в разрезе внутренних хостов, если интересна
такая статистика
7. потом allow на внутреннюю сетку(и), либо хосты, если ты параноик, как я;)
8. потом allow для разрешенных с роутера соединений
9. потом log deny все, что осталось в разрезе всего, что интересно.

ответил на твой вопрос?

в заключении хочу добавить, что FreeBSD -- конструктор Lego, по этому как бы ты не собрал -- работать будет, остается только вопрос -- на сколько хорошо и надежно...

-----------

• FreeBSD: порядок размещения правил для IPFW,Дмитрий, 11:10 , 14-Мрт-03
  • FreeBSD: порядок размещения правил для IPFW,proff, 11:48 , 14-Мрт-03

ОК, полностью согласен, но в каком порядке размещать TCP|UDP|ICMP?
Есть предложение по TCP:
1. разрешаем установку нужных соединений:
allow tcp from откуда-то to куда-то setup
...
2. разрещаем пропускать все установившиеся соединения:
allow tcp from any to any established
3. Рубим все остальное, с занесением в протокол:  
deny log tcp from any to any

Есть ли у кого-нить опыт по установке правил keep-state, check-state?

>ОК, полностью согласен, но в каком порядке размещать TCP|UDP|ICMP?

на мой взгляд, эффективнее правила размещать по уменьшению вероятности трафика внутри каждого раздела. т.е. сначала идут правила, обрабатывающие самый вероятный трафик, и так далее, до правил с наименьшей вероятностью.

>Есть предложение по TCP:
>1. разрешаем установку нужных соединений:
>allow tcp from откуда-то to куда-то setup
>...
>2. разрещаем пропускать все установившиеся соединения:
>allow tcp from any to any established

хорошая, на мой взгляд, идея.
только с одной оговоркой: в разделе deny необходимы правила, блокирующие трафик с "неординарными" флажками.

>3. Рубим все остальное, с занесением в протокол:
>deny log tcp from any to any

верно, но кому-то может потребоваться и по портам разнести. чтобы было  лог удобнее разбирать.

>
>Есть ли у кого-нить опыт по установке правил keep-state, check-state?

у меня лично такого опыта нет.
использую keep-state только в одном месте для трафика утилиты traceroute в соответствие с оговорками, данными в стандартном /etc/rc.firewall и man'e по ipfw.