Обнаружение спамеров на моем сервере
Недавно я получил одно недоставленное письмо, возвращенное отправителю при отправке информационного бюллетеня одному из моих 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.
Итак, если я правильно понял rDNS, получающий почтовый сервер запрашивает IP-адрес отправителя для записи rDNS (94.130.34.42 => должен разрешить => mail.lotsearch.de, что он определенно делает, когда я тестирую его с моей локальной машины через $ host 94.130.34.42 ).
Как можно подделать rDNS? Я не могу себе представить, как это может работать технически (только с атакой «человек посередине» где-то в инфраструктуре между принимающим почтовым сервером и моим сервером).
Провайдер также упомянул, что «вполне вероятно, что компьютер, подключающийся с моего IP-адреса, был скомпрометирован и отправляет эти сообщения через прямые подключения на почтовый сервер получателя (также известный как прямой MX) ». Что означает direct MX ? Кто-то украл или обнаружил просочившиеся учетные данные для одной из моих учетных записей и использовал их для отправки почты?
Что я сделал до сих пор, чтобы убедиться, что мой сервер НЕ / не будет взломан:
- просмотрел журналы электронной почты (
var / log / mail *): там ничего особенного - проверил журналы входа в ssh (
последний,lastb): ничего необычного - проверил если postfix выполняет ретрансляцию: нет, это не так (проверено через telnet)
- проверено на наличие вредоносных программ через clamav: нет результатов
- установлен и настроен fail2ban для ssh, postfix и dovecot
- установлены последние патчи / обновления для Ubuntu 16.04 (я делаю это каждую неделю)
- проверил, находится ли мой IP-адрес в каком-либо черном списке: это не
- проверенная запись rDNS в консоли управления моего хостинг-провайдера:posteitaliane@test123.it в логах. Поэтому, если бы мой сервер был неправомерно использован спамером (например, из-за утечки учетных данных smtp одной из учетных записей электронной почты), я бы увидел это в файлах журнала.
Последняя возможность, о которой я могу думать, это то, что злоумышленник разместил вредоносное ПО на моем сервере я еще не нашел.
Как я могу отслеживать исходящий почтовый трафик (по процессам и по портам)?
Только мониторинг исходящего порта 25 не поможет, так как это позволит перехватить только нерегулярные письма, отправленные через postfix, но не почтовый трафик, вызванный потенциальным заражением вредоносным ПО (если вредоносная программа использует порт, отличный от 25, для прямой отправки почты / общения с получателем. почтовые серверы). Если я буду отслеживать исходящий трафик на всех портах, я получу доступ к огромному файлу журнала, в котором я не смогу эффективно искать подозрительную активность.
EDIT - Добавлен тест для открытого реле:
$ 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/ )
Прежде чем перейти к своему предложению, я хочу немного прокомментировать то, что вам сказал ваш провайдер:
Получено: от mail.com ([94.130.34.42]) по smtp-27.iol.local с SMTP id itOWeYZ6O42IFitOWe35TR; Вт, 13 фев 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 блокирует электронное письмо, тогда никакие другие электронные письма не будут отправлены. В идеале вы хотите что-то подобное. Поскольку второй блокируется, отправка большего количества только усугубит проблему.