Wykryj spamerów na moim serwerze

Niedawno dostałem jeden Undelivered Mail Returned to Senderpodczas wysyłania mojego biuletynu do jednego z moich 1500 klientów. Moja witryna korzysta z procedury podwójnego wyboru, aby upewnić się, że użytkownik wyraźnie chce otrzymywać mój biuletyn.

Komunikat o błędzie:

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.

Dostałem przykładowy spam (od dostawcy poczty odbierającego serwera poczty):

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

Dostawca stwierdził również, że mój serwer wydaje się być zhakowany. Stwierdził ponadto, że „serwer poczty odbiorcy po prostu zarejestrował rDNS przedstawiony mu przez połączenie IP, w tym przypadku mail.com ([94.130.34.42])” - co zdecydowanie NIE jest, ponieważ skonfigurowałem mój wpis rDNS (mail.lotsearch.de) dla mojego adresu IP. Więc jeśli dobrze zrozumiałem rDNS, serwer poczty odbierającej wysyła zapytanie do adresu IP nadawcy o wpis rDNS (94.130.34.42 => powinien rozstrzygnąć na => mail.lotsearch.de, co zdecydowanie robi, kiedy testuję go z mojego komputera lokalnego za pośrednictwem $ host 94.130.34.42).

Jak można sfałszować rDNS? Nie mogę sobie wyobrazić, jak to technicznie może działać (tylko z atakiem man-in-the-middle gdzieś w infrastrukturze między odbierającym serwerem pocztowym a moim serwerem).

Dostawca wspomniał również, że „prawdopodobne jest, że komputer łączący się z mojego adresu IP został przejęty i wysyłał te wiadomości przez bezpośrednie połączenia do serwera poczty odbiorcy (zwanego również bezpośrednim MX)”. Co direct MXznaczy Ktoś ukradł lub znalazł wyciek poświadczeń poczty na jednym z moich kont pocztowych i użył ich do wysyłania poczty?

Co zrobiłem do tej pory, aby upewnić się, że mój serwer NIE jest / nie zostanie zhakowany:

• przeszukiwał mail logs ( var/log/mail*): nic specjalnego
• sprawdziłem logi logowania ssh ( last, lastb): nic niezwykłego
• sprawdzane, czy postfix przekazuje: nie, nie (sprawdzane przez telnet)
• sprawdzone pod kątem złośliwego oprogramowania za pośrednictwem clamav: brak wyników
• zainstalowane i skonfigurowane fail2ban dla ssh, postfix i dovecot
• zainstalowałem najnowsze łatki / aktualizacje dla Ubuntu 16.04 (robię to co tydzień)
• sprawdzone, czy mój adres IP znajduje się na czarnej liście: nie ma go
• zweryfikowany wpis rDNS w konsoli zarządzania mojego dostawcy hostingu: jest poprawnie ustawiony na mail.lotsearch.de.
• zmienione hasła do wszystkich kont pocztowych
• zmieniono klucze publiczne dostępu do powłoki

Ważniejsze: posteitaliane@test123.itw dziennikach nie było żadnych informacji . Więc jeśli mój serwer zostałby niewłaściwie wykorzystany przez spamera (np. Z powodu wycieku poświadczeń smtp jednego z kont pocztowych), zobaczyłbym to w plikach dziennika.

Ostatnią możliwością, o której mogę pomyśleć, jest to, że intruz umieścił złośliwe oprogramowanie na moim serwerze, którego jeszcze nie znalazłem.

Jak mogę monitorować ruch poczty wychodzącej (według procesu i portu)?

Tylko monitorowanie portu wychodzącego 25 nie pomogłoby, ponieważ zatrzymałoby to tylko nieregularne wiadomości e-mail wysyłane za pomocą Postfiksa, ale nie ruch pocztowy spowodowany potencjalnym zainfekowaniem złośliwym oprogramowaniem (jeśli szkodliwe oprogramowanie używa innego portu niż 25 do bezpośredniego wysyłania wiadomości e-mail / komunikacji z serwerami pocztowymi adresatów) . Jeśli monitoruję ruch wychodzący na wszystkich portach, dostanę się do ogromnego pliku dziennika, którego nie będę w stanie skutecznie wyszukać podejrzanej aktywności.

EDYCJA - Dodano test dla otwartego przekaźnika:

