Я недавно получил один 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 => должен решить to => mail.lotsearch.de, что он определенно делает, когда я тестирую его со своего локального компьютера через $ host 94.130.34.42).
Как можно подделать rDNS? Я не могу себе представить, как это может работать технически (только с атакой «человек посередине» где-то в инфраструктуре между получающим почтовым сервером и моим сервером).
Провайдер также упомянул, что «вполне вероятно, что машина, подключающаяся с моего IP-адреса, была взломана и отправляла эти сообщения через прямые соединения на почтовый сервер получателя (также известный как прямой MX)». Что значит direct MX значит? Кто-то украл или обнаружил просочившиеся учетные данные для одной из моих учетных записей и использовал их для отправки почты?
Что я сделал до сих пор, чтобы убедиться, что мой сервер НЕ / не будет взломан:
var/log/mail*): там ничего особенногоlast, lastb): ничего необычного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
РЕДАКТИРОВАТЬ - Запуск веб-приложений
Прежде чем я перейду к своему предложению, я хочу немного прокомментировать то, что вам сказал ваш провайдер:
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, записанный во время подключения.
RFC 5321 раздел 4.4 объясняет формат строки 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 блокирует электронное письмо, и никакие другие электронные письма не отправляются. В идеале вы хотите что-то подобное. Поскольку второй блокируется, отправка большего количества только усугубит проблему.