Мы видим много запросов на несуществующие setup.php файлы в наших журналах доступа (см. ниже). Для некоторых наших клиентов, использующих правила перезаписи, каждый из этих запросов вызывает выполнение сценария PHP, вызывая значительное замедление работы сервера и генерируя ненужный трафик.
Можно ли быстро отклонить подобные запросы? Я думал об установлении общего правила отказа, которое запрещает все setup.php связанные запросы, но это может быть неправильный подход. Какие-либо предложения?
217.115.202.30 - - [17/Nov/2010:09:13:35 +0100] "GET /PHPMYADMIN/scripts/setup.php HTTP/1.1" 404 2452 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:35 +0100] "GET /PMA/scripts/setup.php HTTP/1.1" 404 2444 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:39 +0100] "GET /PMA2005/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:47 +0100] "GET /SSLMySQLAdmin/scripts/setup.php HTTP/1.1" 404 2452 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:42 +0100] "GET /SQL/scripts/setup.php HTTP/1.1" 404 2446 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:49 +0100] "GET /admin/phpmyadmin/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:58 +0100] "GET /admin/scripts/setup.php HTTP/1.1" 404 2442 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:00 +0100] "GET /bbs/data/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:01 +0100] "GET /cpadmin/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:03 +0100] "GET /cpadmindb/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:53 +0100] "GET /admin/pma/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:05 +0100] "GET /cpanelmysql/scripts/setup.php HTTP/1.1" 404 2450 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:11 +0100] "GET /cpanelphpmyadmin/scripts/setup.php HTTP/1.1" 404 2452 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:13 +0100] "GET /cpanelsql/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:23 +0100] "GET /cpphpmyadmin/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:25 +0100] "GET /db/scripts/setup.php HTTP/1.1" 404 2441 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:26 +0100] "GET /dbadmin/scripts/setup.php HTTP/1.1" 404 2445 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:28 +0100] "GET /myadmin/scripts/setup.php HTTP/1.1" 404 2445 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:29 +0100] "GET /mysql-admin/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:32 +0100] "GET /mysql/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:33 +0100] "GET /mysqladmin/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:35 +0100] "GET /mysqladminconfig/scripts/setup.php HTTP/1.1" 404 2453 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:36 +0100] "GET /mysqlmanager/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu"
Начните с того, что не обслуживайте какой-либо контент из виртуального хоста по умолчанию, чтобы боты, которые атакуют вас вслепую, основываясь только на IP-адресе, имеют меньше шансов сделать запрос, который вызовет любое «тяжеловесное» действие с вашей стороны.
тогда вы можете использовать fail2ban и проверьте содержимое ваших журналов + IP-адреса блоков, с которых приходили слепые сканирования.
По-прежнему актуален почти 4 года спустя.
Поскольку предположительно mod_rewrite обрабатывает добросовестный трафик, эти скрипты не собираются сильно увеличивать нагрузку. Но да, они могут на мгновение вызвать задержку. В общем, вы не сможете полностью предотвратить это.
Моды и плагины для смягчения этого, как правило, ориентированы на частоту и скорость до блокировки ip на локальном брандмауэре (iptables). Более эффективный подход должен включать в себя подписи, такие как фрагменты (фиктивные при нормальном использовании) имен каталогов. Затем следует рассмотреть, насколько это должно быть реактивным. Можно адаптировать части пакета «denyhosts» (продукт для защиты от аналогичных проблем при входе в систему с паролем SSH) для чтения журнала и определения «подписей» для добавления IP-адресов в /etc/hosts.deny.
Как правило, эти люди не возвращаются с одного и того же хоста, поэтому мы можем захотеть чего-нибудь быстрее. Прелесть открытого исходного кода в том, что мы можем его настроить. mod_evasive кажется нормальным, но что делать, если ваш сервер запрашивает скрипты законно (curl, wget и т. д.). Следовательно, нет CAPTCHA и необходимости в белых списках или сбросе с помощью POST или GET parms.
Для тех из вас, кто беспокоился о риске атаки (OP не было, OP беспокоило потребление ресурсов), если у вас действительно есть phpmyadmin, тогда:
Используйте директивы для каждого каталога.
ORDER DENY, ALLOW
DENY FROM ALL
ALLOW FROM *safe places*
Серьезно, очень немногие люди должны иметь доступ. Если они не администраторы баз данных, что оправдывает риск? Во время инцидента Apache можно перенастроить по запросу, чтобы открыть дверь с одного адреса. Если вас нет, подключитесь к виртуальному компьютеру VNC / RDP в той же сети или используйте прокси-сервер.
Их сценарий по-прежнему будет попадать вам в течение 404 (и как минимум одного 403). Оставление для них фиктивных папок и кода конфигурации только поощряет их. Я просто использую grep -v, чтобы отфильтровать имена каталогов.
Я сейчас использую @ mod_evasive @, что оказалось отличным решением.
Убедитесь, что PHPMyAdmin обновлен. Скройте его, поместите в каталог, который они не будут сканировать, например /padmin32.