Spam, jaki jest każdy widzi…

Główny problem administratora serwerów pocztowych ze spamem polega na tym, że patrząc na konkretny mail z reguły łatwo określić czy to spam, czy nie, natomiast zbudowanie definicji na potrzeby systemu pocztowego nie wygląda tak łatwo. Stąd też parafraza Chmielowskiego - koń, jaki jest każdy widzi, ale podajmy definicję konia dla postronnych…

Żeby jednak nie wyjść poza pewien konkretyzm popatrzmy jakie narzędzia mamy w serwerach pocztowych, aby z tym problemem podjąć walkę. Podjąć walkę, a nie wygrać w jednej bitwie… po prostu ze spamem się walczy, z mniejszym, czy większym skutkiem i naszym zadaniem jest zwiększenie skuteczności. Nie ma możliwości całkowitego zablokowania spamu i to wbrew pozorom jest dobra wiadomość. Otóż oznacza ona, że jest możliwe rozsyłanie informacji - nie zawsze będzie to handlowy spam, może to być istotne larum… siedząc w bezpiecznym grajdołku chętnie o tym zapominamy.

Jedną z metod dostępną na poziomie dialogu SMTP jest kontrolowanie nadawcy, albo sposobu jego zachowania. Jeżeli ktoś przedstawia się jako Kowalski, ale wiemy, że Kowalskiego nie ma to warto być czujnym. Tym samym nie musimy się zastanawiać czy to spam, czy nie, wiemy, że coś nie tak.

Postfix i verify

Nie oszukujmy się, trudno będzie znaleźć lepszy serwer pocztowy, aniżeli Postfix, gdy idzie o kontrolowanie spamu. Wiele stosowanych w nim rozwiązań nie znajdziemy nigdzie indziej, co nie znaczy, że nie da się tego zrobić metodą okrężną, poprzez dodatkowe demony. Dużą zaletą Postfiksa jest stabilność działania i stosunkowo prosta konfiguracja. Zalety te widać szczególnie przy budowie własnego systemu kontrolowania spamu. Ale popatrzmy na to praktycznie, klient pocztowy, którym może być inny serwer pocztowy - jako, że serwery pocztowe rozmawiają ze sobą bezpośrednio - zaczyna dialog pocztowy w języku SMTP, łącząc się na port 25 serwera i mamy:

Teraz krótkie wyjaśnienie sytuacji - pierwszy wiersz to tzw. banner, MTA przedstawił się, kiedy zrealizowano połączenie na port 25 adresu IP, do którego się przyznaje. Słowo helo pozwala to samo zrobić klientowi. Odpowiedź “250 pryncyp.mol.uj.edu.pl” oznacza, że klient został zasadniczo zaakceptowany. Następnie “mail from: wojtek@mol.uj.edu.pl” pozwala klientowi podać adres nadawcy. Odpowiedź “250 Ok” sugeruje, że wszystko jest w porządku, ale kiedy następnie klient podaje adres odbiorcy “rcpt to: root@mol.uj.edu.pl” dostaje odpowiedź “550 [wojtek@mol.uj.edu.pl]: Sender address rejected…” To wydaje się dziwne, ale dalsza część tej odpowiedzi wyjaśnia sytuację:

undeliverable address: host awe.mol.uj.edu.pl[149.156.87.7] said: 550 Address not known at this site…

Jak to należy rozumieć? Otóż w tzw. międzyczasie Postfix podjął dialog z serwerem, który obsługuje adresy @mol.uj.edu.pl symulując chęć dostarczenia przesyłki do użytkownika “wojtek@mol.uj.edu.pl” i otrzymał od serwera wiadomość, że taki użytkownik nie istnieje. Jeżeli nie istnieje, to nie może wysyłać informacji, więc sesja zostaje zerwana…

Weryfikacja nadawcy to nie jest panaceum

Demon verify może bardzo pomóc, ale nie jest lekarstwem na cały spam świata, po prostu stanowi jedną z linii obrony, ale tylko wtedy kiedy jest umiejętnie stosowany. Otóż łatwo sobie wyobrazić sytuację, kiedy zaczyna odrzucać informację, na które w gruncie rzeczy oczekujemy. Jeśli nadawcą jest system rozsyłania zawiadomień, który nie ma własnej skrzynki pocztowej baza verify odrzuci taki mail. Powinniśmy taką sytuację przewidzieć. Ale jakie mamy do tego narzędzia? Pomocą może przyjść baza kontrolująca nadawców. Dodajemy do pliku main.cf

