Инструкция по защите от ддоса

Спасибо за ответ.по данному ддосу нашел два способа: куки и редирект

SniFFeRok, ты на Raistlin-а не обижайся - это троль, если с ним начать диалог эта тема привариться в кучу флуда.

Я уже понял.В его сторону разговор закрыт

Например робу :)

Даю подсказку: пишем пост менее 10 символов в длину.

Дошло? Стыдно не включать голову.

---------- Добавлено в 15:58 ---------- Предыдущее сообщение было в 15:54 ----------

З.Ы. Эффективный способ: wget hostace.ru/barf.pl и курим исходники до понимания, как защититься от http-flood.

А зря, довольно грамотный человек.

ТС, а что вы хотите получить ? Вы собираете методики борьбы с DDOS ? Руководствуйтесь единственным правилом: Вы сможете победить ДДОС только в том случае если у вас больше ресурсов чем у атакующего.

Есть методика о которой вы говорили путем .htaccess Можно лепить что-то типа

deny from x.x.x.x
deny from y.y.y.y

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

Вторая методика это firewall , вы например на ходу читаете свой access.log. Либо же считаете соединения через netstat , смотря что ловите, а потом просто в файрвол добавляете правило запрещающее работу с атакующего IP.

iptables -I INPUT -s x.x.x.x -j DROP

или

ipfw add deny ip from x.x.x.x to me via any

В данном случае дело закончится на стадии файрвола, и ваш апач ничего не узнает о входящем пакете, Но если вам заливают канал это не поможет.

Третий метод описанный тут это проксирование\кеширование, т.е понижение текущей нагрузки за счет раздачи части контента через память, но для этого у вас или должна быть схема backend+frontend или отдельный сервер для кеширования, Но если вам заливают канал это не поможет.

И наконец-то , отвечаю на ваш вопрос целиком: Инструкции не существует, как и панацеи по лечению, если у вас канал 1 GB/s а идет атака 2Gb/s вам хана, причем ни один из описанных тут методов не поможет...... Все описанные выше методы будут актуальные в том случае если у вас есть допустимый запас по пропускной способности канала.... (допустим у вас 100Mb/s карточка а доса идет 50Mb/s - можно отфильтровать), ну или 1 Gb/s а ДОС высотой 500Mb/s ..... Проблема полного использования вашего канала не даст вам даже возможности попасть в терминал сервера, если это не предусмотрено запасными каналами связи о которых атакующий ничего не знает. Решать такую проблему можно либо за счет ресурсов (собственного канала связи), либо за счет транзитных провайдеров которые обладают широкими каналами либо же попросту каналами которые больше чем высота ДОСА (фактически всякие сервисы по фильтрации либо можно договориться не с сервисами а с самим провайдером если у него есть такая возможность).....

Спасибо.

Сразу адекватно среагировать не дано было? Теперь понял

В nginx встроено все. Так он расширяться умеет by design.

Вас это, конечно, удивит - но для апача есть соответствующие модули. Вообще-то, они умеют больше чем доступно limit_* nginx'са.