DDOS сайта. Как бороться?

1 2345 6
_
На сайте с 24.03.2008
Offline
381
#31
kxk:
_SP_, И дадут ТС`у спуфленного сина, гигов 100:)
Благо это сейчас делаеться 1 кликом мышки, даже самым глупым ддосером...

Чей-то в среднем по больнице не дают.

На меня тут яндекс-бот как-то раз набежал и "огого всё повалил".

Причем игнорировал зарраза все директивы, тыщами в секунду запросы выдавал.

И да, я его не по юзер-агенту нашел :), он потом в я.вебмастере через сутки эту

активность показал.

Бывает и так...

kxk
На сайте с 30.01.2005
Offline
970
kxk
#32

_SP_, Пока не все умеют использовать, но по нашим клиентам бывают прямо волны.

Самое смешное, бьют вполне белых клиентов, на каких и не подумаешь что могут быть атаки.

Ваш DEVOPS
D
На сайте с 07.11.2000
Offline
219
#33

ТС, от такого только самому или к тому, кто разбирается в этом. Сервисы от такого не помогут, т.к. очень просто.

Будете автоматом банить - подсунут ботам Яндекса и Гула много 404 страниц, побаните их автоматом.

1. Т.к. я не думаю, что добавляется куча контента каждые 5 минут - сделайте кеширование ответов бакенда NGINX-ом. Это вообще желательно делать и в нормальном состоянии сайта.

2. Формы логина для админа - вынести отдельно и спрятать. Если Вы пользуетесь НЕ своим движком - есть специальные модули, например для ВП better wp security (вроде так называется).

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

Найдите человека (работа не сложная), сказав ему:

мне нужно кешировать nginx-ом ответы бакэнда (не кешировать админку, куки, учитывать 2 версии сайта). Время кеша - зависит от частоты смены контента. Например, сутки.

И еще полезный секрет :) создайте отдельный урл site.ru/?secret, известный только средствам мониторинга и НЕ кешируйте его nginx (по нему будет отдаваться самая тяжелая страница, например главная) - проверяйте его средствами мониторинга.

Отвалится мускуль, все сломается, сильно нагружен сервер, даже сайт удалите, а страницы сайта будут отдаваться nginx (приоритет должен быть выставлен) из кеша еще сутки (или другое время кеша). Вы получите сигнал и неспешно, не отрываясь от важных дел (или сна) его почините.

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

ИС
На сайте с 12.04.2015
Offline
1
#34

Я бы вставил скриптик на нагруженные странички, что бы они записывали открытие этой страницы в базу (ip,дату,страницу,post и get данные)

Далее кроном, раз 5-10 сек запускается скриптик по фильтрации и смотрит, если какой то ip открывает по 5 страниц за 5 сек, это не есть норма... он выписывает такие ip из базы и формирует списочек, кого на бан

После пишет в файл .htaccess в корне сайта или в папку с нагруженными страницами

И так же кроном удаляем из базы запросы старше 2-12 часов

P.S. Похожий алгоритм я реализовал на защиту админки WP, там удалось полностю снять нагрузку, при атаке с 200 ip

M
На сайте с 30.08.2010
Offline
92
#35
ИванСергеевич:
Я бы вставил скриптик на нагруженные странички, что бы они записывали открытие этой страницы в базу (ip,дату,страницу,post и get данные)

Далее кроном, раз 5-10 сек запускается скриптик по фильтрации и смотрит, если какой то ip открывает по 5 страниц за 5 сек, это не есть норма... он выписывает такие ip из базы и формирует списочек, кого на бан

После пишет в файл .htaccess в корне сайта или в папку с нагруженными страницами

И так же кроном удаляем из базы запросы старше 2-12 часов

P.S. Похожий алгоритм я реализовал на защиту админки WP, там удалось полностю снять нагрузку, при атаке с 200 ip

зачем 2 раза писать то, что так уже есть? для этого достаточно распарсить access log. Ну и дернуть .htaccess - это тоже запрос к apache, который выжрет ресурсы.

zexis
На сайте с 09.08.2005
Offline
388
#36
ИванСергеевич:

Далее кроном, раз 5-10 сек запускается скриптик по фильтрации и смотрит, если какой то ip открывает по 5 страниц за 5 сек, это не есть норма... он выписывает такие ip из базы и формирует списочек, кого на бан
После пишет в файл .htaccess в корне сайта или в папку с нагруженными страницами

Часто отдельные ддос боты не делают много кликов в секунду.

Например, могут делать один клик раз в 5-10 секунд

Но за счет того, что таких ботов например 500, суммарно создают высокую нагрузку.

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

Банить ботов лучше через iptables или ipset. Так как существенно меньше будет нагружать сервер.

ИС
На сайте с 12.04.2015
Offline
1
#37

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

M
На сайте с 30.08.2010
Offline
92
#38
ИванСергеевич:
Если смотреть access_log, то там будет огромная куча запросов, а у нас одна или две нагружены страницы...

grep уже не решает эту задачу?

ИС
На сайте с 12.04.2015
Offline
1
#39
zexis:
Часто отдельные ддос боты не делают много кликов в секунду.
Например, могут делать один клик раз в 5-10 секунд
Но за счет того, что таких ботов например 500, суммарно создают высокую нагрузку.
Для поиска таких медленных ботов, нужно придумывать более сложные механизмы поиска.
Банить ботов лучше через iptables или ipset. Так как существенно меньше будет нагружать сервер.

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

Ну и можно попробовать применить запись в куки или сессию ... через ajax или js записывает некую инфу, и после смотреть, есть данные или нет... такая своеобразная авторизация для браузера ...

---------- Добавлено 13.04.2015 в 01:29 ----------

на счет grep надо проверить что быстрее будет ... так как в access log может быть и по 100к записей, а интересующих 1к =)

zexis
На сайте с 09.08.2005
Offline
388
#40
ИванСергеевич:
Если смотреть access_log, то там будет огромная куча запросов, а у нас одна или две нагружены страницы...

1)Для уменьшения размера логов нужно логи запросов в статике (jpg,gif,css) вести в отдельные лог файлы. Статику очень редко ддосят.

2)Если логи все равно очень большие, то нужно чаще делать ротацию.

3) перед тем как делать для лога grep нужно сделать tail

4) в анализе логов есть очень много ньансов. Например, когда нет атаки его лучше автоматически отключать, что бы не побанить быстрых пользователей.

1 2345 6

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий