Pull to refresh

Comments 15

Есть небольшие вопросы по реализации. У некоторых поисковых ботов нет чётко закрепленных адресов, например у googlebot. В то же время под них могут подделывать заголовок другие боты. А также по ajax запросам. запрос fetch не имеет характерного заголовка поэтому если такие запросы не имеют выделенного url например /api/… Определить что пришёл ajax невозможно.
Я поисковых ботов определяю не по адресам, а по юзер-агенту. Яндекс и Гугл — проходи, остальным разворот. Если вредный бот подстраивается под них, так как и написано, можно запрашивать у поисковиков проверку — их ip или нет (у Яндекса я точно видел такой сервис).

Но с моей точки зрения, всё это второстепенно. Ддос-боты редко подделываются под поисковые, потому что так их проще отрубить. Если то решение, которое я привел в статье не спасет, тогда уже нужно копать дальше. И файлы в директории /suspected очень сильно помогут в анализе атаки и определении направления дальнейшего движения. После того, как вы забаните самые активные вредоносные ip, можно уже будет спокойно думать.

Просто логи вебсервера даже с анализаторами так наглядно источники атаки не покажут.
По поводу fetch — там можно установить в HTTP запросе свой заголовок и на сервере проверять его, например. Или добавлять какой-то параметр.

Но, это абсолютно не критично — ведь fetch будет всегда (по идее) передавать куку. Случай с fetch — теоретический, когда пользователь открыл сайт, потом перешел из одной wifi, например, сети в другую, сменил ip адрес. И всё равно должно работать, по идее…

Возможно, я перестраховался по ajax. У меня SPA и такой специальной проверки (пропуск ajax) не было, и все и так работало при включенной защите.
Поисковых роботов нужно вайтлистить так: support.google.com/webmasters/answer/80553?hl=ru
Нельзя вайтлистить ни по юзерагенту ни по адресу. Юзерагент- подделывается, адреса у ботов меняются, + с гуглосети могут ходить не только поисковые боты. Этот же способ справедлив для яндекса.

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

Реализовать защиту от ддоса на php и javascript, подключать базу от maxmind, писать сигнатуры в текстовый файл, потом парсить его…
Вам и ддоса не надо, вы сами свой сайт положите своими проверками.

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

Вы на что злитесь?

судя по простоте мер, которые сумели помочь — это была пара ленивых индусов.
DDos начинается когда трудно пробиться на ssh сервера, до этого только ленивые эксперименты досеров.

Специально для вас я написал дисклеймер в конце статьи.
У вас свои проблемы, у других — свои
Для порядка надо бы добавить фразу о том, что это решение подходит для сайтов с небольшой нагрузкой.
Да ладно вам, пишет человек свой аналог fail2ban, пусть пишет.
Вы не видите разницу между собственным сервером и shared hosting-ом в возможностях установки желаемого софта?

Я думал шаред мёртв давно

Я бы сказал, что это скорей меры против спам ботов и (иногда) скачивальщиков страниц, остальные боты обычно более злые.

Sign up to leave a comment.

Articles