Предлагаю решение, защищающее от DDOS.

уверен, что не адаптирует. HTTP и, например, SMTP - очень разные прикладные

протоколы. то, что годится для одного - с трудом переносится на другой.

в сухом остатке (на то, "что уже написано") - будет что-то типа

статистики соединений с нашим сервером для каждого клиента.

:)

---------

И что "за нас" придумали?

---------

Давно придумали программную реализацию, по защите от разных рода аттак:

В программный метод защиты относить,всё то что мoжет управляться, на канальном уровне

то-есть к канальному уровню относим ARP драйвера устрйоства,канальный уровень контролирует сетевой уровень,транспортный уровень,и прикладной уровень,есть момент физического уровня но тут уже к сожалению аплинкер может выступать в качестве контроля, у вас доступа к проводам нету :)

Так вот Iptables ipfw nginx и т п всё это программный метод защиты,и в интернете много HOW TO как делать защиту от разных видов аттак.

----------

DDos отражает устройство.

----------

Да кошки рулят но пойдите купите ради 50 мегабитного доса кошку :) или какой нить T3 роутер чтоли :)

----------

1)Речь тут не о каналах и т.д.,

2)а о самой реализации.

----------

1)Вы просто глубоко заблуждаетесь всё имеет значение когда обсуждаем дос атаки.

если дос будет на 70% больше канала...то не железка не програмный метод не что вас не спасёт,будете лежать и не куда не денитесь.....к сожелению,это я писал выше! к таму что зачем строить сложности когда от серьёзного доса врядле что спасёт :)

2) я написал выше что реализация Iptables и прочие фишки которые доступны в инете...уже готовы и голову ломать не надо.

----------

И не обязательно для этого использовать тот же сервер, что и для web.

----------

Я отношу сваю писанину, к серверам начальным.(интернет дц и т п)так или иначе тема затронула скрипт каторый надо обсудить,я углубился и хотел сказать что всё уже придумали не надо строить не чего,это маё мнение..зачем было его обсуждать вам,критикуйте вон скрипт я раз высказался да и хватит..вы же продолжаете развевать маю и сваю мысль :)

Причём тут роутер? Вы похоже немного не в теме. Любой модуль защиты - это устройство. А модули есть, которые и по пол миллиона стоят.

Попытка дублю два: речь не о канале, а о самой реализации. Это понимать нужно так: Канал сейчас - это не вопрос обсуждения. Берём идеальную ситуацию, когда с каналом проблем нет.

Вы видимо это howto не читали и не пробовали реализовывать.

Ничего действительного действенного в интернете не нашёл. Меня не интересует блокировка из-за количества подключений и прочая ерунда. Интересуют качественные методы определения "паразитного" трафика.

Вот покажите мне такую программную реализацию? Хоть одну ссылку.

---------

Ничего действительного действенного в интернете не нашёл. Меня не интересует блокировка из-за количества подключений и прочая ерунда

---------

:)

---------

Интересуют качественные методы определения "паразитного" трафика.

---------

:)

tcpdump

trafshow

&

lsof

netstat

---------

:)

---------

Вы видимо это howto не читали и не пробовали реализовывать.

---------

приведу рабочие примеры на в скидку,я правда отсюда подчеркнул пару токо вариантов прикручивал к csf и всё...

### chains to DROP too many http-s ######
#/sbin/iptables -D INPUT 38
#/sbin/iptables -D LOGDROPIN 17
#/sbin/iptables -I INPUT 38 -i eth0 -p tcp -m limit --limit 25/second --limit-burst 20 -j ACCEPT
#/sbin/iptables -I LOGDROPIN 17 -p tcp --dport 80 -m limit --limit 30/min -j LOG --log-prefix "http flood:"
####
#/sbin/iptables -I INPUT  -p tcp  --dport 80 -i eth0 -m state --state NEW -m recent --set
#/sbin/iptables -I INPUT  -p tcp  --dport 80 -i eth0 -m state --state NEW -m recent --update --seconds 30 --hitcount 10 -j DROP
##############
#/sbin/iptables --new-chain http
#/sbin/iptables -I INPUT -p tcp --syn --dport 80 -i eth0 -m state --state NEW -m recent --set --jump http
#/sbin/iptables --append http -p tcp --syn --dport 80 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 20  --jump RETURN
#/sbin/iptables --append http -m limit --limit 30/min -j LOG --log-prefix "http flood:"
#/sbin/iptables --append http --jump DROP
#echo "### chains to DROP too many ping-s ######"
#/sbin/iptables -N ping-flood
#/sbin/iptables -A INPUT -i eth0 -p icmp --icmp-type ping -m limit --limit 1/second --limit-burst 5 -j ping-flood
#/sbin/iptables -A ping-flood -m limit --limit 1/sec --limit-burst 5 -j RETURN
#/sbin/iptables -A ping-flood -m limit --limit 30/min -j LOG --log-prefix "ping flood:"
#/sbin/iptables -A ping-flood -j DROP

madoff, снова о какой-то ерунде говорите.

Меня не интересуют блокировки фаерволом, основанные на лимитах и прочем.

Меня интересуют алгоритмы определения "паразитного" трафика. Я знаю, что есть намного продвинутее алгоритмы. Вот хотелось бы на основе их реализовать автоматическое определение атак и принятия мер на основе этих данных.

Ваши методы начнут вредить и поисковым ботам, ботам всяких ссылок бирж и т.д.

Да и не хочется мне выходить из ситуации постоянными блокировками. Меня интересуют точные методы определения "паразитов", на основе которых блокировать доступ с определённых ip/сетей.

Постоянные ограничения и одинаковые действия для всех ip не интересуют. Хочется по-настрящему "понимающие" алгоритмы, а не howto, написанное на коленке.

---------------------------------------

Ваши методы начнут вредить и поисковым ботам, ботам всяких ссылок бирж и т.д.

Да и не хочется мне выходить из ситуации постоянными блокировками. Меня интересуют точные методы определения "паразитов", на основе которых блокировать доступ с определённых ip/сетей.

Постоянные ограничения и одинаковые действия для всех ip не интересуют. Хочется по-настрящему "понимающие" алгоритмы, а не howto, написанное на коленке.

----------------------------------

если бы вы знали работу правил то увидили, что те что построены, на лимитах, это не блокировка Ip.иди-ТЕ маны читайте...прежде чем в ввязывать в разговор серьёзный.:) не в обиду а в учение хотите учиться читайте литературу, и вы не будете глупости писать,это тема переросла в сыр бор..как и другие где вы отвечали мне.

Вот не нужно мне тут рассказывать про "серьёздные разговоры". Совершенно не читаете, что я пишу.

Тем более, что вы ввязались в серьёздные разговор, который начал я. Такое же решение, как предлагает ТС, у меня уже есть. Давно написано лично мной.

Большинство правил, которые вы приводите, основываются на лимитах и ограничениях.

Не нужно мне тут ничего рассказывать, я всё хорошо понимаю.

Я даже в первом своём сообщении написал, что это меня не интересует.

Похоже вы не понимаете ни то, что пишу я, и не то, что привели вы. Где-то на сайте по "админству" вычитали и вперёд советовать. Уже 10 раз повторил,что это меня не интересует. Всё это пройденный этап. Задачи стоят другие. Если реально нечего сказать по моему вопросу, то пройдите мимо темы. Ваши "школьные" знания администрирования меня не интересуют.

Вы как-то совсем не хотите понять, что вам Химик пытается донести - а он совершенно прав.

Принимать решение порезать трафик на основе подсчета пакетиков-сессий - ума большого не надо. Давайте, чтобы было понятно, на конкретных примерах - с вашего сервера дергают /index.php 400 раз в секунду. Постоянно с разных ip-адресов. Корреляции между временем запроса и ip-адресом нет, распределение - строго равномерное.

За минуту это будет 24000 хитов. Известно, что из них - 200 хитов валидные, все остальные - ддос.

И - да, 200 хитов - это, скажем, транзакции платежной системы, соответственно, продолбленные 200 запросов - стоят, условно, $10к.

Ваши действия?

разумно платежной системе обращаться по другому URI, что отличать где обращения платежной системы, а где все остальные,а вообще тут однозначно не скажешь,однако балансер тут не помешал бы.

это ладно, когда просто индекс дергают (хотя и тут ваш файервол курит в сторонке - ведь

про URI он _ничего_ не знает). а ведь бот умный пошел - сымитировать

нагрузку от реальных пользователей умеет. зашел на индекс, прошелся по паре ссылок,

статику потянул - ума тут большого ему не надо.

нельзя резать такие вещи на уровне файервола - он ничего о прикладном

протоколе не знает.

а масштабирование поможет, конечно, до какой-то

степени (пачка балансеров, пачка прокси, пачка бакендов - вот только

делать все это исключительно для защиты от ddos - бросать деньги на ветер).