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

Недавно я получил один 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" <[email protected]>
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 => должен разрешаться = = gt; mail.lotsearch.de, что он определенно делает, когда я проверяю его с моего локального машина через $ host 94.130.34.42).

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

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

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

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

Более важно: в журналах не было информации о [email protected]. Поэтому, если бы мой сервер был неправильно использован спамером (например, из-за утечки учетных данных smtp одной из почтовых учетных записей), я бы увидел это в файлах журнала.

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

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

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

EDIT - добавлен тест для открытого реле:

$ telnet mail.lotsearch.de 25
$ HELO [email protected]
250 mail.lotsearch.de
$ MAIL FROM: [email protected]
250 2.1.0 Ok
$ RCPT TO:<[email protected]>
454 4.7.1 <[email protected]>: Relay access denied

EDIT - запуск веб-страниц

12 голосов | спросил mfuesslin 14 FebruaryEurope/MoscowbWed, 14 Feb 2018 17:52:20 +0300000000pmWed, 14 Feb 2018 17:52:20 +030018 2018, 17:52:20

2 ответа


13

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

 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: with формальная грамматика.

В вашем случае не было зарегистрировано обратное 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-серверы, но должны использовать локальную почтовую катушку или аутентифицированную почтовую службу.

ответил Michael Hampton 14 FebruaryEurope/MoscowbWed, 14 Feb 2018 18:59:02 +0300000000pmWed, 14 Feb 2018 18:59:02 +030018 2018, 18:59:02
7

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

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

  • Разделяйте массовые рассылки со всего вашего другого письма на два сервера.

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

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

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

ответил Francisco1844 14 FebruaryEurope/MoscowbWed, 14 Feb 2018 18:22:18 +0300000000pmWed, 14 Feb 2018 18:22:18 +030018 2018, 18:22:18

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132