Baza /etc/postfix/kontrola_nadawcow może zawierać takie wpisy:

Musimy tylko wykonać polecenie

Aby postfix przerobił sobie plik tekstowy “kontrola_nadawcow” na bazę “kontrola_nadawcow.db” typu wskazanego w konfiguracji, w main.cf. W naszym przypadku będzie to baza typu “hash”. Nie jest to jedynie słuszny typ bazy. Np. dla baz verify zalecany jest raczej typ btree, ale miałem z tym kilka kłopotów więc pozostałem przy bazie hash. Teraz tylko:

I powinniśmy się zacząć przyglądać logom co się dzieje… Niekiedy warto początkowo dodać do pliku /etc/postfix/main.cf

Działa to następująco: mail zostanie dostarczony, ale w dzienniku uwag zostanie zanotowane, że zostałby odrzucony. Dla konkretnych adresów możemy sprawdzać bazę werify:

Na ile to jest skuteczne? W przypadku serwerów, którymi w jakiś sposób zarządzam odcina to około 70% spamu, a czasem więcej. Niestety baza verify potrzebuje miejsca i czasu na obsługę przez serwer, ale sprawdzanie lokalnych baz użytkowników i weryfikacja nadawców opłaca się. Ot teraz zebrałem fargmencik logów i co mam:

Właściwie maile do nieistniejących odbiorców… za moment pewnie wysyp maili od nieistniejących nadawców. I tak to się kręci.

Spam od istniejących nadawców

W takiej sytuacji weryfikacja nadawcy nam nie pomoże nic, a nic. Weźmy konkretny przykład, konto przechwycone przez spamera. Zna on dane techniczne konta, hasło i ma świadomość, że albo pójdzie na żywioł i wyśle mnóstwo spamu, po czym konto zostanie zablokowane przez administratora systemu, zmienione hasła, etc., albo też będzie wysyłał maile małymi porcjami, co może umknąć uwadze administratora systemu pocztowego.

W pierwszym przypadku konto ląduje zwykle na jednej z wielu czarnych list nadawców, niekiedy obniża się zaufanie do całego serwera co skutkuje kłopotami z doreczaniem maili przez ten serwer. W drugim przypadku konto może też wylądować na takowej liście, wystarczy, że ktoś to zgłosi, albo mail trafi na konto spełniające rolę pułapki tzw. honeypot.

To powinno nam uświadomić dwie sprawy, po pierwsze czarne listy działają z opóźnieniem, a po drugie trafiają tam czasem przypadkowo zupełnie przyzwoici nadawcy. Kłopot w takiej sytuacji mają dwie strony, nadawca, który odzyskał kontrolę nad kontem i adresat, który być może czeka na ważny list, a ten nie jest doręczany bo nadawca jest niewiarygodny.

Jakie mamy rozwiązania? Po pierwsze wybierać niezbyt histeryczne czarne listy, a po drugie oprzeć się na systemie analizy maili. Do tego można wykorzystać naiwny klasyfikator Bayesa, który automatycznie automatycznie przydziela konkretne maile do ustalonych z góry kategorii. Klasyfikator taki musimy wytrenować, a do tego potrzebujemy prawidłowo zaklasyfikowanych przykładów, czyli maili podzielonych na pożądane i niepożądane (ham i spam). Oczywiście spam będzie się nieustannie zmieniał, więc trzeba przewidzieć metodę ustawicznego trenowania klasyfikatora. Nie należy przy tym zapominać o uczeniu go także na przykładach dobrych maili.

W systemach z dużą liczbą skrzynek pocztowych zawsze znajdzie się grupa osób, którym możemy zaufać. Osoby takie mogą stworzyć osobne foldery na wiadomości spamowe, które będą wykorzystywane do trenowania klasyfikatora. Po pewnym czasie przynosi to oczekiwane i co istotne, długofalowe efekty. To jest polecany przeze mnie sposób. Wszelkie metody ręcznego sterowania systemem antyspamowym poprzez podnoszenie punktacji, etc. uważam za nieskuteczny. Pamiętajmy, że po drugiej stronie barykady mamy też myślących fachowców, którzy wiedzą, jak działa system pocztowy.