Уменьшить нагрузку на сервер, когда боты запрашивают несуществующие страницы

Пейджинг для обмена местами смертелен для производительности. Настройте Apache MPM таким образом, чтобы максимально возможное количество обслуживаемых параллельных подключений, удобно помещалось в память. Примечательно, что директива MaxRequestWorkers .

Подобное планирование емкости помогает добиться хороших всплесков в трафике, а также вредоносных.

Отслеживайте время отклика. Количество фальшивых запросов не имеет значения, если ни один из них не нарушает вашу безопасность, а производительность все равно приемлема.

Запрещение IP-адресов помогает рецидивистам. Однако, вряд ли будет много повторов, что снижает эффективность fail2ban. Взрыв всей сети Интернет за уязвимость веб-приложений месяца зачастую более полезен для злоумышленника, чем подробное сканирование. Кроме того, один злоумышленник может прийти с многих адресов источника.

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

Есть ли способ настроить Apache или другой дополнительный инструмент для переопределения веб-приложения и возврата не загружаемой страницы 404 (статический .html и т.д.)?

Это довольно специфично для вашего веб-приложения.

Если оно использует шаблон фронт-контроллера, который, например, является один index.php обрабатывает практически неограниченное количество различных SEO URL, например /foo/bar, и , то в конфигурации слишком много различных "категорийных" (первого уровня) страниц, то в этом случае не повезло. Однако, предположим, что Ваш сайт обрабатывает только / (домашнюю страницу), затем некоторые /shop/<имя продукта> и /blog/<номер-статьи>.

Вы можете построить простое правило (не человек Apache, извините) в NGINX, например, folowing:

location ~ ^/(?!($|shop/|blog/)) { 
    return 404; 
} 

, которое заставит веб-сервер доставлять прямую не найденную ошибку без обращения к PHP вообще, для запросов, которые, как известно, не являются частью URL "схемы" вашего приложения.

Другой метод, эффективный в этом отношении, это honeypots.

Обычно боты пытаются проверить программное обеспечение/плагины, которые уязвимы, но даже не присутствуют на вашем сайте, чтобы начать с .

Вы можете использовать тот факт, что вы знаете, что у вас их нет. И тогда мгновенно запретит тех, кто пытается загрузить эти конечные точки. (например, смотрите эту honeypot для техники NGINX).

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

Например, вы знаете, что у вас есть сайт Magento, но так много ботов будут пытаться увидеть/войти в систему как Wordpress. Поэтому /wp-login.php является одним из ваших мест расположения honeypot.

После определения в конфигурационном файле вам необходимо передать эти запросы FastCGI скрипту, который взаимодействует с вашим брандмауэром на немедленно ban.

Это не только не вызовет загрузку PHP, но и вызовет мгновенный запрет в брандмауэре.

Таким образом, это сработает намного быстрее по сравнению с Fail2ban (который отслеживает журналы, например, при повторных ошибках входа в систему), потому что запрет происходит сразу же после поступления запроса. Однако это может работать как дополнительная мера по сравнению с Fail2ban

Перенесите оценку на ваш брандмауэр. То, что вы ищете, это Частота 404 на URL-адресе верхнего уровня по IP. Изучите свои текущие журналы, чтобы понять скорость прибытия этих существ, а затем адаптируйте правило к их поведению.

На данный момент у вас есть несколько вариантов * Отправьте их в медленную приманку, а затем в бесплатный облачный уровень, где страницы случайным образом 503. * На брандмауэре 503 IP в течение от 5 до 30 минут. Что вы хотите сделать, так это загнать бота в ловушку и не дать ему изменить код бота. Разработчику сложнее всего проверить код, который иногда работает... а 503 — допустимый код возврата.