Postscreen – Greylisting w Postfixie
Greylisting jest dość powszechnie znaną techniką antyspamową. Jego idea opiera się na tym, że spamujące komputery (często tzw. zombie) nie mają czasu na ponawianie połączenia i starają się wysłać maksymalną ilość spamu w jak najkrótszym czasie łącząc się z różnymi serwerami poczty i nadając przesyłki często nawet bez czekania na odpowiedź serwera lub zakończenie sesji. Porządne serwery poczty natomiast ładnie się przedstawiają i czekają na odpowiedź serwera docelowego, a następnie rozpoczynają nadawanie poczty i jeśli dostaną odpowiedź o błędzie tymczasowym (kod 4xx), to ponawiają przesyłkę za jakiś czas (np. po 5 minutach).
Stosowanie Greylistingu przynosi wymierne korzyści dla systemu pocztowego. Greylisting jest w stanie odfiltrować nawet ponad 90% ruchu przychodzącego do serwera poczty i to już na poziomie sesji, co ma znaczny wpływ na wydajność systemu, gdyż znacznie ogranicza zużycie zasobów potrzebnych na dalsze przetwarzanie poczty. Zasada jest taka, że im wcześniej odrzucimy niechcianą pocztę tym lepiej, jeśli więc możemy odfiltrować ruch na poziomie sesji, to nie ma sensu wpuszczać tego dalej i tracić zasobów na skanowanie antywirusowe i antyspamowe. Wadą Greylistingu jest to, że wysłane wiadomości dochodzą z kilkominutowym opóźnieniem (serwer musi ponowić nadawanie), bo przypadki tzw. false positives są bardzo rzadkie i właściwie powinno to być zmartwienie administratora serwera nadającego pocztę.
Jednym z najbardziej znanych i chyba najczęściej stosowanych rozwiązań tego typu jest Postgrey – Postfix Greylisting Policy Server autorstwa Davida Schweikerta. Jest to oprogramowanie napisane w języku Perl, które stosowaliśmy z powodzeniem przez kilka lat. W chwili obecnej zrezygnowaliśmy z niego na rzecz wbudowanego w nowsze wersje Postfixa mechanizmu Postscreen.
Konfiguracja Postscreena jest prosta i dobrze udokumentowana w HOWTO, aby włączyć sam mechanizm i zobaczyć jak działa w praktyce bez włączania jeszcze Greylistingu wystarczy dodać kilka linijek do konfiguracji Postfixa (w main.cf
) oraz zmodyfikować trochę master.cf
– usługę smtp
zmieniamy tak, aby obsługiwał ją postscreen
i dodajemy jeszcze kilka linijek:
#smtp inet n - - - - smtpd smtp inet n - - - 1 postscreen smtpd pass - - - - - smtpd dnsblog unix - - - - 0 dnsblog tlsproxy unix - - - - 0 tlsproxy
Tworzymy plik postscreen_access.cidr
i do main.cf
dopisujemy na początek coś takiego:
postscreen_blacklist_action = ignore postscreen_access_list = permit_mynetworks cidr:/etc/postfix/postscreen_access.cidr postscreen_greet_action = ignore postscreen_greet_banner = Spammers may talk now :)
Jak widać akcja ustawiona jest na ignore
, czyli nie ma żadnego wpływu na działanie systemu, ale jak zrobimy telnet nazwadomeny.tld 25, to otrzymamy następujące powitanie:
Trying ... Connected to mydomain.tld. Escape character is '^]'. 220-Spammers may talk now :)
I dopiero po kilku sekundach pojawi się druga linia przywitania:
220 mydomain.tld ESMTP Postfix
Po co ta zwłoka? Otóż porządny serwer poczeka aż serwer do którego się łączy zakończy przywitanie, natomiast spamerzy w większości przypadków w ogóle nie czekają na odpowiedź serwera tylko zaczynają nadawać zaraz po połączeniu. Wystarczy zmienić ignore
na enforce
lub drop
aby mechanizm zaczął odrzucać takie nieuprawnione połączenia. Różnica między enforce
a drop
jest taka, że enforce
czeka na zakończenie pozostałych testów, loguje informacje o helo/sender/recipient i odrzuca z kodem 550, natomiast drop
odrzuca połączenie od razu z kodem 521. Polecam użycie enforce
, szczególnie na początku, żeby mieć w logach informację o tym skąd, kto i do kogo próbuje wysłać pocztę i czy nie ma tam false positives.
Na tym etapie można też włączyć sprawdzanie DNSBL, przy takim ustawieniu jak poniżej klient musi być listowany w zen.spamhause.org
(waga 2) oraz przynajmniej jednym z dwóch pozostałych DNSBLi aby osiągnąć wartość progu 3 i zostać odrzuconym. Oczywiście wagi (mnożniki) i serwery DNSBL można ustawić wg własnego uznania.
postscreen_dnsbl_action = enforce postscreen_dnsbl_threshold = 3 postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 b.barracudacentral.org*1
Po restarcie postfixa w logach można będzie zaobserwować podobne wpisy:
Aug 17 15:30:40 mydomain.tld postfix/postscreen[31984]: CONNECT from [41.205.39.169]:4308 Aug 17 15:30:40 mydomain.tld postfix/dnsblog[32089]: addr 41.205.39.169 listed by domain zen.spamhaus.org as 127.0.0.11 Aug 17 15:30:40 mydomain.tld postfix/dnsblog[32089]: addr 41.205.39.169 listed by domain zen.spamhaus.org as 127.0.0.4 Aug 17 15:30:40 mydomain.tld postfix/dnsblog[32088]: addr 41.205.39.169 listed by domain b.barracudacentral.org as 127.0.0.2 Aug 17 15:30:40 mydomain.tld postfix/dnsblog[32088]: addr 41.205.39.169 listed by domain bl.spamcop.net as 127.0.0.2 Aug 17 15:30:46 mydomain.tld postfix/postscreen[31984]: DNSBL rank 4 for [41.205.39.169]:4308 Aug 17 15:30:49 mydomain.tld postfix/postscreen[31984]: NOQUEUE: reject: RCPT from [41.205.39.169]:4308: 550 5.7.1 Service unavailable; client [41.205.39.169] blocked using zen.spamhaus.org; from=..., to=..., proto=ESMTP, helo= Aug 17 15:30:49 mydomain.tld postfix/postscreen[31984]: HANGUP after 3.2 from [41.205.39.169]:4308 in tests after SMTP handshake Aug 17 15:30:49 mydomain.tld postfix/postscreen[31984]: DISCONNECT [41.205.39.169]:4308
Klient, który nie osiągnie progu przewidzianego w parametrze postscreen_dnsbl_threshold
, otrzyma status PASS NEW
:
Aug 17 16:12:43 mydomain.tld postfix/postscreen[2391]: CONNECT from [173.232.32.14]:45116 Aug 17 16:12:43 mydomain.tld postfix/dnsblog[2416]: addr 173.232.32.14 listed by domain b.barracudacentral.org as 127.0.0.2 Aug 17 16:12:49 mydomain.tld postfix/postscreen[2391]: PASS NEW [173.232.32.14]:45116 Aug 17 16:22:26 mydomain.tld postfix/smtpd[2919]: connect from unknown[173.232.29.251] Aug 17 16:22:26 mydomain.tld postfix/smtpd[2919]: 69AD180A94: client=unknown[173.232.29.251]
Natomiast klient, który został już odnotowany wcześniej jako uprawniony i chce nadać kolejną wiadomość zostanie wpuszczony ze statusem PASS OLD
:
Aug 17 16:51:53 mydomain.tld postfix/postscreen[4493]: CONNECT from [213.134.151.158]:45226 Aug 17 16:51:59 mydomain.tld postfix/postscreen[4493]: PASS OLD [213.134.151.158]:45226 Aug 17 16:52:00 mydomain.tld postfix/smtpd[4496]: connect from mail.silfarm.com.pl[213.134.151.158] Aug 17 16:52:00 mydomain.tld postfix/smtpd[4496]: 41B1780295: client=mail.silfarm.com.pl[213.134.151.158]
Jak widać postscreen
ma znacznie większe możliwości niż tylko Greylisting, do którego właściwie dochodzimy dopiero w tym miejscu. W postscreenie jest to określane jako deep_protocol_test
, dokładny opis można znaleźć w angielskiej dokumentacji. Działa to tak, że jeśli klient pomyślnie przejdzie te testy, to jest dodawany do tymczasowej białej listy (whitelist), ale nie może nadać poczty, gdyż dostaje kod błędu 4XX (temporary failure). Jeśli klient połączy się ponownie, to dostaje zezwolenie na nadawanie poczty. Wbudowany w postscreena silnik SMTP nie posiada implementacji AUTH, XCLIENT i XFORWARD. Wsparcie dla AUTH może będzie dodane w przyszłych wersjach. W międzyczasie, jeśli te usługi muszą być dostępne na porcie 25 nie należy włączać tych testów (deep protocol). Dobra praktyka jednak nakazuje, aby nadawanie poczty realizować na przeznaczonym do tego porcie 587 (submission) lub 465 z SSL, więc uruchomienie deep_protocol_test
nie powinno sprawić problemów. Aby je włączyć należy dodać kilka linii do konfiguracji Postfixa (main.cf
).
postscreen_pipelining_action = enforce postscreen_pipelining_enable = yes postscreen_non_smtp_command_action = enforce postscreen_non_smtp_command_enable = yes postscreen_bare_newline_action = enforce postscreen_bare_newline_enable = yes
Po restarcie Postfixa warto jak zawsze spojrzeć w logi i poobserwować czy system zachowuje się zgodnie z oczekiwaniami. Opis poszczególnych testów znajduje się w przytoczonej wcześniej dokumentacji.
I wanted to know how to configure postscreen’s greylisting feature, which unforunately isn’t addressed here.