Недавно я получил один 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/ )
источник
Ответы:
Прежде чем я получу свое предложение, я хочу немного прокомментировать то, что ваш провайдер сказал вам:
Это не означает, что обратным DNS для 94.130.34.42 является (или был) mail.com. Скорее, это означает, что SMTP-клиент отправляется
mail.comв своейHELO(илиEHLO) строке. (Хорошо настроенный почтовый сервер полностью отклонил бы это соединение, но это на Swisscom, а не на вас ...) Эта строка не указывает на обратную запись DNS. Если бы это было так, оно бы появилось в скобках. Например:В этом случае первое имя хоста - это то, что почтовый сервер идентифицировал как свой
EHLO. Второе имя хоста - это обратный DNS, записанный во время установления соединения.Раздел 4.4 RFC 5321 объясняет формат строки Received: с формальной грамматикой.
В вашем случае обратный DNS не был записан. Поскольку у вашего IP-адреса есть запись PTR, это может быть связано с тем, что они его не нашли или произошел временный сбой DNS.
Теперь, похоже, вы используете веб-хостинг и имеете множество веб-приложений. Если один из них скомпрометирован, он может начать рассылку спама. Они часто устанавливают прямые подключения к удаленным почтовым серверам, просматривая их записи MX и подключаясь к порту 25, как если бы они были самим почтовым сервером, вместо того, чтобы доставлять почту в локальную почтовую буферную систему или почтовую службу с проверкой подлинности через порты 587 или 465. как законные веб-приложения.
Один из способов остановить это - реализовать правило брандмауэра, которое запрещает исходящие соединения через порт 25, если пользователь не является пользователем почтового сервера. Например:
Веб-приложения больше не могут доставлять почту напрямую на удаленные SMTP-серверы, но должны использовать локальную почтовую буферизацию или почтовую службу с проверкой подлинности.
источник
iptablesправило, позволяющее пользователям postfix и plesk отправлять электронные письма (я думаю, что Plesk Panel отправляет почту напрямую, а не через postfix). Можно ли также настроить crondaemon (мои cronjobs) для отправки писем через smtp через postfix? Я не хочу добавлять пользователя cron в iptables (как еще одно исключение), так как было бы более безопасно пропустить почтовый трафик, по возможности, через postfix. Можно ли позволить crontab использовать postfix для отправки журналов ошибок? Должен ли я поставить это в новый вопрос здесь о сбое сервера?root? Потому что основной процесс postfix выполняетсяrootв большинстве случаев. Или основной процесс postfix порождает подпроцессы, использующиеpostfix-user для отправки электронных писем / что-то в этом роде? Я попробовал ваше правило iptables, электронные письма не могли быть доставлены ... Если яps -ef | grep "postfix"вижу, я вижу некоторые подпроцессы, выполняемыеpostfix-user, и один главный процесс, выполняемыйroot...В наши дни попытки создать свой собственный почтовый сервер, по большей части, проигрывают, и вам лучше найти доступную услугу. Было сказано, что..
Посмотрите на свои журналы, идущие к провайдеру, который заблокировал вас, и посмотрите, сможете ли вы найти что-нибудь подозрительное. Возможно, и часто случается, что кто-то забывает, что подписался на вашу рассылку, и помечает вас как спам. Затем, в зависимости от провайдера, вы можете попасть в черный список провайдера, даже если вы не сделали ничего плохого.
Отделите массовые рассылки от всех остальных ваших писем на два сервера.
Храните журналы в течение нескольких недель как минимум, а лучше месяцев. Поэтому в любое время вы что-то исследуете
Ежедневно проверяйте свои журналы на предмет подобных ситуаций у любого провайдера и просматривайте их ежедневно или быстрее. В тот момент, когда вы блокируетесь, и если вы продолжаете пытаться отправить, это может ухудшиться. Вы можете перейти от временного блока к постоянному блоку ... чтобы попасть в черный список.
Не уверен, как они это реализуют, но я знаю, что многие провайдеры делают для служб исходящей почты то, что во-вторых, когда провайдер / IP блокирует электронную почту, тогда никакие другие электронные письма не пытаются отправлять. В идеале вы хотите что-то подобное. Поскольку второй блокируется, отправка большего количества только усугубит проблему.
источник