Выяснение источника спама
Несколько месяцев назад мой хост сообщил о спаме с одного из 3 ips на нашем сервере. Узел null маршрутизировал IP, и все было хорошо. У нас ничего не было размещено на этом ip, так что это не имело большого значения.
Хост собирается удалить нулевой маршрут, так как это не постоянное исправление. Тем не менее, я до сих пор не смог выяснить источник проблемы.
Как я могу определить сбой, позволяющий спаму пройти и закрыть его? Сервер Debian, и я вижу процессы sendmail.
Обратите внимание, что ip имеет нулевую маршрутизацию, поэтому я не могу выполнять какие-либо внешние проверки на наличие открытого порта, пока нулевой маршрут не будет удален. Однако удаление нулевого маршрута также открывает потенциал для нового спама.
Вы можете увидеть отчеты о спаме здесь: http://www.projecthoneypot.org/ip_69.197.166.100
1 ответ
Сначала вам нужно внимательно проверить логи sendmail и посмотреть, что происходит. Если он выглядит нормально и sendmail НЕ является открытым ретранслятором, возможно, какой-то другой процесс отправляет электронную почту. Это может быть много вещей, например, злоупотребление php-скриптом (он запускает apache?), Или это может быть угнанная учетная запись, и злоумышленник установил что-то вроде irc-сервера, через который он контролирует спам (я имел дело с очисткой). до такой вещи раньше).
Также проверьте другие журналы на наличие подозрительных действий, посмотрите, кто вошел в систему и откуда. Заполнен ли /var/log/auth.log неудачных попыток входа в систему? (fail2ban - это полезный инструмент, позволяющий остановить перебор паролей).
Если вы не можете найти какие-либо очевидные причины, которые легко устранить, лучше всего полностью стереть систему и переустановить ОС. Вполне возможно, что если ваша система каким-либо образом была скомпрометирована, злоумышленник исправил такие инструменты, как ps, чтобы не быть пойманным.
Также внимательно прочитайте это: http://www.debian.org/doc/manuals/securing-debian-howto/
Особенно: http://www.debian.org/doc/manuals/securing-debian-howto/ch-after-compromise.en.html
Может быть, стоит попытаться выяснить, как произошел компромисс, прежде чем стирать систему, или заменить систему, а затем провести некоторые экспертизы, когда замена работает.