>Простите, а вы заметку https://www.opennet.ru/opennews/art.shtml?num=16080 читали? Там
>схема описана. Так много правил, которые вы перечислили - не требуется.

Эта уникальная заметка вышла слишком поздно для меня (20 мая 2008 - чуть больше недели назад). Мне это нужно было знать на год раньше.

Для сравнения заметка https://www.opennet.ru/docs/RUS/iptables/ была добавлена на OpenNet 01.08.2004. Сравните качество и полноту описания. Посмотрите на рисунок https://www.opennet.ru/docs/RUS/iptables/misc/iptables-tutori...

Схем прохождения пакетов сразу ясна. Каждый эллипс соответствует одной цепочке правил.

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

Комментарии и имена переменных зависят только от сознательности писавшего. Имена могут быть ничего не говорящими типа "a", "uie", "zpt", комментарии могут вообще отсутствовать, могут быть ничего незначащами вроде даты добавления правила и логина добавлявшего.

iptables попросту заставляет разбить огромный фаервол на цепочки, каждую из которых можно анализировать отдельно!

В отличие от исходника, листинг работающего фаервола можно вывести со счётчиками попаданий в правило. Тут сразу будет видно: uptime сервера 3 месяца, 32 правила за это время не использовались ни разу, может удалить? Если же предпочесть скрипт, по которому был сгенерирован листинг, то там нужно будет ещё и искать соответствие правил.

> (который никто не мешает сохранять/загружать аналогично iptables-save). Кроме того, при больших количествах правил народ точно так же применяет скрипты (с переменными, ага) и для iptables.

Вот это (скрипты) они зря делают, потому что фаервол в итоге после нескольких десятков правок разными админами становится попросту нечитаемым. Тут всё равно легче проанализировать реальный листинг, нежели эту запутанную писанину.

> Прочитатйе еще раз заметку со схемой прохождения пакетов. Все вышеперечисленное (кроме модуля FTP, он только в состае ната идет) есть и в ipfw.

Пусть нет ната, а нужно сделать закрытый по-умолчанию фаервол. Как быть в ipfw? Искусственно вводить сюда нат?

> А вот жесткость iptables, что в таблицах, что в формате правила,  начинает мешать в сложных случаях. Попробуйте, например, в одном правиле iptables указать несколько src, аналогично OR-блокам ipfw...

Проверять всё кроме IP-адресов. В случае совпадения прыгать на отдельную специально созданную цепочку, где проверять только IP-адреса. При совпадении адреса - применять правило.

В iptables можно создавать СВОИ цепочки правил. Если взять критерий отбора не по списку IP, а по списку номеров портов - есть модуль multiport.

> Узнали бы, скажем, что на фремах серверов используют сборочный тазик, а вовсе не компилируют на каждой машине, без танцев с бубном. И т.д.

Ферма - это хорошо. Но по сути ферма - это один и тот же клонированный сервер. Что делать в случае десяти-двадцати серверов с РАЗНЫМИ конфигурациями? У каждого своя конфигурация ядра, различаются опции компилирования пакетов на разных серверах? Хорошо, сам то я понимаю что не стоит так делать, и сам бы я ставил на все машины пакет с одинаковыми опциями компилирования. А если мне всё это хозяйство досталось по наследству?

Спасибо, пусть сборочный тазик будет у разработчиков дистрибутива, а не у меня. Я желаю ставить готовые заранее скомпилированные пакеты всегда одной и той же версии, но со всеми последними security-патчами. Хочу чтобы установка обновлений происходила без моего участия и по cron-у. И раз разработчик предоставляет мне такую возможность, зачем мне танцы с бубном, то есть с отдельным сборочным тазиком?