- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
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. атака или сразу прекращается или трафовый ресурс хорошо потеряет своих посетителей.