Новый пакетный фильтр для борьбы с флудом на уровне Linux ядра

tcp syn flood тоже уже научились блокировать?

Насколько я понял из обсуждения на lkml, это абсолютно тупая штука. Ему можно только скормить список IP адресов, MAC адресов или портов для DROP/ACCEPT. За счёт этого ест очень мало памяти.

Так и не понял, можно ли это будет использовать параллельно с netfilter (iptables, iproute2, ipset)?

syn cookies не то?

>Насколько я понял из обсуждения на lkml, это абсолютно тупая штука.

Для провайдеров возможность первичной обработки пакетов - не бесполезная штука. Например, можно защитить DNS, VPN или непосредственно подключить к первичной сети и фильтровать явный DoS или флуд.

дежавю?????????????????

Поддерживаю. в особенности в городских сетях, где частенько есть рассаднички всевозможной живности... хотя втаких случаях управляхи рулят)

s/в таких

>> Насколько я понял из обсуждения на lkml, это абсолютно тупая штука.

>Для провайдеров возможность первичной обработки пакетов - не бесполезная штука.

Я сказал не "бесполезная", а "тупая". В чём польза - сам прекрасно представляю. Киски сосут.

Кстати, сколько стоит циска, способная динамически блочить миллион IP адресов? ;-)

интересненько.
также ждем аналога accf_http

2012ый год, новый фильтр для борьбы с троллями на уровне Linux ядра, имеет вычислять троллей по комбинациям слов вроде BSD RIP

> От ipset новая система отличается тем, что поддерживает блокирование на уровне драйвера e1000.

Юниксвейненько. Такими темпами недолго и в киску привратиться.

> также ждем аналога accf_http

Адски специализированная вещь, если верить гуглу. Насколько часто используется в реальной жизни? Включена ли в основную ветку FreeBSD?
Не лучше ли с точки зрения идеологии поставить перед апачем фронтенд типа nginx?

Предлагаю сразу написать аналоги, ожидающие HELO/EHLO и USER xxx, с изменяемыми через sysctl приветствиями для каждого из сервисов соответственно.

> Такими темпами недолго и в киску привратиться.

Киске до нас по производительности и стабильности ещё пахать и пахать. Гнилая проприетарщина.

Хотя да, замечание справедливое.

>Не лучше ли с точки зрения идеологии поставить перед апачем фронтенд типа nginx?

с точки зрения производительности не очень - таки юзерспейс..

>>Не лучше ли с точки зрения идеологии поставить перед апачем фронтенд типа nginx?

>с точки зрения производительности не очень - таки юзерспейс..

А kHTTPd ( http://www.fenrus.demon.nl/ ) случайно не умеет как прокси работать?
Раз уж так важен кернелспейс.

Правда что-то давно о нём не слышно.

Ура? Теперь-то модерасты на ЛОРе не нужны? Флуд будет резаться на ЛОРовском серваке прямо на уровне ядра?

Ещё некий tux был.

>Насколько я понял из обсуждения на lkml, это абсолютно тупая штука.

для временного дешевого бана со стороны постфикса или апача это то, что надо.

>А kHTTPd ( http://www.fenrus.demon.nl/ ) случайно не умеет как прокси работать?

умеет, но уже давно закопали

>>Не лучше ли с точки зрения идеологии поставить перед апачем фронтенд типа nginx?

>с точки зрения производительности не очень - таки юзерспейс..

Да и по поводу производительности можно поспорить. nginx всё-таки обслуживает всю отдачу, нагружая апач действительно по минимуму, а accf_http ждёт только запроса, после чего соединение полностью отдаётся апачу. Нет?

>для временного дешевого бана со стороны постфикса или апача это то, что надо.

в паре с каким-нибудь fail2ban ваще красиво получицо

Я сказал не "бесполезная", а "тупая".

>nginx всё-таки обслуживает всю отдачу, нагружая апач действительно по минимуму

нгиникс тока статику самостоятельно отдавать умеет - все остальное тупо перекидывает бэкэнду.

>accf_http ждёт только запроса, после чего соединение полностью отдаётся апачу

он ждет правильного запроса, поэтому горы таймвейтов отсутствуют

ну и конечно бесспорная польза нгиникса помимо этого - обработка location

> нгиникс тока статику самостоятельно отдавать умеет - все остальное тупо перекидывает бэкэнду.

энджинЫкс, если уж на то пошло.

Ой ли?
AFAIK, nginx держит соединение с клиентом, одновременно общаясь с apache. И если отдача apache завершилась сильно раньше окончания отдачи контента клиенту, apache уже отдыхает, а трудится nginx.
AFAIK, nginx работает именно как прокси. Иначе он не давал бы таких чудесных результатов.

>Я сказал не "бесполезная", а "тупая".

Ну так оное и хорошо. Уже есть умный iptables. А вот тупого секатора, чтоб отбривал тысячи говноедов за еду, не хватало...

> Ну так оное и хорошо. Уже есть умный iptables. А вот тупого секатора, чтоб отбривал тысячи говноедов за еду, не хватало...

Вот и договорились. :-)
Словом "тупая" я не хотел никого обидеть. :-)

