Виявити спамерів на моєму сервері

Нещодавно я отримав таку 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): нічого незвичайного
• перевіряється, чи відповідає рефіксація постфіксу: ні, це не (перевірено через telnet)
• перевірено наявність шкідливих програм через clamav: результатів немає
• встановлено та налаштовано fail2ban для ssh, postfix та dovecot
• встановлено останні патчі / оновлення для Ubuntu 16.04 (я роблю це щотижня)
• перевіряється, чи є моя IP-адреса в чорному списку: це не так
• підтверджена запис rDNS в консолі управління мого провайдера хостингу: вона правильно встановлена mail.lotsearch.de.
• змінено паролі всіх поштових облікових записів
• змінили відкриті ключі для доступу до оболонки

Ще важливіше: posteitaliane@test123.itв журналах не було інформації про Отже, якщо мій сервер був би неправильно використаний спамером (наприклад, через просочені smtp облікові дані одного з поштових облікових записів), я бачив би це у файлах журналів.

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

Як я можу контролювати трафік вихідної пошти (за процес та за порт)?

Лише моніторинг вихідного порту 25 не допоможе, оскільки це дозволить зафіксувати лише нерегулярні листи, надіслані через поштовий індекс, але не поштовий трафік, спричинений потенційною інфекцією зловмисного програмного забезпечення (якщо зловмисне програмне забезпечення використовує інший порт, ніж 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

EDIT - Запуск веб-сайтів

• Спеціальна платформа на основі 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, записаний під час з'єднання.

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 блокує повідомлення електронної пошти, а потім не намагаються надсилати інші електронні листи. В ідеалі ви хочете щось подібне. Оскільки другий заблокований, надсилання ще лише посилить проблему.