Обнаружить спаммеров на моем сервере

Недавно я получил один Undelivered Mail Returned to Senderпри отправке своей рассылки одному из моих 1500 клиентов. Мой сайт использует процедуру двойного согласия, чтобы убедиться, что пользователь явно хочет получать мою новостную рассылку.

Сообщение об ошибке:

smtp; 554 ...
    Swisscom AG IP: 94.130.34.42, You are not allowed to send us mail. Please
    refer to xyz.com if you feel this is in error.

Я получил пример спама (от почтового провайдера принимающего почтового сервера):

Received: from mail.com ([94.130.34.42])
        by smtp-27.iol.local with SMTP
        id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100
From: "Servizi online - Poste Italiane" <posteitaliane@test123.it>
Subject: Abbiamo ricevuto una segnalazione di accredito
Date: Mon, 12 Feb 2018 11:32:03 -0500

Провайдер также заявил, что мой сервер взломан. Далее он заявил, что «почтовый сервер-получатель просто записал rDNS, предоставленный ему подключающимся IP-адресом, в данном случае mail.com ([94.130.34.42])» - что определенно НЕ так, как я настроил свою запись rDNS (mail.lotsearch.de) для своего IP-адреса. Поэтому, если я правильно понял rDNS, почтовый сервер-получатель запрашивает IP-адрес отправителя для записи rDNS (94.130.34.42 => должен разрешить => mail.lotsearch.de, что он определенно делает, когда я тестирую его с локального компьютера через $ host 94.130.34.42).

Как можно подделать rDNS? Я никак не могу представить, как это технически может работать (только при атаке «человек посередине» где-то в инфраструктуре между принимающим почтовым сервером и моим сервером).

Поставщик также упомянул, что «вероятно, что компьютер, подключающийся с моего IP-адреса, был взломан и отправлял эти сообщения через прямые подключения к серверу получателя (также известному как прямой MX)». Что direct MXзначит? Кто-то украл или обнаружил пропущенные учетные данные в одной из моих учетных записей и использовал их для отправки почты?

Что я сделал до сих пор, чтобы убедиться, что мой сервер НЕ / не будет взломан:

• искал почтовые журналы ( var/log/mail*): там ничего особенного
• проверил логи логина ssh ( last, lastb): ничего необычного
• проверено, работает ли postfix ретрансляция: нет - нет (проверено через telnet)
• проверен на наличие вредоносного ПО через clamav: нет результатов
• установлен и настроен fail2ban для ssh, postfix и dovecot
• установил последние патчи / обновления для Ubuntu 16.04 (я делаю это каждую неделю)
• проверил, есть ли мой IP-адрес в любом черном списке: это не
• подтверждена запись rDNS в консоли управления моего хостинг-провайдера: она правильно установлена ​​на mail.lotsearch.de.
• изменил пароли всех почтовых аккаунтов
• изменены открытые ключи для доступа к оболочке

Более важно: posteitaliane@test123.itв журналах не было никакой информации . Так что, если мой сервер был бы неправомерно использован спамером (например, из-за утечки учетных данных smtp одной из почтовых учетных записей), я бы увидел это в файлах журнала.

Последняя возможность, о которой я могу подумать, состоит в том, что злоумышленник разместил вредоносное ПО на моем сервере, который я еще не обнаружил.

Как я могу отслеживать исходящий почтовый трафик (на процесс и на порт)?

Мониторинг только исходящего порта 25 не поможет, так как он будет перехватывать нерегулярные письма, отправленные через postfix, но не почтовый трафик, вызванный потенциальным заражением вредоносным ПО (если вредоносное ПО использует другой порт, отличный от 25, для прямой отправки почты / связи с почтовыми серверами получателей) , Если я буду отслеживать исходящий трафик на всех портах, я получу доступ к огромному лог-файлу, который я не могу эффективно найти для поиска подозрительной активности.

РЕДАКТИРОВАТЬ - Добавлен тест для открытого реле:

$ telnet mail.lotsearch.de 25
$ HELO test@test.de
250 mail.lotsearch.de
$ MAIL FROM: test@test.com
250 2.1.0 Ok
$ RCPT TO:<realEmail@gmail.com>
454 4.7.1 <realEmail@gmail.com>: Relay access denied

РЕДАКТИРОВАТЬ - Запуск веб-приложений

• Пользовательская платформа на основе Zend Framework 3 ( https://framework.zend.com/ )
• Mediawiki ( https://www.mediawiki.org/ )
• Mantis Bug Tracker ( https://www.mantisbt.org/ )

Прежде чем я получу свое предложение, я хочу немного прокомментировать то, что ваш провайдер сказал вам:

 Received: from mail.com ([94.130.34.42])
        by smtp-27.iol.local with SMTP
        id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100

Это не означает, что обратным DNS для 94.130.34.42 является (или был) mail.com. Скорее, это означает, что SMTP-клиент отправляется mail.comв своей HELO(или EHLO) строке. (Хорошо настроенный почтовый сервер полностью отклонил бы это соединение, но это на Swisscom, а не на вас ...) Эта строка не указывает на обратную запись DNS. Если бы это было так, оно бы появилось в скобках. Например:

Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197])

В этом случае первое имя хоста - это то, что почтовый сервер идентифицировал как свой EHLO. Второе имя хоста - это обратный DNS, записанный во время установления соединения.

Раздел 4.4 RFC 5321 объясняет формат строки Received: с формальной грамматикой.

В вашем случае обратный DNS не был записан. Поскольку у вашего IP-адреса есть запись PTR, это может быть связано с тем, что они его не нашли или произошел временный сбой DNS.

Теперь, похоже, вы используете веб-хостинг и имеете множество веб-приложений. Если один из них скомпрометирован, он может начать рассылку спама. Они часто устанавливают прямые подключения к удаленным почтовым серверам, просматривая их записи MX и подключаясь к порту 25, как если бы они были самим почтовым сервером, вместо того, чтобы доставлять почту в локальную почтовую буферную систему или почтовую службу с проверкой подлинности через порты 587 или 465. как законные веб-приложения.

Один из способов остановить это - реализовать правило брандмауэра, которое запрещает исходящие соединения через порт 25, если пользователь не является пользователем почтового сервера. Например:

iptables -I OUTPUT -m owner ! --uid-owner postfix -m tcp -p tcp --dport 25 -j REJECT

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

В наши дни попытки создать свой собственный почтовый сервер, по большей части, проигрывают, и вам лучше найти доступную услугу. Было сказано, что..

• Посмотрите на свои журналы, идущие к провайдеру, который заблокировал вас, и посмотрите, сможете ли вы найти что-нибудь подозрительное. Возможно, и часто случается, что кто-то забывает, что подписался на вашу рассылку, и помечает вас как спам. Затем, в зависимости от провайдера, вы можете попасть в черный список провайдера, даже если вы не сделали ничего плохого.

• Отделите массовые рассылки от всех остальных ваших писем на два сервера.

• Храните журналы в течение нескольких недель как минимум, а лучше месяцев. Поэтому в любое время вы что-то исследуете

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

• Не уверен, как они это реализуют, но я знаю, что многие провайдеры делают для служб исходящей почты то, что во-вторых, когда провайдер / IP блокирует электронную почту, тогда никакие другие электронные письма не пытаются отправлять. В идеале вы хотите что-то подобное. Поскольку второй блокируется, отправка большего количества только усугубит проблему.