Один из серверов, за которыми я ухаживаю, похоже, участвует в атаках грубой силы на установки Wordpress.
Я получал это много раз, поэтому я хорошо знаком с шагами, которые можно предпринять, чтобы предотвратить это. Однако я борюсь с обнаружением исходящих атак. Сервер представляет собой типичный сервер Apache с несколькими vhosts на нем - здесь, конечно, возникают сложности - если бы на нем был только один, это было бы не так сложно!
В настоящее время я использую tcpflow для регистрации трафика, идущего с любого порта этого сервера на порт 80 на любом другом компьютере, с помощью этой команды:
tcpflow -i eth0 dst port 80 and src host <my_servers_ip> and port not 22
Я считаю, что это предпочтительнее tcpdump. Через некоторое время просмотр его вывода может немного утомить :) tcpflow помещает каждый запрос в отдельный файл ..
Вот некоторые выходные данные файла, которые я считаю подозрительной активностью:
POST /wp-login.php HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Host: somedomain.com
Accept: */*
Cookie: wordpress_test_cookie=WP+Cookie+check
Content-Length: 97
Content-Type: application/x-www-form-urlencoded
log=jacklyn&pwd=london&wp-submit=Log+In&redirect_to=http://somedomain.com/wp-admin/tes1a0&testcookie=1
Обратите внимание, я запутал "Хост:" выше, я считаю, что это атакующий хост (это правильно?).
Итак, на самом деле мой вопрос: как мне обнаружить виртуальный хост, который генерирует этот вредоносный трафик? Если я могу это сделать, я могу сообщить своему клиенту, и он сможет предпринять шаги, чтобы исследовать сайт и внести необходимые изменения, чтобы остановить его.
Любые решения очень благодарны :)
Из того, что вы говорите, я предполагаю, что вы находитесь в системе, в которой вы не можете ограничить загрузку URL-адресов от своих клиентов с помощью allow_url_fopen.
В этом случае на самом деле довольно сложно вернуться к исходному скрипту php, поскольку журнал tcpflow, который вы показываете, фактически не включает эту информацию.
Один простой вариант, который следует рассмотреть, - это заставить любой исходящий запрос иметь раскрывающий пользовательский агент, который можно использовать для идентификации фактического клиента, который его сделал.
Например, вы можете добавить к определению vhost веб-сайта client1 инструкцию
php_admin_value user_agent client1
Это заставит любой http-запрос, сделанный этим веб-сайтом, использовать пользовательский агент «client1», который будет отображаться в вашем журнале tcpflow, что позволит вам узнать, кто его создал.
Обратите внимание, что если конфиденциальность является проблемой, вы можете использовать user_agent, который только вы можете сопоставить с фактическим клиентом (например, шифрование имени клиента).
Однако это может повредить удобству использования, поскольку некоторые веб-сайты будут отображаться по-разному в зависимости от предоставленного user_agent, и что эта настройка намеренно предотвращает любые попытки вашего клиента изменить его.