Найти источник спам-скрипта

У нас есть общий хостинг cgi-сервера с apache2+php fcgi а также dma как mta (он пересылает сообщения в почтовый ретранслятор) — это Debian Wheezy — на нем и с возможностью для клиентов запускать сценарии perl / cgi. Есть один клиент с более чем 70 сайтами, и он спамит из своей учетной записи ftp как сумасшедший. Дело в том, что он не знает, откуда исходит спам-скрипт, и мы тоже.

Процесс (ы), рассылающий спам, является perl-script, скрытым как crond — когда вы проверяете /proc/$PID/cwd это всегда /tmp и файл, который запустил процесс, уже удален. strace процесс не помогает — все, что вы видите, это системные вызовы для создания другого почтового сообщения и заголовков и т. д. Поиск в журналах доступа на его нескольких самых посещаемых сайтах для повторяющихся / подозрительных запросов GET / POST не дает нам никакого результата.

Должен ли я сказать, что регулярно grep на .PHP /.CGI / *. PL для base64,eval,fopen,gzinflate и их комбинации дают нулевой результат.

Вопрос в том, есть ли более эффективные методы / программное обеспечение, чтобы найти сценарии спама или посмотреть, какой сценарий запускался и что? Благодарю.

-1

Решение

Я думаю, что mal-скрипт здесь не в обычной форме расширения .pl / .cgi / .fcgi / .fpl, но все еще выполняется на системном уровне как скрипт cgi. Вам нужно проверить типы Apache Handlers / Apache MIME, чтобы увидеть, какие другие расширения запускаются как скрипт cgi. Как только вы сузите это, простой grep должен работать.

1

Другие решения

У меня была похожая проблема, и, следуя подсказке ITroubs, я нашел задание cron, которое в этом случае запланировало запуск команды каждые 15 минут. /var/spool/cron/apache:

*/15 * * * * /var/tmp/lkvnTiofU >/dev/null 2>&1

Закомментируйте это, изменив владельца файла и группу на root, и, наконец, убив все процессы пользователем apache с помощью команды perl и удалив /var/tmp/lkvnTiofU кажется, решил проблему.

Смотря на открытые файлы оскорбительных процессов, с lsof -p [PID] | more где [PID] — это идентификатор процесса, казалось, что два из трех процессов были заняты установлением SMTP-подключений к множеству разных серверов для отправки спама, полностью минуя мои серверы MTA, а третий процесс прослушивал порт 39331, вероятно, бэкдор справиться со спамом.

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

1

По вопросам рекламы [email protected]