$ 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

EDYCJA - Uruchamianie aplikacji internetowych

• Platforma niestandardowa oparta na Zend Framework 3 ( https://framework.zend.com/ )
• Mediawiki ( https://www.mediawiki.org/ )
• Mantis Bug Tracker ( https://www.mantisbt.org/ )

Zanim przejdę do mojej sugestii, chcę skomentować coś, co powiedział ci twój dostawca:

 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

Nie oznacza to , że zwrotny DNS dla 94.130.34.42 to (lub był) mail.com. Wskazuje raczej, że klient SMTP wysłał mail.comswój HELO(lub EHLO) wiersz. (Dobrze skonfigurowany serwer pocztowy całkowicie odrzuciłby to połączenie, ale dotyczy to Swisscom, nie ty ...) Ta linia nie wskazuje żadnego odwrotnego wpisu DNS. Gdyby tak było, pojawiłby się w nawiasach. Na przykład:

Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197])

W takim przypadku pierwsza nazwa hosta jest identyfikowana przez serwer pocztowy EHLO. Druga nazwa hosta to odwrotny DNS zarejestrowany podczas nawiązywania połączenia.

RFC 5321 sekcja 4.4 wyjaśnia format linii Received: z formalną gramatyką.

W twoim przypadku nie zarejestrowano odwrotnego DNS. Ponieważ twój adres IP ma rekord PTR, może to być spowodowane tym, że nie sprawdzili go lub wystąpiła tymczasowa awaria DNS.

Teraz wydaje się, że prowadzisz usługę hostingową i masz wiele aplikacji internetowych. Jeśli jeden z nich zostanie naruszony, może zacząć wysyłać spam. Często nawiązują bezpośrednie połączenia ze zdalnymi serwerami poczty, wyszukując ich rekordy MX i łącząc się z portem 25, tak jakby to był sam serwer pocztowy, zamiast dostarczać pocztę do lokalnej szpuli poczty lub uwierzytelnionej usługi pocztowej na portach 587 lub 465 tak jak legalne aplikacje internetowe.

Jednym ze sposobów, aby to zatrzymać, jest wdrożenie reguły zapory ogniowej, która zapobiega wychodzącym połączeniom na porcie 25, chyba że użytkownik jest użytkownikiem serwera pocztowego. Na przykład:

iptables -I OUTPUT -m owner ! --uid-owner postfix -m tcp -p tcp --dport 25 -j REJECT

Aplikacje internetowe nie mogą już dostarczać poczty bezpośrednio do zdalnych serwerów SMTP, ale muszą korzystać z lokalnego bufora poczty lub uwierzytelnionej usługi pocztowej.

W dzisiejszych czasach próba stworzenia własnego serwera pocztowego jest w większości przegraną bitwą i lepiej znaleźć niedrogą usługę. Powiedziawszy to ...

• Spójrz na dzienniki prowadzące do dostawcy, który Cię zablokował, i sprawdź, czy możesz znaleźć coś podejrzanego. Możliwe i często zdarza się, że ktoś zapomina o subskrypcji Twojego newslettera i oznaczy Cię jako spam. Następnie w zależności od dostawcy możesz dostać się na czarną listę dostawcy, nawet jeśli nie zrobiłeś nic złego.

• Oddziel masowe wysyłki od wszystkich pozostałych wiadomości e-mail na dwóch serwerach.

• Przechowuj dzienniki przez co najmniej tygodnie i lepsze miesiące. Więc za każdym razem, gdy coś się dzieje, badasz.

• Codziennie sprawdzaj dzienniki pod kątem podobnych sytuacji od dowolnego dostawcy i przeglądaj je codziennie lub szybciej. Sekunda zostanie zablokowana, a jeśli będziesz próbował wysłać, może się pogorszyć. Możesz przejść z bloku tymczasowego do bloku stałego ... i zgłosić się na czarną listę.

• Nie jestem pewien, jak to zaimplementują, ale wiem, że wielu dostawców robi usługi poczty wychodzącej, że po drugie dostawca / adres IP blokuje wiadomość e-mail, a następnie nie próbuje się wysłać żadnej innej wiadomości e-mail. Idealnie chcesz czegoś takiego. Ponieważ drugi zostaje zablokowany, wysyłanie kolejnych tylko pogorszy problem.