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

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

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

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

Однако предположим, что ваш веб-сайт обрабатывает только / (домашняя страница), затем некоторые /shop/<product name> и /blog/<name-of-the-article>.

Вы можете создать простое правило (не Apache man здесь, извините) в NGINX, например, следующее:

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

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

В этом отношении эффективен еще один метод: приманки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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