Jeffrey Merkey представил (http://lkml.org/lkml/2009/1/8/467) в списке рассылки разработчиков Linux ядра код нового специализированного пакетного фильтра FF, предназначенного для блокирования большого числа IP адресов в сетях с интенсивным трафиком. FF состоит из модуля Linux ядра и утилиты для управления пакетным фильтром. Представленный пакетный фильтр не отличается такой гибкостью как iptables, но опережает последний по производительности (блокирование производится на уровне драйвера e1000) и потребляет значительно меньше памяти в расчете на один IP.
Главная задача FF - защита от DoS/DDoS атаки и блокирование различного флуда и паразитного трафика. В качестве примера, представлен код для интеграции разработки с postfix, для борьбы с роботами спамеров, выступая в роли более жесткой системы блокирования для серых или черных списков. На почтовом сервере с 1Гб ОЗУ 500,000URL: http://lkml.org/lkml/2009/1/8/467
Новость: http://www.opennet.me/opennews/art.shtml?num=19731
Зачем сокращение такое? FF - это Firefox.
>Зачем сокращение такое? FF - это Firefox.Firefox - Fx
давно уже.
>Зачем сокращение такое?
мне одному показалось что текст обрывается на полу-слове?
Попытка содрать связку pf+spamd ?
http://www.onlamp.com/pub/a/bsd/2007/01/18/greylisting-with-...
ага.
а ещё и добавить:
>От ipset новая система отличается тем, что поддерживает блокирование на уровне драйвера e1000.
>Главная задача FF - защита от DoS/DDoS атак, блокирование различного флуда и паразитного трафика.
и как поведет себя spamd при 3-4 тыс коннектов к нему?
Не поверите - нормально. На работе стоит на машине дуал п3-800 с 512 мегами памяти и 10мегабитным спам каналом. В оригинале, без спамд, сервак обрабатывал окло 10-15 тысч спам писем. Эксчендж, живущий ЗА постфиксом просто охреневал. Сейчас у мен нормальная загрузка на эксчендже и не тормозящий смтп-сервак, которые рубит спам.
>Не поверите - нормально. На работе стоит на машине дуал п3-800 с 512 мегами памяти и 10мегабитным спам каналом. В оригинале, без спамд, сервак обрабатывал окло 10-15 тысч спам писем.10-15 тыс писем в какую единицу времени то?
в одной маленькой конторе, где я когда-то работал почтовый трафик был 80тыс писем в сутки.
>в одной маленькой конторе, где я когда-то работал почтовый трафик был 80тыс
>писем в сутки.а процент полезной информации?
За час-два. Когда как. Вот цифири:Информация получена скриптиком с calomel.org
***** Spamd Stats on *****
Script run on: Mon Jan 12 2009 at 13:39 in 42 second(s)
Data Range: Jan 11 14:00:02 to Jan 12 13:40:03Time spammers wasted: 1039.37 hours
Total bandwith used: 100.54 megabytes
Average time per tarpit: 0.37 minutes
Unique ip addresses tarpitted: 12135
Total connections made: 167457т.е. за сутки имеем 167500 подключений, которые "зохавал" spamd. Подозреваю что для конторы с 150 почтовыми ящиками спама больше 90%.
А вот результат pflogsumm:
Grand Totals
------------
messages2361 received
2738 delivered
0 forwarded
59 deferred (1271 deferrals)
76 bounced
2 rejected (0%)
0 reject warnings
0 held
0 discarded (0%)343236k bytes received
369136k bytes delivered
350 senders
196 sending hosts/domains
608 recipients
176 recipient hosts/domainsдве с небольшим тысячи обработанных постфиксом писем меркнут на фоне 167 тысяч, которые ему не пришлось обрабатывать.
load averages: 1.21, 1.35, 1.38
61 processes: 60 idle, 1 on processor
CPU0 states: 4.8% user, 0.0% nice, 2.0% system, 0.0% interrupt, 93.2% idle
CPU1 states: 0.0% user, 0.0% nice, 0.2% system, 0.0% interrupt, 99.8% idle
Memory: Real: 107M/283M act/tot Free: 215M Swap: 41M/512M used/tot
................
11853 _spamd 2 0 12M 9140K sleep/0 select 80.6H 1.46% spamd
21354 _spamd 10 0 8936K 556K sleep/0 nanosl 964:41 0.34% spamd
24921 _spamd -6 0 8828K 476K sleep/0 piperd 792:30 0.00% spamd
>Jeffrey Merkey представил (http://lkml.org/lkml/2009/1/8/467) в списке рассылки разработчиков Linux ядра код нового
>специализированного пакетного фильтра FF, предназначенного для блокирования большого числа IP адресов
>в сетях с интенсивным трафиком.Ну наконец-то!
А то маршрутизатор D-Link с Linux'ом пропускает в первую очередь IP-пакеты только от Linux-машин, а все остальные соединения обслуживает в последнюю очередь.
>А то маршрутизатор D-Link с Linux'ом пропускает в первую очередь IP-пакеты только от Linux-машина... можно подробней?
не флуда ради, а образования для.
> >А то маршрутизатор D-Link с Linux'ом пропускает в первую очередь IP-пакеты только от >Linux-машин
>
>а... можно подробней?
>не флуда ради, а образования для.Действительно замечал такое, думал что кажется, ан нет, я не один такой.
ЗЫ: Поменял D-Link на Zyxel, все стало ровно...
D-Link я конечно вообще за аппаратуру не считаю, но...
должно же быть объективное объяснение?
специально... через iptables и прочие извраты я могу представить как это сделать, но чтобы вот так.. на голой машише....
може там ядро проверить/пересобрать?
Запустил параллельно:
* обновление Linux Mint 5.1 -> 6
* обновление портов FreeBSD 7.1-RELEASEТак вот, архивы с исходниками на FreeBSD переставали качаться и скорость скачки быстро понижалась до ~100 байтов в минуту. В это время Linux Mint качал -- дай боже! Вручную отсоединяю патчкорд машины с Linux Mint от ADSL-роутера и как по волшебству скорость закачки архивов на FreeBSD увеличивалась до полной скорости соединения с провайдером. На FreeBSD запущен пакетный фильтр PF с нормализацией всех пакетов на сетевом интерфейсе. На Linux Mint чего-то такого из сетевых экранов специально не настраивалось (похоже, флуд и есть).
Вот и решайте про "избирательность" Linux TCP-стека к разным архитектурам.
>Вот и решайте про "избирательность" Linux TCP-стека к разным архитектурам.вот это не надо... у меня например специально настроено на приоритет винды (даже ttl там разные)
а вот остальное - интересно.
как девайс то точно называется?
может удастся достать и посмотреть.да и adsl (какой?) - вещь интересная... плавали. знаем... критична к настройкам.
особенно на плохих каналах.
поставите фриху - может быть с точностью до наоборот.
>а вот остальное - интересно.
>как девайс то точно называется?D-Link DSL-504T
>может удастся достать и посмотреть.
Вряд ли. Это старенький домашний роутер.
>да и adsl (какой?) - вещь интересная... плавали. знаем... критична к настройкам.
ADSL провайдерский. 128 kbps.
>особенно на плохих каналах.
На канал не жалуюсь.
>поставите фриху - может быть с точностью до наоборот.
Здесь уж приходится выбирать: либо Linux качает, либо FreeBSD.
вообще adsl вещь интересная в том плане, что кто первый, тот и папа.
приходилось сети объединять.. серьезные.. ряд гипермаркетов. и другого выбора не было.
перешел на самбу, чтобы каждый чих контролировать... не решил тогда только печать, если кто в очередь ставит, то в это время все курят (не большое, но..). сейчас бы решил.девайс посмотрю... но что-то совсем маленький (128 kbp). у меня даже в обратку раза в 4 больше было.. 1999-2000 где-то.
Вообще, ситуация такая: Linux Mint изо-всех сил ломится скачивать бинарные обновления в несколько потоков (при этом можно насчитать от пяти до десятка одновременно открытых соединений в окне обновлений), и быстро отбрасывает соединение (там бинарные пакетики по несколько десятков килобайт быстро скачиваются).FreeBSD качает архивы с исходниками по одному с помощью стандартного fetch.
Как только включаю обновление Linux Mint -- всё, на FreeBSD можно вешаться, перезапуск закачки не помогает, и нужно физически отсоединять Linux Mint от роутера.
(FreeBSD находится в DMZ роутера.)Чувство такое, что Linux генерирует паразитный трафик, мешающий соединениям с других машин.
кстати, а как в pf(точнее altq) справедливо распределить полосу между несколькими ip-адресами?
>кстати, а как в pf(точнее altq) справедливо распределить полосу между несколькими ip-адресами?
>Гы! В /usr/share/examples/pf/ примерчики глянуть можно.
>Гы! В /usr/share/examples/pf/ примерчики глянуть можно.да ну?
вот есть канал в 10мбит, сеть на /23. Как равномерно распределить полосу, чтобы клиент запустивший торрент не "сожрал" весь доступный канал?
>вот это не надо... у меня например специально настроено на приоритет винды
>(даже ttl там разные)Давеча качал фаерфокс под вистой.Убиться можно - тормозит адски.Скачка заняла почти полчаса.Маршрутизаторы вообще киски.А с машин под чем-то иным качается так что глазом не моргнуть.Может дело не в линуксе в длинке а кто-то просто нахимичил в сетевом стеке так что он иногда работает малоэффективно в некоторых условиях?А то сообщения про просадку сети в висте при проигрывании звука бывают например.
>>вот это не надо... у меня например специально настроено на приоритет винды
>>(даже ttl там разные)
>
>Давеча качал фаерфокс под вистой.Убиться можно - тормозит адски.Скачка заняла почти полчаса.Маршрутизаторы
>вообще киски.Несколько месяцев назад такая же ситуация была и у меня, но только под WindowsXP SP2 + всё тот же D-Link DSL-504T. Закачивал разные версии Sun JDK и драйвера NVIDIA. Через Firefox и через Download Master одинаково тормозно и бесперспективно. С тех пор никогда ничего не закачиваю через WindowsXP -- это просто невозможно стало -- всё тормозит на "тяжёлых" закачках, скорость скачки падает до нуля в течение пяти минут. FreeBSD на том же соединении не тормозит и спокойно качает многомегабайтные файлы без разрывов и пересоединений.
(В роутере прошивку не менял.)
>Несколько месяцев назад такая же ситуация была и у меня, но только
>под WindowsXP SP2 + всё тот же D-Link DSL-504T. Закачивал разные
>версии Sun JDK и драйвера NVIDIA. Через Firefox и через Download
>Master одинаково тормозно и бесперспективно. С тех пор никогда ничего не
>закачиваю через WindowsXP -- это просто невозможно стало -- всё тормозит
>на "тяжёлых" закачках, скорость скачки падает до нуля в течение пяти
>минут.Много лет пользую D-Link 504T. Правда вот с прошивкой от McMcc (родная прошивка извините кривая: лапухи из длинка не умеют параметры NAT ставить в соответствие с имеющейся у девайса оперативой, они такие не единственные "красавцы" кстати).Работает как часы и строго говоря - не тормозит.Ни в XP SP2 не тормозило, ни в Linux.Правда сам по себе XP SP2 потенциально куда тормознее из-за лимита на half-open соединения.
>FreeBSD на том же соединении не тормозит и спокойно качает
>многомегабайтные файлы без разрывов и пересоединений.До кучи у него наверняка нет лимита на half-open число соединений что ускорит иной раз скачку.
>(В роутере прошивку не менял.)
А это напрасно.Я как-то развлекался флудом в адрес роутера(со стороны LAN): ~1000 TCP соединений за 1 присест + несколько тысяч UDP датаграмм (все это на разные адреса в виде интенсивного флуда, должно проходить через длинковский нат) не просто сорвали крышу девайсу.Он не только ребутнулся\сглючил как полагается но до кучи еще и слетел на дефолты, включая ессно и логин (т.е. по сути я порутал свой же девайс - административный доступ с дефолтными параметрами, правда логин на интернет тоже слетает ессно).Макаки из длинка оказывается засунули систему в виде "как есть".Не утруждаясь какой-то адаптацией под low-memory conditions хотя делов то - параметры айпитаблесу подкрутить чтобы он не пытался отращивать таблицы трекинга соединений больше чем у девайса есть оперативы (коей у длинка всего 16 мегз из которых бОльшая часть уже занята при старте и нет свопа).Потом пробовал такое же в адрес прощивки с McMcc - ему просто пофиг.Несмотря на идентичность настроек.Даже осел работающий с 1000 соединений (разрешено до 400 соединений в секунду!) несколько дней не вызывает никаких проблем (иногие роутеры от такого очень любят глючить по все той же причине - таблица натинга имеет свойство оказываться крупнее доступной мизерной оперативки если производитель ступил и не подкрутил дефолты под особо-куцую оперативку).
Отсюда вывод: длинковские железки могут вызывать разные впечатления.Само по себе железо сделано достаточно неплохо, а вот софт в них пихается удивительно безбашенно и без должной адаптации... особенно позорен тот факт что рецепт адаптации гуляет много лет в интернете (как известно, спасение утопающих - дело рук самих утопающих) и вообще-то удивительно прост и логичен: максимальное количество отслеживаемых соединений\ассоциаций должно ставиться с учетом доступной оперативки а чтобы не упираться в этот лимит время трекинга должно ограничиваться разумной величиной.Иначе рано или поздно девайс или начнет испытывать проблемы из-за выюзывания всей оперативки или юзеры начнут замечать проблемы с NAT когда у него закончится лимит на ассоциации (можут случиться при большом числе соединений, длинном времени трекинга и куцей оперативке).Как пример: у одного небезызвестного вендора по дефолту фирмваре зачем-то трекит состояния соединений с таймаутом ... в НЕДЕЛЮ.Понятно что за НЕДЕЛЮ можно столько соединений сделать что никакой оперативы для их трекинга не хватит(производитель девайса набил достаточно много оперативы поэтому видимо проблему вот так сходу - не отхватил).
Соотношение между доступной оперативой и тем что сможет в даденых условиях изобразить NAT по идее очевидно любому продвинутому сетевику.Но у тайваньцев походу нет адекватных специалистов.Все на что их хватает - взять референсную схему от вендора чипсета (плюс\минус лапоть), софт в совершенно дефолтном виде.Ну и - вперед, бездумно штамповать!Логично что результат на выходе напоминает рулетку.Толи повезет, толи нет ;).Спасибо что хоть сорцы выкладывают - другие их кривизну поправить могут.Особо адекватные даже потом эти изменения интегрируют(в данном случае интересы юзеров и производителя совпадают - им обоим надо работающие и фичастые железки, так что кооперация - случается.Правда вот длинк в этом вопросе - редкостные лапухи.Тот же McMcc работает в результате ... на их конкурента (Acorp), у которого с дефолтным фирмваре в результате порядок out of the box, оно и не глючит и под местные особенности типа локалок с PPTP адаптировано, фичей куда больше и так далее... при столь же ширпотребной цене.В общем длинк - понятно кто.Обычные штампователи с минимальной компетенцией достаточной для штампования.
конечно девайс я такой вряд ли найду, но могу предположить (из всего того, что Вы описали) в чем проблема. скорее всего это связано с неправильной настройкой фрагментацией пакетов и mtu/mru (стандартное значение которых как правило 1500). особенно если Вы ещё и соединяетесь с провайдером через (PPPoA/PPPoE/PPTP) т.е. думаю, что здесь ключевые слова mtu+mru+mss+fragmentation. типа так: http://www.opennet.me/cgi-bin/opennet/ks.cgi?mask=trouble+mt...
вот примеры помощи (значения mss ставьте свои. ну и man iptables по этим параметрам):
$iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1350
$iptables -A FORWARD -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1301:65535 -j TCPMSS --set-mss 1300
$iptables -A FORWARD -o ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1301:65535 -j TCPMSS --set-mss 1300
или же (и что возможно более правильно):
$iptables -t mangle -o "$PPP_IFACE" --insert FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu
а, да. ещё многие забывают, что mss можно поставить не только через фаервол (iptables), но и просто задав его в таблицу маршрутизации (http://linux.die.net/man/8/route):
route [-v] [-A family] add [-net|-host] target [netmask Nm] [gw Gw] [metric N] [mss M] [window W] [irtt I] [reject] [mod] [dyn] [reinstate] [[dev] If]
...
mss M set the TCP Maximum Segment Size (MSS) for connections over this route to M bytes. The default is the device MTU minus headers, or a lower MTU when path mtu discovery occured. This setting can be used to force smaller TCP packets on the other end when path mtu discovery does not work (usually because of misconfigured firewalls that block ICMP Fragmentation Needed)ну или естественно через ip - man ip http://linux.die.net/man/8/ip
os fingerprint. Я могу, при желании, на Опене настроить pf на неполучение пакетов с венды или линукса или того же опена. Или по очередям раскидать... Понятно, что это не панацея, особенно если "подпилить" "отпечатки" своей оси.
>os fingerprint. Я могу, при желании, на Опене настроить pf на неполучение
>пакетов с венды или линукса или того же опена. Или по
>очередям раскидать... Понятно, что это не панацея, особенно если "подпилить" "отпечатки"
>своей оси.Подскажите навскидку, возможно ли и каким правилом можно отправить через PF (pass out on $intf...) os fingerprint, допустим "Linux", чтобы проверить селективность роутера к сторонним системам.
(Я только начал с PF разбираться, пока до этого не дошёл).
man pf.conf
поиск по fingerprint дает примеры правил для подобной фильтрации:Examples:
pass out proto tcp from any os OpenBSD
block out proto tcp from any os Doors
block out proto tcp from any os "Doors PT"
block out proto tcp from any os "Doors PT SP3"
block out from any os "unknown"
pass on lo0 proto tcp from any os "OpenBSD 3.3 lo0"ключевое слово os, а дальше смотрите свой /etc/pf.os.
З.Ы. нижеотписавшемуся:
Я в курсе, что и ФрииБСД и линукс умеют фингерпринтить, правда не знаю, насколько нативно. В общем то метод придумали давно...
>man pf.confДа, спасибо. Сумел сделать отсылку фингерпринта ("Linux", "Windows" "Cisco" и их вариации) на исходящем соединении. Но это не помогло -- сам роутер не справляется от паразитного трафика, генерируемого Linux Mint. Просто модем не такой функциональный, чтобы шейпить по-нормальному и отсекать излишне "разговорчивых" клиентов.
>Но это не помогло -- сам роутер не справляется от паразитного трафика, генерируемого Linux Mint.это полная чушь.
приведите хоть один пример "паразитного" трафика от линуха (tcpdump подойдёт).
некоторые вещи я написал выше....
годов так 8 назад сильно боролся с adsl (авив правда был)...
сейчас могу заключить только одно - Вы не справились... в Вашем случае линух победил бзд.
>>Но это не помогло -- сам роутер не справляется от паразитного трафика, генерируемого Linux Mint.
>
>это полная чушь.
>приведите хоть один пример "паразитного" трафика от линуха (tcpdump подойдёт).
>некоторые вещи я написал выше....
>годов так 8 назад сильно боролся с adsl (авив правда был)...
>сейчас могу заключить только одно - Вы не справились... в Вашем случае
>линух победил бзд.Кто кого "победил" — тот ещё вопрос.
Когда машины с альтернативными операционками начинают задыхаться от присутствия в сети борова под названием Linux, который выжирает в буквальном смысле всю полосу пропускания, дай только коннект... Это, позвольте заметить, уже серьёзный удар по этим самым альтернативным операционкам, которые настроены на минимизацию своих "голосов" и упорядочение исходящего от них трафика в едином домене коллизий (то биш в одном сегменте локалки).
>[оверквотинг удален]
>>сейчас могу заключить только одно - Вы не справились... в Вашем случае
>>линух победил бзд.
>
>Кто кого "победил" — тот ещё вопрос.
>Когда машины с альтернативными операционками начинают задыхаться от присутствия в сети борова
>под названием Linux, который выжирает в буквальном смысле всю полосу пропускания,
>дай только коннект... Это, позвольте заметить, уже серьёзный удар по этим
>самым альтернативным операционкам, которые настроены на минимизацию своих "голосов" и упорядочение
>исходящего от них трафика в едином домене коллизий (то биш в
>одном сегменте локалки).linux убил локалку -- бред
о чем и речь.
и на вопрос "приведите пример этого паразитного трафика" получаю вот этот бред.
ну что тут скажешь?
тем более, что уж в линухе весь трафик контролировать или как минимум смотреть не проблема - tcpdump, trafshow,... iptables'ом в лог загнать наконец...
всё это больше говорит о квалификации оппонента.
ведь эти же вопросы (контроль трафика) решаются и в бзд, и в солярке, и в макоси, и даже в виндах.
зато ляпнуть, что линух гамно, а вот в бзд супер-пупер - это да.
>linux убил локалку -- бредНе бред. Сегодня снёс к чертям собачьим Linux Mint и на ту же машину установил PC-BSD 7.0.1.
В текущий момент она занимается обновлением установленного ПО из бинарных пакетов, качает некоторые пакеты из Интернет, а другие пакеты берёт с моей машины (по NFS расшарен каталог packages/All).И я здесь всё это расписываю, не ощущая никаких неудобств с сетью.
у Вас на adsl стоит линух... (или для Вас это был секрет?).. и то что я писал про mss, фрагментацию,.. всё относилось именно к нему.и Вы всё это расписываете не ощущая никаких неудобств с сетью.
>у Вас на adsl стоит линух... (или для Вас это был секрет?)..
>и то что я писал про mss, фрагментацию,.. всё относилось именно
>к нему.Не к роутеру, как к таковому (в локалке он работает фактически как свитч), а к Linux Mint, установленному на одной из машин в локалке. Именно настольный Linux зафлуживал локальную сеть так, что ни одна из других машин не могла "пробиться" к роутеру (и нормальным образом пользоваться Интернетом).
Ещё Linux учудил: на роутере я изменил фиксированный IP-адрес, так он ни в какую не пожелал работать с ним и не принимал новый IP-адрес роутера за адрес основного шлюза. Перезагрузки, включение DHCP, переконфигурирвание соединения в графическом настройщике -- бестолку -- IP-адрес шлюза был и оставался старый айпишник. :)) Устал бороться. Снёс. Теперь спокойно пользуюсь PC-BSD (ответ на вопрос "как настроить переключалку клавиатуры ЛАТ/РУС в KDE" мне ещё предстоит выяснить, потому что заветная строчка в xorg.conf, которая работает в Xfce4, в PC-BSD отказывает работать! :) )
>и Вы всё это расписываете не ощущая никаких неудобств с сетью.
Ага. Модем тут ни при чём -- две машины FreeBSD с ним и между собой ладят отлично.
passive os fingerprinting можно и в freebsd делать, и в linux, а не только в openbsd.
DSCP настраивали?
Нет, Умка.
Связка pf+spamd вполне заменима связкой ipt+spamd. Которая, кстати говоря, ipt+spamd, пожалуй, пошустрее будет. По крайней мере быстрее pf+spamd во Фре.
Спасибо отсутствию нетграфоподобных надстроек над сетевым стеком в линюхах.
А тут - фильтр для борьбы с флудом, а не связка пакетного фильтра и спаморезки.
>Спасибо отсутствию нетграфоподобных надстроек над сетевым стеком в линюхах.Так, для общего развития. Вообще-то pf во Фряхе работает не используя подсистему netgraph. Насколько я помню pf и ipfilter используют NetBSD'шный интерфейс PFIL_HOOKS(9) (этот же интерфейс использует и OpenBSD), что подрубаются напрямую к ip-стеку. Поэтому прежде чем говорить глупости попробуйте изучить подробнее данную тематику. А бред про тормознутость netgraph мы уже слышали, но netgraph был изобретён именно как эффективное решение поставленых для него задач. Собственно со своими задачами он хорошо и справляется.
По-поводу новости. Больше велосипедов интересных и разных! FF - это flud filter?
хм... а ведь там по-русски написано.
но ведь Вам и не важно, не так ли?
>хм... а ведь там по-русски написано.
>но ведь Вам и не важно, не так ли?Важно, на родном языке читать приятней.
Jeffrey Merkey случаем не в Intel работает???
Для pavlinux.
По последним развед. данным.
http://www.wolfmountaingroup.com/
>По последним развед. данным.G://"Jeffrey Merkey"
=> http://en.wikipedia.org/wiki/Jeff_V._Merkey
>>По последним развед. данным.
>
>G://"Jeffrey Merkey"
>=> http://en.wikipedia.org/wiki/Jeff_V._MerkeyТак там написано, что товарищ - порядочный мудак.
On October 4, 2004, Merkey offered US$50,000 on LKML, the Linux kernel mailing list, to anyone able to provide him a version of the Linux kernel that was not licensed under the GPL for his project.
И тон его сабжевого сообщения в lkml это только подтверждает.
Так это можно будет использовать параллельно с netfilter (iptables, iproute2, ipset)?
>Так это можно будет использовать параллельно с netfilter (iptables, iproute2, ipset)?Можно, тольк ещё сетевуху Intel Gigabit надо купить, где будешь юзать :)
>>Так это можно будет использовать параллельно с netfilter (iptables, iproute2, ipset)?
>
>Можно, тольк ещё сетевуху Intel Gigabit надо купить, где будешь юзать :)
>Уже прикупил, около ста штук e1000. Все серваки на них.
Весь мир нах зафаерволлю! :-)
Jeffrey Merke --- красавчег )
Давно следил за FF, и вот свершилось !!!
Захэшировал базу rbl на диске, и фильтровать эти адреса? Еще один велосипед?
если он это будет делать быстро (а есть подозрения, что так), тогда это очень быстрый велосипед.
многим может пригодиться.