Борьбя с DDOS на VPS

тупые боты любят вести себя вообще не адекватно и делают по 30-40 запросов в секунду особенно когда хороший канал между сервером и ботом, так что много вообще не нужно, 20-30 ботов порою вполне достаточно.

Den73, да, вы полностью правы. Стоило написать 500-700 запросов.

Случилась на днях, как всегда, не в самый подходящий момент, DDoS-атака на один из сайтов, размещенных на моем сервере. DDoS-атаки бывают разные, в этот раз злоумышленники запустили HTTP флуд.

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

Железные решения я считаю правильным выбором, но доступны они не всем и не всегда, а многие атаки, как показала моя практика, успешно отбиваются правильным использованием доступных программных средств. К тому же, захотелось немного поэкспериментировать.

После детального изучения возможностей давно и вполне успешно используемой мною связки nginx + Apache и документации к nginx родилось решение на базе модуля ngx_http_limit_req_module.

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

Что я сделал

Я проверил, собран ли nginx с модулем ngx_http_limit_req_module и внес в конфигурационный файл сервера следующие строки:

http {

# Директива описывает зону, в которой хранятся состояния сессий.

# Значения сессий определяется заданной переменной.

limit_req_zone $binary_remote_addr zone=one:10m rate=2r/s;

# В данном случае состояния сессий хранятся в зоне "one" размером

# 10 мегабайт и средняя скорость запросов для этой зоны не может

# более 2 запросов в секунду.

# Данный случай частный лично для моей

# ситуации и подбирается индивидуально.

...

# Атакуемый домен.

server {

...

location / {

# Директива задаёт зону (zone) и максимально возможные всплески

# запросов (burst). Если скорость запросов превышает описанную

# в зоне, то их обработка запроса задерживается так, чтобы запросы

# обрабатывались с заданной скоростью. Избыточные запросы задерживаются

# до тех пор, пока их число не превысит

# заданное число всплесков. В этом случае запрос завершается кодом

# "Service unavailable" (503).

limit_req zone=one burst=4;

}

* This source code was highlighted with Source Code Highlighter.

* пример конфигурации и пояснения со страницы документации по модулю

Что я получил

Все боты, которые с неистовой частотой «долбили» сервер, начали получать в ответ http- ошибку 503. А выбрать с логов IP ботов например так:

tail -1000 /var/log/nginx-access.log | grep " 503 " | cut -f1 -d" " | sort -u

И после этого занести их в таблицу фаервола (у меня FreeBSD и IPFW) проще некуда, равно как и поставить это все в crontab.

Вот, собственно, и все. На оригинальность идеи я не претендую, спасибо Игорю Сысоеву за реализацию nginx и данного модуля к нему.

Надеюсь, этот вполне доступный способ защиты от динамичного и интенсивного по частоте запросов HTTP-флуда будет вам полезен.

http://habrahabr.ru/post/67685/

Shur1k_ua, направление у вас верное, но реализация имеет много минусов.

1) вы парсите лог ища подстроку grep " 503 ". но цифра 503 может быть и в других полях строки, а не только в коде ответа, из за этого будут ложные баны.

2) Вы забаните только быстрых ботов, делающих более 2-х запросов в секунду. Но на практике в ботнете много медленных ботов, которые не превысят этого лимита и забанены не будут.

Нужно делать более интеллектуальные алгоритмы поиска ботов в логах. Но на их создание и отладку уйдет не один месяц.

у него там пробелы " 503 " так что терпимо ибо вхождение должно быть с пробелами, если без пробелов то действительно может зацепить лишнего.

С двумя запросами в секунду в бан улетит весь гугл, яху и яндекс

У меня гугл матюгается даже если стоит 10 + burst 20 ибо он долбит непрерывно и никакие burst не помогут.

Так что включать limit_req на загруженном проекте имеет смысл только временно, чтобы побанить ботов. Причём скрипт обязательно должен проверять адрес на вхождение в CIDR известных поисковиков. Они довольно легко гуглятся.

Вот, к примеру, скрипт проверки, который использую я.

$GoodBots - массив CIDR поисковиков. Например

$GoodBots["Google"]="66.249.64.0/19";

$GoodBots["Google_1"]="209.85.128.0/17";

.... и так далее...

function isGoodBot($IP){
	global $GoodBots;
	foreach($GoodBots as $BotName=>$CIDR){
		list($Net,$CIDR_2)=preg_split("|\/|",$CIDR);
		$Mask=long2ip(pow(2,32) - pow(2, (32-$CIDR_2)));
		if (((ip2long($IP))&(ip2long($Mask)))==ip2long($Net)){
			return $BotName;		
		};
	};
	return false;
};

угу, основная ошибка - это обработка статики(картинки, js, css и т.д.) и динамики в одной куче.

статику нужно отдавать без лимитов или ставить лимиты в 15-20 запросов в секунду.

динамику (php, html) - лимитировать уже более жестко. 5-7 запросов в секунду. (на 2-3 слишком много ложных срабатываний, тотже самый msnbot автобанится на раз)

иначе в бан пойдут обычные браузеры, которые при загрузке одной страницы открывают 5-10-15 потоков.

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

---------- Добавлено 31.12.2013 в 12:20 ----------

хинт: этот функционал встроен в nginx - модуль geo. прописываете нужные сети и nginx сам рулит без дерганья бекенда и пхп. часть ip/сетей можно сразу 444-м сбрасывать.

есть еще перловые хуки, все никак не доберусь до них. все на потом откладываю... :(

admak

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

по хорошему 2 варианта

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

2. отрабатывать все что пролезло в лимиты. (нужно много ресурсов)

У меня задача стоит не отбрасывать, а вычислять злодеев и пихать их в ipset, дабы они даже до nginx не доходили.

главное - не запутаться в своих лимитах на лимиты :)

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

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

для любителей создавать нагрузку, показывая картинку в ифрейме или скрыто, на трафовых ресурсах - хороший ответ нашего сервера: 401. атака или сразу прекращается или трафовый ресурс хорошо потеряет своих посетителей.