Niedawno dostałem jeden Undelivered Mail Returned to Sender
podczas 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" <[email protected]>
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 MX
znaczy 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: [email protected]
w 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 [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
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/ )
źródło
Odpowiedzi:
Zanim przejdę do mojej sugestii, chcę skomentować coś, co powiedział ci twój dostawca:
Nie oznacza to , że zwrotny DNS dla 94.130.34.42 to (lub był) mail.com. Wskazuje raczej, że klient SMTP wysłał
mail.com
swójHELO
(lubEHLO
) 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: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:
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.
źródło
iptables
regułę, aby umożliwić użytkownikom postfix i plesk wysyłanie e-maili (jak myślę, że Panel Plesk wysyła maile bezpośrednio, a nie przez postfix). Czy można również skonfigurować crondaemona (moje cronjobs), aby wysyłał e-maile przez smtp przez Postfix? Nie chcę dodawać użytkownika cron do iptables (jako innego wyjątku), ponieważ bezpieczniej byłoby pozwolić ruchowi pocztowemu, gdzie to możliwe, przejść przez Postfix. Czy jest możliwe, aby crontab używał Postfiksa do wysyłania dzienników błędów? Czy powinienem umieścić to w nowym pytaniu na temat błędu serwera?root
? Ponieważroot
w większości przypadków uruchamiany jest proces główny postfiksa . Czy też proces główny postfiksa spawnuje podprocesy za pomocą opcjipostfix
-user do wysyłania e-maili / robienia rzeczy? Wypróbowałem twoją regułę iptables, e-maile nie mogły zostać dostarczone ... Jeśli to zrobięps -ef | grep "postfix"
, zobaczę niektóre podprocesy uruchomione przezpostfix
-user i jeden proces główny uruchomiony przezroot
...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.
źródło