Вышел (http://netfilter.org/news.html#2007-12-22) iptables 1.4.0 (http://netfilter.org/projects/iptables/downloads.html#iptabl...), спустя почти 3 года с момента выхода первого релиза ветки 1.3.x. В iptables 1.4 проведена существенная работа по улучшению поддержки IPv6, исправлено большое число ошибок. Кроме того, можно отметить появление базовой реализация инфраструктуры xtables, возможность восстановления состояний отдельных таблиц в iptables-restore (ключ -table), проведение работы по оптимизации производительности операций сортировки цепочек.URL: http://marc.info/?l=netfilter&m=119833164027492&w=2
Новость: http://www.opennet.me/opennews/art.shtml?num=13448
ключ -table в iptables-restore недавно нужен был, ток подумал и тут новость :)
есть слова.. с pf не сравнится..
> На мини-роутерах (aka домашний D-link) таки рулит бсд, или, линь?Embedded-системы -- вообще беседа отдельная. Строго говоря, для них и BSD, и Linux одинаково плохи.
Дело в том, что и Linux, и *BSD разрабатывались для машин с MMU. Нет, безусловно, и Linux, и BSD _в теории_ могут работать и без MMU (ну, не будет вам fork()'a, перебьётесь парой vfork()/exec(), никуда не денетесь). Но делают они это крайне хреново: надо algorithmic base менять. И в ядре, и в User Land'е.
Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного. Скажем так, если десять лет назад, увидев роутер на Линуксе, имело смысл немедленно оный Линукс снести, и поставить *BSD, то теперь это неактуально: да, будет чуть лучше, но овчинка выделки не стоит.
IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables. Слишком много точек входа в ядро, код перегружен и глючит.
Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает, по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Зато у PF есть таблицы. _Нормальные_ таблицы, обновляемые из User Land на лету, и поиск по которым осуществляется по RADIX Tree, а не по линейному списку. PF умеет якоря (anchors), и несколько программ, модифицирующих правила пакетного фильтра, _никогда_ не подерутся.
Но пакетный фильтр -- это не то, за что идёт борьба на роутере. На роутере идёт борьба за пакетную производительность. А она достигается использованием либо ASIC'ов, либо NPU. Period.
Спасибо, нормально объяснили. По-больше б таких камментов на ОпенНете
да, спасибо...
Интересно, почему под Линь только iptables?
А под бсд столько много фильтров?
Кстати, у Солярки есть API для пакетных фильтров?
> да, спасибо...
> Интересно, почему под Линь только iptables?Это неправда. Есть порт IP Filter под Linux.
> А под бсд столько много фильтров?
Потому, что они изначально не договорились, но обмениваются кодом.
Изначально был IP Firewall под BSDi. По его образу и подобию был сделан ipfw для FreeBSD. А для NetBSD Darren Reed (кстати, соавтор RFC на IRC :) написал IP Filter.
Потом IP Filter был спортирован под FreeBSD и OpenBSD. Потом Reed поменял лицензию, и Тео де Раадт, который, как обычно, хотел быть святее Папы Римского, вынес IP Filter из дерева исходников. А другой человек написал взамен PF.
> Кстати, у Солярки есть API для пакетных фильтров?
Нет. Но есть порт IP Filter для Solaris.
> да, спасибо...
> Интересно, почему под Линь только iptables?
> Это неправда. Есть порт IP Filter под Linux.Это тот, который IP filter -> IP chains -> IP tables?
Благородный дон не понимает разницы между IP Filter и ipfwadm?-)
Ааа... Это про тот IPFilter, который ipf и пишется слитно?
> Ааа... Это про тот IPFilter, который ipf и пишется слитно?Благородный дон не потрудится ли посетить http://coombs.anu.edu.au/~avalon/ и убедиться, что "IP Filter" пишется раздельно? Прям первая строчка на странице...
>> На мини-роутерах (aka домашний D-link) таки рулит бсд, или, линь?
>
>Embedded-системы -- вообще беседа отдельная. Строго говоря, для них и BSD, и
>Linux одинаково плохи.
>Дело в том, что и Linux, и *BSD разрабатывались для машин с
>MMU. Нет, безусловно, и Linux, и BSD _в теории_ могут работатьНе совсем понял какое отношение это имеет к вопросу о
>> На мини-роутерах (aka домашний D-link) таки рулит бсд, или, линь?мне показалось что вы говорили о задачах где решаются вопросы с сколько нибудь значимым трафиком а не в условиях "доманего" использования. Поправьте меня где я ошибся.
> Не совсем понял какое отношение это имеет к вопросу о
>>> На мини-роутерах (aka домашний D-link) таки рулит бсд, или, линь?
> мне показалось что вы говорили о задачах где решаются вопросы с сколько
> нибудь значимым трафиком а не в условиях "доманего" использования. Поправьте меня
> где я ошибся.Дело в том, что на домашних роутерах стоит одна задача -- удешевления. И поэтому там ставят настолько слабое железо, насколько это вообще возможно. И при таком раскладе вопрос, так сказать, "профпригодности" данной конкретной операционки выходит на первый план.
Ситуация примерно такая же, как и со смартфонами -- там ставят настолько слабый микропроцессор, насколько это вообще возможно, иначе не добиться сколь-нибудь разумного мобильного ресурса.
Никто не хочет заряжать батарею мобилки раз в 8-10 часов.
Никто не хочет платить за домашний роутер $300. Даже $300. Не говоря уже о большей сумме.
>Embedded-системы -- вообще беседа отдельная. Строго говоря, для них и BSD, и
>Linux одинаково плохи.
>Дело в том, что и Linux, и *BSD разрабатывались для машин с
>MMU. Нет, безусловно, и Linux, и BSD _в теории_ могут работать
>и без MMU (ну, не будет вам fork()'a, перебьётесь парой vfork()/exec(),
>никуда не денетесь). Но делают они это крайне хреново: надо algorithmic
>base менять. И в ядре, и в User Land'е.Сейчас железки без MMU - скорее экзотика.
>Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного.Если лучше, то почему куда ни плюнь в классе adsl роутеров/модемов & AP - попадёшь в linux?
>IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables.
>Слишком много точек входа в ядро, код перегружен и глючит.Самый ужас - это conntrack. Сам netfilter умеет скалиться на SMP, чего не умеет PF.
Да, сейчас и одноядерные процессоры весьма быстры, но когда у вас 4 гигабитных сетевухи и 2 ядра... хм, пакетный фильтр, болтающийся на одном cpu в случае DoS ничем не поможет.
> Сейчас железки без MMU - скорее экзотика.Да ладно уж, экзотика. Xscale далеко не везде.
>> Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного.
> Если лучше, то почему куда ни плюнь в классе adsl роутеров/модемов &
> AP - попадёшь в linux?Я обычно в VXWorks и его дериваты попадаю. Не туда плюю?-)
>> IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables.
>> Слишком много точек входа в ядро, код перегружен и глючит.
> Самый ужас - это conntrack. Сам netfilter умеет скалиться на SMP, чего
> не умеет PF.PF _отлично_ скалируется на SMP. Настолько отлично, насколько отлично на SMP скалируется TCP/IP-стек вообще. С этим, правда, проблемы почти везде. :( Но во FreeBSD уже давно есть netisr, где всё хорошо. Пока речь не идёт о fragmentation/reassembly. :)
>Да, сейчас и одноядерные процессоры весьма быстры, но когда у вас 4
>гигабитных сетевухи и 2 ядра... хм, пакетный фильтр, болтающийся на одном
>cpu в случае DoS ничем не поможет.Пакетный фильтр в случае DoS не поможет, будь он хоть сто раз скалируемый. :)
> Пакетный фильтр в случае DoS не поможет, будь
>он хоть сто раз скалируемый. :)ну 100kpps вполне реально получить на половине fast ethernet.
>> Пакетный фильтр в случае DoS не поможет, будь
>>он хоть сто раз скалируемый. :)
>
>ну 100kpps вполне реально получить на половине fast ethernet.Так сейчас так, втупую, никто не DoS'ит: микропроцессоры стали достаточно быстрыми для того, чтобы не заметить какие-то там 100 kpps. Хуже, когда DoS'ят целенаправленно сервис.
>Так сейчас так, втупую, никто не DoS'ит: микропроцессоры стали достаточно быстрыми для
>того, чтобы не заметить какие-то там 100 kpps. Хуже, когда DoS'ят
>целенаправленно сервис.ага, но остались ОС, в которых нет polling и которым от относительно небольших значений kpps становится плохо ;)
> ага, но остались ОС, в которых нет polling и которым от относительно
> небольших значений kpps становится плохо ;)Ну, в эпоху PCI Express (и даже PCI с Message-signalled Interrupts) это уже малоактуально. Да и сама идея MSI значительно более, так сказать, "пряма", нежели поллинг.
>>> IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables.
>>> Слишком много точек входа в ядро, код перегружен и глючит.
>> Самый ужас - это conntrack. Сам netfilter умеет скалиться на SMP, чего
>> не умеет PF.
>
> PF _отлично_ скалируется на SMP. Настолько отлично, насколько
>отлично на SMP скалируется TCP/IP-стек вообще. С этим, правда, проблемы почти
>везде. :( Но во FreeBSD уже давно есть netisr, где всё
>хорошо. Пока речь не идёт о fragmentation/reassembly. :)Ой. Шо, таки уже убрали один глобальный лок на весь PF ? Пока что на тестах файрволовна6-ке ipfw опережал в скорости pf, в среднем раза в полтора.
>[оверквотинг удален]
>AP - попадёшь в linux?
>
>>IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables.
>>Слишком много точек входа в ядро, код перегружен и глючит.
>
>Самый ужас - это conntrack. Сам netfilter умеет скалиться на SMP, чего
>не умеет PF.
>Да, сейчас и одноядерные процессоры весьма быстры, но когда у вас 4
>гигабитных сетевухи и 2 ядра... хм, пакетный фильтр, болтающийся на одном
>cpu в случае DoS ничем не поможет.Насчет SMP можно медленнее и подробнее ? Ксеоны 3.4 однако :
router:/# LANG=C mpstat -P ALL 10 3
Linux 2.6.23.14 (router) 01/17/0819:20:49 CPU %user %nice %system %iowait %irq %soft %idle intr/s
19:20:59 all 0.02 0.74 0.12 0.17 0.05 24.67 74.22 321.10
19:20:59 0 0.00 0.00 0.00 0.00 0.20 99.80 0.00 321.10
19:20:59 1 0.00 0.80 0.20 0.10 0.00 0.10 101.10 0.00
19:20:59 2 0.10 1.30 0.20 0.40 0.00 0.00 98.10 0.00
19:20:59 3 0.00 1.00 0.20 0.10 0.00 0.00 101.00 0.0019:20:59 CPU %user %nice %system %iowait %irq %soft %idle intr/s
19:21:09 all 0.02 1.25 0.37 0.05 0.05 24.64 73.62 361.90
19:21:09 0 0.00 0.00 0.00 0.00 0.20 99.80 0.00 361.90
19:21:09 1 0.00 2.00 0.30 0.10 0.00 0.00 103.40 0.00
19:21:09 2 0.00 1.30 0.80 0.10 0.00 0.20 97.60 0.00
19:21:09 3 0.10 1.70 0.40 0.00 0.00 0.10 98.50 0.0019:21:09 CPU %user %nice %system %iowait %irq %soft %idle intr/s
19:21:19 all 0.02 0.90 0.17 0.15 0.02 24.41 74.32 385.50
19:21:19 0 0.00 0.00 0.00 0.00 0.10 99.90 0.00 385.50
19:21:19 1 0.00 2.00 0.20 0.40 0.00 0.00 104.60 0.00
19:21:19 2 0.00 1.10 0.20 0.20 0.00 0.00 98.50 0.00
19:21:19 3 0.10 0.60 0.20 0.00 0.00 0.10 101.00 0.00Average: CPU %user %nice %system %iowait %irq %soft %idle intr/s
Average: all 0.02 0.97 0.22 0.12 0.04 24.57 74.05 356.17
Average: 0 0.00 0.00 0.00 0.00 0.17 99.83 0.00 356.17
Average: 1 0.00 1.60 0.23 0.20 0.00 0.03 103.03 0.00
Average: 2 0.03 1.23 0.40 0.23 0.00 0.07 98.07 0.00
Average: 3 0.07 1.10 0.27 0.03 0.00 0.07 100.17 0.00
>Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного.
>Скажем так, если десять лет назад, увидев роутер на Линуксе, имело
>смысл немедленно оный Линукс снести, и поставить *BSD.....Прочитал сие и сразу средце екнуло: неужели к нам сам Rusty Russell заглянул, либо, на худой конец, Алексей Кузнецов. Ан нет! Andrew Kolchoogin вынес свой окончательный вердикт и расставил все точки. Финал. Занавес. Аплодисменты.
Мое мнение. По функционалу BSD с PF отдыхает против связки iptables+iproute2 (в умелых руках, конечно). Всякие кивки про лучшую производительность BSD на 4 гигабитных сетевухах - бред. Нормальные провайдеры (и крупные сети) на нагруженных каналах используют магистральные маршрутизаторы. И только в России остаются уроды, ставящие на шлюзы транспортной сети BSDовые рутеры. Одного такого знаю - Ринет. Как же их колбасит при суммарном транзитном трафике 500 - 800 Гб в месяц! Я недавно от этого кошмара отключился - не нарадуюсь. (Да и Ринету на 100 Гб в месяц легче стало :-))
>[оверквотинг удален]
>>Скажем так, если десять лет назад, увидев роутер на Линуксе, имело
>>смысл немедленно оный Линукс снести, и поставить *BSD.....
>
>Прочитал сие и сразу средце екнуло: неужели к нам сам Rusty Russell
>заглянул, либо, на худой конец, Алексей Кузнецов. Ан нет! Andrew Kolchoogin
>вынес свой окончательный вердикт и расставил все точки. Финал. Занавес. Аплодисменты.
>
>
>Мое мнение. По функционалу BSD с PF отдыхает против связки iptables+iproute2 (в
>умелых руках, конечно).Аналог scrub и modulate state у iptables в студию.
> Всякие кивки про лучшую производительность BSD на 4
>гигабитных сетевухах - бред. Нормальные провайдеры (и крупные сети) на нагруженных
>каналах используют магистральные маршрутизаторы. И только в России остаются уроды, ставящие
>на шлюзы транспортной сети BSDовые рутеры. Одного такого знаю - Ринет.
>Как же их колбасит при суммарном транзитном трафике 500 - 800
>Гб в месяц! Я недавно от этого кошмара отключился - не
>нарадуюсь. (Да и Ринету на 100 Гб в месяц легче стало
>:-))Я знаю "Ринет" с 1996 года, на магистрали там _всегда_ стояли Циски. Сейчас там шеститонник+7206. А судя по запальчивости тона, проблемы, как всегда, на стороне клиента.
> Аналог scrub и modulate state у iptables в
>студию.Скажите, а часто вы на интенсивном трафике пользуетесь scrub & state modulation?
Да и пересборка пакетов - вещь затратная как по памяти, так и по cpu.А вот куда более жизненное DSCP матчить/выставлять - это да, не умеет pf.
Как и не умеет от SCTP, который во всю уже используется вменяемыми людьми.
И ECN не умеет, и по длине пакета матчить не может...
А вы говорите о каких-то полухакерских плюшках(passive os fingerprint из той же оперы).
> Я знаю "Ринет" с 1996 года, на магистрали
>там _всегда_ стояли Циски. Сейчас там шеститонник+7206. А судя по запальчивости
>тона, проблемы, как всегда, на стороне клиента.7206 - откровенное г-но.
> Скажите, а часто вы на интенсивном трафике пользуетесь scrub & state modulation?
> Да и пересборка пакетов - вещь затратная как по памяти, так и по cpu.Стоять. Вопрос был в возможностях пакетных фильтров.
Так что не надо увиливать. Аналоги в студию.
> А вот куда более жизненное DSCP матчить/выставлять - это да, не умеет pf.
Матчить умеет ALTQ, коему это, вообще говоря, и надо делать. А _выставлять_ DiffServ CodePoint пакетный фильтр вообще не должен, он _не_ генерирует TCP/IP-траффик.
> Как и не умеет от SCTP, который во всю уже используется вменяемыми людьми.
PF разрабатывается совместно с TCP/IP-стеком *BSD. А у *BSD с SCTP пока не всё ладно, что уж тут поделать. Только вот насчёт "вовсю" -- это явный перегиб. ;)
> И ECN не умеет, и по длине пакета матчить не может...
ECN тоже поддерживается в ALTQ, пакетному фильтру он плоскопараллелен. А за длину пакета -- не менее "полухакерская штучка" (C).
> 7206 - откровенное г-но.
Аминь! (C)
>Стоять. Вопрос был в возможностях пакетных фильтров.
>Так что не надо увиливать. Аналоги в студию.вы же прекрасно понимаете что прямых аналогов нет.
часть функционала есть в штатных модулях iptables. Тупо сравнивать "а у нас есть вот эта мегакрутая фича, а у вас нет" - это не путь к конструктиву :)))
Чего стоят модули string, connbytes, u32.
Кстати, а для чего вам state modulation?>Матчить умеет ALTQ, коему это, вообще говоря, и надо делать. А _выставлять_
>DiffServ CodePoint пакетный фильтр вообще не должен, он _не_ генерирует TCP/IP-траффик.Дал мне один isp впн для объединения регионов и спрашивает: "Вы сами трафик красить будете?"
>PF разрабатывается совместно с TCP/IP-стеком *BSD. А у *BSD с SCTP пока
>не всё ладно, что уж тут поделать. Только вот насчёт "вовсю"
>-- это явный перегиб. ;)SCTP используется везде где есть sigtran(т.е. это его часть ;))).
Так что используют весьма активно(та же cisco).>ECN тоже поддерживается в ALTQ, пакетному фильтру он плоскопараллелен. А за длину
>пакета -- не менее "полухакерская штучка" (C).ну почему же. зафильтровать skype/voip/syn-флуд и вообще как доп. проверка.
PS: а вот интересно, почему не обратили внимание на такую вещь: pf - это пакетный фильтр, а iptables - это скорее язык программирования правил фильтрации(переходы, возвраты, проверки условий, итп).
>> Стоять. Вопрос был в возможностях пакетных фильтров.
>> Так что не надо увиливать. Аналоги в студию.
> вы же прекрасно понимаете что прямых аналогов нет.Ну тогда и не надо кричать. Надо уметь честно признаваться, что "у нас вот этого вот нет, и это плохо".
> часть функционала есть в штатных модулях iptables. Тупо сравнивать "а у нас
> есть вот эта мегакрутая фича, а у вас нет" - это
> не путь к конструктиву :)))Это и есть путь к конструктиву, если фича _действительно_ мегакрутая, а не чушь типа сравнения длин пакетов.
> Чего стоят модули string, connbytes, u32.
Во FreeBSD есть значительно более общий способ исследования пакетов -- NetGraph. Но включая его, админ берёт на себя ответственность за снижение пакетной производительности маршрутизатора из-за удлинения packet flow path.
А вот в пакетный фильтр вставлять "тяжёлые" фичи, на мой взгляд, конечно -- совершенно не нужно.
> Кстати, а для чего вам state modulation?
Для защиты хостов за пакетным фильтром от SYN-based атак. А для чего вообще нужен пакетный фильтр, как не для защиты хостов за ним?-)
>> Матчить умеет ALTQ, коему это, вообще говоря, и надо делать. А _выставлять_
>> DiffServ CodePoint пакетный фильтр вообще не должен, он _не_ генерирует TCP/IP-траффик.
> Дал мне один isp впн для объединения регионов и спрашивает: "Вы сами
> трафик красить будете?"Правильно! Вот пусть какой-нибудь Asterisk и красит свой голосовой траффик! Он же его генерирует -- а пакетный фильтр-то тут при чём?!
>> PF разрабатывается совместно с TCP/IP-стеком *BSD. А у *BSD с SCTP пока
>> не всё ладно, что уж тут поделать. Только вот насчёт "вовсю"
>> -- это явный перегиб. ;)
> SCTP используется везде где есть sigtran(т.е. это его часть ;))).
> Так что используют весьма активно(та же cisco).Какие Юниксовые распространённые серверные приложения поддерживают SCTP?
>> ECN тоже поддерживается в ALTQ, пакетному фильтру он плоскопараллелен. А за длину
>> пакета -- не менее "полухакерская штучка" (C).
> ну почему же. зафильтровать skype/voip/syn-флуд и вообще как доп. проверка.SYN-флуд фильтруется PF'ным synproxy. Длины пакетов тут ни при чём.
А L7-filtering, опять-таки, IMHO, конечно, слишком "тяжёл" для того, чтобы его включать в пакетный фильтр, да и малопригоден в случае, например, смены протокола. Ядро хачить каждый раз?
Надо фильтрануть/зашейпить Skype/пиринговые сети -- NetGraph вам в руки, только вот зачем?..
> PS: а вот интересно, почему не обратили внимание на такую вещь: pf
> - это пакетный фильтр, а iptables - это скорее язык программирования
> правил фильтрации(переходы, возвраты, проверки условий, итп).Что называется английским словом "overbloated". :)
И вызывает сложности в отладке.
> Ну тогда и не надо кричать. Надо уметь
>честно признаваться, что "у нас вот этого вот нет, и это
>плохо".Ооох... заглянем в в man:
http://www.freebsd.org/cgi/man.cgi?query=pf.conf&apropos=0&s...no-df - есть.
min-ttl - есть
max-mss - есть
random-id - нет(реально, зачем оно надо?)fragment reassemble
Using scrub rules, fragments can be reassembled by normalization.
In this case, fragments are buffered until they form a complete
packet, and only the completed packet is passed on to the filter.
The advantage is that filter rules have to deal only with complete
packets, and can ignore fragments. The drawback of caching frag-
ments is the additional memory cost. But the full reassembly
method is the only method that currently works with NAT. This is
the default behavior of a scrub rule if no fragmentation modifier
is supplied.- потенциальный DoS на память. Опять же, зачем это?
fragment crop - опять же, зачем? (плюс fragment crop reassembly mechanism does not yet work with NAT.)
reassemble tcp - всё это есть в iptables.
> Это и есть путь к конструктиву, если фича
>_действительно_ мегакрутая, а не чушь типа сравнения длин пакетов.не сравнения, а матчинга по длине пакета.
> Во FreeBSD есть значительно более общий способ исследования
>пакетов -- NetGraph. Но включая его, админ берёт на себя ответственность
>за снижение пакетной производительности маршрутизатора из-за удлинения packet flow path.ага-ага. И эротические экзерцисы с ng_bpf и её своеобразным языком?
Опять же, поиск по маске вы так не сделаете.> А вот в пакетный фильтр вставлять "тяжёлые" фичи,
>на мой взгляд, конечно -- совершенно не нужно.iptables - модульный, в отличие от pf.
И кстати, как по-другому эти "тяжелые" фичи реализовать?
btw, написание модулей для iptables весьма просто + внятная документация.
>Для защиты хостов за пакетным фильтром от SYN-based
>атак. А для чего вообще нужен пакетный фильтр, как не для
>защиты хостов за ним?-)да ну? злоумышленник начнёт бомбить пакетами по 64к мелкими фрагментами и хосту с pf станет плоха. И state modulation - это костыль против ОС с плохой генерацией ISN, а не средство защиты от SYN-flood.
> Правильно! Вот пусть какой-нибудь Asterisk и красит свой
>голосовой траффик! Он же его генерирует -- а пакетный фильтр-то тут
>при чём?!ага-ага. Только когда у вас 50-60 sip-устройств проще покрасить на шлюзе.
Тем более это куда более правильно с точки зрения безопасности, т.к. в противном случае
_любой_ источник bulk-трафика может поставить раком voip, покрасив свой трафик как ему вздумается. ы?
> Какие Юниксовые распространённые серверные приложения поддерживают SCTP?cisco pgw-2200. И кстати, причём тут софт? pf стоит на роутере, а за роутером может быть целый зоопарк устройств.
>SYN-флуд фильтруется PF'ным synproxy. Длины пакетов тут ни
>при чём.ок, закройте pf'ом skype, не тронув dns & rtp.
> А L7-filtering, опять-таки, IMHO, конечно, слишком "тяжёл" для
>того, чтобы его включать в пакетный фильтр, да и малопригоден в
>случае, например, смены протокола. Ядро хачить каждый раз?Вот для этого и нужен анализ по длине пакета и модули, которые вам кажутся ненужными.
На примере того же skype:
Сначала отбираем udp пакеты + опр. длины. А потом уже отправляем на L7-filter.
pf так может?>Надо фильтрануть/зашейпить Skype/пиринговые сети -- NetGraph вам в
>руки, только вот зачем?..зачем? Чтобы несколько десятков юзеров не уложили всё торрентами, чтобы фильтровать нежелательный skype etc.
А с netgraph ещё помучиться придётся.>> PS: а вот интересно, почему не обратили внимание на такую вещь: pf
>> - это пакетный фильтр, а iptables - это скорее язык программирования
>> правил фильтрации(переходы, возвраты, проверки условий, итп).
> Что называется английским словом "overbloated". :)
> И вызывает сложности в отладке.в чём сложности? каждый модуль можно отлаживать отдельно, логика iptables весьма прозрачна, traffic path в картинках есть, производить действия над пакетом можно в любой момент. Хоть до nat, хоть после.
>>SYN-флуд фильтруется PF'ным synproxy. Длины пакетов тут ни
>>при чём.
>
>ок, закройте pf'ом skype, не тронув dns & rtp.кесарю кесарево знаете-ли
нюхач snort + snortsam
>Вот для этого и нужен анализ по длине пакета и модули, которые
>вам кажутся ненужными.
>На примере того же skype:
>Сначала отбираем udp пакеты + опр. длины. А потом уже отправляем на
>L7-filter.
>pf так может?Может см. выше
>кесарю кесарево знаете-ли
>нюхач snort + snortsamснорт даст куда большую нагрузку на cpu. Хотя бы потому что ему придётся слушать весь трафик(я уж не говорю о копировании данных в юзерланд).
>>Вот для этого и нужен анализ по длине пакета и модули, которые
>>вам кажутся ненужными.
>>На примере того же skype:
>>Сначала отбираем udp пакеты + опр. длины. А потом уже отправляем на
>>L7-filter.
>>pf так может?
>Может см. вышеООх... http://nuclight.livejournal.com/122098.html
"Стоит заметить, что не всякий L7 filtering может быть сделан с помощью ng_bpf - поскольку в этом ассемблере запрещены условные переходы назад и таким образом циклы, нельзя организовать, например, поиск фиксированной подстроки по заранее неизвестному (и никак не вычисляемому из других данных) смещению в пакете (то, что делает iptables -m string) - думается, в будущем будет написан netgraph-узел, который займется именно этим :)"
>>кесарю кесарево знаете-ли
>>нюхач snort + snortsam
>
>снорт даст куда большую нагрузку на cpu. Хотя бы потому что ему
>придётся слушать весь трафик(я уж не говорю о копировании данных в
>юзерланд).Ох, ну ведь можно-же хоть иногда думать на шаг вперед,а не воспринимать все в лоб !!!
Написано "нухач снорт" - совсем не трудно догадаться что сие есть отдельная машинка которая просто коллектит алерты и рассылает их посредством snortsam на пакетные фильтры ???>>>Вот для этого и нужен анализ по длине пакета и модули, которые
>>>вам кажутся ненужными.
>>>На примере того же skype:
>>>Сначала отбираем udp пакеты + опр. длины. А потом уже отправляем на
>>>L7-filter.
>>>pf так может?
>>Может см. выше
>
>ООх... http://nuclight.livejournal.com/122098.htmlПочетал, автор жжот, хотя для экспириенса полезно - но существуют другие пути решения
>
>"Стоит заметить, что не всякий L7 filtering может быть сделан с помощью
>ng_bpf - поскольку в этом ассемблере запрещены условные переходы назад и
>таким образом циклы, нельзя организовать, например, поиск фиксированной подстроки по заранее
>неизвестному (и никак не вычисляемому из других данных) смещению в пакете
>(то, что делает iptables -m string) - думается, в будущем будет
>написан netgraph-узел, который займется именно этим :)"А зачем ???, зачем вещать весь груз на одну лошадь ??? Идеология аля мелкософт :(
>Ох, ну ведь можно-же хоть иногда думать на шаг вперед,а не воспринимать
>все в лоб !!!
>Написано "нухач снорт" - совсем не трудно догадаться что сие есть отдельная
>машинка которая просто коллектит алерты и рассылает их посредством snortsam на
>пакетные фильтры ???вы алерты откуда получать будете? С сенсоров? В любом случае сенсоры должны мониторить почти весь проходящий трафик и сравнивать с сигнатурами.
>Почетал, автор жжот, хотя для экспириенса полезно - но существуют другие пути
>решениякакие?
>А зачем ???, зачем вещать весь груз на одну лошадь ??? Идеология
>аля мелкософт :(а как вы хотите? быстрее всего матчить в ядре.
>ага-ага. И эротические экзерцисы с ng_bpf и её своеобразным языком?
>Опять же, поиск по маске вы так не сделаете.Он не свобеобразный, а вполне себе обычный язык tcpdump. Который уже и так обязан знать любой сетевой админ. Так что новый язык учит не придется.
>ага-ага. Только когда у вас 50-60 sip-устройств проще покрасить на шлюзе.
>Тем более это куда более правильно с точки зрения безопасности, т.к. в
>противном случае
>_любой_ источник bulk-трафика может поставить раком voip, покрасив свой трафик как ему
>вздумается. ы?См. в другом комменте - к ipfw есть патч для dscp.
>Вот для этого и нужен анализ по длине пакета и модули, которые
>вам кажутся ненужными.
>На примере того же skype:
>Сначала отбираем udp пакеты + опр. длины. А потом уже отправляем на
>L7-filter.
>pf так может?ipfw может. Пример в man ng_tag так и делает - сначала выбирается нужная длина пакета.
>А с netgraph ещё помучиться придётся.
Не более, чем с модулями к iptables.
>traffic path в картинках есть, производить действия над пакетом можно в
>любой момент. Хоть до nat, хоть после.ipfw в этом еще гибче.
> Во FreeBSD есть значительно более общий способ исследования
>пакетов -- NetGraph. Но включая его, админ берёт на себя ответственность
>за снижение пакетной производительности маршрутизатора из-за удлинения packet flow path.Если фильтровать на уровне ядра через узлы NetGraph (а ipfw имеет свои узлы), скорость фильтрации возрастает чуть ли не в десять раз, если сравнивать с реализацией сходной функциональности на Pf на пользовательском уровне. Но идут работы по созданию узла NetGraph для Pf.
>А вы говорите о каких-то полухакерских плюшках(passive os fingerprint из той же
>оперы).Кстати, passive os fingerprinting в iptables поддерживается модулем OSF (OS fingerprint).
>А вот куда более жизненное DSCP матчить/выставлять - это да, не умеет
>pf.Есть патч для ipfw (емнип, даже в базе PRов). И он и без патча уже может матчить биты ECN и длину пакета.
> Аналог scrub и modulate state у iptables в
>студию.http://ozlabs.org/~rusty/index.cgi/2006/08/15
no scrubbing, but we do fragment reassembly because we use "-m state" and NAT, either of which requires connection tracking
>> Аналог scrub и modulate state у iptables в
>>студию.
>
>http://ozlabs.org/~rusty/index.cgi/2006/08/15
>
>no scrubbing, but we do fragment reassembly because we use "-m state"
>and NAT, either of which requires connection trackingЯ ж просил аналоги вполне конкретных вещей: "scrub" и "modulate state". И где они там?
>Я ж просил аналоги вполне конкретных вещей: "scrub" и "modulate state". И
>где они там?Вобщем-то, правильно сказали выше.
Некорректно требовать именно "аналога вот этой фишки". Нужно рассматривать проблему,
которая решается (или пытается быть решенной) этой фишкой - и уж сравнивать аналоги схем решения.scrub:
А аналоги проверки валидности TCP пакета и его пересборка в iptables есть:
-m state --state INVALID -j DROP - неправильные TCP флаги идут фтопкуа пересборка и так производится коннтреком. Нужно просто загрузить его модуль (или же он собран статикой) и все. Даже никаких правил не надо :)
modulate state:
iptables таким не занимается, в нем такого нет. И проблему нужно решать на корню: в ОСе, которая генерит плохие TCP seq ids.
> Я знаю "Ринет" с 1996 года, на магистрали
>там _всегда_ стояли Циски. Сейчас там шеститонник+7206. А судя по запальчивости
>тона, проблемы, как всегда, на стороне клиента.Тоже знаю Ринет и знаю, подтверждаю, что там циски, но фрю там любят. Не рекламы ради, но мне нравился Ринет, к сожалению я переехал, и теперь скучаю по нему.
>[оверквотинг удален]
>
>Мое мнение. По функционалу BSD с PF отдыхает против связки iptables+iproute2 (в
>умелых руках, конечно). Всякие кивки про лучшую производительность BSD на 4
>гигабитных сетевухах - бред. Нормальные провайдеры (и крупные сети) на нагруженных
>каналах используют магистральные маршрутизаторы. И только в России остаются уроды, ставящие
>на шлюзы транспортной сети BSDовые рутеры. Одного такого знаю - Ринет.
>Как же их колбасит при суммарном транзитном трафике 500 - 800
>Гб в месяц! Я недавно от этого кошмара отключился - не
>нарадуюсь. (Да и Ринету на 100 Гб в месяц легче стало
>:-))что вы плетёте??? какие 800 Гб - это 25 Гб в день
поверьте БСД способна перелопатить гораздо больше
Вы не думали, что просто их каналы были не такие уж широкие
> поверьте БСД способна перелопатить гораздо больше
> Вы не думали, что просто их каналы были не такие уж широкиеИздеваетесь, коллега?-)))
Там только на инфраструктуру MSK-IX гигабит. :)
> Издеваетесь, коллега?-)))
> Там только на инфраструктуру MSK-IX гигабит. :)Вообще-то я имел ввиду ширину внешних каналлов, но не в этом суть. Это всего лишь предположение, я не знаком с данным ИСП так-как проживаю в другом городе, более того - в другой стране. Исходя из Ваших слов могу предположить, что это довольно крупный провайдер и цифра в 800 Гб/мес просто смешная (мой домашний роутер/сервер отдаёт в Мир по 500 Гб/мес и это не считая трафика внутри страны, который во много раз больше).
ПС: Ко всем - Как надоели уже эти холивары, может хватит поносить системы которые вы не используете по тем или иным причинам. Ничего тут не поделаешь, ну не нравится мне Линух на сервере, ну нравится мне БСД, тут дело вкуса каждого. Ведь было время когда людей объединяла общая идея и небыло никакой разницы какую систему он использовал. Хочешь что-то изменить? - начни с себя.
>Ничего
>тут не поделаешь, ну не нравится мне Линух на сервере, ну
>нравится мне БСД, тут дело вкуса каждого.Без обид, но это первый признак непрофессионализма - исходить из личных предпочтений.
несмотря на то что в данной дискуссии я занимаю сторону iptables, мне нравится pf и его синтаксис.
Это потрясающе - мало того, что сам нифига не знает, дык ещё и других поучать берётся!>Дело в том, что и Linux, и *BSD разрабатывались для машин с
>MMU. Нет, безусловно, и Linux, и BSD _в теории_ могут работать
>и без MMU (ну, не будет вам fork()'a, перебьётесь парой vfork()/exec(),
>никуда не денетесь). Но делают они это крайне хреново: надо algorithmic
>base менять. И в ядре, и в User Land'е.Дело в том, что менять нужно то, что по недоразумению ты считаешь своим мозгом - оно явно не работает вообще. А вот Linux отлично работает без MMU: http://www.uclinux.org/
>Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного.
Бред. Linux как маршрутизатор - хорошо, как мультисервисный маршрутизатор - великолепен, бздя - терпимо.
>Скажем так, если десять лет назад, увидев роутер на Линуксе, имело
>смысл немедленно оный Линукс снести, и поставить *BSD, то теперь это
>неактуально: да, будет чуть лучше, но овчинка выделки не стоит.Вменяемые люди делают с точностью до наоборот - ставят открытую прошивку с Linux: dd-wrt к примеру: http://www.dd-wrt.com/
>IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables.
>Слишком много точек входа в ядро, код перегружен и глючит.Во истину идиот - что именно "глючит" помимо твоих перегревшихся от безуспешных попыток думать мозгов? Багрепорт сделал?
>Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает,
>по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Зато у PF есть таблицы."Пёс" с недоумками, рассуждающими о том с чем они знакомы весьма поверхностно.
> _Нормальные_ таблицы, обновляемые из User Land на
>лету, и поиск по которым осуществляется по RADIX Tree, а не по линейному списку.Таблицы там вполне нормальные, обновляю я их как раз из пространства пользователя, а как именно они сортируются мне до лампочки - главное что это происходит быстро.
> PF умеет якоря (anchors), и несколько программ, модифицирующих
>правила пакетного фильтра, _никогда_ не подерутся.За каким упырём нескольким программам модифицировать правила МСЭ одновременно?!
>Но пакетный фильтр -- это не то, за что идёт борьба на
>роутере. На роутере идёт борьба за пакетную производительность. А она достигается
>использованием либо ASIC'ов, либо NPU. Period.Idiot. В маршрутизаторе важно удобство конфигурации и спектр поддерживаемых протоколов плюс безопасность. Производительность по пакетам имеет решающее значение для коммутаторов.
Ну вот опять. Только дин думающий и вменяемый человек на опеннете высказался, как пришло двое, с личными комплексами и начали его грязью поливать, параллельно навешивая ярлыки и на своих провайдеров и на имя и фамилию человека, не побоявшегося подписаться.
Высказался может и правильно да вот только (ИМХО) не объективно
> Высказался может и правильно да вот только (ИМХО) не объективноНа OpenNet'е высказываются почти никогда не объективно: объективность _может_ быть достигнута только приведением результатов тестов. А может и _не быть достигнута_ -- постановка экспериментов -- это большое искусство.
На OpenNet'е высказываются, исходя из своего _личного_ опыта. Ну и неких общеизвестных вещей, легко устанавливаемых чтением документации.
> на имя и фамилию человека, не побоявшегося подписаться.Ну, я человек без комплексов, ФСБ не боюсь, так что подписываюсь везде и всегда реальным именем. :) И очень удивлён, что на OpenNet'е это необщепринятая практика. У участников форума схизис (расщепление личности) -- в RL одно, в Интернете -- другое?-)
> Это потрясающе - мало того, что сам нифига не знает, дык ещё
> и других поучать берётся!Гражданин, OpenNet -- не место, где показывают свои комплексы.
> Дело в том, что менять нужно то, что по недоразумению ты считаешь
> своим мозгом - оно явно не работает вообще. А вот Linux
> отлично работает без MMU: http://www.uclinux.org/Во-первых, я, видимо, по недоразумению считаю то, чем Вы смотрите в монитор, глазами. Я писал, что Linux и *BSD _могут_ работать без MMU. Но делают это _плохо_. Рекомендую читать всё, и внимательно. А почему плохо -- да потому, что весь User Land работает на модели fork(). Ну, написан он так был 30 лет назад.
>> Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного.
> Бред. Linux как маршрутизатор - хорошо, как мультисервисный маршрутизатор - великолепен,
> бздя - терпимо.Это частное, ничем не подкреплённое мнение, такое же, как и моё высказывание.
Но я не позволяю себе давать оценок типа "бред". Хотите полемики? Либо пишите IMHO, либо тесты в студию.
>> Скажем так, если десять лет назад, увидев роутер на Линуксе, имело
>> смысл немедленно оный Линукс снести, и поставить *BSD, то теперь это
>> неактуально: да, будет чуть лучше, но овчинка выделки не стоит.
> Вменяемые люди делают с точностью до наоборот - ставят открытую прошивку с
> Linux: dd-wrt к примеру: http://www.dd-wrt.com/Вменяемые люди понимают отличие домашней радиобалалайки от роутера.
>> IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables.
>> Слишком много точек входа в ядро, код перегружен и глючит.
> Во истину идиот - что именно "глючит" помимо твоих перегревшихся от безуспешных
> попыток думать мозгов? Багрепорт сделал?О да, делали. :))) Одно чинят, другое ломают. :))) Есть такая наука у Линуксоидов и Цисководов: подберите Линуксовое ядро/версию Cisco IOS, в котором не сломан нужный вам набор фич. ;)))
>> Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает,
>> по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Зато у PF есть таблицы.
> "Пёс" с недоумками, рассуждающими о том с чем они знакомы весьма поверхностно.Да-да-да, вот из-за таких вот недоумков, как Вы, почтенный, OpenNet превращается в LOR, ибо предмет Вы знаете, прямо скажем, не очень. ;)
>> _Нормальные_ таблицы, обновляемые из User Land на
>> лету, и поиск по которым осуществляется по RADIX Tree, а не по линейному списку.
> Таблицы там вполне нормальные, обновляю я их как раз из пространства пользователя,
> а как именно они сортируются мне до лампочки - главное что
> это происходит быстро.Я сейчас от смеха лопну. Вы, правда, не понимаете разницы между O(n) и O(log(n))?-) И почему это критично на обработке TCP/IP-траффика?-)
>> PF умеет якоря (anchors), и несколько программ, модифицирующих
>> правила пакетного фильтра, _никогда_ не подерутся.
> За каким упырём нескольким программам модифицировать правила МСЭ одновременно?!Что значит "за каким"? ftpsesame+обработчик UPnP на клиентском роутере. Вот и одновременно. Вы что, никогда клиентских роутеров не делали, да?
>> Но пакетный фильтр -- это не то, за что идёт борьба на
>> роутере. На роутере идёт борьба за пакетную производительность. А она достигается
>> использованием либо ASIC'ов, либо NPU. Period.
> Idiot. В маршрутизаторе важно удобство конфигурации и спектр поддерживаемых
> протоколов плюс безопасность.
> Производительность по пакетам имеет решающее значение для коммутаторов.Всё понятно. Аминь!
7604+куча LAN-карт -- это НЕ коммутатор. Но сетку на 10GigE на пол-Ленинграда держит. ;) Так что Вы сначала какую-нибудь сетку постройте диаметром больше, чем Ваша квартира, а потом судить беритесь.
>>> Linux, как роутер, безусловно плох. Впрочем, *BSD ненамного лучше. Лучше. Но ненамного.
>> Бред. Linux как маршрутизатор - хорошо, как мультисервисный маршрутизатор - великолепен,
>> бздя - терпимо.
>
> Это частное, ничем не подкреплённое мнение, такое же,
>как и моё высказывание.
>
> Но я не позволяю себе давать оценок типа
>"бред". Хотите полемики? Либо пишите IMHO, либо тесты в студию.При админе-эникейщике все пофиг - все равно работать не будет.
>>> Скажем так, если десять лет назад, увидев роутер на Линуксе, имело
>>> смысл немедленно оный Линукс снести, и поставить *BSD, то теперь это
>>> неактуально: да, будет чуть лучше, но овчинка выделки не стоит.Странно, а у меня выходит наоборот - ну не знаю я *BSD до такой степени, в результате под пингвином у меня работает надежнее чем под фряхой или опенком.
> Вменяемые люди понимают отличие домашней радиобалалайки от роутера.А еще есть маньяки, которые домой для личного пользования цисковские роутеры ставят....
>>> IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables.
>>> Слишком много точек входа в ядро, код перегружен и глючит.
>> Во истину идиот - что именно "глючит" помимо твоих перегревшихся от безуспешных
>> попыток думать мозгов? Багрепорт сделал?
>
> О да, делали. :))) Одно чинят, другое ломают.
>:))) Есть такая наука у Линуксоидов и Цисководов: подберите Линуксовое ядро/версию
>Cisco IOS, в котором не сломан нужный вам набор фич. ;)))По личному опыту: у BSD-шников не лучше. Иначе только в винде - там за админа все дяди из МС решают.
>>> Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает,
>>> по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Зато у PF есть таблицы.
>> "Пёс" с недоумками, рассуждающими о том с чем они знакомы весьма поверхностно.
>
> Да-да-да, вот из-за таких вот недоумков, как Вы,
>почтенный, OpenNet превращается в LOR, ибо предмет Вы знаете, прямо скажем,
>не очень. ;)Он не умеет по маку фильтровать? Хоть и действует только в рамках одной сетки, но полезно.
> При админе-эникейщике все пофиг - все равно работать не будет.Безусловно. Всё, что один человек сделал, другой завсегда сломать может. :)
Но это отдельная и, прямо скажем, весьма и весьма болезненная тема -- тема нехватки квалифицированных кадров. Правда, она не совсем для OpenNet'а. IMHO, конечно. :)
> Странно, а у меня выходит наоборот - ну не знаю я *BSD
> до такой степени, в результате под пингвином у меня работает надежнее
> чем под фряхой или опенком.Безусловно, знание есть вещь великая. Меня по-детски смешат высказывания на форумах, где люди мучаются с установкой FreeBSD на ноутбуки. Два ноута было -- на обоих Фря стояла, и не жужжала. ;) И сейчас я пишу с ноута из-под Фри. ;)
>> Вменяемые люди понимают отличие домашней радиобалалайки от роутера.
> А еще есть маньяки, которые домой для личного пользования цисковские роутеры ставят....Сложный вопрос. Их последняя 18'я серия, рассчитанная на MetroEthernet, стоит нормальных денег.
>> :))) Есть такая наука у Линуксоидов и Цисководов: подберите Линуксовое ядро/версию
>> Cisco IOS, в котором не сломан нужный вам набор фич. ;)))
> По личному опыту: у BSD-шников не лучше. Иначе только в винде -
> там за админа все дяди из МС решают.Опять-таки, по личному опыту: _сеть_ во FreeBSD за последние 11 лет не ломали _ни разу_. ATA ломали, USB ломали, а вот сеть -- не ломали.
> Он не умеет по маку фильтровать? Хоть и действует только в рамках
> одной сетки, но полезно.Нет, не умеет.
> Опять-таки, по личному опыту: _сеть_ во FreeBSD за
>последние 11 лет не ломали _ни разу_. ATA ломали, USB ломали,
>а вот сеть -- не ломали.em, bge в 6ке? или "это драйвера, не считается"?
> em, bge в 6ке? или "это драйвера, не считается"?У меня 6'ка с em работает два года, и ничего там не ломается. "Что я делаю не так?"
>> em, bge в 6ке? или "это драйвера, не считается"?
>У меня 6'ка с em работает два года, и ничего там не
>ломается. "Что я делаю не так?"т.е. то что творилось в freebsd-net & freebsd-current перед выпуском 6.2 - это галлюцинации?
>>> em, bge в 6ке? или "это драйвера, не считается"?
>> У меня 6'ка с em работает два года, и ничего там не ломается. "Что я делаю не так?"
> т.е. то что творилось в freebsd-net & freebsd-current перед выпуском 6.2 -
> это галлюцинации?А, это про импорт и откаты? Так это же _перед_ выпуском!
Вы бы почитали -current в момент строительства пятёрки... ;)
> 7604+куча LAN-карт -- это НЕ коммутатор. Но сетку
>на 10GigE на пол-Ленинграда держит. ;) Так что Вы сначала какую-нибудь
>сетку постройте диаметром больше, чем Ваша квартира, а потом судить беритесь.
>имеется ввиду, что он у вас core router?
ЗЫ постинги на редкость осмысленные для опеннет, спсб
>> 7604+куча LAN-карт -- это НЕ коммутатор. Но сетку
>> на 10GigE на пол-Ленинграда держит. ;) Так что Вы сначала какую-нибудь
>> сетку постройте диаметром больше, чем Ваша квартира, а потом судить беритесь.
> имеется ввиду, что он у вас core router?Не у меня, у tvoe.tv. Да, MPLS Core сделан на нескольких 7604'х. У меня core сделан на двух Cisco Catalyst 6506, но у меня L3 Switching, для энтерпрайзных сетей MPLS нужен редко.
> ЗЫ постинги на редкость осмысленные для опеннет, спсб
:) Спасибо за комплимент.
>А почему плохо -- да потому, что весь User
>Land работает на модели fork(). Ну, написан он так был 30
>лет назад.Так, теперь ещё и ядро с дистрибутивом путаем... вообще красота!
Ядро и базовые библиотеки отлично работают без MMU - см. приведённую ссылку.
Дистрибутивы, рассчитанные на работу без MMU соответственно имеют отлично работающий userland - где надо - пересобрано, где надо - переписано.
И в качестве лекарства от прогрессирующего маразма - не могло пользовательское окружение линукса быть написано 30 лет назад - тогда линукса ещё просто не было!> Вменяемые люди понимают отличие домашней радиобалалайки от роутера.
ну давай, докажи мне что точка доступа с dd-wrt это не роутер.
клоун, блин!>:))) Есть такая наука у Линуксоидов и Цисководов: подберите Линуксовое ядро/версию
>Cisco IOS, в котором не сломан нужный вам набор фич. ;)))с сиькой это известная история, а про линукс - снова брехня!
не утомился врать-то?> Я сейчас от смеха лопну. Вы, правда, не
>понимаете разницы между O(n) и O(log(n))?-) И почему это критично на
>обработке TCP/IP-траффика?-)Единственное чего я не понимаю - это какое отношение имеет генерируемый тобой бред к действительности? Покажи мне тест, где iptables сливает pf с соотношением n\log n при нагрузке в n пакетов в секунду.
> Что значит "за каким"? ftpsesame+обработчик UPnP на клиентском
>роутере. Вот и одновременно. Вы что, никогда клиентских роутеров не делали, да?ни сезам ни упнп не использовал ни разу - и всё отлично работает и все довольны.
по существу сказать нечего, да?> 7604+куча LAN-карт -- это НЕ коммутатор. Но сетку
>на 10GigE на пол-Ленинграда держит. ;) Так что Вы сначала какую-нибудь
>сетку постройте диаметром больше, чем Ваша квартира, а потом судить беритесь.Я работал с сетями городского масштаба, поэтому прекрасно осведомлён, что 7600 это ровно то же самое, что 6500 у сиськи. До недавнего времени там даже софт без проблем ставился между сериями: аппаратно они абсолютно одинаковы. Так что это именно коммутатор. Хороший коммутатор 3 уровня с поддержкой протоколов маршрутизации.
>> А почему плохо -- да потому, что весь User
>> Land работает на модели fork(). Ну, написан он так был 30
>> лет назад.
> Так, теперь ещё и ядро с дистрибутивом путаем... вообще красота!Извините, у нас принято говорить про работающую платформу.
Или ядро Линукса уже научилось грузиться непосредственно из BIOS'а?
Или grub/lilo стали частью ядра?
Так что отделять ядро от базовых библиотек/утилит -- это дурь красноглазых линуксоидов-дистростроителей.
> Ядро и базовые библиотеки отлично работают без MMU - см. приведённую ссылку.
_Далеко_ не отлично. У меня почему-то Apache 1.3 в этом окружении без кучи мегапатчей не работает. БА-А-А-АГА!!!
> Дистрибутивы, рассчитанные на работу без MMU соответственно имеют отлично
> работающий userland - где надо - пересобрано, где надо - переписано.Прелесть Юникса в том, что можно взять софт и собрать его, не переписывая под каждую платформу. Так вот, MMU-less Linux и NetBSD -- это некое странное поделие, претендующее на почти-POSIX-совместимость (нет fork() -- POSIX Incompatible, period.), которое делают исключительно для того, чтобы показать, что "и так мы тоже можем".
> И в качестве лекарства от прогрессирующего маразма - не могло пользовательское окружение
> линукса быть написано 30 лет назад - тогда линукса ещё просто не было!Во-первых, аккуратнее с тоном. У меня тоже есть масса соображений по поводу Вашего умственного уровня.
Во-вторых, можно написать что-то и год назад. Но написано это будет по образу и подобию того, что было 20-25-30 лет назад, ибо POSIX.>> Вменяемые люди понимают отличие домашней радиобалалайки от роутера.
> ну давай, докажи мне что точка доступа с dd-wrt это не роутер.Он умеет BGP? OSPF? Policy-based routing? CARP?
Радиобалалайка это для дома, а не роутер.
>> :))) Есть такая наука у Линуксоидов и Цисководов: подберите Линуксовое ядро/версию
>> Cisco IOS, в котором не сломан нужный вам набор фич. ;)))
> с сиькой это известная история, а про линукс - снова брехня!-- Но нет таких языков, в котором двойное утверждение обозначало бы отрицание...
-- Да ладно, профессор!В 2.6 ветке уже починили IP over ATM в недефолтных таблицах роутинга?-)
А зависание atmarpd?
> не утомился врать-то?
Это просто кто-то тут не в курсе, что бывает не только Fast Ethernet. :)
>> Я сейчас от смеха лопну. Вы, правда, не понимаете разницы между O(n) и O(log(n))?-)
>> И почему это критично на обработке TCP/IP-траффика?-)
> Единственное чего я не понимаю - это какое отношение имеет генерируемый тобой
> бред к действительности? Покажи мне тест, где iptables сливает pf с
> соотношением n\log n при нагрузке в n пакетов в секунду.Результаты или модель теста?
>> Что значит "за каким"? ftpsesame+обработчик UPnP на клиентском
>> роутере. Вот и одновременно. Вы что, никогда клиентских роутеров не делали, да?
> ни сезам ни упнп не использовал ни разу - и всё отлично
> работает и все довольны.Да? Не жалуются, почему файлы по аське не ходят?
Ну тогда Вам повезло. Для Москвы и Ленинграда такой уровень сервиса уже не прокатывает, где из-за NAT'а прямые соединения не работают.
> по существу сказать нечего, да?
Это Вам по существу сказать нечего. Весь ваш бред сводится к следующему: "Я не делал вот этого, этого и этого -- и у меня всё работает!"
А ещё можно просто всё выключить и уйти бухать.
>> 7604+куча LAN-карт -- это НЕ коммутатор. Но сетку
>> на 10GigE на пол-Ленинграда держит. ;) Так что Вы сначала какую-нибудь
>> сетку постройте диаметром больше, чем Ваша квартира, а потом судить беритесь.
> Я работал с сетями городского масштаба, поэтому прекрасно осведомлён, что 7600 это
> ровно то же самое, что 6500 у сиськи.Оп-па... А мужики-то и не знают...
> До недавнего времени там даже софт без проблем ставился между сериями: аппаратно
> они абсолютно одинаковы. Так что это именно коммутатор. Хороший коммутатор 3 уровня с
> поддержкой протоколов маршрутизации.Аминь! (C)
>>> А почему плохо -- да потому, что весь User
>>> Land работает на модели fork(). Ну, написан он так был 30
>>> лет назад.
> Или ядро Линукса уже научилось грузиться непосредственно из
>BIOS'а?да.
> _Далеко_ не отлично. У меня почему-то Apache 1.3
>в этом окружении без кучи мегапатчей не работает. БА-А-А-АГА!!!Андрей, вы же вроде адекватный человек...
А давайте туда постгрес с 50гиговой базой впендюрим? Или jvm...
(из той же серии, что и ваш вопрос).
> Прелесть Юникса в том, что можно взять софт
>и собрать его, не переписывая под каждую платформу. Так вот, MMU-less
>Linux и NetBSD -- это некое странное поделие, претендующее на почти-POSIX-совместимость
>(нет fork() -- POSIX Incompatible, period.), которое делают исключительно для того,
>чтобы показать, что "и так мы тоже можем".оно там работает и вполне успешно. Написание своего - куда более затратно.
> Он умеет BGP? OSPF? Policy-based routing? CARP?
да. и carp в linux ядерный, и стейты все сохраняются.
> В 2.6 ветке уже починили IP over ATM
>в недефолтных таблицах роутинга?-)ох, опять вы про ipoatm. 2.6 в железках вроде дсл-роутеров скорее исключение из правил.
> Это просто кто-то тут не в курсе, что
>бывает не только Fast Ethernet. :)ага. а много ли pf знает о чём-то, отличном от ip/tcp/udp/icmp?
> Да? Не жалуются, почему файлы по аське не
>ходят?
>Ну тогда Вам повезло. Для Москвы и Ленинграда
>такой уровень сервиса уже не прокатывает, где из-за NAT'а прямые соединения
>не работают.pf & active ftp, pf & sip, pf & dcc в irc, pf & pptp?
>> Или ядро Линукса уже научилось грузиться непосредственно из
>>BIOS'а?
>
>да.Это как сказать, где-то умеет, с использованием "мегахаков", а где то нет. Есть openbios построенный на linux ядре, но грузицо он не везде и не всегда. ИМХО сей проект пока что глубокой преальфе, и говорить что оно работает еще рано, можно сказать "потенциально может" но не более ....
>
>да. и carp в linux ядерный, и стейты все сохраняются.Пока carp в глубокой бетте, bgp-fullview домашния радоибалалайка не потянет по причине отсутсвия нормального проца и достаточного кол-ва мозгов, с ospf тоже самое
>ага. а много ли pf знает о чём-то, отличном от ip/tcp/udp/icmp?
А оно ему надо ?
Зато про то что он знает он знает на очень приличном уровне - уровне комерческих решений, а это совсем не мало !!!>
>pf & active ftp, pf & sip, pf & dcc в irc,
>pf & pptp?ftp-proxy, pptp-proxy, sip-proxy, про dcc не знаю поэтому ничего сказать не могу, но имхо bi-nat это вполне может решить :)
>Пока carp в глубокой бетте, bgp-fullview домашния радоибалалайка не потянет по причине
>отсутсвия нормального проца и достаточного кол-ва мозгов, с ospf тоже самоенасчёт беты: вы где прочитали?
зачем домашнему роутеру принимать fullview?
ospf с небольшим числом роутеров и достаточно стабильной сети вполне потянет.
>>ага. а много ли pf знает о чём-то, отличном от ip/tcp/udp/icmp?
>А оно ему надо ?
>Зато про то что он знает он знает на очень приличном уровне
>- уровне комерческих решений, а это совсем не мало !!!мда, как обычно "это нам не надо".
Типичный openbsd-way: виртуализация несекурна - это нам не надо. HT несекурно, это нам не надо. Многоядерные процессоры несекурны - это нам не надо.
Подключение по ethernet несекурно - могут трафик слушать. может и его того, а?>ftp-proxy, pptp-proxy, sip-proxy, про dcc не знаю поэтому ничего сказать не могу,
>но имхо bi-nat это вполне может решить :)так и думал что будет юзерспейсовые костыли.
50-60 человек активно качающих по ftp и ftp-proxy "уложит" роутер.
Насчёт pptp-proxy:
"The proper way of forwarding PPTP is to use native kernel NAT, but it isn't always easy, feasible or even implemented properly. pptpproxy was written for these situations."А binat вам не поможет.
>>Пока carp в глубокой бетте, bgp-fullview домашния радоибалалайка не потянет по причине
>>отсутсвия нормального проца и достаточного кол-ва мозгов, с ospf тоже самое
>
>насчёт беты: вы где прочитали?В рассылках, до сих пор существует проблемы которые не позволяют использовать carp и ucarp в решениях выше класса "на поигратцо", следовательно , бетта :)
>
>зачем домашнему роутеру принимать fullview?
>ospf с небольшим числом роутеров и достаточно стабильной сети вполне потянет.А потому как использование bgp без анализа fullview практически бессмысленно. Насчет ospf примерно тоже - немного легче, но похоже.
>>>ага. а много ли pf знает о чём-то, отличном от ip/tcp/udp/icmp?
>>А оно ему надо ?
>>Зато про то что он знает он знает на очень приличном уровне
>>- уровне комерческих решений, а это совсем не мало !!!
>
>мда, как обычно "это нам не надо".
>Типичный openbsd-way: виртуализация несекурна - это нам не надо. HT несекурно, это
>нам не надо. Многоядерные процессоры несекурны - это нам не надо.я-же говорил что кесарю кесарево, нужно просто уметь находить оптимальные решения, для каких-то вещей наиболее оптимальные выход это применения проприетарной системы на кучу килобаксов, для другого наоборот. В этом-то все и дело, а зацикливацо на одном варианте - есть путь ущербный и неправильный. ИМХО.
>
>Подключение по ethernet несекурно - могут трафик слушать. может и его
>того, а?см. выше
>
>>ftp-proxy, pptp-proxy, sip-proxy, про dcc не знаю поэтому ничего сказать не могу,
>>но имхо bi-nat это вполне может решить :)
>
>так и думал что будет юзерспейсовые костыли.
>50-60 человек активно качающих по ftp и ftp-proxy "уложит" роутер.Нет (с)
>Насчёт pptp-proxy:
>"The proper way of forwarding PPTP is to use native kernel NAT,
>but it isn't always easy, feasible or even implemented properly. pptpproxy
>was written for these situations."Абсолютно правильно бекоз pptp таже самая отрыжка прошлого как и ipx/spx, appletalk, но сохранять возможность использования пока еще надо. По крайней мере с l2tp таких проблем не возникает :)
>В рассылках, до сих пор существует проблемы которые не позволяют использовать carp
>и ucarp в решениях выше класса "на поигратцо", следовательно , бетта
>:)а мы с вами об одном и том же говорим?
я про http://tservice.net.ru/~s0mbre/old/?section=projects&item=carp
>А потому как использование bgp без анализа fullview практически бессмысленно. Насчет ospf
>примерно тоже - немного легче, но похоже.ну взять сеточку из одной area, 20-30 роутеров, трафик - макс. 5-6мбит.
и чего тут не хватит?>я-же говорил что кесарю кесарево, нужно просто уметь находить оптимальные решения, для
>каких-то вещей наиболее оптимальные выход это применения проприетарной системы на кучу
>килобаксов, для другого наоборот. В этом-то все и дело, а зацикливацо
>на одном варианте - есть путь ущербный и неправильный. ИМХО.а не проще тогда забыть о fw ОС общего назначения и поставить pix/netscreen/checkpoint?
И вообще не заморачиваться с pf/ipfw/etc?
>а мы с вами об одном и том же говорим?
>я про http://tservice.net.ru/~s0mbre/old/?section=projects&item=carpДа именно, не так пока еще хорошо вылизано как в исходной ОС, второе не понятна почему похерена совмесимость.
It is based on OpenBSD CARP protocol but is not compatible with it since OpenBSD implementation does not contain protection against repeated message sending attack.
>ну взять сеточку из одной area, 20-30 роутеров, трафик - макс. 5-6мбит.
>
>и чего тут не хватит?Мы про bgp или ospf ?:)
>
>а не проще тогда забыть о fw ОС общего назначения и поставить
>pix/netscreen/checkpoint?
>И вообще не заморачиваться с pf/ipfw/etc?Нет. Выбор того или иного решения должен определяться с точки зрения эффективности данного решения, а не нравицо/не нравицо.
>Да именно, не так пока еще хорошо вылизано как в исходной ОС,
>второе не понятна почему похерена совмесимость.
>It is based on OpenBSD CARP protocol but is not compatible with
>it since OpenBSD implementation does not contain protection against repeated message
>sending attack.а зачем? логика работы разная, функционал - тоже.
>>ну взять сеточку из одной area, 20-30 роутеров, трафик - макс. 5-6мбит.
>>и чего тут не хватит?
>Мы про bgp или ospf ?:)area чаще всего контексте ospf упоминается ;)))
>Нет. Выбор того или иного решения должен определяться с точки зрения эффективности
>данного решения, а не нравицо/не нравицо.всеми руками за.
>>It is based on OpenBSD CARP protocol but is not compatible with
>>it since OpenBSD implementation does not contain protection against repeated message
>>sending attack.
>
>а зачем? логика работы разная, функционал - тоже.Ну вот об этом и речь, так как сам по себе голый carp не очень-то и нужен, как я уже говорил "на поиграцо", а вот когда к нему могут привязыватся и синхронизороваться такие вещи как fw states, ipsec SA и пр. вот тогда это уже что-то серьезное получается :)
>area чаще всего контексте ospf упоминается ;)))
В контексте opennet приходится переспришивать уж не обижайтесь :)
Я могу потдтвердить или опровергнуть потянут или нет эти балалайки такую нагрузку, но сомнения гложут. Даже если просто посчитать 6 балалаек в одной area это получается 6*(6-1)/2=30 LS на каждой.
>
>>Нет. Выбор того или иного решения должен определяться с точки зрения эффективности
>>данного решения, а не нравицо/не нравицо.
>
>всеми руками за.Во-во поэтому крики что "данная ОС" мегарулез форева режет слух :)
>[оверквотинг удален]
>>>it since OpenBSD implementation does not contain protection against repeated message
>>>sending attack.
>>
>>а зачем? логика работы разная, функционал - тоже.
>
>Ну вот об этом и речь, так как сам по себе голый
>carp не очень-то и нужен, как я уже говорил "на поиграцо",
>а вот когда к нему могут привязыватся и синхронизороваться такие вещи
>как fw states, ipsec SA и пр. вот тогда это уже
>что-то серьезное получается :)дык стейты iptables синхронизируются, иначе смысла нет.
Аффтар просто написал что "с pf оно несовместимо".
>Во-во поэтому крики что "данная ОС" мегарулез форева режет слух :)именно.
>> В 2.6 ветке уже починили IP over ATM
>> в недефолтных таблицах роутинга?-)
> ох, опять вы про ipoatm. 2.6 в железках вроде дсл-роутеров скорее исключение
> из правил.Я не про IPoATM.
Я про Ваш предыдущий пост. Я писал, что Linux чем-то схож с Cisco -- игра "найдите ядро с несломанными фичами".
Вы сказали, что я написал бред.
Я Вам привёл опровергающий пример.
Вы отказываетесь от своих слов?
> Я про Ваш предыдущий пост. Я писал, что
>Linux чем-то схож с Cisco -- игра "найдите ядро с несломанными
>фичами".
>
> Вы сказали, что я написал бред.
>
> Я Вам привёл опровергающий пример.
>
> Вы отказываетесь от своих слов?да, есть такое дело, что что-то ломают. никто от этого не застрахован.
вопрос: а соляра (10) в этом смысле лучше/быстрее или хуже/медленнее Linux или BSD (если использовать SPARC, AMD64) тестировать буду в 08 для 100-150 бит на пакет траффика (ну вы поняли) -- интересно ваше мнение
> вопрос: а соляра (10) в этом смысле лучше/быстрее или хуже/медленнее Linux или
> BSD (если использовать SPARC, AMD64) тестировать буду в 08 для 100-150
> бит на пакет траффика (ну вы поняли) -- интересно ваше мнениеСложный вопрос. Как маршрутизатор, или как платформа для какого-то сервиса?
как генератор помех на канале для тестирования в ims (те умный бридж)ЗЫ байт на пакет...
> как генератор помех на канале для тестирования в ims (те умный бридж)
> ЗЫ байт на пакет...Я бы взял FreeBSD. На нём есть dummynet, который, собственно, для такого тестирования и был придуман -- это потом им люди шейпить стали, а Luigi, его автор, сначала называл их извращенцами, а потом смирился со своей участью. ;)
>IP Tables _сильно_ хуже PF'а, но это из-за самой архитектуры IP Tables.
>Слишком много точек входа в ядро, код перегружен и глючит.
>Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает,
>по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Затовыдержки из man iptables
mac
--mac-source [!] address
Match source MAC address. It must be of the form
XX:XX:XX:XX:XX:XX. Note that this only makes sense for packets
coming from an Ethernet device and entering the PREROUTING, FOR-
WARD or INPUT chains.
>у PF есть таблицы. _Нормальные_ таблицы, обновляемые из User Land на
>лету, и поиск по которым осуществляется по RADIX Tree, а не
>по линейному списку. PF умеет якоря (anchors), и несколько программ, модифицирующих
>правила пакетного фильтра, _никогда_ не подерутся.Так же неверная информация.
Не стоит забывать, что дропать покеты с бОльшей производительностью можно с помощью iproute>Но пакетный фильтр -- это не то, за что идёт борьба на
>роутере. На роутере идёт борьба за пакетную производительность. А она достигается
>использованием либо ASIC'ов, либо NPU. Period.Т е вы утверждаете что пакетный фильтр слабо влияет на "пакетную производительность"? Это мягко говоря неверно 8-).
> выдержки из man iptablesВы невнимательно читаете мои комментарии.
Именно это я и написал. Что PF _не_ знает ничего про L2, а NetFilter знает.
В любом случае, спасибо за документальное подтверждение моих слов. ;)
> Так же неверная информация.
В смысле? У PF нет таблиц?-) pf.conf(5) Вас в этом легко разубедит. ;)
> Не стоит забывать, что дропать покеты с бОльшей производительностью можно с помощью
> iprouteЗачем их дропать? Задача маршрутизатора -- их не дропать. ;)
>> Но пакетный фильтр -- это не то, за что идёт борьба на
>> роутере. На роутере идёт борьба за пакетную производительность. А она достигается
>> использованием либо ASIC'ов, либо NPU. Period.
> Т е вы утверждаете что пакетный фильтр слабо влияет на "пакетную производительность"?
> Это мягко говоря неверно 8-).Как ни странно, слабо.
При правильной его настройке, конечно. Если использовать таблицы вместо линейного списка правил, использовать state filtering и ещё несколько техник, то слабо.
Безусловно, если нарисовать 10 000 "dummy"-правил фильтрации линейным списком, то пакетная производительность, мягко говоря, несколько снизится. ;)
А теперь, внимание, вопрос: а зачем так делать?-)
> Безусловно, если нарисовать 10 000 "dummy"-правил фильтрации линейным
>списком, то пакетная производительность, мягко говоря, несколько снизится. ;)
> А теперь, внимание, вопрос: а зачем так делать?-)сеть /22, каждому хосту в ней зарезать полосу в 1Мбит.
На ipfw есть хоть динамические правила, а в pf?
> сеть /22, каждому хосту в ней зарезать полосу в 1Мбит.
> На ipfw есть хоть динамические правила, а в pf?А PF вообще полос не режет. Но altq спасёт отца русской демократии. :)
>> сеть /22, каждому хосту в ней зарезать полосу в 1Мбит.
>> На ipfw есть хоть динамические правила, а в pf?
>
>А PF вообще полос не режет. Но altq спасёт отца русской демократии.
>:)altq - часть pf ;)
>>> сеть /22, каждому хосту в ней зарезать полосу в 1Мбит.
>>> На ipfw есть хоть динамические правила, а в pf?
>>
>>А PF вообще полос не режет. Но altq спасёт отца русской демократии.
>>:)
>
>altq - часть pf ;)altq не часть pf :) Просто pf умеет с работать с очередями. Но должную функциональность должна реализовывать сетевая карта.
>> сеть /22, каждому хосту в ней зарезать полосу в 1Мбит.
>> На ipfw есть хоть динамические правила, а в pf?
>
>А PF вообще полос не режет. Но altq спасёт отца русской демократии.
>:)Вы явно подробно с PF не знакомились. PF может управлять шейпингом.
>> Безусловно, если нарисовать 10 000 "dummy"-правил фильтрации линейным
>>списком, то пакетная производительность, мягко говоря, несколько снизится. ;)
>> А теперь, внимание, вопрос: а зачем так делать?-)
>
>сеть /22, каждому хосту в ней зарезать полосу в 1Мбит.
>На ipfw есть хоть динамические правила, а в pf?В PF есть возможно динамически изменять правила через механизм якорей. PF вообще значительное мощнее, функциональней и несколько быстрее ipfw на пользовательском уровне. На уровне ядра (через NetGraph) ipfw превосходит по производительности Pf на пользовательском уровне в разы.
>[оверквотинг удален]
>Слишком много точек входа в ядро, код перегружен и глючит.
>Да, PF умеет фильтровать только IP-пакеты. Про Ethernet он ничего не знает,
>по MAC-адресу им не зафильтруешь. Ну и пёс с ним. Зато
>у PF есть таблицы. _Нормальные_ таблицы, обновляемые из User Land на
>лету, и поиск по которым осуществляется по RADIX Tree, а не
>по линейному списку. PF умеет якоря (anchors), и несколько программ, модифицирующих
>правила пакетного фильтра, _никогда_ не подерутся.
>Но пакетный фильтр -- это не то, за что идёт борьба на
>роутере. На роутере идёт борьба за пакетную производительность. А она достигается
>использованием либо ASIC'ов, либо NPU. Period.Знает PF об ethernet. Есть там возможность фильтровать по мас-адресам на основе политик. Возможно немного вас не допонял. Я о том?
пакетный фильтр в случае ДоС как раз и спасает,
особенно pf с лимитами
>пакетный фильтр в случае ДоС как раз и спасает,
>особенно pf с лимитамиОсобенно, когда DoS'ят Апач, вызывая динамический контент. Загрузка проца взлетает до 50-60, а лимиты всё ещё не исчерпаны. Ибо NAT'ы везде, и "задвигать" их сильно вниз некошерно.
>Особенно, когда DoS'ят Апач, вызывая динамический контент.у нормальных людей опач работает бэкэндом. А такую паразитную активность весьма просто пресечь, ограничив число входящих SYN в ед. времени экспоненциально.
Чуть более сложные меры вообще исключат подобный сценарий, оставив только возможность полностью забить канал входящим трафиком(но от этого никто не застрахован).
>>Особенно, когда DoS'ят Апач, вызывая динамический контент.
> у нормальных людей опач работает бэкэндом.И что? Он от этого как-то сильно меньше CPU Time кушать начинает?
> А такую паразитную активность весьма просто пресечь, ограничив число входящих SYN
> в ед. времени экспоненциально.Exponential Backoff в данном случае совершенно бесполезен, так как это лишь _одна из возможных реакций_ на активность с некоторого IP-адреса. Тупой сброс соединений -- это, если хотите, EB после предельного перехода. :)
Ну и что? Всё равно микропроцессор на Apache просядет. Как не выкручивайся. Потому, что не за'backoff'ить каждый конкретный IP без риска за'backoff'ить огромную сеть за NAT'ом.
А вот разговоры в ключе "ну и сами виноваты, пусть меняют провайдера" я считаю тупиковыми.
> Чуть более сложные меры вообще исключат подобный сценарий, оставив только
> возможность полностью забить канал входящим трафиком(но от этого никто не застрахован).Почему, можно попытаться прогнуть апстрима на RSVP. :)))
> И что? Он от этого как-то сильно меньше
>CPU Time кушать начинает?Да с cpu time не проблема. Опач обычно в prefork гоняют, так что чаще упираешься в пямять.
Да и кеширование на фронтенде решает ;))> Ну и что? Всё равно микропроцессор на Apache
>просядет. Как не выкручивайся. Потому, что не за'backoff'ить каждый конкретный IP
>без риска за'backoff'ить огромную сеть за NAT'ом.Имхо, слабый DoS должен никак не сказываться на работе сервиса. А что-то более заметное будет иметь вполне очевидный профиль. И, кстати, борьба с DoS - это всегда компромисс и риск false positives.
> А вот разговоры в ключе "ну и сами
>виноваты, пусть меняют провайдера" я считаю тупиковыми.+1
PS: спасибо за адекватную и достаточно сдержанную дискуссию.
>> И что? Он от этого как-то сильно меньше CPU Time кушать начинает?
> Да с cpu time не проблема. Опач обычно в prefork гоняют, так
> что чаще упираешься в пямять.Согласен.
> Да и кеширование на фронтенде решает ;))Далеко не всегда.
В большинстве случаев, с которыми мне приходилось встречаться, Web-код написан, прямо скажем, не очень хорошо. Не сказать жёстче: руки бы повырывать. ;) И "агрессивное" кэширование приводит к появлению stale pages. А "кооперативное" кэширование на фронтэнде при помощи какого-нибудь memcached ещё в Web-код встраивать надо, а в плохой код его встроить просто невозможно.
> Имхо, слабый DoS должен никак не сказываться на работе сервиса. А что-то
> более заметное будет иметь вполне очевидный профиль. И, кстати, борьба с
> DoS - это всегда компромисс и риск false positives.Равно, как и борьба со спамом. Подписываюсь под каждым словом.
Пакетный фильтр вас не спасет при DOS-е службы. Уж слишком низкий может оказаться порог для дос аткаки. Обычный index.php какого-нибудь треклятого форумного движка может быть целеноправленно атакован сравнительно небольшим количеством запросом и ваш фильтр даже не сможет выделить эти аномалии из фона, а апач будет буксовать глотая последние мегабайты свопа.
> Обычный index.php какого-нибудь треклятого форумного движкаindex.php ещё, как правило, переживаемо. А вот index.pl может уже на 50 запросах/сек ТА-А-А-АК раскорячить Apache... :)
ОФФ: Andrew Kolchoogin, респект за грамотную дискуссию. Кое-что "открыл" для себя, что следовало бы знать уже лет 8 как, чьорт побьери. Век живи - век учись! :-)Побольше бы таких участников конференций. Может, и с квалификацией кадров получше стало бы? :-)
PS Просьба не обращать внимания на профессиональных флеймогонов - это единственное, что они знают толком.
>ОФФ: Andrew Kolchoogin, респект за грамотную дискуссию. Кое-что "открыл" для себя, что
>следовало бы знать уже лет 8 как, чьорт побьери. Век живи
>- век учись! :-)
>Побольше бы таких участников конференций. Может, и с квалификацией кадров получше стало
>бы? :-)
>PS Просьба не обращать внимания на профессиональных флеймогонов - это единственное, что
>они знают толком.Андрюша, хватит уже отвешивать себе комплименты с помощью виртуалов - смотреть противно!
Так и до дурки не далеко...
>Андрюша, хватит уже отвешивать себе комплименты с помощью виртуалов - смотреть противно!Так и до дурки не далеко...
гоЗть - хорош трепаться - санитары идут! ,)
Ну а по теме - молодец Андрей. А ты - ламо ,) Причем знаешь об этом от того и сопли-слюни агресивность ,)
>> Обычный index.php какого-нибудь треклятого форумного движка
>
> index.php ещё, как правило, переживаемо. А вот index.pl
>может уже на 50 запросах/сек ТА-А-А-АК раскорячить Apache... :)Не надо наезжать на Perl, ибо связка mod_perl + Apache дает очень хорошую производительность.
> Не надо наезжать на Perl, ибо связка mod_perl + Apache дает очень
> хорошую производительность.Упаси меня Ларри наезжать на Perl. Просто PHP-интерпретатор легче перлового.
впику Вашей нелюбви к Netfilterпроблема: DoS на вебсервис и границы синов далеки до реакции, а апач, как выше выразилиьсь, доедает своп...
Что делать BSD админу - неизвестно.А вот в Линухе проблема имеет вид даже некоторого решения.
Пишеться модуль, который в зависимости от нагрузки на CPU и/или винта и/или память, принимает или дропает пакет, собирается для текущего ядра и загружается в него.Аналогичный модуль-собрат пишется и для user-level iptables тулзы.
Все границы/лимиты задаются параметрами этого user-level модуля из команды iptables.Зависимость на род нагрузки исчезает. Это может быть сколь угодно плохой и неоптимальный пользовательский код.
В результате: можно вести разговор о дропе новых соединений, если загрузка системы и/или этих 3-х подсистем выше заданной. А также, совмещать эти лимиты с другими сетевыми ограничениями.
На практике получается более чем красивое и элегантное решение.
Например: в зависимости от нагрузки (уровни нагрузки: 5-10, 10-20, 20-30...) регулируется количество одновременных коннектов из /24 сетки (например: 50, 30, 10...). И даже глубина битности измеряемых сетей: /24, /25, /26....
В результате имеем более равномерное распределение мощностей системы между клиентами в условиях DoS'a.Чем бы порадовал PF?
могу ошибаться -- но как мне думается тут и писать ничего не придётся
проблему можно будет решить например так
несколько recent (в зависимости от нагрузки) соответственным образом помечают пакет (-j MARK)
а потом в зависимости от марки используем limit
дописать модуль к тому же apache, чтоб он рулил этой политикой, тогда можно хоть электрическим реле провода размыкать. это ниразу не дело ядра.
кроме апача источников нагрузки бывает немало
Ой, и вы ЭТО называете красивым и элегантным решением?! Это же жуткий костыль. Начать с того, что следует организовывать вообще схему фронтенд/бэкенд (необязательно на одной машине). Если уж у вас такие DoS'ы, с которыми справляется ядро.Далее, писать модуль ядра для отслеживания загрузки чего-то в юзерлэнде - это криво. Такие вещи следует в юзерлэнде же и отрабатывать, выдавая команду файрволу, который, кстати, может находиться на другой машине, равно как и анализатор (на сервере же только датчики). В ядре отслеживать, что конкретно не нравится процессу - слишком сложно.
Наконец, когда решением предлагается _написать_ модуль ядра (!) - тут уже лицемерно говорить, что в одной ОСи это можно сделать, в другой нет - специалист, на такое способный, сделает для любой, средства есть.
Другое дело, что это может быть невозможно даже при наличии специалиста - например, когда ДДОСили bash.org.ru, они не имели возможность поменять на машине netfilter на nf-hipac - тупо из-за VDS (решили доморощенным аналогом). Да, хостер был плохой (потом сменили), да, отслеживание и перекрытие DoS'ов вообще задача хостера, ну вот такие были условия, что поделать...
Отсюда, кстати, видно, что предложенный к написанию модуль тем более хуже - сыграет на руку DDoS'у, дропая, возможно, вполне легитимные коннекты - не те критерии ибо.
>Ой, и вы ЭТО называете красивым и элегантным решением?!Угу
>Это же жуткий
>костыль. Начать с того, что следует организовывать вообще схему фронтенд/бэкенд (необязательно
>на одной машине). Если уж у вас такие DoS'ы, с которыми
>справляется ядро.кому следует орагнизовывать схему - тот организовывает схему.
А кому следует не принимать новый запрос в систему если загрузка выше нормы - тот не принимает запрос.
>Далее, писать модуль ядра для отслеживания загрузки чего-то в юзерлэнде - это
>криво.загрузка системы пока что понятие одно на систему. А не на ядро или на юзерлевел.
"загрузки чего-то в юзерлэнде" звучит неразумно.
>Такие вещи следует в юзерлэнде же и отрабатывать,вообще неразумно.
Управлять user-level'ом из него же - ненадежно.>выдавая команду файрволу, который, кстати, может находиться на другой машине, равно как и
>анализатор (на сервере же только датчики).о какой команде ФАЕРВОЛУ идет речь? Мне кажеться Вы не уловили суть в принципе...
>В ядре отслеживать, что конкретно
>не нравится процессу - слишком сложно.:))
улыбнуло.
Вообще-то это и есть задача ядра: отслеживать все что кому нравится и что нет.
Наиболее эффективно управлять как минимум траффиком и процессами - из ядра.>Наконец, когда решением предлагается _написать_ модуль ядра (!) - тут уже лицемерно
>говорить, что в одной ОСи это можно сделать, в другой нетпредполагается отсутствие даунтайма на загрузкку нового ядра.
Netfiler модуль вставляется находу.
Если PF умеет это же - тогда все описанное может и он. Собственно, в этом был вопрос.
>- специалист, на такое способный, сделает для любой, средства есть.неспециалист сидит дома или учится
>Другое дело, что это может быть невозможно даже при наличии специалиста -
>например, когда ДДОСили bash.org.ru, они не имели возможность поменять на машине
>netfilter на nf-hipac - тупо из-за VDS (решили доморощенным аналогом).
>Да, хостер был плохой (потом сменили), да, отслеживание и перекрытие DoS'ов вообще задача хостерадык, под такой проект, ессьно, нужен лишь выделенный сервер с возможностью менять в системе по желанию что угодно.
>Отсюда, кстати, видно, что предложенный к написанию модуль тем более хуже -
>сыграет на руку DDoS'у, дропая, возможно, вполне легитимные коннекты - не
>те критерии ибо.расширьте сознание. Предлагаемый модуль НЕ дропает ничего.
Он умеет отслеживать загрузку. И именно в связке с другими методами ограничения дает неплохие результаты.
Наш новый гуру нам все объяснил!Как же он смог подняться на такие высоты? После небольшого поиска все встало на свои места:
http://www.behigh.org/drugs/substances/parkopan/overview.htmlВидим ниже
Andrew Kolchoogin 2:5020/118.22 Thu 06 Apr 95 19:54Это давно, всерьез и похоже навсегда.
Извините за оффтоп, но ві такими выпадами похожи на журналиста желтой прессы, который вместо веских аргументов кричит "Ба, да он же пидар (наркоман, алкоголик, нужное подчеркнуть)".))))
> Извините за оффтоп, но ві такими выпадами похожи на журналиста желтой прессы,
> который вместо веских аргументов кричит "Ба, да он же пидар (наркоман,
> алкоголик, нужное подчеркнуть)".))))Да хоть всё сразу. :) Мне приятно ощущать свою уникальность в антиобщественности.
Только вот какая незадача: гугл индексирует и этот сайт, и этот форум. И когда-нибудь кто-нибудь попытается поискать опусы этих граждан, и что он найдёт?-)
Не рой другому яму -- пусть сам роет. ;)
Может быть я и есть журналист желтой прессы, откуда вам знать?
А завтра напишу статью "Сисадмины-наркоманы идут на город" или "Величие и позор русской школы системного администрирования".Что касается непосредственно темы, то я это просто ради интереса посмотрел, чтобы понимать, с кем имею дело, когда хотел вступить в дискуссию по вопросу.
Учитывая безапелляционный тон и однобокую аргументацию данного участника дискуссии желание вступать в нее пропало, да тем и лучше, ибо в споре, как известно, никакой истины нет, а есть только ересь и отстаивание собственных заведомо верных точек зрения.
Ну а запостил я так, шутки ради, очень уж смешным мне это показалось.
> Видим ниже
> Andrew Kolchoogin 2:5020/118.22 Thu 06 Apr 95 19:54
>
> Это давно, всерьез и похоже навсегда.Кроме IT, в мире есть ещё много увлекательных наук. Химия, например. Или математика. А с компактными (то есть, с замкнутыми и ограниченными) людьми на OpenNet'е мне встречаться
крайне странно. ;)
KdF, спасибо посмеялся. Гугл очень силен =)
Хочется вериться, что Andrew Kolchoogin все таки находиться в трезвом уме по понедельникам.Andrew Kolchoogin, спасибо за комментарии.
> KdF, спасибо посмеялся. Гугл очень силен =)Да, Гугль про меня много разного рассказывает. :)
> Хочется вериться, что Andrew Kolchoogin все таки находиться в трезвом уме по
> понедельникам.Абсолютно. Химия и физиология психотомиметиков перестала меня интересовать примерно лет восемь назад.
Замечательная дискуссия.Андрей - вопрос, если можно:
"Где учат" кошерной работе с пакетными фильтрами? На самом деле интересует "идеология".
Ответ может выглядеть так: средства отладки такие-то, best-practice вот такая-то и т.д.
Почитав Ваши посты про ускорение работы ПФ узнал несколько новых подходов в написанию правил, очень забавно. :) Система может получиться очень красивой.
> Андрей - вопрос, если можно:
>
> "Где учат" кошерной работе с пакетными фильтрами? На самом деле интересует "идеология".Да вот, здесь, на OpenNet'е. Если, конечно, отфильтровывать гон от дискуссий.
> Ответ может выглядеть так: средства отладки такие-то, best-practice вот такая-то и т.д.
Если бы всё было так просто... ;)
И еще вопрос:Вы действительно где-то используете RSVP?
> Вы действительно где-то используете RSVP?Нет, конечно.
мда, виртуальные интерфейсы по прежнему не поддерживаются.
>мда, виртуальные интерфейсы по прежнему не поддерживаются.пардон
поясните что именно не поддерживается?
видимо он имел ввиду отсутствие возможности написать iptables ... -i eth1:1 ...
>видимо он имел ввиду отсутствие возможности написать iptables ... -i eth1:1 ...а...
ну так это ж не отдельный интерфейс, и даже не виртуальный :)
это просто label для алиаса, не более.
За сим -i eth1 == -i eth1:500