Один из серверов, за которыми я присматриваю, по-видимому, участвует в атаках методом подбора паролей на установки 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
Обратите внимание, я скрыл «Хост:» выше, я полагаю, что это хост, который подвергается атаке (это правильно?).
Так что мой вопрос на самом деле в том, как мне обнаружить vhost, который генерирует этот вредоносный трафик? Если я могу это сделать, я могу сообщить об этом своему клиенту, и он может предпринять шаги для расследования сайта и внести необходимые изменения, чтобы остановить его..
Любые решения будут приняты с благодарностью :)
решение1
Из того, что вы говорите, я предполагаю, что вы находитесь в ситуации, когда вы не можете ограничить загрузку URL-адресов со своих клиентов с помощью allow_url_fopen.
В этом случае на самом деле довольно сложно вернуться к исходному PHP-скрипту, поскольку показанный вами журнал tcpflow на самом деле не содержит эту информацию.
Одним из простых вариантов, которые можно рассмотреть, было бы принудительное указание для любого исходящего запроса раскрывающего user-agent, который можно было бы использовать для идентификации фактического клиента, сделавшего этот запрос.
Например, вы можете добавить к определению vhost веб-сайта client1 инструкцию
php_admin_value user_agent client1
Это заставит любой http-запрос, сделанный этим веб-сайтом, использовать user-agent «client1», что отобразится в вашем журнале tcpflow, что позволит вам узнать, кто его инициировал.
Обратите внимание: если конфиденциальность имеет значение, вы можете использовать user_agent, который только вы можете сопоставить с реальным клиентом (например, шифрование имени клиента).
Однако это может нанести ущерб удобству использования, поскольку некоторые веб-сайты будут отображаться по-разному в зависимости от предоставленного user_agent, и эта настройка намеренно предотвращает любые попытки вашего клиента изменить его.