Порядок прохождения пакетов при одновременном использовании ipfilter, pf и ipfw:
При загрузке фильтров модулями, порядок будет определяться порядком загрузки модулей.
Причина здесь в том, что пакетные фильтры регистрируют себя в pfil(9).При включении всех фильтров в ядро порядок будет определять SYSINIT.
Чтобы определить порядок, нужно открыть файл sys/kernel.h.
В нём определён порядок инициализации определённых подсистем. Теперь, простейшее:# grep DECLARE_MODULE netinet/ip_fw_pfil.c
DECLARE_MODULE(ipfw, ipfwmod, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_ANY);
# grep DECLARE_MODULE contrib/pf/net/pf_ioctl.c
DECLARE_MODULE(pf, pf_mod, SI_SUB_PROTO_IFATTACHDOMAIN, SI_ORDER_FIRST);
# grep DECLARE_MODULE contrib/ipfilter/netinet/mlfk_ipl.c
DECLARE_MODULE(ipfilter, ipfiltermod, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY);От сюда следует: первым будет ipfilter, затем pf, затем ipfw.
URL: http://www.opennet.me/openforum/vsluhforumID1/75042.html
Обсуждается: http://www.opennet.me/tips/info/1431.shtml
вот неудобно, однако, хочется чтоб порядок прохождения на вход и на выход были обратными, т.е.:на вход: ipfilter, pf, ipfw
на выход: ipfw, pf, ipfilterТогда получается довольно удобно для тех, кто использует два пакетных фильтра (например я): фильтровать в ipfw, а натить в pfnat. В данном случае появится возможность дополнительно неотначеные пакеты фильтровать на внешнем интерфейсе посредством ipfw.
Так и есть на самом деле. Регистрация хуков от пакетных фильтров происходит следующим образом:
/* обычно фильтр регистрирует хук как на вход так и на выход, поэтому: */
1. Первым регистрируется ipfilter, ещё не было зарегистрировано ниодного фильтра, поэтому списки хуков выглядят так:
ph_in: [ipfilter]
ph_out: [ipfilter]2. Вторым регистрируется pf (изображая по порядку вызова слева на право):
ph_in: [ipfilter]-[pf]
ph_out: [pf]-[ipfilter]3. Третий регистрируется ipfw:
ph_in: [ipfilter]-[pf]-[ipfw]
ph_out: [ipfw]-[pf]-[ipfilter]Из этих схем видно, что для исходящих пакетов порядок вызова фильтров инвертирован по отношению ко входящим
Это неудобство объясняется очень просто: нет у фри нормального файрвола и нормального описания к нему. Есть целых три файрвола, каждый из которых описан частично. Отсюда всякие уродские гибриды ipfw/ipnat или ipfw/pfnat. Фрю люблю, но линуксоидам завидую - у них всего один файрвол, зато мощный и хорошо описанный.
И с которым граблей........................
>И с которым граблей........................Нисколько!
Со времени, прошедшего с того коммента, успел на практике настроить несколько интернет-серверов на основе Debian. Так вот, пакетный фильтр iptables, гораздо проще и нагляднее ipfw.
Сейчас по собственной воле использовать FreeBSD не стану, не в последнюю очередь на это решение повлиял ipfw. Главная причина - "нетехнологично". Хотя FreeBSD по чистоте и правильности кода, на мой взгляд, гораздо лучше Linux'а, но использовать её лучше прежде всего в образовательных целях.
Ну так остановитесь на каком-нибудь одном и его пользуйте....
Одного PF недостаточно?
>Ну так остановитесь на каком-нибудь одном и его пользуйте....
>Одного PF недостаточно?Я остановился на iptables :-)
Птичий синтаксис нагляднее? Не поверю. Новичка ipfw можно научить за час-полтора, включая базовые сведения по tcp/ip и хождению пакетов вообще, с нуля (проверено на wipfw и пользователе windows). Если у человека есть знание английского, синтаксис и семантика ему будут во многом интуитивно понятны.И в чем "нетехнологичность" ?.
Новичка iptables можно научить за то-же время и на таком-же уровне. При этом я не считаю, что фаерволл можно толком изучить за час-полтора. Основы - да, можно. Что-то более сложное - нет.По теме, почему я предпочитаю iptables.
Во FreeBSD всё наглядно, да. Но только на первый взгляд. Стоит попробовать настроить закрытый по умолчанию фаерволл с NAT, и который должен пропускать через себя PPTP-соединения, FTP-трафик и т.п. Вот тут-то и начинается головняк. Нетехнологичность проявляется сразу же: здесь входящие, исходящие и маршрутизируемые пакеты, NAT и QoS свалены в кучу! Особенно долго приходится разбираться с тем почему не проходят определённые пакеты при наличии NAT: нужно прописать разрешающее правило на вход в интерфейс, разрешающее правило на выход из интерфейса, разрешающее правило на вход в divert-сокет, разрешающее правило на выход из divert-сокета, настроить перехват пакетов которые должны попасть в divert-сокет, настроить сам divert-сокет. Вкупе с примешанными в этом же файле правилами QoS это становится ещё сложнее. Настройка нормально работающего FTP - вообще песня.
Мне попадались уже настроенные фаерволы во FreeBSD. Разобраться в них на уровне "добавить ещё одно разрешающее правило" можно. А вот понять как работает ВСЁ это хозяйство на несколько килобайт становится сложновато. Если же учитывать вольность синтаксиса (определение переменных в тексте фаервола) разобраться в написанном кем-то фаерволе становится практически невозможно.
Для сравнения, в iptables одна таблица для форвардящихся пакетов, одна таблица для пакетов попадающих в систему, одна таблица для пакетов, выходящих из системы, одна таблица для SNAT, одна для DNAT. Для поддержки FTP есть модуль ядра, который заглядывает в управляющую сессию и добавляет в таблицу установленных соединений запись для сессии данных. QoS отдельно, маршрутизация отдельно. Причем фаерволом можно помечать пакеты, QoS будет реализовывать политику для этих пакетов, маршрутизатор выбирать одну из НЕСКОЛЬКИХ таблиц маршрутизации. Если придерживаться правил загружать и сохранять фаервол средствами iptables-save iptables-restore, то разобраться в чужом фаерволе значительно легче.
Далее, если отклониться от темы фаерволов, можно сравнить как происходит латание дыр в сервисах или установка новых программ во FreeBSD и, например, Debian.
Во FreeBSD если ты полгода-год где-то был, не обновлял систему и порты, то потом тебе для установки новой программы нужно будет скачать (или обновить через CVS, не суть важно) дерево исходников системы и новые порты. Затем перекомпилить ядро и систему, при учёте нестандартного конфига ядра. Потом несколько перезагрузок, чтобы проверить как работает новое ядро и окружение системы. Потом перекомпилить все установленные порты с помощью portupgrade (а что если она не была установлена - откуда её взять?). Потом ставить новую прогу. При этом компиляция будет происходить на рабочей машине, ухудшая качество обслуживания пользователей, или удалённо по NFS, лишая админа удобств.
В Debian:
apt-get update
apt-get upgrade
apt-get install что-нужно
Если обновилось ядро, то перезагрузиться.Если сервер один, денёк ещё можно поплясать с бубном, ничего не случится. Если серверов с десяток - будешь плясать с бубном неделями.
Я НЕ противник FreeBSD, я НЕ говорю, что FreeBSD сосёт. Мне эта система нравится, но я предпочитаю тратить своё время с пользой для себя, а не для системы.
Не надо всё переводить на религиозную войну FreeBSD vs. Linux. Я никого не хочу оскорблять. Просто прежде чем спорить что лучше, стоит ознакомиться и с тем и с другим и выбрать для себя что-то, что больше подходит. При этом не стоит поливать помоями того, кто выбрал что-то другое. Вам нравится FreeBSD? Это Ваш выбор. Мне нравится и то и другое, но я выбрал Debian, это мой выбор.
Прошу прощения за столь длинный коммент.
Ещё могу добавить что из Linux'ов я не считаю технологичными:
1. Slackware - отсутствует менеджер пакетов, в результате нужно разбираться с зависимостями; часто нужна компиляция, придётся грузить систему.
2. Gentoo (и по тем же причинам все BSD) - всегда нужна компиляция, придётся грузить систему; в репозитарии всегда самые свежие программы, при смене версии программы часто меняется конфиг, в результате может оказаться что после обновления что-то не работает, т.к. нужна правка конфига. Предпочитаю одну и ту же версию пакета, но постоянно патчащуюся.
3. Ubuntu и иже сними - в репозитарии всегда самые свежии версии программ, причину см. выше.
4. Нынешний Mandrake - по-моему тоже основан на Ubuntu, может быть ошибаюсь, поправьте.
5. Отечественный Alt Linux, по той же причине, что и два предыдущих пункта.Считаю технологичными:
1. Debian,
2. Red Hat (но не Fedora), возможно CentOS,
3. возможно SUSE...
>Новичка iptables можно научить за то-же время и на таком-же уровне. При
>этом я не считаю, что фаерволл можно толком изучить за час-полтора.
>Основы - да, можно. Что-то более сложное - нет.Разумеется, о владении в совершенстве никто не говорил.
>Во FreeBSD всё наглядно, да. Но только на первый взгляд. Стоит попробовать
>настроить закрытый по умолчанию фаерволл с NAT, и который должен пропускать
>через себя PPTP-соединения, FTP-трафик и т.п. Вот тут-то и начинается головняк.Да без проблем.
>Нетехнологичность проявляется сразу же: здесь входящие, исходящие и маршрутизируемые пакеты, NAT
>и QoS свалены в кучу! Особенно долго приходится разбираться с тем
>почему не проходят определённые пакеты при наличии NAT: нужно прописать разрешающее
>правило на вход в интерфейс, разрешающее правило на выход из интерфейса,
>разрешающее правило на вход в divert-сокет, разрешающее правило на выход из
>divert-сокета, настроить перехват пакетов которые должны попасть в divert-сокет, настроить сам
>divert-сокет. Вкупе с примешанными в этом же файле правилами QoS это
>становится ещё сложнее. Настройка нормально работающего FTP - вообще песня.Простите, а вы заметку http://www.opennet.me/opennews/art.shtml?num=16080 читали? Там схема описана. Так много правил, которые вы перечислили - не требуется.
>Мне попадались уже настроенные фаерволы во FreeBSD. Разобраться в них на уровне
>"добавить ещё одно разрешающее правило" можно. А вот понять как работает
>ВСЁ это хозяйство на несколько килобайт становится сложновато. Если же учитывать
>вольность синтаксиса (определение переменных в тексте фаервола) разобраться в написанном кем-то
>фаерволе становится практически невозможно.
>Если придерживаться правил загружать
>и сохранять фаервол средствами iptables-save iptables-restore, то разобраться в чужом фаерволе
>значительно легче.Пардон, вы путаете шелл-скрипт и "текст файрвола". И я как раз-таки предпочту изучать чужой шелл-скрипт, поскольку в нем есть имена переменных и комментарии, помогающие разобраться в смысле, в отличие от голого вывода ipfw list (который никто не мешает сохранять/загружать аналогично iptables-save). Кроме того, при больших количествах правил народ точно так же применяет скрипты (с переменными, ага) и для iptables.
>Для сравнения, в iptables одна таблица для форвардящихся пакетов, одна таблица для
>пакетов попадающих в систему, одна таблица для пакетов, выходящих из системы,
>одна таблица для SNAT, одна для DNAT. Для поддержки FTP есть
>модуль ядра, который заглядывает в управляющую сессию и добавляет в таблицу
>установленных соединений запись для сессии данных. QoS отдельно, маршрутизация отдельно. Причем
>фаерволом можно помечать пакеты, QoS будет реализовывать политику для этих пакетов,
>маршрутизатор выбирать одну из НЕСКОЛЬКИХ таблиц маршрутизации.Прочитатйе еще раз заметку со схемой прохождения пакетов. Все вышеперечисленное (кроме модуля FTP, он только в состае ната идет) есть и в ipfw. А вот жесткость iptables, что в таблицах, что в формате правила, начинает мешать в сложных случаях. Попробуйте, например, в одном правиле iptables указать несколько src, аналогично OR-блокам ipfw...
>Далее, если отклониться от темы фаерволов, можно сравнить как происходит латание дыр
>в сервисах или установка новых программ во FreeBSD и, например, Debian.[...]
>Если сервер один, денёк ещё можно поплясать с бубном, ничего не случится.
>Если серверов с десяток - будешь плясать с бубном неделями.
>
>Я НЕ противник FreeBSD, я НЕ говорю, что FreeBSD сосёт. Мне эта
>система нравится, но я предпочитаю тратить своё время с пользой для
>себя, а не для системы.
>
>Не надо всё переводить на религиозную войну FreeBSD vs. Linux. Я никого
>не хочу оскорблять. Просто прежде чем спорить что лучше, стоит ознакомитьсяДа, но вы зачем-то с темы файрволов свернули именно на религозную тематику, вместо того, чтоб, например, ознакомиться с опытом других, как они поддерживают большое количество машин. Узнали бы, скажем, что на фремах серверов используют сборочный тазик, а вовсе не компилируют на каждой машине, без танцев с бубном. И т.д.
>Простите, а вы заметку http://www.opennet.me/opennews/art.shtml?num=16080 читали? Там
>схема описана. Так много правил, которые вы перечислили - не требуется.Эта уникальная заметка вышла слишком поздно для меня (20 мая 2008 - чуть больше недели назад). Мне это нужно было знать на год раньше.
Для сравнения заметка http://www.opennet.me/docs/RUS/iptables/ была добавлена на OpenNet 01.08.2004. Сравните качество и полноту описания. Посмотрите на рисунок http://www.opennet.me/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-у. И раз разработчик предоставляет мне такую возможность, зачем мне танцы с бубном, то есть с отдельным сборочным тазиком?
>Эта уникальная заметка вышла слишком поздно для меня (20 мая 2008 -
>чуть больше недели назад). Мне это нужно было знать на год
>раньше.
>
>Для сравнения заметка http://www.opennet.me/docs/RUS/iptables/ была добавлена на OpenNet 01.08.2004. Сравните качество и
>полноту описания. Посмотрите на рисунок http://www.opennet.me/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-у. И раз разработчик предоставляет
>мне такую возможность, зачем мне танцы с бубном, то есть с
>отдельным сборочным тазиком?Такой подход годится, когда серверов несколько штук. А когда их сотни, опции по умолчанию из дистрибутива для всех случаев подходить не надо, и все равно придется собирать. За то админам больших ферм серверов и платят, собственно.
>Вы делаете некорректное сравнение. Во первых, схема прохождения пакетов через 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-у. И раз разработчик предоставляет
>>мне такую возможность, зачем мне танцы с бубном, то есть с
>>отдельным сборочным тазиком?
>
>Такой подход годится, когда серверов несколько штук.Такой подход годится именно тогда, когда их много и они все разные. Каждый сервер будет минимальное время работать с уязвимыми пакетами. У каждого будет минимум непроизводительного простоя, минимум неудобств пользователям.
>А когда их сотни, опции
>по умолчанию из дистрибутива для всех случаев подходить не надо, и
>все равно придется собирать.Я не буду пересобирать дистрибутивы ни в коем случае. Это вызовет проблемы при обновлении. Я за то, чтобы работала техника, а не человек.
>За то админам больших ферм серверов и
>платят, собственно.Понятие админ здесь снисходит до понятия техник, персонал обслуживающий технику. У админа есть более крупные задачи, некогда ему фигнёй страдать.
Вы можете увлекаться компилированием до тех пор, пока не появятся системы и люди, для которых компилирование не является обязательным атрибутом процесса решения задачи. И спешу вам сообщить, что и такие системы и такие люди уже есть.
Оффтопик.Ещё раз обозначу почему я так люблю употреблять слово "технологичность".
Для меня самый ценный ресурс - время человека. Если какая-то система позволяет освободить человека от механической работы, максимально автоматизировать работу человека, то такая система более технологична.
Я хочу вовремя есть и спать, а не задерживаться на работе для того, чтобы исправить какую-то неполадку или для устранения уязвимостей ситемы.
Я хочу вовремя и без проблем отдохнуть в отпуске, быть уверенным что моя система при появлении новой дыры автоматически обновится. Я не хочу, чтобы в моё отсутствие систему взломали или система сама потеряла работоспособность после обновления.
Я хочу, чтобы мой шеф не держал в штате дюжину яйцеголовых специалистов, воюющих между собой в попытке доказать у кого из них круче яйца, уход из компании любого из которых может поставить компанию на грань разорения.
Технологичность iptables
На мой взгляд iptables позволяет максимально разделить суть разные правила: входящие пакеты, исходящие пакеты, маршрутизируемые пакеты, NAT, QoS, полиси рутинг.
При этом iptables поддерживает создание собственных цепочек и таблиц, стимулируя к делению задачи на мелкие подзадачи.
iptables позволяет не беспокоиться о работе сложных протоколов вроде FTP.
iptables поддерживает технологию statefull (ipfw тоже поддерживает), что избавляет от дублирования правил для двух направлений пакетов.
iptables явно обозначает политику цепочки по умолчанию, при чём для каждой цепочки можно выбирать свою политику по-умолчанию.
iptables-save и iptables-restore позволяют иметь всегда упорядоченный и красиво отформатированный список правил.
Технологичность пакетно-ориентированных систем
Такие системы позволяют избегать траты времени на компилирование пакетов, на обновление пакетов с устранением уязвимостей, на отслеживание взаимозависимостей пакетов, отслеживание опций сборки пакетов.
Для меня пакетно-ориентированной системой является также Cisco IOS. Не являются Windows (не позволяет отслеживать зависимости и легко обновлять ВСЕ программы), *BSD/Gentoo/Slackware (стимулируют к компилированию), *Ubuntu/Mandriva (не обновляют уязвимые пакеты, или обновляют только с одновременной сменой версии пакета, что может привести к необходимости редактировать конфиг).
>На мой взгляд iptables позволяет максимально разделить суть разные правила: входящие пакеты,
>исходящие пакеты, маршрутизируемые пакеты, NAT, QoS, полиси рутинг.Это все мишура. То, что кому-то там легче/сложнее читать - лишь его проблемы.
На практике не встречал случаев когда linux+iptables был бы производительнее fbsd+ipfw (хотя у iptables много "отдельных" таблиц). Скажем в том же PBR. Только это важно. А удобство дело туалетное.
>Это все мишура. То, что кому-то там легче/сложнее читать - лишь его проблемы.Ну да, я вот о Вас забочусь, хочу чтобы Вам не достались такие же через заднее место сделанные системы, а Вы говорите: "Мои проблемы, мне нравиться заниматься сексом с железом" :)
>На практике не встречал случаев когда linux+iptables был бы производительнее fbsd+ipfw (хотя у iptables много "отдельных" таблиц).
А я не встречал случаев, когда производительность ПиСи-роутера была критичной. Если производительность критична, лучше купить аппаратный маршрутизатор.
>Скажем в том же PBR. Только это важно. А удобство дело туалетное.
Вы раб лампы, то есть железа. Я исхожу из позиции, что железо - мой раб. Должно быть удобно мне, а не железу.
Скорость - миф. Лучше купить железку помощнее и пользоваться удобствами, чем сэкономить жалкие крохи и потом ежедневно терять время при эксплуатации оборудования.
в линухе фаервол не такой уж мощный - ему очень нехватает таблиц. с 1000 правил и 800 полос в шейпере на 10000 пакетов/сек становится на колени очень мощный писюк, в тоже время на фре с таблицами тоже самое просто летает, и не мудрено - таблицы это вам не цепочки правил
>в линухе фаервол не такой уж мощный - ему очень нехватает таблиц.Название iptables ни о чём не говорит?
>с 1000 правил и 800 полос в шейпере на 10000 пакетов/сек
>становится на колени очень мощный писюк,Нечего не зеркало пенять коли рожа (то есть руки) крива.
Вы это флейма ради или Вы всё-таки представляете разницу между средствами управления трафиком во FreeBSD и Linux?
>в тоже время на фре
>с таблицами тоже самое просто летает, и не мудрено - таблицы
>это вам не цепочки правилОчень глубокомысленный вывод. Ценю. "Таблицы" звучит круче чем "Цепочки".
> Название iptables ни о чём не говорит?вот именно что название, название новое а внутри все теже ipchains =)
Не знаете разницы между таблицами и цепочками? слышали про быстрый поиск с хеш-таблицами? нет? погуглите.
Время поиска по цепочке правил линейно зависит от количества правил. Поиск же по хеш таблице практически не зависит от количества записей в таблице. Вот цитата с букваря по pf "a table is ideal for holding a large group of addresses as the lookup time on a table holding 50,000 addresses is only slightly more than for one holding 50 addresses"
>Нечего не зеркало пенять коли рожа (то есть руки) крива.
А как иначе разруливать ситуацию когда есть 600 адресов которые нужно дропнуть, и 400 адресов которые нужно натить, причем эти адреса постоянно добавляются/удаляются?
в случае с pf мы добавляем 2 правила:
block from <drops> to any
nat from <nats> to anyНачинку таблиц без проблем можно менять на лету. Время поиска по такой таблице очень и очень маленькое.
В случае с линухом мы вынуждены держать 1000 правил, поиск по 1000 правил идет настолько долго что ksoftirqd вылазит вверх (это симптом, никогда такого не видели?) и машина просто не вылазит из прерываний. LA растер вверх а количество успешно прошедших пакетов - вниз.
Есть патч для linux который добавляет такой функционал, но не очень хочется приключений связанных с глюками third level патча.
> Очень глубокомысленный вывод. Ценю. "Таблицы" звучит круче чем "Цепочки".
Не просто звучит, но и работает =) Простой линейный поиск гораздо медленеей поиска по self-ballancing binary tree (хотя я не уверен что в pf именно такое дерево, лень в исходники лезть)
>Не знаете разницы между таблицами и цепочками? слышали про быстрый поиск с
>хеш-таблицами? нет? погуглите.Погуглил, нашёл вот такой интересный тест:
http://bulk.fefe.de/scalability/
Правда он к обсуждаемому вопросу не имеет отношения...>Время поиска по цепочке правил линейно зависит от количества правил. Поиск же
>по хеш таблице практически не зависит от количества записей в таблице.
>Вот цитата с букваря по pf "a table is ideal for
>holding a large group of addresses as the lookup time on
>a table holding 50,000 addresses is only slightly more than for
>one holding 50 addresses"Аналогом таблиц pf в iptables является модуль ipset. Поиск же по спискам правил точно так же линеен.
В Linux эмпирическим путём обнаружилась интересная особенность - кэширование совпадений для правил, правда не нашёл прямых упоминаний об этом от разработчиков netfilter. В цепочках iptables долго идёт только первый поиск. Если приходит пакет с такими же атрибутами, что и уже проверенный, для этого пакета правило определяется из кэша: http://www.protocols.ru/Papers/iptables-test.shtml
>>Нечего не зеркало пенять коли рожа (то есть руки) крива.
>А как иначе разруливать ситуацию когда есть 600 адресов которые нужно дропнуть,
>и 400 адресов которые нужно натить, причем эти адреса постоянно добавляются/удаляются?
>в случае с pf мы добавляем 2 правила:
>block from <drops> to any
>nat from <nats> to anyВ случае с iptables точно так же, почитайте man:
http://ipset.netfilter.org/ipset.man.html>Начинку таблиц без проблем можно менять на лету. Время поиска по такой
>таблице очень и очень маленькое.
>В случае с линухом мы вынуждены держать 1000 правил, поиск по 1000
>правил идет настолько долго что ksoftirqd вылазит вверх (это симптом, никогда
>такого не видели?) и машина просто не вылазит из прерываний. LA
>растер вверх а количество успешно прошедших пакетов - вниз.Я же говорю - руки кривые.
>Есть патч для linux который добавляет такой функционал, но не очень хочется
>приключений связанных с глюками third level патча.Каждый сильно востребованный патч со временем попадёт в upstream.
>> Очень глубокомысленный вывод. Ценю. "Таблицы" звучит круче чем "Цепочки".
>Не просто звучит, но и работает =) Простой линейный поиск гораздо медленеей
>поиска по self-ballancing binary tree (хотя я не уверен что в
>pf именно такое дерево, лень в исходники лезть)Ну и iptables тоже не просто звучит, но и работает =)
>Погуглил, нашёл вот такой интересный тест:
>http://bulk.fefe.de/scalability/
>Правда он к обсуждаемому вопросу не имеет отношения...
>говорит 404..
>Аналогом таблиц pf в iptables является модуль ipset. Поиск же по спискам
>правил точно так же линеен.
>ipset это и есть тот самый левый патч который страшно ставить в продакшн.. приключений както не хочется..
>В Linux эмпирическим путём обнаружилась интересная особенность - кэширование совпадений для правил,
>правда не нашёл прямых упоминаний об этом от разработчиков netfilter. В
>цепочках iptables долго идёт только первый поиск. Если приходит пакет с
>такими же атрибутами, что и уже проверенный, для этого пакета правило
>определяется из кэша: http://www.protocols.ru/Papers/iptables-test.shtml"В завершении я хочу привести результаты теста на реально используемом шлюзе с достаточно высоким уровнем трафика (на момент тестирования исходящий трафик составлял около 2 Мбит/с)."
ой я вас умоляю не смешите мне тапочки этими двумя мегабитами. кеширование это костыли которые дают прирост только в синтетике
>В случае с iptables точно так же, почитайте man:
>http://ipset.netfilter.org/ipset.man.html
>все тот же стремный левый патч
>>Начинку таблиц без проблем можно менять на лету. Время поиска по такой
>>таблице очень и очень маленькое.
>>В случае с линухом мы вынуждены держать 1000 правил, поиск по 1000
>>правил идет настолько долго что ksoftirqd вылазит вверх (это симптом, никогда
>>такого не видели?) и машина просто не вылазит из прерываний. LA
>>растер вверх а количество успешно прошедших пакетов - вниз.
>
>Я же говорю - руки кривые.
>удивительный коментарий, и чего я вам доказываю?
>>Есть патч для linux который добавляет такой функционал, но не очень хочется
>>приключений связанных с глюками third level патча.
>
>Каждый сильно востребованный патч со временем попадёт в upstream.
>этот востребованный патч уже давно есть в *BSD, а в линухе от него кернел паники бывают
>>> Очень глубокомысленный вывод. Ценю. "Таблицы" звучит круче чем "Цепочки".
>>Не просто звучит, но и работает =) Простой линейный поиск гораздо медленеей
>>поиска по self-ballancing binary tree (хотя я не уверен что в
>>pf именно такое дерево, лень в исходники лезть)
>
>Ну и iptables тоже не просто звучит, но и работает =)ага, работает и ядро до полусмерти зашугивает... подождем когда его вылижут, а пока его даже на тестовую железку ставить страшно
Это уже давно не патч, модуль ipset у меня наличествует в дистрибутиве Debian Etch (stable), который часто BSD-шники обвиняют в том, что он устаревает на момент выпуска. Заметьте - это самый консервативный дистрибутив, и даже в нём этот модуль есть!Вот вам "расследование" и доказательство.
Судя по репозиторию исходников netfilter, модуль ipset был добавлен туда 9 февраля 2004 года. Убедитесь сами: http://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a...
Впервые он появился в составе iptables версии 1.3.0 от 12 февраля 2005 года, можете посмотреть дату релиза вот здесь: http://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a...
В самом консервативном из Linux-дистрибутивов Debian модуль ipset появился в составе пакета iptables версии 1.3.6 (посмотрите тут http://packages.debian.org/search?keywords=iptables&searchon...), это была версия 4.0 выпущенная 08 апреля 2007 (можете посмотреть тут http://www.debian.org/News/2007/20070408).
Debian - самый тормозной дистрибутив из всех Linux'ов, но даже там поддержка модуля ipset на уровне системы, без привлечения сторонних патчей, появилась полтора года назад. Думаю в репозиториях backports или volatile этот модуль появился ещё раньше, мне уже искать лень. Не стоит думаю доказывать, что в остальных дистрибутивах этот модуль в системе появился ещё раньше. Всё вопрос исчерпан.
Прежде чем повторять одну и ту же мантру "ipset не для продакшн" или "костыли в виде патчей", стоит ознакомиться с вопросом.
А вот в *BSD до сих пор несколько PPTP-сессий нельзя установить из-за NAT'а, несмотря на все их три фаерволла. И в stateful режиме фаерволлов не отслеживаются сессии данных активных FTP-клиентов, благодаря чему приходится настраивать ещё и NAT там, где он не нужен.
А уж насчёт стабильности BSD так лучше бы вообще помолчали, там разработчики отвечают только за базовую систему, а дырки в программах из портов их не волнуют. Метод закрытия дырок тоже занятный - берут более свежую версию программы, в которой дыра уже закрыта. В Debian берут ту же версию и закрывают дырку в ней, благодаря чему обновления безопасности происходят совершенно безболезненно, даже в автоматическом режиме без участия сисадмина. Во FreeBSD порт может не скомпилироваться, во время компиляции будет создаваться дополнительная нагрузка на сервер, после установки какое-нибудь мелкое изменение в формате конфига при переходе с одной версии на другую может привести к тому, что обновлённый демон не запустится. Поэтому при обновлении FreeBSD сисадмин должен быть рядом с сервером. А если их двадцать, тридцать и на каждом разные задачи? А если сисадмин уехал в отпуск на месяц, можно ли без участия обновить системы? Нельзя? :-( Что теперь - системы не патчить или обновлять автоматом и молиться, что ни одно обновление не приведёт к неработоспособности сервака?
На йух BSD, им место на маршрутизаторах, только в виде базовой системы, и лучше без портов. И это должны быть единичные маршрутизаторы или абсолютно идентичные, чтоб по rsync все обновлять можно было.
>Это уже давно не патч, модуль ipset у меня наличествует в дистрибутиве
>Debian Etch (stable), который часто BSD-шники обвиняют в том, что он
>устаревает на момент выпуска. Заметьте - это самый консервативный дистрибутив, и
>даже в нём этот модуль есть!
>http://w3dev.org.ua/debian-guaranteed-entropy.jpg
ок>Прежде чем повторять одну и ту же мантру "ipset не для продакшн"
>или "костыли в виде патчей", стоит ознакомиться с вопросом.кто повторял? я разок сказал, а вы тут про дебиан 3 абзаца мантр =)
дело даже не в том что ipset это костыль который стремаются
добавлять в основную ветку, а в том что iptables даже вместе с
ipset уступают и ipfw и pf.>
>А вот в *BSD до сих пор несколько PPTP-сессий нельзя установить из-за
>NAT'а, несмотря на все их три фаерволла. И в stateful режиме
>фаерволлов не отслеживаются сессии данных активных FTP-клиентов, благодаря чему приходится настраивать
>ещё и NAT там, где он не нужен.насчет pptp не тестил, но FTP работает отменно, враки это всё
>А уж насчёт стабильности BSD так лучше бы вообще помолчали, там разработчики
>отвечают только за базовую систему, а дырки в программах из портов
>их не волнуют. Метод закрытия дырок тоже занятный - берут более
>свежую версию программы, в которой дыра уже закрыта. В Debian берут
>ту же версию и закрывают дырку в ней, благодаря чему обновления
>безопасности происходят совершенно безболезненно, даже в автоматическом режиме без участия сисадмина.ну вы поняли лол
http://w3dev.org.ua/debian-guaranteed-entropy.jpg>Во FreeBSD порт может не скомпилироваться, во время компиляции будет создаваться
>дополнительная нагрузка на сервер, после установки какое-нибудь мелкое изменение в формате
>конфига при переходе с одной версии на другую может привести к
>тому, что обновлённый демон не запустится. Поэтому при обновлении FreeBSD сисадмин
>должен быть рядом с сервером. А если их двадцать, тридцать и
>на каждом разные задачи? А если сисадмин уехал в отпуск на
>месяц, можно ли без участия обновить системы? Нельзя? :-( Что теперь
>- системы не патчить или обновлять автоматом и молиться, что ни
>одно обновление не приведёт к неработоспособности сервака?
>чего это вдрук оно приведет к неработоспособности?
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/up...
ок
>На йух BSD, им место на маршрутизаторах, только в виде базовой системы,
>и лучше без портов. И это должны быть единичные маршрутизаторы или
>абсолютно идентичные, чтоб по rsync все обновлять можно было.обновлять, строить кластеры, идентичные, не идентичные, можно всё
это не проблема. но и речь не об этомоткуда такая ненависть к BSD?
>дело даже не в том что ipset это костыль который стремаются
>добавлять в основную ветку, а в том что iptables даже вместе с
>ipset уступают и ipfw и pf.Уступает в чём?
>>А вот в *BSD до сих пор несколько PPTP-сессий нельзя установить из-за
>>NAT'а, несмотря на все их три фаерволла. И в stateful режиме
>>фаерволлов не отслеживаются сессии данных активных FTP-клиентов, благодаря чему приходится настраивать
>>ещё и NAT там, где он не нужен.
>
>насчет pptp не тестил, но FTP работает отменно, враки это всёПассивные соединения работают отменно (это когда клиент сам устанавливает два соединения с FTP-сервером), а активные нет (когда клиент устанавливает управляющее соединение, а сервер подключается к клиенту для передачи данных).
>чего это вдрук оно приведет к неработоспособности?
>
>http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/up...
>окПосмотрел. Это читать при каждом обновлении каждого сервера? То есть появилась дырка, нужно обновить 50 серваков. Я буду шаманить с бубном перед каждым серваком? Да я пока закончу, новые дырки появятся.
Особенно хорош вот этот ЛОЛ:
># portupgrade -afНа каждом сервере.
>откуда такая ненависть к BSD?
Как таковой ненависти к BSD нет. Я постоянно использую FreeBSD. Особенно мне нравится VPN-сервер mpd. Мне нравится маленький размер NetBSD. Мне нравится концепция ядра DragonFly BSD.
В BSD мне не нравятся:
1. неудобство пакетной системы (каждый раз пытаясь обновить или установить программу в FreeBSD вспоминаю насколько легко и быстро я то же самое сделал бы в Debian),
2. неразвитость ядра (те небольшие, на первый взгляд, недостатки иногда могут становиться принципиальными недостатками. Например, те же несколько PPTP-соединений через NAT были для меня просто до жути необходимы, причём срочно. Мне пришлось испытать ОЧЕНЬ сильную головную боль из-за этого),
3. фанатики с одним-двумя серверам, блещущие знаниями хэндбука, которые говорят МНЕ, что недостатков, которые Я прочувствовал на СВОЕЙ шкуре, нет. Это, знаете ли, несколько оскорбляет.
>>дело даже не в том что ipset это костыль который стремаются
>>добавлять в основную ветку, а в том что iptables даже вместе с
>>ipset уступают и ipfw и pf.
>
>Уступает в чём?
>в ipfw есть tablearg (очень очень приятная вещь)
в ipfw есть простые шустрые шейпера (pipes)(в линухе
чтобы получить такой функционал приходится юзать костыль imq
который кроме всего прочего дико тормозит)
это то изза чего я кое-где пересел на FreeBSD, не удивлюсь если
есть еще>># portupgrade -af
>
>На каждом сервере.
>а дебиан чудесным образом сам запустит все на всех серверах? лол
>
>В BSD мне не нравятся:
>1. неудобство пакетной системы (каждый раз пытаясь обновить или установить программу в
>FreeBSD вспоминаю насколько легко и быстро я то же самое сделал
>бы в Debian)да ну прям таки сделать cd ..... && make install прямо таки головная боль
>2. неразвитость ядра (те небольшие, на первый взгляд, недостатки иногда могут становиться
>принципиальными недостатками.неразвитость ядра???77 там три пакетных фильтра, и на SMP оно уделывает всех.
это неразвитость? чего вам там нехватает? jfs? лол>Например, те же несколько PPTP-соединений через NAT были для
>меня просто до жути необходимы, причём срочно.
> Мне пришлось испытать ОЧЕНЬ
>сильную головную боль из-за этого)так вот откуда ненависть =)
>3. фанатики с одним-двумя серверам, блещущие знаниями хэндбука
лол кто ето?
> которые говорят МНЕ, что недостатков, которые Я прочувствовал на
> СВОЕЙ шкуре, нет. Это, знаете ли, несколько оскорбляет.недостатки есть, но позвольте напомнить что речь идет о пакетных фильтрах
в FreeBSD и Linux, а не о крутости менеджера пакетов в Debian/GNU
>>>дело даже не в том что ipset это костыль который стремаются
>>>добавлять в основную ветку, а в том что iptables даже вместе с
>>>ipset уступают и ipfw и pf.
>>
>>Уступает в чём?
>>
>
>в ipfw есть tablearg (очень очень приятная вещь)ipset
>в ipfw есть простые шустрые шейпера (pipes)(в линухе
>чтобы получить такой функционал приходится юзать костыль imq
>который кроме всего прочего дико тормозит)Про imq первый раз слышу. Не пробовали tc? Не костыль, а штатная очень гибкая система приоритезации, формирования и ограничения трафика.
>это то изза чего я кое-где пересел на FreeBSD, не удивлюсь если
>есть ещеОтветы выше.
>>># portupgrade -af
>>
>>На каждом сервере.
>>
>
>а дебиан чудесным образом сам запустит все на всех серверах? лолНет. Он просто не будет компилировать. А ещё он (если это стабильная ветка) не будет чинить то, что не сломалось - обновит только дырявые пакеты их патчеными версиями.
>>В BSD мне не нравятся:
>>1. неудобство пакетной системы (каждый раз пытаясь обновить или установить программу в
>>FreeBSD вспоминаю насколько легко и быстро я то же самое сделал
>>бы в Debian)
>
>да ну прям таки сделать cd ..... && make install прямо таки
>головная больЧитаем http://www.lissyara.su/?id=1153
Видим:>Ага. libtool в двух экземплярах... Либо чё-то глюкануло, либо так и задумано, ввиду того >что не все приложения переваривают новые версии зависмостей, а хотят чё-то старое. >Попробуем пофиксить БД:
>/usr/home/lissyara/>pkgdb -F
>Прервал - куча ошибок из-за одного отсутствующего порта. Значит пойдём правильным путём, >- доставим зависисмось, которую он хочет:
>/usr/home/lissyara/>cd /usr/ports/misc/ldconfig_compatВот мои главные претензии. В 60% случаев невозможно собрать что-нибудь, не споткнувшись на каком-нибудь глюке парочку-другую раз.
И ещё мне не нравится, что я не могу собрать по команде make package определённый пакет, если в системе уже установлен другой пакет или пакеты других версий, от которых зависит собираемый пакет. То есть практически всегда такая ситуация: здесь играем, здесь не играем, здесь пятно от рыбы... Ну некогда мне заниматься обходом граблей и сооружением костылей, лучше я возьму предсказуемую систему.
>>2. неразвитость ядра (те небольшие, на первый взгляд, недостатки иногда могут становиться
>>принципиальными недостатками.
>
>неразвитость ядра???77 там три пакетных фильтра, и на SMP оно уделывает всех.Три пакетных фильтра - это да, это серьёзно. Можно зафильтроваться по самое нихочу. Лучше брать качеством, а не количеством.
Кого SMP уделывает, простите? Может Solaris? В Linux поддержка SMP появилась гораздо раньше. Вот у Мэта Диллона свой взгляд на SMP и уделыванием он занимается довольно серьёзно. В NetBSD SMP Эндрю Доран занимается хоть и поздно, зато планомерно и качественно: http://www.netbsd.org/~ad/smp/tasks.html В общем, пустой трёп.
>это неразвитость? чего вам там нехватает? jfs? лол
Аналога OpenVZ, UML, Xen dom0 (хотя уже утрачивает актуальность), ядра на ARM-процессорах. В том числе, да, и XFS и ReiserFS в режиме записи. Не хватает аналога LVM. Нет аналога LTSP для FreeBSD, хотя безусловно, всё то же самое можно сделать и самому.
>>Например, те же несколько PPTP-соединений через NAT были для
>>меня просто до жути необходимы, причём срочно.
>> Мне пришлось испытать ОЧЕНЬ
>>сильную головную боль из-за этого)
>
>так вот откуда ненависть =)Ещё раз говорю, ненависти нет. Просто я научился грамотнее тратить своё время.
>>3. фанатики с одним-двумя серверам, блещущие знаниями хэндбука
>
>лол кто ето?Ну, может быть к этой категории относитесь и Вы. Есть ещё Lissyara, Федорчук, iZen. Ещё мне нравится коронная фраза приверженцев FreeBSD и Gentoo "Ну, компьютеры сейчас мощные.", когда я говорю о том, что компиляция портов или портежей отнимает ресурсы системы и занимает немалое время.
>> которые говорят МНЕ, что недостатков, которые Я прочувствовал на
>> СВОЕЙ шкуре, нет. Это, знаете ли, несколько оскорбляет.
>недостатки есть, но позвольте напомнить что речь идет о пакетных фильтрах
>в FreeBSD и Linux, а не о крутости менеджера пакетов в Debian/GNUГрамотно брошенная в это раздел форума фраза "с которым граблей" была не моя. До этой фразы я был BSD'шником. Когда ответил на неё, уже хорошо познакомился с Debian и понял сколько времени и нервов я потерял (во многом) зря, отстаивая преимущества FreeBSD. Вы тоже начали ещё одну ветку, забросив фразу "в линухе фаервол не такой уж мощный".
>>
>>в ipfw есть tablearg (очень очень приятная вещь)
>
>ipset
>в ipset нет tableargs, погуглите
>>в ipfw есть простые шустрые шейпера (pipes)(в линухе
>>чтобы получить такой функционал приходится юзать костыль imq
>>который кроме всего прочего дико тормозит)
>
>Про imq первый раз слышу. Не пробовали tc? Не костыль, а штатная
>очень гибкая система приоритезации, формирования и ограничения трафика.
>tc привязывается к интерфейсу, а если у меня куча интерфейсов и трафик
по ним гуляет? приходится юзать IMQ, это виртуальный интерфейс
сделан специально для таких и подобных целей. tc+imq жутко тормозит.
на том же железе ipfw2 + tableargs + pipes удалось выжать почти в
десять раз больше (100килопакетов на фре против 12 на линухе)
>Ответы выше.ок
>[оверквотинг удален]
>Вот мои главные претензии. В 60% случаев невозможно собрать что-нибудь, не споткнувшись
>на каком-нибудь глюке парочку-другую раз.
>
>И ещё мне не нравится, что я не могу собрать по команде
>make package определённый пакет, если в системе уже установлен другой пакет
>или пакеты других версий, от которых зависит собираемый пакет. То есть
>практически всегда такая ситуация: здесь играем, здесь не играем, здесь пятно
>от рыбы... Ну некогда мне заниматься обходом граблей и сооружением костылей,
>лучше я возьму предсказуемую систему.
>это все ок, но ведь речь о пакетных фильтрах лол
>Три пакетных фильтра - это да, это серьёзно. Можно зафильтроваться по самое
>нихочу. Лучше брать качеством, а не количеством.
>iptables качеством уделывает только Outpost лол
>Кого SMP уделывает, простите? Может Solaris? В Linux поддержка SMP появилась гораздо
>раньше.наличие поддержки и ее качество -- вещи разные, есть
много бенчмарков где видно насколько все плохо с SMP в Linux
>Аналога OpenVZ, UML, Xen dom0 (хотя уже утрачивает актуальность), ядра на ARM-процессорах.
>В том числе, да, и XFS и ReiserFS в режиме записи.
>Не хватает аналога LVM. Нет аналога LTSP для FreeBSD, хотя безусловно,
>всё то же самое можно сделать и самому.
>лол зачем всё это? во фре уже теперь есть zfs
(хотя говаривают что в линухе недавно появилась поддержка
btrfs ок)ядра на ARM процессорах? это чтобы ОСь можно было на пылесосе запустить?
но зачем?>Ну, может быть к этой категории относитесь и Вы. Есть ещё Lissyara,
>Федорчук, iZen. Ещё мне нравится коронная фраза приверженцев FreeBSD и Gentoo
>"Ну, компьютеры сейчас мощные.", когда я говорю о том, что компиляция
>портов или портежей отнимает ресурсы системы и занимает немалое время.она занимает немалое время если собирать KDE4, но вы ведь на серверах
не пользуетесь кедами? =)собрать nginx, питон да postgres -- пара минут делов, зато оптимизации,
все дела.. как известно у гентушников даже скорость света на 6% выше =))где вы видели сервер на котором установлено 300 пакетов которые будут
2е суток компилироваться? развечто "сервер сегмента говносети" лолобычно сервер выполняет конкретные фунции, на нем кроме ядра и баша
установлена еще пара софтин и ВСЁ.>Грамотно брошенная в это раздел форума фраза "с которым граблей" была не
>моя. До этой фразы я был BSD'шником. Когда ответил на неё,
>уже хорошо познакомился с Debian и понял сколько времени и нервов
>я потерял (во многом) зря, отстаивая преимущества FreeBSD. Вы тоже начали
>ещё одну ветку, забросив фразу "в линухе фаервол не такой уж
>мощный".дык, ветка то о порядке прохождения пакетов в pf, никто вас сюда не звал
со своим линухом
>в ipset нет tableargs, погуглитеПогуглил. Отвечу Вашими словами:
>лол зачем всё это?
Фраза в духе названных мной фряшников-фанатиков: "Во FreeBSD всё есть. А если чего и нет, то значит оно не нужно." Я думаю Вы уже поняли, что объяснять Вам, занимающему такую позицию, зачем всё это нужно, мне не особо хочется, да и не имеет смысла.
>собрать nginx, питон да postgres -- пара минут делов, зато оптимизации,
все дела.. как известно у гентушников даже скорость света на 6% выше =))
Затраты и выгода несоизмеримы. Слышал о домохозяйках, которые поедут в другую часть города, ради того, чтобы купить один-единственный пакет молока на рубль дешевле, потратив при этом двадцать рублей на транспорт.
>обычно сервер выполняет конкретные фунции, на нем кроме ядра и баша установлена еще пара софтин и ВСЁ.
Конкретные функции - терминальный сервер X. У Вас все пользователи дружно логинятся по ssh и лабают документы в latex'е?
>где вы видели сервер на котором установлено 300 пакетов которые будут 2е суток компилироваться? развечто "сервер сегмента говносети" лол
Ну как раз фанатики таким и занимаются. Почему бы не настроить терминальный сервер X вместе со всеми KDE, OpenOffice и прочей лабудой на основе FreeBSD, собрав всё из портов? Чтобы на 6% быстрее работало? Как ни странно, такие люди есть.
>дык, ветка то о порядке прохождения пакетов в pf,
Не о порядке прохождения пакетов в pf, а о порядке прохождения пакетов через фаерволлы (ipf, ipfw и pf).
>никто вас сюда не звал со своим линухом
Собственно Вы и позвали фразой "в линухе фаервол не такой уж мощный". Продолжать беседу считаю бессмысленным, поскольку кроме очередного холивара, ожидать от Вас нечего.
>>в ipset нет tableargs, погуглите
>
>Погуглил. Отвечу Вашими словами:
>
>>лол зачем всё это?
>я гдето выше говорил о шейперах
>Фраза в духе названных мной фряшников-фанатиков: "Во FreeBSD всё есть. А если
>чего и нет, то значит оно не нужно." Я думаю Вы
>уже поняли, что объяснять Вам, занимающему такую позицию, зачем всё это
>нужно, мне не особо хочется, да и не имеет смысла.
>вообщето FreeBSD работает на ARM ;-)
>
>Затраты и выгода несоизмеримы. Слышал о домохозяйках, которые поедут в другую часть
>города, ради того, чтобы купить один-единственный пакет молока на рубль дешевле,
>потратив при этом двадцать рублей на транспорт.
>пара минут на компиляцию это затраты? затраты это лишние
доли секунд на каждый проходящий пакет>Конкретные функции - терминальный сервер X. У Вас все пользователи дружно логинятся
>по ssh и лабают документы в latex'е?
>дык для X линух получше будет, это известно всем
(только причем тут фаерволы лол)>Не о порядке прохождения пакетов в pf, а о порядке прохождения пакетов
>через фаерволлы (ipf, ipfw и pf).вот именно лол
>>никто вас сюда не звал со своим линухом
>
>Собственно Вы и позвали фразой "в линухе фаервол не такой уж мощный".эта фраза была ответом если вы не заметили =)
>Продолжать беседу считаю бессмысленным, поскольку кроме очередного холивара, ожидать от Вас
>нечего.отлично, переходим на личности лол
я бы сказал что ничего кроме холивара не стоит ожидать от ветки про
пакетные фильтры в FreeBSD в которую втулился очередной красноглазый
линуксоид с криками про мощный линуксовый фаервол
По опыту использованию
на выходе ipfw ipfilter.
> iptables попросту заставляет разбить огромный
> фаервол на цепочки, каждую из которых можно
> анализировать отдельно!а меня втыкает pf, который умеет и натить аж 2-мя способами у каждого по 2-ва мода, включая нат проксирование и бинат, меня втыкает теггирование пакетов и возможность рулить пакетами на основе политик и прочее и прочее... молчу уже о том, что они iptables имеют одни корни(тем кто не знает - разошлись из-за лицензии)... и вот когда мне чего-то не хватает в pf - я решаю вопросы на ipfw... такие например как фильтрация на L2 уровне...
Получается, что если пакет прошёл один файервол, он не проходит остальные. Так?
> Получается, что если пакет прошёл один файервол, он не проходит остальные. Так?Нет, пакет должен получить одобрение от всех фаерволлов. Если пакет прошёл через один фаерволл, то другие могут его заблокировать, а могут и нет.
