>Вы делаете некорректное сравнение. Во первых, схема прохождения пакетов через ipfw сразу
>же ясна еще из мана - там куда меньше мест, для
>вызова.Но при этом вся таблица правил свалена в кучу и будет просматриваться для проходящих через маршрутизатор пакетов ДВА раза. Один раз когда пакет войдёт на интерфейс, один раз когда пакет выйдет из интерфейса.
Сравним три отдельные цепочки iptables: 10 правил на вход, 10 правил на выход, 10 правил для проходящих через маршрутизатор пакетов. Сравним общий список из 30 правил ipfw. В случае iptables для каждого проходящего через маршрутизатор пакета в среднем будет просмотрено 10/2=5 правил, в случае ipfw (30 + 30)/2=30 правил. Добавьте сюда ещё правила, связанные с трансляцией адресов и портов, полиси рутинг, QoS.
Но это не важно, главное, что отдельные цепочки легче анализировать не только машине, но и человеку! У каждой цепочки может быть своя политика по умолчанию: разрешающая или запрещающая. Для редактирования фаерволла чаще всего вообще не приходится пользоваться редактором!
>Во вторых, на схеме на рисунке совершенно не показаны собственные
>цепочки, которые могут быть подключены в любую из других - если
>нарисовать все возможные пути, схема станет весьма запутанной. В третьих, сравнение
>качества и полноты документации некорректно - посмотрите в man iptabes, где
>там ваша схема? А в man ipfw есть и схема, и
>отсылки на другие маны, прочитав это всё вместе и подумав, вполне
>можно понять, как оно работает. Я в своей заметке просто описал
>всё это по-русски еще и вместе с деталями реализации, которые в
>маны пихать просто неположено.
Мои претензии к качеству документации и к понятности каждого из фаерволлов исходят из практики. Сравните количество документации и её качество для обоих фаерволлов, сравните доступность документации на русском. Практика показывает, что у людей пользующихся iptables не возникает почти никаких вопросов. В случае ipfw видно, что люди постоянно задают друг другу вопросы и придумывают уродские гибриды ipfw+ipnat.
>Вы снова передергиваете на случай "плохого админа". То же самое бывает и
>с iptables, комментирование скриптов - зависит только от админа, не от
>системы и файрвола.
Здесь я ничего не передёргиваю, я просто говорю что скрипт не обязательно хорошо прокомментирован. Мне до сих пор ещё ни разу не попадался хорошо прокомментированный фаерволл. Поэтому я сам пользуюсь iptables-save и iptables-restore и хотел-бы, чтобы все пользовались именно таким способом хранения правил фаерволла.
Но даже если мне попадётся исходник для iptables, я просто его выполню и сохраню результат с помощью iptables-save. Затем у меня появляется прекрасная возможность анализировать каждую цепочку отдельно, а не кашу из перемешанных между собой правил.
>Ага, заставляет в отдельных случаях так, что лучше бы этого не было.
>Вот к примеру скрипт на http://freebsd.pastebin.com/d2cac785 - создается 8 пользовательских цепочек.
>На ipfw этот большой скрипт переписывается в несколько правил.
Не нашёл по указанной ссылке ничего, но не важно. Не думаю что это было настолко страшно, как попадавшиеся мне фаерволлы.
>>В отличие от исходника, листинг работающего фаервола можно вывести со счётчиками попаданий в правило.
>
>В ipfw тоже можно.
Контекст: я имел ввиду, что листинг со счётчиками легко сравнивать с сохранённым с помощью iptables-save фаерволлом. Листинг и в сохранка будут повторять друг друга до безобразия. Листинг же со скриптом сравнивать не удобно.
>>Тут сразу будет видно: uptime сервера 3 месяца, 32
>>правила за это время не использовались ни разу, может удалить?
>
>Очень странный подход, я бы сказал. Из того, что 3 месяца не
>было атак, никак не следует, что они не появятся на следующий
>день.
Вот, сразу видно что фаерволл у вас по-умолчанию открыт и вы затыкаете в нём дырки. У меня все атаки будут блокироваться правилом по-умолчанию. Таким методом в своём закрытом по-умолчнию фаерволле я легко поудаляю лишние дыры.
>>Если же предпочесть скрипт, по которому был сгенерирован листинг, то там нужно
>>будет ещё и искать соответствие правил.
>
>В скрипте, генерирующем правила iptables, тоже нужно будет. И?
Ещё раз говорю о том, что я предпочитаю не пользоваться скриптами, так как толку от скриптов, написанных криворукими одминами - ноль. Я предпочитаю анализировать листинг, и иметь возможность сохранить и загрузить его. При этом предпочитаю анализировать каждую цепочку отдельно, а не весь фаерволл разом.
>Это вам попадались плохие, неорганизованные скрипты, значит.
Да, только такие и попадались.
>И не попадались файрволы на
>тысячи и десятки тысяч правил, значит, если вы предпочитаете писать их
>вручную без генерации.
Не могу себе представить случай, когда нужно генерировать скриптами полный листинг фаерволла. Если нужно генерировать огромный листинг скриптом, то это говорит об одной из нескольких вещей: непродумана структура сети, непродумана структура ограничения прав доступа, непродумана структура фаерволла, фаервол не имеет некоторых очень нужных возможностей.
В случае с iptables вся логика фаервола выделена в отдельные цепочки и таблицы. Я не анализирую сразу весь листинг целиком, я анализирую только одну интересующую меня часть. Раздельные цепочки, раздельные таблицы, поддержка состояний (Statefull) и политика по-умолчанию мне в этом очень помогает.
>>Пусть нет ната, а нужно сделать закрытый по-умолчанию фаервол. Как быть в
>>ipfw? Искусственно вводить сюда нат?
>
>Снова передергиваете? В исходном вопросе вам хотелось для случая с натом -
>решение есть. Да, были оговорены проблемы для другого частного случая (про
>который вы даже не спрашивали) - теперь вы заостряете на нем
>внимание. Это некорректно.
Это корректно. Мне не хотелось случая с натом, я привёл его для живописности: указать что в ipfw с натом много гемора. Но это не значит, что на практике мне не встретится случай без ната, и он встречался. В случае с ipfw приходилось FTP-сервер запускать в пассивном режиме, когда он ожидал соединений для данных на свой 20 порт. В случае с iptables достаточно было загрузить модуль ядра ip_conntrack_ftp и на этом моя головная боль оканчивалась.
>>Проверять всё кроме IP-адресов. В случае совпадения прыгать на отдельную специально созданную
>>цепочку, где проверять только IP-адреса. При совпадении адреса - применять правило.
>>
>>В iptables можно создавать СВОИ цепочки правил. Если взять критерий отбора не
>>по списку IP, а по списку номеров портов - есть модуль
>>multiport.
>
>В результате получаются такие запутанные скрипты, как я привел по ссылке выше.
>Нет уж, спасибо.
Уже ответил. Запутанные скрипты получаются когда есть один большой листинг, в котором всё свалено в кучу.
>Постепеннно разбираться и унифицировать, разумеется.
С христианским смирением принять испытания, посланные мне господом? :)
>Как все это и делают, собственно.
Я привык отвечать только за себя, а не за всех. Я вижу, что обычно людям не нравится разбираться в говне, даже в собственном. Они либо делают его, а потом сваливают, либо забивают и оставляют всё как есть, до тех пор пока 1) не грохнется, 2) не хакнут, 3) не станет нужно.
>Странно предъявлять претензии к временному решению.
Я против временных решений. Временные решения ВСЕГДА отзываются ОГРОМНЫМИ граблями в будущем, причём иногда не тем людям, которые их принимали.
Если у меня есть выбор: сделать временное решение и потом его расхлёбывать или сделать всё сразу как надо, то я выберу второе. Я за то чтобы изначально делать всё правильно.
>>Спасибо, пусть сборочный тазик будет у разработчиков дистрибутива, а не у меня.
>>Я желаю ставить готовые заранее скомпилированные пакеты всегда одной и той
>>же версии, но со всеми последними security-патчами. Хочу чтобы установка обновлений
>>происходила без моего участия и по cron-у. И раз разработчик предоставляет
>>мне такую возможность, зачем мне танцы с бубном, то есть с
>>отдельным сборочным тазиком?
>
>Такой подход годится, когда серверов несколько штук.
Такой подход годится именно тогда, когда их много и они все разные. Каждый сервер будет минимальное время работать с уязвимыми пакетами. У каждого будет минимум непроизводительного простоя, минимум неудобств пользователям.
>А когда их сотни, опции
>по умолчанию из дистрибутива для всех случаев подходить не надо, и
>все равно придется собирать.
Я не буду пересобирать дистрибутивы ни в коем случае. Это вызовет проблемы при обновлении. Я за то, чтобы работала техника, а не человек.
>За то админам больших ферм серверов и
>платят, собственно.
Понятие админ здесь снисходит до понятия техник, персонал обслуживающий технику. У админа есть более крупные задачи, некогда ему фигнёй страдать.
Вы можете увлекаться компилированием до тех пор, пока не появятся системы и люди, для которых компилирование не является обязательным атрибутом процесса решения задачи. И спешу вам сообщить, что и такие системы и такие люди уже есть.
