https://opennet.me/openforum/vsluhforumID3/39553.html Вышел (http://netfilter.org/news.html#2007-12-22) iptables 1.4.0 (http://netfilter.org/projects/iptables/downloads.html#iptables-1.4.0), спустя почти 3 года с момента выхода первого релиза ветки 1.3.x. В iptables 1.4 проведена существенная работа по улучшению поддержки IPv6, исправлено большое число ошибок. Кроме того, можно отметить появление базовой реализация инфраструктуры xtables, возможность восстановления состояний отдельных таблиц в iptables-restore (ключ -table), проведение работы по оптимизации производительности операций сортировки цепочек.<br><br>URL: http://marc.info/?l=netfilter&m=119833164027492&w=2<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=13448<br> https://opennet.me/openforum/vsluhforumID3/39553.html#123 Thu, 17 Jan 2008 17:38:16 GMT &gt;[оверквотинг удален]<br>&gt;AP - попадёшь в linux? <br>&gt;<br>&gt;&gt;IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables. <br>&gt;&gt;Слишком много точек входа в ядро, код перегружен и глючит. <br>&gt;<br>&gt;Самый ужас - это conntrack. Сам netfilter умеет скалиться на SMP, чего <br>&gt;не умеет PF. <br>&gt;Да, сейчас и одноядерные процессоры весьма быстры, но когда у вас 4 <br>&gt;гигабитных сетевухи и 2 ядра... хм, пакетный фильтр, болтающийся на одном <br>&gt;cpu в случае DoS ничем не поможет. <br><br>Насчет SMP можно медленнее и подробнее ? Ксеоны 3.4 однако :<br><br>router:/# LANG=C mpstat -P ALL 10 3<br>Linux 2.6.23.14 (router) 01/17/08<br><br>19:20:49 CPU %user %nice %system %iowait %irq %soft %idle intr/s<br>19:20:59 all 0.02 0.74 0.12 0.17 0.05 24.67 74.22 321.10<br>19:20:59 0 0.00 0.00 0.00 0.00 0.20 99.80 0.00 321.10<br>19:20:59 1 0.00 0.80 0.20 0.10 0.00 0.10 101.10 0.00<br>19:20:59 2 0.10 1.30 0.20 0.40 0.00 0.00 98.10 https://opennet.me/openforum/vsluhforumID3/39553.html#122 Wed, 09 Jan 2008 12:54:34 GMT &gt;видимо он имел ввиду отсутствие возможности написать iptables ... -i eth1:1 ... <br><br>а...<br>ну так это ж не отдельный интерфейс, и даже не виртуальный :)<br>это просто label для алиаса, не более.<br>За сим -i eth1 == -i eth1:500<br> https://opennet.me/openforum/vsluhforumID3/39553.html#121 Wed, 09 Jan 2008 10:09:17 GMT видимо он имел ввиду отсутствие возможности написать iptables ... -i eth1:1 ...<br> https://opennet.me/openforum/vsluhforumID3/39553.html#120 Sun, 30 Dec 2007 20:57:37 GMT &gt;Ой, и вы ЭТО называете красивым и элегантным решением?!<br><br>Угу<br><br><br>&gt;Это же жуткий <br>&gt;костыль. Начать с того, что следует организовывать вообще схему фронтенд/бэкенд (необязательно <br>&gt;на одной машине). Если уж у вас такие DoS'ы, с которыми <br>&gt;справляется ядро.<br><br>кому следует орагнизовывать схему - тот организовывает схему.<br>А кому следует не принимать новый запрос в систему если загрузка выше нормы - тот не принимает запрос.<br><br><br>&gt;Далее, писать модуль ядра для отслеживания загрузки чего-то в юзерлэнде - это <br>&gt;криво.<br><br>загрузка системы пока что понятие одно на систему. А не на ядро или на юзерлевел.<br>"загрузки чего-то в юзерлэнде" звучит неразумно.<br><br><br>&gt;Такие вещи следует в юзерлэнде же и отрабатывать,<br><br>вообще неразумно.<br>Управлять user-level'ом из него же - ненадежно.<br><br>&gt;выдавая команду файрволу, который, кстати, может находиться на другой машине, равно как и <br>&gt;анализатор (на сервере же только датчики).<br><br>о какой команде ФАЕРВОЛУ идет речь? Мне кажеться Вы не уловили суть в принципе...<br><br><br>&gt;В ядре отсле https://opennet.me/openforum/vsluhforumID3/39553.html#119 Sun, 30 Dec 2007 20:40:39 GMT кроме апача источников нагрузки бывает немало<br> https://opennet.me/openforum/vsluhforumID3/39553.html#118 Sun, 30 Dec 2007 19:42:36 GMT Ой, и вы ЭТО называете красивым и элегантным решением?! Это же жуткий костыль. Начать с того, что следует организовывать вообще схему фронтенд/бэкенд (необязательно на одной машине). Если уж у вас такие DoS'ы, с которыми справляется ядро.<br><br>Далее, писать модуль ядра для отслеживания загрузки чего-то в юзерлэнде - это криво. Такие вещи следует в юзерлэнде же и отрабатывать, выдавая команду файрволу, который, кстати, может находиться на другой машине, равно как и анализатор (на сервере же только датчики). В ядре отслеживать, что конкретно не нравится процессу - слишком сложно.<br><br>Наконец, когда решением предлагается _написать_ модуль ядра (!) - тут уже лицемерно говорить, что в одной ОСи это можно сделать, в другой нет - специалист, на такое способный, сделает для любой, средства есть.<br><br>Другое дело, что это может быть невозможно даже при наличии специалиста - например, когда ДДОСили bash.org.ru, они не имели возможность поменять на машине netfilter на nf-hipac - тупо из-за VDS (решили доморощенным аналогом). https://opennet.me/openforum/vsluhforumID3/39553.html#117 Sun, 30 Dec 2007 19:29:22 GMT &gt;ага-ага. И эротические экзерцисы с ng_bpf и её своеобразным языком? <br>&gt;Опять же, поиск по маске вы так не сделаете. <br><br>Он не свобеобразный, а вполне себе обычный язык tcpdump. Который уже и так обязан знать любой сетевой админ. Так что новый язык учит не придется. <br><br>&gt;ага-ага. Только когда у вас 50-60 sip-устройств проще покрасить на шлюзе. <br>&gt;Тем более это куда более правильно с точки зрения безопасности, т.к. в <br>&gt;противном случае <br>&gt;_любой_ источник bulk-трафика может поставить раком voip, покрасив свой трафик как ему <br>&gt;вздумается. ы? <br><br>См. в другом комменте - к ipfw есть патч для dscp.<br><br>&gt;Вот для этого и нужен анализ по длине пакета и модули, которые <br>&gt;вам кажутся ненужными. <br>&gt;На примере того же skype: <br>&gt;Сначала отбираем udp пакеты + опр. длины. А потом уже отправляем на <br>&gt;L7-filter. <br>&gt;pf так может? <br><br>ipfw может. Пример в man ng_tag так и делает - сначала выбирается нужная длина пакета.<br><br>&gt;А с netgraph ещё помучиться придётся. <br><br>Не более, чем с модулями к iptables.<br><br>&gt;traffic path в картинка https://opennet.me/openforum/vsluhforumID3/39553.html#116 Sun, 30 Dec 2007 19:20:21 GMT &gt;А вот куда более жизненное DSCP матчить/выставлять - это да, не умеет <br>&gt;pf. <br><br>Есть патч для ipfw (емнип, даже в базе PRов). И он и без патча уже может матчить биты ECN и длину пакета.<br> https://opennet.me/openforum/vsluhforumID3/39553.html#115 Sun, 30 Dec 2007 19:18:08 GMT &gt;&gt;&gt; IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables. <br>&gt;&gt;&gt; Слишком много точек входа в ядро, код перегружен и глючит. <br>&gt;&gt; Самый ужас - это conntrack. Сам netfilter умеет скалиться на SMP, чего <br>&gt;&gt; не умеет PF.<br>&gt;<br>&gt; PF _отлично_ скалируется на SMP. Настолько отлично, насколько <br>&gt;отлично на SMP скалируется TCP/IP-стек вообще. С этим, правда, проблемы почти <br>&gt;везде. :( Но во FreeBSD уже давно есть netisr, где всё <br>&gt;хорошо. Пока речь не идёт о fragmentation/reassembly. :) <br><br>Ой. Шо, таки уже убрали один глобальный лок на весь PF ? Пока что на тестах файрволовна6-ке ipfw опережал в скорости pf, в среднем раза в полтора.<br><br>