Здравствуйте, уважаемые форумчане! Столкнулся со следующей проблемой.. Есть дедик на Linux/FreeBSD, на нем размещено более сотни сайтов. Сайты разные, разные CMS.. Через фтп/аккаунт одного сайта, на другой залезть невозможно. Периодически через уязвимости движков взламывают то один то другой сайт. В последнее время при взломах начали размещать в папках взломанного сайта системы для спам-рассылки. О том что на дедике размещена такая система я узнаю только когда айпишник сервера попадает в стоп-листы почтовых служб (проверяем тут - http://www.senderbase.org) и перестают отправляться письма с почтовых акков сервера. Приходится сливать все сайты и искать нечисть просто по названию файлов, т.к. хостер не предоставляет никакой статистики, которая позволила бы определить подозрительную активность. Однако после последнего взлома и попадания в стоп-листы, проверив файлы поиском - к сожалению ничего не нашел, хотя спам 100% рассылается, и рассылается именно с нашего IP. Перепроверять сотни тысяч файлов вручную - конечно не вариант. Посоветуйте пожалуйста, как быть в данной ситуации. Чем можно найти эту спам-систему? Спасибо.
Возможны следующие варианты: 1. спам через sendmail Нужно подменить sendmail в период активности (использования) системы на скрипт или другое приложение, которое залогирует информацию о вызвавшем его скрипте, юзере, текущей директории и т.д., что даст возможность вычислить систему. 2. спам через proxy/socks Настройка firewall ipfw или iptables, для невозможности использовать сервер в качестве proxy/socks 3. спам через dns Настройка firewall ipfw или iptables, для невозможности использовать встроенный smtp сервер, кроме sendmail, здесь возможно поможет selinux 4. найти вредосные скрипты можно через консоль при помощи следующих утилит grep -rn 'system' /var/vhosts grep -rn 'passthru' /var/vhosts grep -rn 'eval' /var/vhosts grep -rn 'mail' /var/vhosts grep -rn 'другая критическая сигнатура' /var/vhosts grep -rn [регулярное выражение] /var/vhosts и т.д. Проверить директории, имеющие права на запись. Уменьшить их количество до минимума. Проверить скрипты, файлы (возможно расширение не скрипта, а используется допустим локальный include файла с кодом) Запретить работу с сокетами в скриптах, если таковая ненужна, по средством php.ini
