>Эта уникальная заметка вышла слишком поздно для меня (20 мая 2008 -
>чуть больше недели назад). Мне это нужно было знать на год
>раньше.
>
>Для сравнения заметка https://www.opennet.ru/docs/RUS/iptables/ была добавлена на OpenNet 01.08.2004. Сравните качество и
>полноту описания. Посмотрите на рисунок https://www.opennet.ru/docs/RUS/iptables/misc/iptables-tutori...
>
>Схем прохождения пакетов сразу ясна. Каждый эллипс соответствует одной цепочке правил. Вы делаете некорректное сравнение. Во первых, схема прохождения пакетов через ipfw сразу же ясна еще из мана - там куда меньше мест, для вызова. Во вторых, на схеме на рисунке совершенно не показаны собственные цепочки, которые могут быть подключены в любую из других - если нарисовать все возможные пути, схема станет весьма запутанной. В третьих, сравнение качества и полноты документации некорректно - посмотрите в man iptabes, где там ваша схема? А в man ipfw есть и схема, и отсылки на другие маны, прочитав это всё вместе и подумав, вполне можно понять, как оно работает. Я в своей заметке просто описал всё это по-русски еще и вместе с деталями реализации, которые в маны пихать просто неположено.
>Комментарии и имена переменных зависят только от сознательности писавшего. Имена могут быть
>ничего не говорящими типа "a", "uie", "zpt", комментарии могут вообще отсутствовать,
>могут быть ничего незначащами вроде даты добавления правила и логина добавлявшего.
Вы снова передергиваете на случай "плохого админа". То же самое бывает и с iptables, комментирование скриптов - зависит только от админа, не от системы и файрвола.
>iptables попросту заставляет разбить огромный фаервол на цепочки, каждую из которых можно
>анализировать отдельно!
Ага, заставляет в отдельных случаях так, что лучше бы этого не было. Вот к примеру скрипт на http://freebsd.pastebin.com/d2cac785 - создается 8 пользовательских цепочек. На ipfw этот большой скрипт переписывается в несколько правил.
>В отличие от исходника, листинг работающего фаервола можно вывести со счётчиками попаданий в правило.
В ipfw тоже можно.
>Тут сразу будет видно: uptime сервера 3 месяца, 32
>правила за это время не использовались ни разу, может удалить?
Очень странный подход, я бы сказал. Из того, что 3 месяца не было атак, никак не следует, что они не появятся на следующий день.
>Если же предпочесть скрипт, по которому был сгенерирован листинг, то там нужно
>будет ещё и искать соответствие правил.
В скрипте, генерирующем правила iptables, тоже нужно будет. И?
>Вот это (скрипты) они зря делают, потому что фаервол в итоге после
>нескольких десятков правок разными админами становится попросту нечитаемым. Тут всё равно
>легче проанализировать реальный листинг, нежели эту запутанную писанину.
Это вам попадались плохие, неорганизованные скрипты, значит. И не попадались файрволы на тысячи и десятки тысяч правил, значит, если вы предпочитаете писать их вручную без генерации.
>Пусть нет ната, а нужно сделать закрытый по-умолчанию фаервол. Как быть в
>ipfw? Искусственно вводить сюда нат?
Снова передергиваете? В исходном вопросе вам хотелось для случая с натом - решение есть. Да, были оговорены проблемы для другого частного случая (про который вы даже не спрашивали) - теперь вы заостряете на нем внимание. Это некорректно.
>Проверять всё кроме IP-адресов. В случае совпадения прыгать на отдельную специально созданную
>цепочку, где проверять только IP-адреса. При совпадении адреса - применять правило.
>
>В iptables можно создавать СВОИ цепочки правил. Если взять критерий отбора не
>по списку IP, а по списку номеров портов - есть модуль
>multiport.
В результате получаются такие запутанные скрипты, как я привел по ссылке выше. Нет уж, спасибо.
>Ферма - это хорошо. Но по сути ферма - это один и
>тот же клонированный сервер. Что делать в случае десяти-двадцати серверов с
>РАЗНЫМИ конфигурациями? У каждого своя конфигурация ядра, различаются опции компилирования пакетов
>на разных серверах? Хорошо, сам то я понимаю что не стоит
>так делать, и сам бы я ставил на все машины пакет
>с одинаковыми опциями компилирования. А если мне всё это хозяйство досталось
>по наследству?
Постепеннно разбираться и унифицировать, разумеется. Как все это и делают, собственно. Странно предъявлять претензии к временному решению.
>Спасибо, пусть сборочный тазик будет у разработчиков дистрибутива, а не у меня.
>Я желаю ставить готовые заранее скомпилированные пакеты всегда одной и той
>же версии, но со всеми последними security-патчами. Хочу чтобы установка обновлений
>происходила без моего участия и по cron-у. И раз разработчик предоставляет
>мне такую возможность, зачем мне танцы с бубном, то есть с
>отдельным сборочным тазиком?
Такой подход годится, когда серверов несколько штук. А когда их сотни, опции по умолчанию из дистрибутива для всех случаев подходить не надо, и все равно придется собирать. За то админам больших ферм серверов и платят, собственно.
