Увеличение загрузки процессора из-за спама admin-ajax.php

Я испытал, что мой сервер получил нагрузку на процессор в 99%, и сайт идет почти вниз.

Проверьте файл журнала доступа, и есть несколько следующих записей:

203.115.XXX.XXX - - [13/Oct/2017:12:40:01 +0000] "POST /wp-admin/admin-ajax.php HTTP/1.0" 200 178 212.92.XXX.XXX - - [13/Oct/2017:12:40:01 +0000] "GET /wp-admin/admin-ajax.php HTTP/1.0" 200 1 218.29.XXX.XXX - - [13/Oct/2017:12:40:02 +0000] "GET /wp-admin/admin-ajax.php HTTP/1.0" 200 1 104.130.XXX.XXX - - [13/Oct/2017:12:40:02 +0000] "GET /wp-admin/admin-ajax.php HTTP/1.0" 200 1 176.123.XXX.XXX - - [13/Oct/2017:12:40:02 +0000] "POST /wp-admin/admin-ajax.php HTTP/1.0" 200 178 45.115.XXX.XXX - - [13/Oct/2017:12:40:03 +0000] "GET /wp-admin/admin-ajax.php HTTP/1.0" 200 1 212.92.XXX.XXX - - [13/Oct/2017:12:40:03 +0000] "POST /wp-admin/admin-ajax.php HTTP/1.0" 200 178 31.179.XXX.XXX - - [13/Oct/2017:12:40:04 +0000] "GET /wp-admin/admin-ajax.php HTTP/1.0" 200 1 92.240.XXX.XXX - - [13/Oct/2017:12:40:07 +0000] "GET /wp-admin/admin-ajax.php HTTP/1.0" 200 1 92.240.XXX.XXX - - [13/Oct/2017:12:40:07 +0000] "GET /wp-admin/admin-ajax.php HTTP/1.0" 200 1 61.5.XXX.XXX - - [13/Oct/2017:12:40:07 +0000] "POST /wp-admin/admin-ajax.php HTTP/1.0" 200 178 201.59.XXX.XXX - - [13/Oct/2017:12:40:07 +0000] "GET /wp-admin/admin-ajax.php HTTP/1.0" 200 1 

В течение нескольких часов почти 800 одиночных запросов одинаковых IP-адресов. Мне это не кажется естественным. Кроме того, согласно аналитике, на этой странице не так много пользователей на странице.

Таким образом, кажется, что хит пришел извне и влияет на мощность моих серверов.

Когда блокируется доступ к файлу admin-ajax.php через htaccess, загрузка процессора возвращается к 1-3%, и все в порядке.

Мой вопрос:

Есть ли способ заблокировать эти запросы на рассылку в файле admin-ajax.php, который поступает из «снаружи» и разрешает только установленным плагинам / темам доступ к файлу admin-ajax.php ?

Solutions Collecting From Web of "Увеличение загрузки процессора из-за спама admin-ajax.php"

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

Вы можете попытаться заблокировать их, исходя из того, отправляют ли они заголовок Origin или нет. Браузеры обычно будут, разработчики ботов не могут, потому что им обычно не нужно (и как кто-то, кто написал несколько ботов, по крайней мере, я довольно ленив при кодировании).

Кажется, они используют HTTP / 1.0, в то время как браузеры обычно используют 1.1 (и выше).

Они отправляют User-Agents, которые выглядят как законный браузер или у них просто есть «libwww-perl / 5.76» или что-то подобное?

Я бы выбрал механизм многокритериального блокирования. Если он выглядит как законный User-Agent, но использует HTTP 1.0 и не отправляет заголовок Origin, он, вероятно, является ботом. Вы можете пойти дальше и заблокировать только после того, как они сделали один подозрительный запрос (например, посмотрев, какое действие они пытаются выполнить).

Передовая идея состоит в том, чтобы перекрестно ссылаться на то, что с «сделал ли этот IP регулярный просмотр страницы перед запуском AJAX-запросов?» или «сделал ли этот IP-запрос когда-либо образ или файл css / js?», потому что боты, скорее всего, не будут, если они не пытаются быть действительно скрытыми или специально нацелены на ваш сайт. Это может стать проблематичным, если вы позволите прокси-серверам кэшировать эти ресурсы (CloudFlare сделает это автоматически), и, возможно, это будет слишком много усилий для их удержания.

Хотя нет надежного способа отличить настоящие вызовы AJAX от ботов, в такой ситуации вы можете заблокировать доступ с помощью .htaccess

Обычный без референтного блока (как предложено @ janh2):

 RewriteEngine on RewriteCond %{HTTP_REFERER} ^-?$ RewriteRule ^wp-admin/admin-ajax.php - [F,L] 

или с ModSecurity и настраиваемым сообщением:

 <Locationmatch “/wp-admin/admin-ajax.php”> SecRule REQUEST_METHOD “POST” “deny,status:401,id:972687,chain,msg:'wp-admin ajax request blocked, no referrer'” SecRule &HTTP_REFERER “@eq 0” </Locationmatch> 

(Источник: https://troyglancy.com/stopped-wordpress-brute-force-attacks-server/ )

Опять же, не то, что вы хотели бы сделать, если бы у вас еще не было проблем, поскольку заголовок рефери можно легко подделать, но это может повлиять на вас или кого-либо еще с активным вектором атаки admin-ajax.php.

Нет никакого пути, не более, чем есть способ заблокировать «спамеров» от доступа к вашей домашней странице. Я имею в виду, что вы можете поместить все виды чеков, но в итоге вы будете ломать, как должны вести себя сайты, что будет означать, что кто-то где-то не получит свой контент. Если все, что у вас есть, это блог, может быть, вам просто все равно, пока ваши друзья и семья могут его прочитать, но если вы на самом деле зарабатываете деньги на своем сайте, вам может быть интересно больше.

Вместо того, чтобы смотреть журналы, вы должны спросить себя, почему запрос, который ничего не должен делать, кроме bootstraping wordpress, сводит ваш сайт. Если вы запустите php 7+ и кеш объектов, то стоимость процессора для обработки запроса «спам» должна быть близка к нулю. Таким образом, либо вы должны обновить серверную сторону, чтобы улучшить трафик gandle, либо у вас есть целенаправленная атака на определенный плагин, который пытается использовать его обработчик ajax, и в этом случае определение цели атаки должно быть главным приоритетом. Хотя атака маловероятна, все же может иметь смысл изменить свой журнал, чтобы показать полезную нагрузку запроса.