Комментарии 39
Идея
Вычислить IP адреса которые делают много запросов за короткий промежуток времени.
Зафиксировать количество обращений к сайту
На основе количества обращений блокировать доступ к сайту
Ну и получить падение реальной посещаемости, так как через этот IP, возможно, NATится сетка крупного провайдера или корпорации, либо это ip адрес VPN сервера или узла TOR.
Ну прям по граблям РКН. :)
Так же всегда есть возможность самостоятельно проверить IP (кто, от куда) и скорректировать правило.
Или пойти дальше и блокировать таких «ботов» на определённое время
Ещё извращённей вариант, это показывать заглушку до основного роута cms с предложеним ввести капчу :)
Ограничение скорости обработки запросов в nginx
Вкратце: с помощью nginx можно настроить ограничить скорость с предусмотрением всплесков.
У вас ошибка в слове Cloudflare
fail2ban сейчас практически не защищает от атак. Если устанавливать лимиты в nginx можно по крайней мере отделить запросы на приложение от простых запросов статики. А fail2ban все считает равноценными. Для него запрос 1 к php и 99 к статике равноценны 100 запросам к php. И получается что установив например те же 100 запросов в секунду как лимит мы можеи забанить нормального клиента который сделал 1 запрос к php и 99 запросов к статике и в то же время пропускать бота который будет делать атаку по 99 запросов в секунду к php
Сам сайт носит СМИ направленность для провинциального города.
Я не утверждаю что опубликованное мной решение — хорошее, это всего лишь вариант.
В качестве мидлвар можно сделать связку с redis или memcached, но это уже другая история и пожалуй другая статья, хотя и возможна на приведённом в статье хостинг провайдере.
Числятся ли эти айпишники в спам-базах
Да, с этих IP приходит спам в комментарии к постам, об этом так же сообщает сервис Akismet.
Вместе с последней картинкой просто просится график посещаемости сайта :)
Суммарно он не изменился, по данным Яндекс Метрики
Ну я не очень то понял, почему конкретно тормозит база
Тормозит совсем не база, а у хостинга есть абстрактная величина «CP» — которая имеет разумные рамки и при превышении рамок сообщает «Эй, клиент, у тебя превышен отведённый тебе лимит нагрузки на центральный процессор, сделай что нибудь, а то мы выключим сайт». Да, конечно нужно уменьшить количество запросов к БД генерируемых 1-й страницей сайта, но требовалось именно потушить пожар (снизить нагрузку, что бы не получить санкции). Пожар потушен, можно проводить анализ.
Как вы поняли что это боты?
- По заголовкам браузера
- По запросам POST и GET. Например бот «прозванивает» роуты сайта на наличие тех или иных плагинов которые видимо имеют уязвимость(но этих плагинов у меня нет)
Была пара статей на Хабре например https://habr.com/ru/post/354744/ и в ней ссылка на еще одну статью как определять ботов. Простых ботов можно определить по способности сетать куки и делать редиректы. Конечно, продвинутые боты это обойдут. Но продвинутые боты никогда и не стучатся с одного адреса. То есть от серьезной атаки не спасет ни один из этих методов.
Универсальной защиты конечно нет. Но есть успешные примеры кастомных решений под свои нужды, исходя из особенностей конкретного проекта. Основной вопрос тут: а какая итоговая цель?
2) отбиваться от ботов (на первом этапе этого непростого пути) надо хотя бы через резолвинг айпи в имя, а еще лучше через rest.db.ripe.net/search. Получаете ответ, парсите его и понимаете с хорошей долей вероятности, «кто же это такой красивый к вам пришел».
Как минимум, более менее честный белый список поисковых ботов составите. Уже не навредите своим позициям в поисковых системах.
Прочитал статью, поплевался на код, вспомнил, что это шаред хостинг и вордпресс и вот что хочется сказать: решение вполне жизнеспособное, сыроватое, но когда тебя парсят или пытаются школьники задедосить и нужно что-то на быструю руку, то вариант вполне. Теперь немного по критике способа. Мы используем похожую систему, но сильно модифицированную, но начинали примерно с такой же, поэтому есть что сказать и автору и критикам.
Тем, кто думает, что блокировка айпи может как-то повлиять на посещаемость, то вынужден разочаровать — нат, впн, прокси, мобильные айпи — это редкие единичные случаи, которыми можно пренебречь. Кроме того, можно сделать и временную блокировку (и лучше так и делать) и кроме этого можно для таких айпи и каптчу спрашивать (в том числе и рекаптчу3 или вторую в невидимом режиме и лучше так и поступать вместо блокировки).
Про fail2ban, очень много сайтов грузят статику с того же домена, что и странички, кроме того, бывают случаи, когда нельзя полностью вынести статику на поддомен, поэтому fail2ban решение ещё хуже, чем у автора, ложно-положительных блокировок будет просто очень много, а это уже плохо, просто представьте интернет-магазин с большим количеством товаров и на страницу минимум 50 запросов и задайте себе вопрос, что проще поставить код автора или настроить fail2ban, CDN, и что ещё может понадобиться и все это, чтобы работало вдобавок на шареде.
Правильно говорили про резолв айпишек с блокировкой проксей, впнов и хостингов. Как минимум таким образом делается детект поисковых ботов (двойной резолвинг айпи и результата в айпи и айпи при этом должны совпадать) без вайтлистинга (если нет желания или возможности или нет надобности в белых списках).
Про тестовые куки и редиректы тоже хорошо, поверьте большинство ботов по нашей статистике (пусть она и небольшая — проекты не сильно большие, но все же она на реальных данных) не понимают js, против продвинутых сложно что-то сделать, но можно (та же рекаптча или кастомные проверки на js), хотя и не всех, правильно говорили серебряной пули нет.
И блокировки по диапазонам айпи тоже очень действенные, при условии, что не это будут блокировки, а проверка каптчей или любое кастомное решение для проверки человечности.
И из того что не говорили про то, что портянка в htaccess — это плохо, да так и есть, когда будет там пара тысяч строк, то ниче интересного из этого не получится, кроме того, когда понадобиться удалять из простыни какой-то определённый айпи и если это надо будет делать часто, то это не самое удобное занятие.
Ещё хотел бы добавить, что можно проверять на правильность HTTP заголовков — это почти без оверхеда, но нужно понимать, что искать (тот же язык браузера, как минимум). Кроме этого, автору я бы посоветовал познакомиться с filter_var и фильтрами для айпи и заодно блокировать «неправильные» запросы, типа wp-login.php и остальных (с учетом переноса оригинальных страниц на другие УРЛ) и всякие ?page=‘—.
Этим скриптом должны порезаться и боты ПС и другие от Majestic, Ahrefs и прочих важных сервисов. А это уже не хорошо для сайта.
Есть к примеру боты сервиса hypefactors.com и подобные (которые могут генерировать большое количество запросов). Мне в принципе такие боты на сайте не нужны, так как аудитория этого сайта — жители провинциального города РФ.
У меня на паре проектов 100 тыс+ страниц Гугл пачками делает много запросов. Правда да, там оптимизировано сильно время отдачи страницы.
Можно конечно сказать, что на таких проектах люди сами должны сообразить что можно, а что нельзя. Но когда «горит», то можно что-то и упустить. А восстанавливаться долго и мучительно после таких ошибок.
В любом случае любой ответ будет холиварным, так как кому-то они не нужны совсем и у них простой лэндингпэйдж, другие делают проект под продажу и им статистика от ряда «важных» сервисов нужна для этих целей, а у кого-то Bing или Baidu дает больше трафика чем Гугл и Яндекс, хотя большинство вебмастеров даже не заморачиваются и грубо режут эти поисковики. Цели и задачи у всех разные. А моя мысль была в том, что нужно предупреждать о возможных рисках. А дальше каждый уже сам принимает решение — относятся ли эти риски к его проекту или нет.
Вычисляем потенциальных «злых» ботов и блокируем их по IP