У самого десяток роутеров с 50К правил в iptables на каждом. Будем посмотреть.

Если мне память не изменяет, то эту новость уже постили.

> Киски сосут.

Не материтесь (киска -- это то же, что cunt по-английски).

Кроме того, произносится "сиско" по-американски, можно "циско" по-русски (это два последних слога из названия всем известного города в Калифорнии).

> Если мне память не изменяет, то эту новость уже постили.

На ОпенНЕТе?

>Кроме того, произносится "сиско"

сиськи сосут?

> Не материтесь (киска -- это то же, что cunt по-английски).

Извините. Никого не хотел обидеть. Не учёл, что на LORе столь чувствительная и воспитанная публика. Будь Вы девушкой - пришёл бы с цветами и оркестром под окна прощения просить.

>У самого десяток роутеров с 50К правил в iptables на каждом. Будем посмотреть.

для таких дел еще важно, можно ли быстро и надежно грузить/удалять/модифицировать правила фильтра поодиночке и списком. То есть нужна удобная юзерспейсная либа.

> для таких дел еще важно, можно ли быстро и надежно грузить/удалять/модифицировать правила фильтра поодиночке и списком.

Есть претензии к iptables-restore ?
Конфиги генерятся самописными скриптами, загружаются через wget + iptables-restore, на всё про всё менее десяти секунд. Происходит ПОЛНОЕ обновление конфигурации. iptables-restore занимает две-три секунды.

?

Но сабж посмотрю. :-)

Да, забыл уточнить. Jeffrey Merkey хоть в педерастии замечен и не был, но под подозрением ходил. Пытался linux купить за 50 килобаксов, и вообще никакого уважения к iptables: обматерил в сабжевом сообщении.

>Есть претензии к iptables-restore ?

Вот нехорошо это. Для программы-фильтра лучше бы прикомпилиться к iptables и за миллисекунды только добавлять и удалять разницу в состояниях.

>Пытался linux купить за 50 килобаксов,

то есть передаст в плохом смысле?

> Jeffrey Merkey хоть в педерастии замечен

Он был замечен в зоологическом антимормонизьме и антиновелизьме. Ну и в алкоголизьме. Хотя это его характеризует скорее положительно.

> Кроме того, произносится "сиско" по-американски, можно "циско" по-русски

Нет, "сиська" :-)

>> Я сказал не "бесполезная", а "тупая".

> Ну так оное и хорошо. Уже есть умный iptables. А вот тупого секатора, чтоб отбривал тысячи говноедов за еду, не хватало...

Так там же нигде и не говороилось, что это плохо =)

>> также ждем аналога accf_http
>
>Адски специализированная вещь, если верить гуглу. Насколько часто используется в реальной жизни? Включена ли в основную ветку FreeBSD?
Вещь очень удобная и простая в обращении, затыкает основной недостаток в Apache это нехватка процессов и отжирание не вероятного количиества памяти при медленных клиентах. В основной ветки наверное с 4 версии
>Не лучше ли с точки зрения идеологии поставить перед апачем фронтенд типа nginx?
Лучше, но его надо настраивать, а там включил и оно работает
>...
>anonymous (*) (14.01.2009 1:09:14)

>tcp syn flood тоже уже научились блокировать?

давно и успешно. только у cisco есть как минимум три набора устройств.

http://www.cisco.com/en/US/products/ps6235/index.html
хоть два миллиона, и даже не адресов а одновременных соединений, на скоростях до 16-ми гигабит/с, и не просто блочить а анализировать, отсекать паразитный трафик не трогая валидные пакеты.

кто по-традиции хочет сказать что cisco сосет и в линуксе есть хоть намек на подобную функциональность, с удовольствием послушаю.

SO_ACCEPTFILTER не то?

Стоимость?

~25000$

Плюс шасси 6500/7600, или шасси уже включено?

есть разные модели деплойментс
аплайнсы где включено действительно все, и суп, и шасси и линейные платы. все это добро (если покупать вместе) вложиться в ~60000.
6500/7600 - это почти стандарт в ЦОД-ах или датацентрах, так что я бы не стал путать цену устройства и цену инфраструктуры, хотябы еще потому, что 6500/7600 исполняют еще кучу функций, г топику не относящихся.