- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
lonelywoolf, благодарю что своим молчанием на оба вопроса подтвердили свою неправоту.
Сами это перечитайте.
Им вообще ничего не отдается? А что анализирует тогда ваш скрипт? Если веб-сервер таки обрабатывает запрос бота, не суть важно какой ответ будет дан, 1 бот = 1 процесс. 500-700 ботов и средненький сервер лежит, так как апач не переварил это дело. Можно конечно увеличить эти циферки, но не столь существенно.
тупые боты любят вести себя вообще не адекватно и делают по 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-х запросов в секунду. Но на практике в ботнете много медленных ботов, которые не превысят этого лимита и забанены не будут.
Нужно делать более интеллектуальные алгоритмы поиска ботов в логах. Но на их создание и отладку уйдет не один месяц.
1) вы парсите лог ища подстроку grep " 503 ". но цифра 503 может быть и в других полях строки, а не только в коде ответа, из за этого будут ложные баны.
у него там пробелы " 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";
.... и так далее...
угу, основная ошибка - это обработка статики(картинки, 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. отрабатывать все что пролезло в лимиты. (нужно много ресурсов)
хинт: этот функционал встроен в nginx - модуль geo. прописываете нужные сети и nginx сам рулит без дерганья бекенда и пхп. часть ip/сетей можно сразу 444-м сбрасывать.
У меня задача стоит не отбрасывать, а вычислять злодеев и пихать их в ipset, дабы они даже до nginx не доходили.
лимитировать нужно все и проверять валидность, никто не мешает злоумышленнику устроить ддос на картинку, будет огромный исходящий трафик и это как минимум.
главное - не запутаться в своих лимитах на лимиты :)
предусмотреть все - не возможно, но возможно поиграть в бесконечную игру "абсолютной защиты" в вакуме. шутка
картинка - да, может загрузить канал, но скорее всего проц и память останутся целыми и будет возможность зацепиться на сервер и подкрутить гайки в защите.
для любителей создавать нагрузку, показывая картинку в ифрейме или скрыто, на трафовых ресурсах - хороший ответ нашего сервера: 401. атака или сразу прекращается или трафовый ресурс хорошо потеряет своих посетителей.