Ochrona przed spamem na serwerze

Ochrona przed spamem na serwerze Michał Talecki Tomasz Nidecki Artykuł opublikowany w numerze 2/2004 magazynu hakin9. Zapraszamy do lektury całego magazynu. Wszystkie prawa zastrzeżone. Bezpłatne kopiowanie i rozpowszechnianie artykułu dozwolone pod warunkiem zachowania jego obecnej formy i treści. Magazyn hakin9, Software-Wydawnictwo, ul. Piaskowa 3, 01-067 Warszawa, pl@hakin9.org

Ochrona przed spamem na serwerze Michał Talecki Tomasz Nidecki Solidny administrator serwera pocztowego powinien zadbać zarówno o ochronę antywirusową, jak i antyspamową dla swoich użytkowników. Filtrowanie poczty przez program antywirusowy nie budzi zazwyczaj żadnych kontrowersji wśród użytkowników, lecz zastosowanie programów antyspamowych tak. Nie wynaleziono bowiem jak dotąd doskonałej metody na pozbycie się spamu, a filtry antyspamowe mylą się o wiele łatwiej niż antywirusowe. Obrona Do walki ze spamem stosowanych jest obecnie wiele różnych metod. Niektóre charakteryzują się wysoką skutecznością, lecz powodują, iż część niewinnych listów nie dociera do adresatów. Inne z kolei rzadko się mylą, lecz ich skuteczność pozostawia wiele do życzenia. Tak więc usatysfakcjonowanie użytkowników w zakresie ochrony przed spamem to nie lada wyzwanie dla administratora. Przedstawimy stosowane obecnie techniki ochrony przed spamem. Doradzimy, które z nich wybrać w zależności od warunków, w jakich działa serwer pocztowy. Zaprezentujemy także sposób zainstalowania serwera pocztowego wraz z narzędziami do ochrony antyspamowej. Techniki filtracji na poziomie MTA Techniki stosowane przez administratorów serwerów można podzielić na dwie grupy (patrz Rysunek 1): działające na poziomie MTA (Mail Transport Agent część systemu pocztowego odpowiedzialna za przesyłanie listów między serwerami) i te działające na poziomie MDA (Mail Delivery Agent część systemu pocztowego odpowiedzialna za dostarczanie listów do lokalnych użytkowników). Walka ze spamem na poziomie MTA ma wiele zalet. Jeśli list zostaje rozpoznany jako spam już na poziomie sesji SMTP, przed przekazaniem treści, list ten nie musi być przesłany w całości przez nasze łącze, przechowany na naszym dysku i dostarczony do użytkownika. Jeśli serwer obsługuje dużą liczbę użytkowników, system antyspamowy na poziomie MTA to ogromna oszczędność zasobów: zarówno przestrzeni dyskowej, jak i pamięci, mocy procesora oraz łącza. Systemy działające na poziomie MTA mają jednak swoje wady. Aby bowiem umożliwiły odrzucenie listu przed jego otrzymaniem, nie mogą opierać się na analizie treści. Tak więc do rozpoznawania spamu wykorzystywana jest tylko część informacji. To z kolei powoduje, że systemy te są o wiele bardziej podatne na błędy niż te, które mogą dokonać analizy również na podstawie treści wiadomości. Analiza danych kopertowych Najprostszym sposobem na odrzucenie części spamu jest analiza danych, które nasz serwer otrzymuje podczas sesji SMTP, zwanych danymi kopertowymi (z ang. envelope). W zasadzie powinniśmy zwrócić uwagę jedynie na trzy 2 www.hakin9.org

Ochrona przed spamem na serwerze Z artykułu nauczysz się... jakie metody są najczęściej stosowane do zwalczania spamu, jaką metodę wybrać do konkretnego rodzaju zastosowań (w firmie, u dostawcy, w sieci osiedlowej itp.), jak zainstalować i skonfigurować serwer pocztowy wraz z zabezpieczeniami antyspamowymi. Co powinieneś wiedzieć... jak działa poczta elektroniczna (podstawy protokołu SMTP patrz artykuł Jak wysyłany jest spam), jak korzystać z podstawowych narzędzi i komend w systemie Linux, jakie potrzeby w zakresie ochrony antyspamowej mają Twoi użytkownicy. Rysunek 1. Poziomy ochrony antyspamowej przekazywane elementy: adres IP, z którego nadchodzi połączenie, parametr komendy HELO lub EHLO oraz tzw. adres nadawcy kopertowego (envelope-sender), podawany po komendzie MAIL FROM:. Analizując te elementy mamy możliwość wykrycia sporej liczby spamerów. Według dokumentu RFC 2821 (sekcja 4.1.1.1) definiującego protokół SMTP, serwer pocztowy powinien rozpoczynać sesję przedstawiając się za pomocą komendy HELO lub EHLO. Parametrem tej komendy powinien być FQDN (Fully Qualified Domain Name adres hosta w formie znakowej, np. mail.example.com). RFC 2821 zakłada jedynie, że adres ten powinien być prawidłowy syntaktycznie (mieć prawidłową formę). Z kolei RFC 1123 (sekcja 5.2.5) zabrania serwerowi odrzucać połączenia, jeśli adresu nie da się zweryfikować w DNS-ie. Mimo sugestii zawartych we wspomnianych RFC, wiele narzędzi antyspamowych nie przyjmuje połączeń pocztowych, jeśli adres podany jako parametr HELO lub EHLO jest nierozwiązywalny (non-resolvable), czyli nie ma odpowiadającego mu wpisu określającego IP (rekord A) w serwerach DNS. Z jednej strony jest to metoda dość skuteczna programy stosowane przez spamerów często podają nieistniejące adresy jako parametry komend HELO /EHLO. Z drugiej jednak strony wiele serwerów przedstawia się zgodnie z RFC 2821 i RFC 1123 (czyli adresem hosta, który jest prawidłowy pod względem syntaktycznym), lecz adres jest nierozwiązywalny (np. rozwiązywalny tylko w sieci wewnętrznej). Często zdarza się to w przypadku Lotus Notes (ale nie tylko). Jeśli więc zastosujemy w swoim serwerze analizę parametru HELO /EHLO, musimy się liczyć z tym, że poczta wysyłana z niektórych serwerów będzie zawsze odrzucana przez nasz MTA. Innym elementem koperty SMTP, który możemy analizować, jest adres nadawcy kopertowego, podawany jako parametr komendy SMTP MAIL FROM:. Nie należy go mylić z adresem podawanym w nagłówku From: nagłówek ten jest przesyłany w treści listu. Adres nadawcy kopertowego znajdziemy w zakolejkowanym już liście w nagłówku Return-Path:. Według RFC 2821 (sekcja 3.3) jest to adres, na który wysłane mają być raporty w razie wystąpienia błędów w sesji SMTP. Z założenia więc musi istnieć jedynym wyjątkiem jest specjalny, pusty adres nadawcy kopertowego (<>), który oznacza, iż list został wysłany przez robota pocztowego (Mailer-Daemon) i zawiera automatyczną informację o wystąpieniu błędu. Analiza adresu nadawcy kopertowego może polegać na: sprawdzeniu, czy część domenowa adresu jest rozwiązywalna, sprawdzeniu, czy część domenowa ma odpowiadający jej adres MX (Mail Exchanger), sprawdzeniu, czy adres użytkownika istnieje. Sprawdzenie, czy część domenowa adresu jest rozwiązywalna odbywa się na identycznej zasadzie, co sprawdzenie parametru komendy HELO /EHLO. Aby jednak serwer nadawcy mógł odebrać pocztę, musi również mieć stosowny wpis w serwerze DNS określający wymiennik poczty, czyli adres serwera odpowiedzialnego za odbieranie poczty dla danej domeny. Wpis ten (w tzw. rekordzie MX) określa serwer odpowiedzialny za przyjmowanie poczty dla danej domeny. Ponieważ druga metoda obejmuje zakres pierwszej www.hakin9.org 3

Obrona Listing 1. Odpowiedź serwera qmail na komendę VRFY $ telnet smtp.wp.pl 25 < Trying 212.77.101.160... < Connected to smtp.wp.pl. < Escape character is '^]'. < 220 smtp.wp.pl ESMTP > EHLO hakin9.org < 250-smtp.wp.pl < 250-PIPELINING < 250-AUTH=LOGIN PLAIN < 250-AUTH LOGIN PLAIN < 250-STARTTLS < 250-SIZE < 250 8BITMIME > VRFY test@wp.pl < 252 send some mail, i'll try my best (jeśli dla danej domeny istnieje wymiennik poczty, to jest ona na pewno rozwiązywalna), najczęściej stosowana jest właśnie weryfikacja wymiennika poczty. Aby sprawdzić, czy konto istnieje, możemy połączyć się z domniemanym serwerem nadawcy i zastosować komendę VRFY (stanowiącą element rozszerzonego protokołu SMTP). Serwer pocztowy powinien umożliwić zastosowanie tej komendy (RFC 2821, sekcja 3.5.1), ale nie musi (sekcja 3.5.2 informuje, że powinna być możliwość wyłączenia tej opcji). W praktyce rzadko który serwer umożliwia zastosowanie VRFY np. qmail zakłada, że każdy nadawca istnieje (patrz Listing 1) i zawsze zwraca tę samą odpowiedź: send some mail, i'll try my best, czyli wyślij pocztę, spróbuję ją dostarczyć. Należy też zauważyć, że rezultat EHLO nie anonsuje możliwości użycia VRFY. Exim (patrz Listing 2), podobnie, jak qmail, zwraca kod 252 (oznacza on: nie mogę zweryfikować, czy użytkownik istnieje, ale mogę przyjąć dla niego pocztę i spróbować ją dostarczyć). Niektóre inne serwery w ogóle nie mają zaimplementowanej tej komendy. Wynika to z faktu, że VRFY może być wykorzystywane także przez spamerów (do sprawdzania, czy na dany adres warto wysyłać pocztę). Jak więc widać szansa natrafienia na serwer, który umożliwia skorzystanie z VRFY (np. Postfix, patrz Listing 3; Sendmail, patrz Listing 4), jest na tyle mała, że nie ma sensu stosować tej metody. Spamerzy coraz częściej podszywają się pod roboty pocztowe, podając pusty adres nadawcy kopertowego. Istnieje jednak metoda sprawdzenia, czy jest to prawdziwy list od Mailer-Daemona, czy spam. Otóż z założenia list od pustego nadawcy kopertowego może mieć tylko jednego odbiorcę (parametr komendy RCPT TO:). Z kolei spamerowi zależy, by wysłać list do wielu odbiorców naraz. Jeśli więc w sesji SMTP podany zostanie pusty adres nadawcy kopertowego i więcej niż jeden odbiorca, sesję można odrzucić, będąc pewnym, iż jest to próba przesłania spamu. Ostatnim elementem, który warto sprawdzić, jest FQDN odpowiadający adresowi IP nadawcy. Jeśli adres IP nie ma odpowiednika symbolicznego, istnieje duże prawdopodobieństwo, że otrzymamy spam. Listing 2. Odpowiedź serwera Exim na komendę VRFY Korzystanie z serwerów DNSBL Zanim nastała moda na stosowanie filtrów bayesowskich, najpopularniejszą metodą ochrony przed spamem było korzystanie z serwerów DNSBL (DNS-based Blocking Lists, czyli czarnych list opartych na serwerach DNS). Serwery te przechowują adresy IP nadawców, od których z tych czy innych powodów (według administratora czarnej listy) nie warto odbierać poczty. Informacje o adresach IP przekazywane są za pomocą tego samego protokołu, co w serwerach DNS. Stosowanie DNSBL jest z jednej strony bardzo skuteczne i efektywne, z drugiej dość ryzykowne. Jedyną informacją, na podstawie której system ocenia, czy dany list jest spamem czy nie, jest adres IP z którego przychodzi poczta. Oznacza to dużą możliwość pomyłki z serwera, który znajduje się na czarnej liście, może korzystać też całkiem niewinny użytkownik. Z drugiej strony do podjęcia decyzji, czy przyjąć czy odrzucić połączenie, potrzebne jest jedynie jego zainicjowanie nie trzeba odbierać żadnych danych, a więc mamy do czynienia z ogromną oszczędnością zasobów. Czarne listy zbierają adresy IP wedle różnych kryteriów. Oto najpopularniejsze z nich: Open relay serwery skonfigurowane jako open relay (wolne przekaźniki). Przykłady takich list to: Open Relay DataBase (http:// www.ordb.org), Distributed Server $ telnet mail.exim.org 25 < Trying 195.92.249.251... < Connected to mail.exim.org. < Escape character is '^]'. < 220 exim-colo-01.whoc.theplanet.co.uk ESMTP Exim 4.30 Wed, 04 Feb 2004 20:45:47 +0000 > EHLO hakin9.org < 250-exim-colo-01.whoc.theplanet.co.uk Hello hakin9.org [127.0.0.1] < 250-SIZE 52428800 < 250-8BITMIME < 250-PIPELINING < 250 HELP > VRFY test@exim.org < 252 Administrative prohibition 4 www.hakin9.org

Ochrona przed spamem na serwerze Listing 3. Odpowiedź serwera Postfix na komendę VRFY $ telnet mail.cloud9.net 25 < Trying 168.100.1.3... < Connected to mail.cloud9.net. < Escape character is '^]'. < 220 camomile.cloud9.net ESMTP Postfix > EHLO hakin9.org < 250-camomile.cloud9.net < 250-PIPELINING < 250-SIZE 25360000 < 250-VRFY < 250-ETRN < 250 8BITMIME > VRFY test@postfix.org < 550 <test@postfix.org> User unknown in virtual alias table > VRFY postmaster@postfix.org < 252 postmaster@postfix.org Boycott List (http://www.dsbl.org), Not Just Another Bogus List (http://www.njabl.org). Open proxy podobnie jak open relay umożliwiają wykorzystanie serwera do masowej wysyłki poczty. Przykład takiej listy to Blitzed Open Proxy Monitor (http://opm.blitzed.org). Dynamiczne adresy IP na czarnych listach tego typu zamieszczone są całe zakresy dynamicznych IP (np. zakresy nadawane połączeniom typu dial-up, ADSL) serwer SMTP powinien mieć stałe IP (w przeciwnym wypadku trudno do takiego serwera przesłać pocztę). Potwierdzone źródła spamu przykładem serwisu zbierającego raporty o spamie jest Spam- Cop (http://www.spamcop.net). Nadsyłane raporty są przetwarzane i jeśli wystąpi określona liczba skarg na dany IP, jest on umieszczany na czarnej liście (na pewien czas, zależny od tego, ile zgłoszeń otrzymał SpamCop). Gangi spamerskie przykładem takiego serwisu jest SpamHaus (http://www.spamhaus.org). Zbiera on adresy IP wykorzystywane przez znane gangi spamerskie (czyli adresy przypisane przez usługodawców firmom, które zajmują się rozsyłaniem spamu). Usługodawcy popierający spamerów przykładem jest Spam Prevention Early Warning System (http://www.spews.org) najbardziej chyba drastyczna czarna lista. Z założenia umieszczane są tu zakresy o wiele szersze niż wykorzystywane przez spamerów. Jeśli korzystamy ze SPEWS istnieje spora szansa, że odrzucimy listy od niewinnych osób. Blokady ogólnokrajowe jeśli nie spodziewamy się np. otrzymywać żadnej poczty z Chin, możemy zablokować wszystkie adresy IP z tego kraju. Wiele list ogólnokrajowych możemy znaleźć w serwisie Blackholes.us (http://www.blackholes.us). Jest również możliwe znakowanie listów na podstawie obecności IP w DNSBL. Wtedy decyzja o odrzuceniu listu może być podjęta dopiero na poziomie MDA lub MUA (Mail User Agent programu użytkownika). Szare listy Szare listy (greylisting) to metoda wynaleziona stosunkowo niedawno. Jej implementacje dopiero powstają. Metoda ta ma jednak dużą skuteczność, a efekty uboczne są, w porównaniu do innych technik, o wiele mniej groźne. Stosując szare listy nie można bowiem utracić niewinnej poczty. Można jedynie otrzymać ją o około godzinę później, niż byśmy się tego spodziewali. Technika szarych list opiera się na dwóch założeniach: Spamerzy w większości przypadków nie korzystają z typowych serwerów pocztowych do rozsyłania spamu (jedynym wyjątkiem są open relay i open proxy). Stosują do tego celu specjalne programy, które nie oferują pełnej funkcjonalności serwera pocztowego. Spamerzy prawie nigdy nie wysyłają spamu po raz drugi do tej samej osoby, stosując ten sam adres zwrotny. Listing 4. Odpowiedź serwera Sendmail na komendę VRFY $ telnet smtp.sendmail.com 25 < Trying 209.246.26.40... < Connected to smtp.sendmail.com. < Escape character is '^]'. < 220 foon.sendmail.com ESMTP Sendmail Switch-3.1.4/Switch-3.1.0; Thu, 12 Feb 2004 10:19:24-0800 > EHLO hakin9.org < 250-foon.sendmail.com Hello hakin9.org [127.0.0.1], pleased to meet you < 250-ENHANCEDSTATUSCODES < 250-PIPELINING < 250-8BITMIME < 250-SIZE 50000000 < 250-DSN < 250-ETRN < 250-STARTTLS < 250-DELIVERBY < 250 HELP > VRFY test@sendmail.com < 550 5.0.0 test@sendmail.com... User unknown > VRFY postmaster@sendmail.com < 250 2.1.5 <postmaster@foon.sendmail.com> www.hakin9.org 5

Obrona Rysunek 2. Schemat działania szarych list Szare listy opierają się na gromadzeniu trzech informacji kopertowych (patrz Rysunek 2). Pierwsza z nich to adres IP nadawcy. Druga: parametr MAIL FROM:, a trzecia: parametr RCPT TO:. Te trzy elementy zwane są w przypadku szarych list trójką (triplet). Trójki przechowywane są w bazie. Jeśli trójka zostanie rozpoznana, list jest przyjmowany. Jeśli jednak nie ma w bazie trójki odpowiadającej aktualnemu połączeniu, szara lista odrzuca tymczasowo połączenie, wysyłając kod z serii 4xx (na przykład 452) oznaczający tymczasową niemożność przyjęcia poczty (patrz artykuł Jak wysyłany jest spam przyp. red.). Po odrzuceniu połączenia trójka jest zapisywana do bazy, a następne połączenie o tej samej trójce zostanie już przyjęte. Ponieważ według pierwszego założenia większość spamerów korzysta z programów o bardzo ograniczonej funkcjonalności, programy te nie reagują odpowiednio na kod serii 4xx. Traktują go identycznie jak kod 5xx, czyli nie ponawiają próby połączenia. Jeśli programy stosowane przez spamerów gromadziłyby odpowiedzi serwerów i odpowiednio na nie reagowały, wykorzystywałyby znacznie więcej zasobów i prowadzenie działalności spamerskiej byłoby o wiele bardziej kosztowne. Z kolei każdy serwer pocztowy jest przygotowany na otrzymanie odpowiedzi 4xx i ponowi próbę za określony czas (zazwyczaj około godziny) wtedy zaś połączenie zostanie już zaakceptowane przez serwer chroniony szarą listą. Techniki filtracji na poziomie MDA Druga grupa technik antyspamowych działa w oparciu o treść listów, w związku z tym jest możliwa do zastosowania jedynie po odebraniu i lokalnym zakolejkowaniu listu, czyli na poziomie programu dostarczającego pocztę do skrzynek użytkowników Mail Delivery Agent (MDA). Najpopularniejsze metody tego typu to analiza heurystyczna (analiza treści), sieci antyspamowe, filtry bayesowskie (statystyczne) i systemy challenge-response. Analiza heurystyczna Narzędzia do analizy heurystycznej opierają się na rozbudowanych, często aktualizowanych bazach danych zawierających słowa i wyrażenia charakterystyczne dla spamu i niespamu (hamu). Ich działanie polega na nadawaniu listom wartości punktowej w oparciu o wystąpienie w treści lub nagłówkach listu elementów z bazy (tzw. scoring). List jest oznaczany jako spam po osiągnięciu określonej liczby punktów (regulowanej przez użytkownika lub administratora). Narzędzia heurystyczne mają kilka znaczących wad. Analiza heurystyczna jest powolna treść listu trzeba porównać z ogromną bazą danych. Wymagają ciągłej aktualizacji bazy danych, ponieważ spamerzy uczą się obchodzić reguły. Ich efektywność nie jest najgorsza, ale pozostawia wiele do życzenia. Sieci antyspamowe Sieci antyspamowe (collaborative spam filtering network) wymagają sporego zaangażowania użytkowników. Są stosowane rzadko i jedynie jako element wspomagający strategię ochrony przed spamem. Działanie takich systemów opiera się na tworzeniu sum kontrolnych (sygnatur) nadchodzących listów (na podstawie ich treści). Użytkownik zgłasza następnie do sieci, czy dany list jest spamem, czy hamem, a centralna baza systemu odnotowuje sygnaturę. System antyspamowy po otrzy- 6 www.hakin9.org

Ochrona przed spamem na serwerze maniu każdego listu, ale przed dostarczeniem go do skrzynki, zapytuje centralną bazę, czy list o danej sygnaturze jest rozpoznawany jako spam, czy nie. Niestety, reakcje użytkowników (raportowanie spamu) są dość opóźnione, a spamerzy nauczyli się obchodzić ten system dostawiając do każdego listu inne, losowe znaki (które zmieniają sygnaturę). Tak więc skuteczność sieci antyspamowych jest niewielka (rozpoznają zaledwie około 50% spamu). Najpopularniejsze takie sieci to Vipul's Razor oraz Pyzor. Istnieją jednak sieci sum kontrolnych, które nie wymagają od użytkownika raportowania (np. DCC Distributed Checksum Clearinghouse). Do bazy przekazywana jest każda sygnatura nadchodzącego listu, zaś system przechowuje ją nie jako spam lub ham, lecz odnotowuje tylko liczbę nadesłanych sygnatur. Gdy przekroczy ona określoną sumę, list o danej sygnaturze jest rozpoznawany jako spam. Niestety, systemy te nie potrafią rozróżnić spamu od np. list dyskusyjnych, stąd ich mała przydatność. Filtry bayesowskie Analiza statystyczna jest obecnie najpopularniejszą metodą walki ze spamem. Choć próbowano ją zastosować już kilka lat temu, to burzę rozpętał artykuł Paula Grahama A Plan for Spam. Skuteczność zastosowanych przez Paula filtrów bardzo zainteresowała osoby walczące ze spamem i powstało wiele aplikacji stosujących technikę analizy statystycznej (nazywaną analizą bayesowską od nazwiska Thomasa Bayesa brytyjskiego matematyka). W uproszczeniu analiza bayesowska polega na gromadzeniu słów występujących częściej w spamie niż hamie i odwrotnie. Różni się od heurystycznej tym, że w analizie bayesowskiej nie ma z góry ustalonych zasad filtr sam wyznacza zasady (czyli charakterystyczne dla spamu i hamu słowa), gdy wskazujemy mu listy, które są spamem i te, które nim nie są. Wbrew pozorom analiza taka jest o wiele szybsza od heurystycznej Rysunek 3. Schemat działania systemu challenge-response i o wiele bardziej skuteczna. Nie wymaga bowiem ciągłej aktualizacji baz. Niestety wymaga zaangażowania użytkownika, który musi wpierw nakarmić filtr przykładowym spamem i hamem, by narzędzie nauczyło się rozpoznawać, co dany użytkownik określa jako spam, a co jako ham. Poza tym warto regularnie dokarmiać filtr błędnie zakwalifikowanymi listami, by poprawić jego efektywność. Systemy challenge-response Choć zdecydowanie najskuteczniejsze w walce ze spamem, systemy challenge-response są przez wielu uznawane za rozwiązanie niedopuszczalne i wprost szkodliwe. Ich działanie opiera się na założeniu, że spamer nie czyta odpowiedzi na swoje listy (założeniu błędnym praktycznie jedynie w przypadku nigeryjskich oszustów, których działalność wymaga czytania odpowiedzi). Zanim więc list od nieznanego jeszcze nadawcy zostanie dostarczony do odbiorcy, system challenge-response wysyła do nadawcy automatyczną odpowiedź z prośbą o weryfikację (odesłanie poczty, kliknięcie w link itp.). Kiedy nadawca potwierdzi, oryginalny list dostarczany jest do odbiorcy (patrz Rysunek 3). Wiele osób uważa, że wymaganie potwierdzenia www.hakin9.org 7

Obrona chęci nadania listu jest niekulturalne. Dziwne jednak, że te same metody, stosowane od lat do ochrony list dyskusyjnych, nie budzą kontrowersji. Niestety, systemy challenge-response są chyba najbardziej zasobożernymi rozwiązaniami: zarówno niedostarczone jeszcze listy, jak i potwierdzenia muszą być przechowywane w katalogu użytkownika. Wysłanie listu z prośbą o potwierdzenie i otrzymanie potwierdzenia również konsumują zasoby serwera pocztowego. Poza tym systemy te powodują potencjalne problemy, np. gdy natrafią na siebie wzajemnie (gdy obaj korespondenci używają takiego mechanizmu, żaden nie otrzyma prośby o potwierdzenie), gdy korzystamy z subskrypcji przez stronę WWW (mechanizmy wysyłkowe nie odpowiedzą na prośbę o potwierdzenie), z list dyskusyjnych. Na szczęście nowoczesne systemy challenge-response (np. TMDA) obchodzą wiele z tych ograniczeń wprowadzając adresy o określonej ważności (np. przez pięć dni) lub przyjmujące pocztę tylko z określonego adresu nadawcy. Największą plagą dla systemów challenge-response są jednak wirusy podszywające się pod innych użytkowników: jeśli używamy systemu challenge-response, a na naszym serwerze nie ma programu antywirusowego, wiele osób otrzyma od nas prośby o potwierdzenie, choć nigdy do nas nic nie wysyłało (wirus podszył się pod ich adres). W ten sposób sami nieświadomie stajemy się w pewnym sensie spamerami i możemy trafić na czarne listy wielu użytkowników. Wybór metody Znając już podstawowe techniki obrony przed spamem stajemy przed wyborem tej, którą zdecydujemy się zastosować na własnym serwerze. Wbrew pozorom wybór nie jest prosty i zależy od wielu czynników. Zupełnie inaczej rozwiążemy ochronę antyspamową w firmie, gdzie decyzja będzie zależała od nas i od naszych przełożonych. Inaczej w sieci osiedlowej, gdzie wszystko zależne jest od ustaleń MessageWall Choć większość mechanizmów działających na poziomie MTA musi być stosowana globalnie, dla wszystkich użytkowników, istnieją narzędzia umożliwiające obejście tych ograniczeń. Przykładem może być proxy o nazwie MessageWall. Narzędzie to współpracuje z każdym serwerem SMTP na platformie linuksowej. Keszuje ono i analizuje otrzymywane od innych serwerów informacje kopertowe i w zależności od nich podejmuje odpowiednie działania. Załóżmy, że mamy dwóch użytkowników serwera. Użytkownik pierwszy: test pragnie jak najlepszej ochrony antyspamowej i chce, by w jego przypadku konsultowane były listy DNSBL oraz sprawdzana poprawność danych kopertowych. Z kolei użytkownik test2 nie chce żadnej ochrony antyspamowej. Z naszym proxy (MessageWall) kontaktuje się serwer SMTP. MessageWall gromadzi dane kopertowe (do własnej pamięci podręcznej), aż do otrzymania RCPT TO:, po czym okazuje się, że odbiorcą listu jest użytkownik test2. Od tego momentu MessageWall przekazuje wszystkie dane (wraz z tymi w pamięci podręcznej) nietknięte serwerowi pocztowemu. Jeśli jednak okaże się, że odbiorcą jest użytkownik test, MessageWall sprawdza, czy przechowane w pamięci podręcznej dane kopertowe są prawidłowe. Jeśli nie odrzuca połączenie, nie przyjmując listu. Jeśli jednak dane są poprawne, przekazuje list do serwera SMTP. Bez stosowania MessageWall nie byłoby to możliwe, ponieważ w przypadku większości serwerów dane nie są keszowane, a decyzja o odrzuceniu podejmowana jest, zanim serwer dowie się, kto jest odbiorcą listu. Inną zaletą MessageWall jest fakt, że dzięki niemu nie jesteśmy zdani na możliwości stosowanego serwera SMTP. Nawet jeśli nasz serwer nie ma mechanizmów antyspamowych, dzięki MessageWall możemy je nań nałożyć bez czasochłonnej i pracochłonnej zmiany i rekonfiguracji MTA. MessageWall umożliwia obecnie stosowanie m.in. następujących metod weryfikacji poczty (indywidualnie, dla każdego użytkownika, lecz na poziomie MTA, czyli przed przyjęciem listu): sprawdzenie adresu IP w DNSBL, sprawdzenie sumy kontrolnej listu w globalnej bazie (DCC), sprawdzenie MX dla adresu podanego w MAIL FROM:, sprawdzenie FQDN dla adresu IP nadawcy (RevDNS). Pełna lista: http://messagewall.org/features.html z użytkownikami. Jeszcze inaczej u dostawcy usług internetowych, gdzie prawo głosu powinni mieć przede wszystkim klienci. Globalnie czy indywidualnie? Najpierw musimy zdecydować, czy ochrona antyspamowa będzie globalna czy indywidualna. Jeśli zastosujemy rozwiązanie globalne, wszyscy użytkownicy serwera będą obowiązkowo chronieni przez system antyspamowy. Jeśli zaś wybierzemy ochronę indywidualną, każdy użytkownik będzie miał możliwość samodzielnego wyboru, czy korzysta z ochrony, czy nie. Może też mieć opcję samodzielnej konfiguracji i dopasowania narzędzia do własnych potrzeb. Rozwiązanie globalne ma wielką zaletę: możemy zastosować metody na poziomie MTA i przez to oszczędzić mnóstwo zasobów. Spam może być filtrowany przed odebraniem. Takie rozwiązanie jest też o wiele mniej pracochłonne, ponieważ nie musimy ustawiać indywidualnych opcji dla użytkowników ani przygotowywać narzędzi do samodzielnej konfiguracji filtrów przez użytkownika. Rozwiązania globalne są zazwyczaj stosowane w firmach, gdzie użytkownicy nie mają wiele do powiedzenia i gdzie o funkcjonalności serwera decyduje administrator w porozumieniu ze swoimi przełożonymi. Zupełnie nie nadają się do zastosowania u dostawców usług, ponieważ mogą spowodować niezadowolenie klientów. Często stosowane są w niewielkich, prywatnych sieciach, w których administrator sam zadecydował 8 www.hakin9.org

Ochrona przed spamem na serwerze o wprowadzeniu filtrów lub też uzgodnił to z użytkownikami. Model otwarty czy zamknięty? Wybór stosowanych metod jest też w dużej mierze zależny od działalności, jaką prowadzimy. Jeśli zakładamy, że będzie się kontaktowało z nami wielu użytkowników, z różnych krajów, często z darmowych kont, łącz typu dial-up itp., wybierzemy zupełnie inną metodę, niż w przypadku gdy istnieje stała liczba rozmówców i nowi dochodzą bardzo rzadko (co ma miejsce w przypadku wielu firm). Od naszej działalności zależy też, czy wybierzemy metody bardziej skuteczne, czy bardziej ryzykowne. Jeśli e-mail nie jest krytycznym elementem naszej działalności, możemy zastosować metody, które powodują większe ryzyko, że list zostanie błędnie zaklasyfikowany jako spam. Jeśli zaś musimy się upewnić, że każdy list nie będący spamem trafi do odbiorcy, zastosujemy metody mniej ryzykowne, ale też często mniej skuteczne. Metody też warto dostosować do ilości otrzymywanego spamu jeśli nie jest go dużo, spróbujmy najpierw zastosować mniej ryzykowną metodę. Przykład 1: sieć korporacyjna W sieci korporacyjnej możemy przyjąć następujące założenia: użytkownicy nie potrzebują indywidualnej ochrony system antyspamowy może być narzucony przez administratora, administrator nie ma czasu, by konfigurować system lub przygotowywać dla użytkowników narzędzia do samodzielnej konfiguracji, zasoby serwera nie są elementem krytycznym łącze jest wydajne, a pamięć, moc obliczeniowa serwera i przestrzeń dyskowa mogą być w razie potrzeby rozszerzone, e-mail jest istotnym elementem prowadzonej działalności i należy się upewnić, że żaden e-mail nie może być odrzucony. Jednak niewielkie opóźnienie dostarczenia poczty nie jest krytyczne dla prowadzonej przez korporację działalności. Przy takich założeniach dobrym połączeniem będzie stosowanie szarych list na poziomie MTA i globalnego filtra heurystycznego na poziomie MDA (np. SpamAssassin). Szare listy zredukują około 90 do 95% otrzymywanego spamu zanim dotrze on do serwera i nie spowodują odrzucenia żadnego listu wysłanego z serwera pocztowego. Pozostały spam zostanie przeanalizowany przez filtr heurystyczny. Jeśli list zostanie zakwalifikowany jako spam, trafi do specjalnej skrzynki, przeglądanej np. raz dziennie przez wyznaczonego pracownika. Listy, które znajdą się w skrzynce, a będą błędnie zakwalifikowane jako spam, zostaną przez tego pracownika przekazane adresatom, zaś pozostałe (spam) skasowane. Z serwerów DNSBL możemy korzystać tylko, jeśli listy będą znakowane (a następnie przez MDA lub MUA przenoszone do specjalnego katalogu globalnego lub katalogów indywidualnych użytkowników do okresowego przeglądania). Filtry bayesowskie niezbyt dobrze nadają się do stosowania w firmach, ponieważ ich karmienie wymaga czasu, który pracownicy i administrator mogą przeznaczyć na bardziej istotne zadania. Jeśli jednak można poświęcić trochę czasu na uczenie filtrów, warto rozważyć ich użycie. Przykład 2: dostawca usług internetowych W przypadku dostawcy usług internetowych możemy przyjąć następujące założenia: użytkownicy muszą mieć opcję indywidualnego wyboru i konfiguracji mechanizmów antyspamowych nic nie może być z góry narzucone przez administratora, administrator nie ma czasu by konfigurować konta, a więc użytkownik powinien mieć możliwość samodzielnej konfiguracji (np. przez interfejs WWW), zasoby serwera nie są elementem krytycznym łącze jest wydajne, a pamięć, moc obliczeniowa serwera i przestrzeń dyskowa mogą być w razie potrzeby rozszerzone, użytkownik musi mieć pełną kontrolę nad własną pocztą i decydować, czy dostaje całą pocztę, czy część jest kasowana przez filtry antyspamowe. Przy takich założeniach możemy zastosować następujące połączenie: brak filtracji na poziomie MTA i kilka mechanizmów filtracji na poziomie MDA do wyboru dla użytkownika: filtr heurystyczny (np. SpamAssassin), filtr bayesowski (np. Bogofilter) oraz system challenge-response (np. Tabela 1. Techniki antyspamowe i ich sugerowane zastosowania Technika Firmy Dostawcy usług Sieci prywatne Analiza danych kopertowych +** + Serwery DNSBL +* +* + Szare listy + + Analiza heurystyczna + +* +*** Analiza statystyczna (bayesowska) +* + Sieci antyspamowe +* + Systemy challenge-response +** +*** * pod warunkiem, że listy będą znakowane, a nie odrzucane ** pod warunkiem, że użytkownicy będą mieli możliwość samodzielnej konfiguracji oraz włączania/wyłączania opcji *** pod warunkiem, że serwer dysponuje dużymi zasobami lub ruch na nim jest niewielki www.hakin9.org 9

Rysunek 4. Schemat działania przedstawionego zestawu filtrów antyspamowych Obrona TMDA wraz z TMDA-CGI). Użytkownik powinien mieć możliwość samodzielnego włączenia filtru heurystycznego i ewentualnie ustawienia poziomu wrażliwości filtru. Powinien też mieć specjalne aliasy pocztowe, na które mógłby przesyłać ham i spam do karmienia filtru bayesowskiego, a także możliwość włączenia/wyłączenia tego rodzaju filtracji. Wreszcie potrzebny będzie interfejs graficzny do zarządzania kolejką listów oczekujących na potwierdzenie w systemie challenge-response zadanie to świetnie spełni interfejs WWW dostępny w TMDA-CGI. Oczywiście użytkownik powinien też móc sam zdecydować, czy poczta jest jedynie znakowana jako spam (na podstawie analizy heurystycznej lub statystycznej), czy spam jest od razu kasowany (to również umożliwi mu TMDA-CGI). Wszystkie decyzje o przyjęciu lub odrzuceniu listu powinny być podejmowane na poziomie MDA (indywidualnie, według życzeń użytkownika) lub MUA (znakowanie listów), ewentualnie MTA, jeśli stosowane jest narzędzie keszujące (np. MessageWall patrz Ramka). Przykład 3: prywatny serwer pocztowy lub niewielka sieć lokalna Jeśli mamy własny, niewielki serwer pocztowy, na którym konta mają jedynie znajomi i rodzina, mamy największą swobodę w wyborze odpowiedniej metody. Oto założenia: możemy zastosować zarówno metody globalne, jak i indywidualne, możemy dopasować poziom ochrony do własnych potrzeb, nie musimy tworzyć graficznych interfejsów do zarządzania filtrami, poczta nie jest krytycznym elementem działalności nic strasznego się nie stanie, jeśli omyłkowo nie dostaniemy jakiegoś listu, zasoby są elementem krytycznym system nie może tak obciążyć serwera (który w przypadku niewielkich sieci lokalnych jest zazwyczaj niezbyt rozbudowany), by nie dało się z niego korzystać. W tej sytuacji możemy zastosować metody filtracji na poziomie MTA oparte na analizie danych kopertowych (np. dostępne w SPAM- CONTROL), wybrane serwery DNSBL a także analizę bayesowską. Analizę heurystyczną i system challenge-response możemy zastosować tylko, jeśli nasz serwer dysponuje odpowiednią ilością zasobów, a użytkowników jest niewielu (i większość z nich nie otrzymuje zbyt du- 10 www.hakin9.org

Ochrona przed spamem na serwerze qmail czy netqmail? Na stronie http://www.qmail.org (wbrew pozorom nie jest to oficjalna strona qmaila) zamiast wersji 1.03 qmaila znajdziemy netqmail 1.05. Czemu więc w artykule prezentujemy pozornie starszą wersję? Ostatnią oficjalną wersją qmaila jest 1.03. netqmail jest dystrybucją nieoficjalną, która zawiera qmail 1.03 oraz zestaw łatek i skrypt aplikujący łatki (licencja qmaila zabrania dystrybucji zmodyfikowanych źródeł). Większość łatek zawartych w netqmail wchodzi także w skład SPAMCONTROL i próba jednoczesnego zaaplikowania obu zestawów zakończy się niepowodzeniem. Jeśli jednak nie zamierzamy stosować SPAMCONTROL, możemy zamiast qmail 1.03 pobrać ze strony http://www.qmail.org dystrybucję netqmail. żo poczty). Globalne zastosowanie SpamAssassina na dość aktywnym lecz niezbyt rozbudowanym serwerze może powodować jego częste awarie (o czym przekonali się autorzy tego artykułu). Instalacja oprogramowania Przedstawiamy przykładową konfigurację serwera pocztowego z zabezpieczeniami antyspamowymi. Zastosujemy w nim najważniejsze opisane techniki prócz eksperymentalnych szarych list, mało efektywnych sieci antyspamowych oraz analizy heurystycznej, która działa w sposób bardzo zbliżony do bayesowskiej. Wszystkie opisane mechanizmy należy potraktować opcjonalnie możemy je włączyć lub wyłączyć w zależności od potrzeb. Nasz serwer zbudujemy w oparciu o następujące komponenty: qmail 1.03 serwer pocztowy, daemontools 0.76 narzędzie do nadzorowania procesów (standardowo stosowane do nadzorowania procesów qmaila), ucspi-tcp 0.88 zestaw narzędzi TCP (m.in. serwer TCP, narzędzie do blokowania połączeń w oparciu o DNSBL), SPAMCONTROL 2.2.9 zestaw łatek do qmaila rozszerzających jego możliwości w zakresie filtrowania spamu na poziomie MTA, maildrop 1.6.3 narzędzie umożliwiające dostarczanie poczty do lokalnych skrzynek po ich uprzednim przetworzeniu (MDA), Bogofilter 0.16.4 najpopularniejszy filtr bayesowski, TMDA 1.0.1 system challengeresponse. Przedstawiony proces instalacji przeprowadzono na systemie Linux, dystrybucji Slackware 9.1. Chronione konto to admin (z hasłem: secret). Ochronę można określić jako paranoiczną. Serwer odrzuca połączenia w oparciu o cztery znane bazy DNSBL, analizuje poprawność danych w HELO /EHLO oraz MAIL FROM:, następnie przeprowadza analizę bayesowską treści listu. Jeśli wypadnie ona negatywnie (list zostanie określony jako spam), e-mail jest odbijany do nadawcy. Jeśli pozytywnie nadawca jest proszony o potwierdzenie, iż nie przesłał spamu (dba o to system challenge-response). W związku z tym prawdopodobieństwo otrzymania spamu na tak kompleksowo chronione konto jest bliskie zeru. Zebranie niezbędnego oprogramowania Pierwszym niezbędnym krokiem jest skopiowanie z dołączonego do naszego pisma CD źródeł programów: # cp /mnt/cdrom/_materials/ spam-admin/software/* /usr/src Proponujemy jako katalog roboczy wykorzystać standardowy /usr/src, zaś większość zadań wykonywać z poziomu superużytkownika. Instalacja i konfiguracja serwera pocztowego Następnym krokiem będzie przygotowanie katalogu, grup i kont systemowych niezbędnych do działania qmailowi. Struktura qmaila jest doskonałym przykładem na skuteczną politykę bezpieczeństwa. qmail to zestaw niezależnych od siebie programów. Każdy z nich działa z poziomu innego użytkownika. Dlatego też niezbędne jest stworzenie siedmiu oddzielnych kont systemowych. # mkdir /var/qmail # groupadd nofiles # useradd -g nofiles -d \ /var/qmail/alias alias # useradd -g nofiles -d \ /var/qmail qmaild # useradd -g nofiles -d \ /var/qmail qmaill # useradd -g nofiles -d \ /var/qmail qmailp # groupadd qmail # useradd -g qmail -d /var/qmail qmailq # useradd -g qmail -d /var/qmail qmailr # useradd -g qmail -d /var/qmail qmails Zanim skompilujemy i zainstalujemy qmaila, zastosujemy zestaw łat znany pod nazwą SPAMCONTROL. Zestaw ten umożliwia użycie wielu mechanizmów antyspamowych, zawiera także nie związane ze spamem, lecz przydatne łaty na qmaila, m.in. łatę wprowadzającą autoryzację poczty wychodzącej (SMTP-AUTH), łatę errno dla najnowszych wersji kompilatorów C (bez niej kompilacja mogłaby zakończyć się błędem) i wiele innych ciekawostek. Pełen przegląd możliwości SPAMCONTROL znajdziemy w dokumencie http://www.fehcom.de/ qmail/spamcontrol/readme_spamcontrol.html. SPAMCONTROL warto zastosować, nawet, jeśli nie zamierzamy korzystać z mechanizmów ochrony na poziomie MTA można je wyłączyć, a późniejsze włączenie będzie o wiele łatwiejsze, niż ponowna kompilacja qmaila. # cd /usr/src # tar -xzf qmail-1.03.tar.gz # mv /usr/src/spamcontrol-229.tgz \ /usr/src/qmail-1.03 # cd /usr/src/qmail-1.03 # tar -xzf spamcontrol-229.tgz #./spamcontrol.sh www.hakin9.org 11

Obrona Następnie kompilujemy, instalujemy qmaila i przeprowadzamy wstępną konfigurację podając FQDN naszego serwera (przykładowy: mail.example.com). # make setup check #./config-fast mail.example.com Do autoryzacji zarówno przy pobieraniu poczty (przez POP3), jak i jej wysyłaniu (SMTP-AUTH) konieczne będzie zastosowanie programu weryfikującego hasła. Architektura qmaila (i łatki SMTP-AUTH) umożliwia zastosowanie do tego celu dowolnego programu zgodnego z interfejsem we/wy oryginalnego checkpassword dzięki temu możliwe jest np. przechowywanie haseł w bazie danych lub oddzielnych plikach. Standardowy checkpassword, którego użyjemy, weryfikuje hasła na podstawie kont systemowych. Na checkpassword, podobnie jak na qmaila, powinniśmy nałożyć przed kompilacją łatę errno. Następnie kompilujemy i instalujemy program. # cd /usr/src # tar -xzf checkpassword-0.90.tar.gz # cd checkpassword-0.90 # patch \ <../checkpassword-0.90.errno.patch # make # make setup check qmail nie posiada mechanizmów kontroli dostępu na poziomie TCP. Dlatego powinien być uruchamiany za pośrednictwem serwera TCP, np. popularnych inetd lub xinetd. Autor sugeruje jednak stosowanie własnego serwera tcpserver (patrz Ramka), wchodzącego w skład pakietu ucspi-tcp. W skład tego pakietu wchodzi również rblsmtpd narzędzie, które wykorzystamy do sprawdzania, czy adres IP nadawcy jest w bazach DNSBL. Kompilujemy więc i instalujemy narzędzia ucspi-tcp. # cd /usr/src # tar -xzf ucspi-tcp-0.88.tar.gz Pliki konfiguracyjne qmaila i SPAMCONTROL Konfiguracja qmaila znajduje się w plikach przechowywanych w katalogu /var/qmail/ control. Tę samą strukturę przyjął autor SPAMCONTROL. Oto najważniejsze pliki i ich znaczenie: qmail: badmailfrom lista adresów, których wystąpienie w MAIL FROM: spowoduje odrzucenie listu, defaultdelivery typ skrzynki pocztowej (zazwyczaj./mailbox lub./maildir/), locals lista domen, do których poczta będzie dostarczana lokalnie, me FQDN naszego systemu (najważniejszy i jedyny niezbędny plik konfiguracyjny), rcpthosts lista domen, do których poczta będzie przyjmowana przez serwer, # cd ucspi-tcp-0.88 # patch \ </usr/src/ucspi-tcp-0.88.errno.patch # make SPAMCONTROL: badrcptto lista adresów, których wystąpienie w RCPT TO: spowoduje odrzucenie listu, badhelo lista ciągów znakowych, których wystąpienie w HELO/EHLO spowoduje odrzucenie listu, badmimetypes lista dziewięcioznakowych sygnatur MIME jeśli załączony w liście plik jest zgodny z sygnaturą, list zostanie odrzucony (mechanizm ten może zostać wykorzystany np. do odrzucania wszystkich załączników z plikami wykonywalnymi); po zmianie zawartości pliku należy przekompilować badmimetypes.cdb wywołując komendę /var/qmail/bin/qmail-newbmt. Więcej informacji: http://miketeo.net/ref/qmail/config.html, http://www.fehcom.de/qmail/ spamcontrol/readme_spamcontrol.html, man qmail-control. # make setup check Następnym elementem standardowo stosowanym w instalacjach qmaila jest daemontools zestaw narzędzi do nadzorowania pracy daemonów (patrz Ramka). daemontools co sekundę sprawdza, czy nadzorowane przezeń daemony działają prawidłowo. Jeśli nie restartuje je. Narzędzie to oparte jest o nieco nietypową architekturę wprowadza dwa nowe katalogi: /package i /service. Jego instalacja nie jest jednak trudna. # cd /usr/src # mkdir -p /package # mv daemontools-0.76.tar.gz /package # chmod 1755 /package # cd /package # tar xzf daemontools-0.76.tar.gz # cd /package/admin/daemontools-0.76 # cd src # patch \ </usr/src/ daemontools-0.76.errno.patch # cd.. # package/install Aby skutecznie sterować qmailem warto zastosować skrypt qmailctl. Jest to prosty skrypt shellowy, przypominający konstrukcją systemowe skrypty startowe (/etc/init.d), zawierający m.in. opcje umożliwiające uruchomienie, wyłączenie lub sprawdzenie stanu pracy qmaila. # cd /usr/src # chmod 755 qmailctl # mv qmailctl /var/qmail/bin # ln -s /var/qmail/bin/qmailctl \ /usr/bin Ponieważ niektóre skrypty uruchomieniowe (patrz Ramka o daemontools) dla qmaila są dość złożone, zamieściliśmy je na naszym CD. Wystarczy je rozpakować do odpowiedniego katalogu i nadać im stosowne prawa dostępu. 12 www.hakin9.org

Ochrona przed spamem na serwerze tcpserver Wchodzący w skład pakietu ucspi-tcp tcpserver może, w połączeniu z daemontools, zastąpić całkowicie inetd lub xinetd. Zapoznajmy się z najważniejszymi jego opcjami. Składnia wywołania tcpservera (zazwyczaj wywoływany jest on ze skryptu uruchomieniowego) to: tcpserver <opcje> <host> <port> <program> gdzie: <opcje> lista opcji tcpservera, <host> adres IP lub symboliczny na którym ma nasłuchiwać tcpserver, <port> port podany w formie symbolicznej (np. smtp) lub numerycznej (np. 25), <program> program do wywołania po przyjęciu połączenia. tekstowego z zasadami to: <użytkownik>@<ip>:<instrukcje> lub <IP>:<instrukcje>, gdzie: użytkownik nazwa użytkownika (uzyskana przez ident) opcjonalne, IP adres lub zakres IP (patrz przykłady), ewentualnie =<HOST>, jeśli włączona jest opcja -h w tcpserverze, instrukcje allow (zezwól na połączenie) lub deny (odrzuć połączenie), ZMIENNA="wartość" ustawa zmienną otoczenia na określoną wartość. Linie są przetwarzane sekwencyjnie. Przykłady: 127.0.0.1:allow,RELAYCLIENT="" Najważniejsze opcje tcpservera to: - x <ścieżka do pliku> plik z zasadami dla tcpservera w formacie cdb. - c <liczba połączeń> serwer ma przyjmować nie więcej, niż określoną liczbę połączeń jednocześnie (wartość domyślna: 40), -h sprawdza w DNS-ie adres symboliczny dla IP, z którego nadchodzi połączenie (domyślnie włączone), -H nie sprawdza w DNS-ie adresu symbolicznego (połączenie jest szybciej przyjmowane, ale nie ma np. adresów symbolicznych w logach), -r sprawdza dane użytkownika dla nadchodzącego połączenia za pomocą protokołu ident (domyślnie włączone), -R nie sprawdza danych użytkownika, -t <liczba sekund> zrywa nieudane połączenia po określonym czasie (domyślnie: 26). Połączenie ze 127.0.0.1 jest dozwolone, zmienna otoczenia RELAYCLIENT przyjmuje wartość pustą (czyli dozwolone jest przesyłanie poza serwer). test@192.168.1.5:deny Połączenie z adresu 192.168.1.5 zainicjowane przez użytkownika test jest odrzucane. 192.168.1.:allow,RBLSMTPD="" Pozostałe połączenia z zakresu 192.168.1.1-192.168.1.254 są dozwolone; IP nie będą sprawdzane w bazach DNSBL. 10.10.10.1-30:deny Połączenia z zakresu 10.10.10.1-10.10.10-30 są odrzucane. Pełną listę opcji tcpservera znajdziemy na stronie http://cr.yp.to/ ucspi-tcp/tcpserver.html. Plik z zasadami dla tcpservera przygotowujemy za pomocą programu tcprules (również wchodzącego w skład ucspi-tcp). Program ten wywołujemy w następujący sposób: =hakin9.org:allow,relayclient="" Połączenia z hakin9.org są przyjmowane, zmienna otoczenia RELAYCLIENT przyjmuje wartość pustą. tcprules <cdb> <tmp> < <zasady> =.software.com.pl:allow,rblsmtpd="" gdzie: <cdb> plik docelowy (do wykorzystania przez tcpserver), <tmp> plik tymczasowy, <zasady> plik źródłowy z zasadami (tekstowy). Przykład: Wszystkie połączenia z *.software.com.pl są przyjmowane, IP nie będą sprawdzane w bazach DNSBL. =:allow Wszystkie połączenia, dla których możliwe jest uzyskanie symbolicznej nazwy hosta, są przyjmowane. tcprules tcp.smtp.cdb tcp.smtp.tmp <tcp.smtp :deny Zasady można zmieniać i rekompilować w trakcie pracy tcpservera, nie wyłączając daemonów. Format każdej linii pliku Pozostałe połączenia (z adresów IP, dla których nie ma odpowiednika symbolicznego) są odrzucane. www.hakin9.org 13

Obrona # cat >/var/qmail/rc <<EOF > #!/bin/sh > exec env - \\ > PATH="/var/qmail/bin:\$PATH" \\ > qmail-start \\ > "\`cat /var/qmail/control /defaultdelivery\`" > EOF # cd /usr/src # tar -xzf run-scripts.tar.gz # mv supervise /var/qmail # chmod 755 \ /var/qmail/supervise /qmail-send/run # chmod 755 \ /var/qmail/supervise /qmail-send/log/run # chmod 755 \ /var/qmail/supervise /qmail-smtpd/run # chmod 755 \ /var/qmail/supervise /qmail-smtpd/log/run # chmod 755 \ /var/qmail/supervise /qmail-pop3d/run # chmod 755 \ /var/qmail/supervise /qmail-pop3d/log/run Przygotowane przez nas skrypty uruchomieniowe są w większości standardowe i nie wymagają zmian. Musimy jedynie zajrzeć do: Do prawidłowego działania skryptów uruchomieniowych niezbędne będzie wprowadzenie dwóch nowych zmiennych konfiguracyjnych (qmail przechowuje całą konfigurację w katalogu /var/qmail/control w formie oddzielnych plików). Pierwdaemontools Nadzór nad daemonami, który sprawuje daemontools, oparty jest o zestaw skryptów zwanych uruchomieniowymi (run scripts). Nadzorowanie działania usług monitorowanych przez daemontools jest możliwe za pomocą dwóch programów: svc i svstat. Pierwszy umożliwia uruchamianie i wysyłanie sygnałów do daemonów, drugi zaś podaje informacje o ich działaniu. Oto sposób uruchamiania programu svc: svc <opcje> <usługi> gdzie: <opcje> lista opcji svc, <usługi> katalogi usług linki symboliczne w /service (/service/nazwausługi) A oto jego opcje: -u Jeśli usługa nie działa, włącz ją. Jeśli zatrzyma się po uruchomieniu, włącz ją ponownie. -d Jeśli usługa działa, wyślij do niej sygnał TERM a następnie CONT. Kiedy przestanie działać, nie uruchamiaj jej ponownie. -o Jeśli usługa nie działa, uruchom ją. Nie uruchamiaj jej jednak ponownie, jeśli zatrzyma się po uruchomieniu. -p Wyślij usłudze sygnał STOP. -c Wyślij usłudze sygnał CONT. -h Wyślij usłudze sygnał HUP. -a Wyślij usłudze sygnał ALARM. -i Wyślij usłudze sygnał INT. -t Wyślij usłudze sygnał TERM. -k Wyślij usłudze sygnał KILL. Przykład: svc -d /service/qmail-smtpd /service/qmail-smtpd/log wysyła sygnał TERM a następnie CONT do qmail-smtpd i usługi logowania dla qmail-smtpd. Korzystanie z programu svstat jest jeszcze prostsze: svstat <usługi> gdzie <usługi> katalogi usług analogicznie jak dla svc. daemontools może być z powodzeniem wykorzystane do nadzorowania wszelkich daemonów na serwerze. Jest to rozwiązanie o wiele lepsze, niż standardowe skrypty startowe (np. w /etc/init.d), ponieważ usługi są cały czas nadzorowane i uruchamiane ponownie w razie awarii. W tym celu należy przygotować skrypty uruchomieniowe do każdej usługi, a monitorowana przez daemontools usługa nie może działać w tle (musi mieć opcję uruchomienia nie w tle). Niestety daemontools jeszcze nie umożliwia ustalenia kolejności uruchamiania usług, co może w niektórych przypadkach powodować problemy. Aby nie pisać samodzielnie skryptów uruchomieniowych, możemy skorzystać z gotowej, rozbudowanej kolekcji przykładów, którą znajdziemy pod adresem: http://smarden.org/runit/runscripts.html. /var/qmail /super vise /qmailpop3d/run należy w nim zmienić mail.example.com na FQDN naszego serwera POP3 (jeśli POP3 i SMTP są na tej samej maszynie, można oczywiście użyć tego samego FQDN), /var/qmail /super vise /qmailsmtpd/run w skrypcie możemy wybrać, z których DNSBL będziemy korzystać za pomocą rblsmtpd (patrz Ramka); w przykładowym stosujemy cztery serwery: ORDB, DSBL, SpamCop i SpamHaus. Ponieważ rblsmtpd wykonuje testy sekwencyjnie, sugerujemy nie wykorzystywać więcej niż pięć serwerów może to spowolnić reakcję daemona SMTP na nadchodzące połączenia (serwery łączące się z nami mogą zrywać połączenie, zanim zweryfikujemy IP). Aby nie korzystać z serwerów DNSBL wystarczy usunąć ze skryptu komendę rblsmtpd wraz z parametrami lub ustawić zmienną RBLSMTPD="" dla wszystkich zakresów IP w /etc/tcp.smtp. 14 www.hakin9.org

Ochrona przed spamem na serwerze rblsmtpd Program rblsmtpd funkcjonuje jako proxy. Udaje on MTA stosując jedynie podstawowe komendy SMTP, a jednocześnie sprawdzając, czy IP połączenia jest wylistowane w wybranych bazach DNSBL. Następnie, w zależności od wyniku, przekazuje lub odrzuca połączenie. rblsmtpd wywołujemy w następujący sposób: rblsmtpd <opcje> <program> gdzie: <opcje> lista opcji rblsmtpd, <program> program, który zostanie uruchomiony, jeśli test wypadnie pozytywnie i któremu zostanie przekazane połączenie. Opcje rblsmtpd to: -t <liczba sekund> maksymalny czas prowadzenia sesji SMTP (domyślnie 60 sekund), -r <adres serwera DNSBL> jeśli IP nadchodzącego połączenia jest wylistowane w serwerze, połączenie jest odrzucane, -a <adres serwera DNSBL> jeśli IP nadchodzącego połaczenia jest wylistowane w serwerze, połączenie jest przyjmowane (opcja wykorzystywana np. do akceptowania połączeń z danego kraju, nawet, jeśli są wylistowane w innych DNSBL). Opcje -r i -a mogą występować wielokrotnie. Przykład: -a nigeria.blackholes.us -r bl.spamcop.net -r list.dsbl.org spowoduje, że przyjmowane będą wszystkie połączenia z Nigerii, a w przypadku pozostałych połączeń będą przyjmowane tylko te, których IP nie znajduje się w DNSBL SpamCopa ani DSBL. Istnieje możliwość zmiany sposobu funkcjonowania rblsmtpd tak, by zamiast odrzucania połączeń program dopisywał jedynie stosowne nagłówki do listu. Wtedy każdy list jest przyjmowany przez serwer, a użytkownik może sam zadecydować czy list na podstawie tych nagłówków kasować, czy nie. W tym celu należy zastosować łatki przygotowane przez Markusa Stumpfa, dostępne na stronie http://www.lamer.de/ maex/creative/software/ucspi-tcp/0.88-rblsmtpd-rblid/. Musimy nałożyć łatkę na rblsmtpd oraz qmail-smtpd. Po nałożeniu łatek możemy stosować nową opcje rblsmtpd: -p <id>:<dnsbl> do listu zostanie dodany nagłówek RBLID= <id>, jeśli IP nadawcy znalazło się w DNSBL o adresie <dnsbl>. Przykład: -p SPAMCOP:bl.spamcop.net -p NIGERIA:nigeria.blackholes.us spowoduje, że w nagłówkach listu pojawią się dwa nowe: X-RBL-Check: SPAMCOP, jeśli IP połączenia jest wylistowane w SpamCopie, X-RBL-Check: NIGERIA, jeśli IP połączenia jest z Nigerii. Z kolei w logach qmail-smtpd zobaczymy wpis: rblsmtpd: x.x.x.x pid yyy: RBLID= SPAMCOP NIGERIA gdzie x.x.x.x to adres IP połączenia, a yyy to identyfikator (numer) procesu. Uwaga: łatka na qmail-smtpd nie współdziała ze SPAMCONTROL, które również modyfikuje qmail-smtpd. W przypadku stosowania obu tych łat jest konieczna samodzielna modyfikacja kodu. sza z nich określa, że listy będą dostarczane do skrzynek typu Maildir (możemy zamiast tego zastosować Mailbox), druga zaś określa, że będziemy przyjmować nie więcej niż 20 połączeń przychodzących jednocześnie. # echo./maildir/ \ >/var/qmail/control /defaultdelivery # echo 20 \ >/var/qmail/control /concurrencyincoming # chmod 644 \ /var/qmail/control /defaultdelivery # chmod 644 \ /var/qmail/control /concurrencyincoming Przygotujmy też katalogi, w których przechowywane będą logi qmaila. Logi tworzone będą za pomocą wchodzącego w skład daemontools narzędzia multilog (patrz Ramka). # mkdir -p /var/log/qmail/smtpd # mkdir /var/log/qmail/pop3d # chown -R qmaill /var/log/qmail Następnie przygotujmy zasady w oparciu o które tcpserver będzie przyjmował połączenia do serwera SMTP. Poniższe zasady zakładają, że wszystkie połączenia z 127.0.0.1-127.255.255.254 są przyjmowane i użytkownik z tego zakresu IP ma prawo przesyłać pocztę na zewnątrz serwera bez konieczności autoryzacji SMTP-AUTH (ustawiona zmienna otoczenia RELAYCLIENT). Wszystkie pozostałe połączenia z rozwiązywalnych adresów również są przyjmowane, jednak do przesyłania poczty poza serwer użytkownik musi się autoryzować (brak RELAYCLIENT); następuje też weryfikacja HELO /EHLO (ustawiona zmienna HELODNSCHECK) oraz MAIL FROM: (ustawiona zmienna MFDNSCHECK). Połączenia z nierozwiązywalnych adresów IP nie będą przyjmowane. Jak widać, za pomocą ustawień tcpservera możemy w pełni kontrolować, które adresy IP są zaufane, a które nie. www.hakin9.org 15

# cat >/etc/tcp.smtp <<EOF > 127.:allow,RELAYCLIENT="" > =:allow,mfdnscheck="",helodnscheck="" > :deny > EOF Jeśli nie chcemy stosować kontroli rozwiązywalności IP oraz poprawności HELO /EHLO i MAIL FROM:, wystarczy zastąpić dwie ostatnie linie tcp.smtp następującą: :allow Jeśli nie chcemy korzystać z serwerów DNSBL wystarczy, by linia ta zawierała: :allow,rblsmtpd="" Po zmianie ustawień należy przekompilować plik tcp.smtp zawierający ustawienia dla tcpservera tcpserver korzysta bowiem z plików w formacie cdb. Do rekompilacji służy opcja cdb skryptu qmailctl. # qmailctl cdb multilog Program multilog wchodzący w skład daemontools odczytuje sekwencję linii ze standardowego wejścia i rozdziela je do logów według określonych zasad. Rotuje on logi w oparciu o ich wielkość, a nie czas (jak powszechnie używany logrotate), dzięki czemu logi zajmują zawsze tyle samo miejsca. Czas w logach zapisywany jest w formacie TAI64 (międzynarodowy format czasu atomowego Temps Atomique International więcej informacji: http://cr.yp.to/libtai/tai64.html). W pakiecie daemontools jest narzędzie do konwersji tego formatu na standardowy (tai64nlocal). multilog uruchamiamy w następujący sposób: multilog <skrypt> gdzie <skrypt> to ciąg argumentów, z których każdy określa jedno zadanie do wykonania. Argumenty są przetwarzane według podanej kolejności. Podstawowe działania to: -<wzorzec> ignoruje linie, które pasują do wzorca (wzorzec budujemy podobnie, jak wzorce plikowe, oznaczając znakiem * dowolny ciąg znaków), +<wzorzec> dokłada do określonego logu linie, które pasują do wzorca, t dopisuje aktualny czas w formacie TAI64 przed każdą linią (t musi być podane jako pierwsze działanie), <katalog> zapisuje wybrane linie do określonego katalogu (nazwa katalogu musi się rozpoczynać znakiem. lub /), s<wielkość> określa wielkość każdego pliku logu (domyślnie: 99999 bajtów), n<liczba> określa liczbę plików logów (domyślnie: 10). Przykład: multilog \ t s999999 n50 /var/log/qmail/smtpd \ t s9999 n5 -* +* rblsmtpd: * /var/log/qmail/rblsmtpd Obrona Zastąpmy teraz standardową aplikację sendmail (służącą do wysyłania poczty z linii komend) jej odpowiednikiem działającym z qmailem. # mv /usr/lib/sendmail \ /usr/lib/sendmail.old # mv /usr/sbin/sendmail \ /usr/sbin/sendmail.old # chmod 0 /usr/lib/sendmail.old # chmod 0 /usr/sbin/sendmail.old # ln -s /var/qmail/bin/sendmail \ /usr/lib # ln -s /var/qmail/bin/sendmail \ /usr/sbin Przed samym uruchomieniem serwera powinniśmy jeszcze stworzyć obowiązkowe aliasy pocztowe: postmaster oraz abuse, a także przydatny (ale nieobowiązkowy): root (qmail nie zezwala na dostarczanie poczty do katalogu superużytkownika, dlatego root musi być aliasem do nieuprzywilejowanego konta). Zarządzanie aliasami w qmailu jest bardzo proste. Wystarczy, że Takie wywołanie multilogu (w skrypcie /service/qmail-smtpd/log/run) spowoduje, że: do katalogu /var/log/qmail/smtpd będą zapisywane wszystkie (poprzedzone zapisem czasu w formacie TAI64) linie; plików logu będzie maksimum 50, a każdy z nich zajmie nie więcej niż 999999 bajtów, do katalogu /var/log/qmail/rblsmtpd będą zapisywane wszystkie (poprzedzone zapisem czasu w formacie TAI64) linie zawierające * rblsmtpd: *; plików logu będzie maksimum 5, a każdy z nich zajmie nie więcej, niż 9999 bajtów. Aktualny log zawsze znajduje się w pliku current. Starsze pliki mają nazwy odpowiadające czasowi zakończenia logu w formacie TAI64. Końcówka nazwy pliku może być dwojaka:.s: plik został w całości zapisany na dysku,.u: plik został stworzony po awarii systemu może być niekompletny. Więcej informacji na temat multilogu można znaleźć pod adresem: http://cr.yp.to/ daemontools/multilog.html. w /var/qmail/alias stworzymy plik o nazwie.qmail-nazwaaliasu, a zawartością tego pliku będzie nazwa konta lokalnego (lub adres, na który należy przekazywać pocztę). Uwaga: warto wiedzieć, iż w przypadku aliasów zawierających kropkę nazwa pliku musi w tym miejscu zawierać dwukropek (czyli dla aliasu j.doe musimy stworzyć plik.qmail-j:doe). # echo admin \ >/var/qmail/alias/.qmail-root # echo admin \ >/var/qmail/alias/.qmail-postmaster # echo admin \ >/var/qmail/alias/.qmail-abuse # chmod 644 \ /var/qmail/alias/.qmail-root # chmod 644 \ /var/qmail/alias/.qmail-postmaster 16 www.hakin9.org

Ochrona przed spamem na serwerze # chmod 644 \ /var/qmail/alias/.qmail-abuse Listing 5. Stan działania procesów qmaila Utwórzmy też strukturę Maildir dla przykładowego użytkownika. Warto później utworzyć taką strukturę w /etc/skel, by była wykorzystywana przy dodawaniu nowych użytkowników do systemu. # maildirmake /home/admin/maildir # chown -R admin:users \ /home/admin/maildir # chmod -R 700 /home/admin/maildir Przyszedł czas na uruchomienie qmaila. Zanim jednak to zrobimy, upewnijmy się, że nasz system nie ma już daemona SMTP (możemy to zrobić np. za pomocą komendy netstat lub telnet localhost 25). Jeśli ma: należy go wyłączyć (np. w /etc/rcx.d lub w plikach konfiguracyjnych inetd lub xinetd w zależności od dystrybucji). Następnie uruchamiamy qmaila, tworząc dowiązania symboliczne do skryptów uruchomieniowych w katalogu /service (tak należy stosować daemontools nadzór uruchamiamy tworząc dowiązania symboliczne w /service a przerywamy kasując te dowiązania; nie należy tworzyć plików bezpośrednio w katalogu /service). # ln -s \ /var/qmail/supervise/qmail-send \ /service # ln -s \ /var/qmail/supervise/qmail-smtpd \ /service # ln -s \ /var/qmail/supervise/qmail-pop3d \ /service Po kilku sekundach możemy sprawdzić stan działania procesów qmaila: # qmailctl stat Powinniśmy zobaczyć wynik zbliżony do przedstawionego na Listingu 5. Jeśli którykolwiek z nadzorowanych przez daemontools daemonów będzie wciąż wskazywał, że działa zaledwie 0 lub 1 sekundę, oznacza /service/qmail-send: up (pid 16423) 3 seconds /service/qmail-send/log: up (pod 16424) 3 seconds /service/qmail-smtpd: up (pid 16428) 3 seconds /service/qmail-smtpd/log: up (pod 16430) 3 seconds /service/qmail-pop3d: up (pid 16432) 3 seconds /service/qmail-pop3d/log: up (pod 16434) 3 seconds messages in queue: 0 messages in queue but not yet preprocessed: 0 to, że jest non stop restartowany, ze względu na błąd. Najczęściej popełniane błędy to: nie działają qmail-send/log, qmail-smtpd/log lub qmail-pop3d/log: brak katalogów logów lub nieprawidłowy użytkownik/prawa dostępu do katalogów logów (właścicielem powinien być qmaill); warto też sprawdzić czy nie popełniliśmy błędu w skryptach /service/qmail-*/log/run. nie działa qmail-smtpd: warto obejrzeć log /var/log/qmail/ smtpd/current najczęściej problem powoduje inny daemon SMTP, którego nie wyłączyliśmy przed uruchomieniem qmaila. nie działa qmail-send: warto obejrzeć skrypt /var/qmail/rc. Możemy spróbować wyłączyć qmaila (# qmailctl stop) i uruchomić skrypt samodzielnie zobaczymy wtedy ewentualne komunikaty o błędach składniowych, które mogły nie zostać zalogowane w /var/log/qmail/ current. Logi qmail-send i qmail-smtpd możemy przeglądać wywołując: # qmailctl logs Do dostarczania poczty do skrzynek qmail nie potrzebuje żadnego dodatkowego narzędzia. Jeśli jednak stosujemy o wiele efektywniejszy od tradycyjnych Mailboksów format Maildir, narzędzia, którymi filtrujemy pocztę, muszą umieć umieścić list w strukturze Maildir. Niestety, nie każde narzędzie to potrafi, tak więc warto zastosować program maildrop, który o to zadba. # cd /usr/src # tar -xjf maildrop-1.6.3.tar.bz2 # cd maildrop-1.6.3 #./configure # make # make install-strip # make install-man W tej chwili mamy w pełni działający serwer SMTP z opcjonalną ochroną na poziomie MTA (DNSBL, weryfikacja HELO /EHLO oraz MAIL FROM:). Proces instalacji można w tym momencie zakończyć, jeśli nie chcemy stosować np. filtrów bayesowskich lub challenge-response. Ochronę na poziomie MDA możemy potraktować jako opcjonalną. Instalacja i konfiguracja filtra bayesowskiego Jako narzędzie do filtrowania bayesowskiego przychodzącej poczty zastosujemy Bogofilter. Jego instalacja nie powinna sprawić problemów. # cd /usr/src # tar -xjf bogofilter-0.16.4.tar.bz2 # cd bogofilter-0.16.4 #./configure # make # make install Konfigurację Bogofiltra musimy przeprowadzać z poziomu konta użytkownika, dla którego zamierzamy www.hakin9.org 17

Obrona zastosować to narzędzie, tu: admin. Najpierw nakarmimy Bogofiltra spamem i hamem. Na CD zamieściliśmy przykładową bazę spamu (z http:// www.spamarchive.org). W przypadku hamu musimy przygotować własną przykładową paczkę w formacie Mailbox. Następnie uczymy filtr. $ gunzip spam-example.gz $ cat spam-example bogofilter -Ns $ cat nasz-ham bogofilter -Sn Opcja -s oznacza, że wszystkie listy zawarte w paczce powinny być traktowane jako spam, zaś -N że nie są hamem. Podobnie w przypadku opcji -S (niespam) i -n (ham). Opcje -S i - N nie są w tym przypadku konieczne (ale nie zaszkodzą), ponieważ służą do odwołania wcześniejszej klasyfikacji (jeśli wcześniej nakarmiliśmy filtr listem, który oznaczyliśmy za pomocą opcji -s jako spam, możemy cofnąć tę decyzję karmiąc jeszcze raz tym samym listem z opcją -S). Teraz przygotujemy pliki konfuracyjne qmaila i maildropa tak, by poczta była automatycznie filtrowana i by użytkownik miał możliwość samodzielnego douczania fitra. Najpierw ustalamy, iż maildrop ma zawsze dostarczać pocztę do struktury Maildir. $ cat >.mailfilter <<EOF > to "\$HOME/Maildir/" > EOF $ chmod 600.mailfilter Następnie ustalamy, iż qmail ma dostarczać pocztę do maildropa po wcześniejszym przefiltrowaniu jej za pomocą Bogofiltra. Opcja -p nakazuje Bogofiltrowi dodawać tag X-Bogosity do nagłówków przefiltrowanej poczty, a następnie przekazywać list na standardowe wyjście; opcja -e by zawsze zwracał kod wyjścia 0; opcja -u by uczył się na podstawie własnych decyzji (jeśli zdecyduje, że list jest spamem lub hamem, uczy się na tej podstawie i następne listy klasyfikuje jeszcze skuteczniej ewentualne błędy możemy odwołać za pomocą wymienionych wcześniej opcji -S lub -N). $ cat >.qmail <<EOF > /usr/local/bin/bogofilter -u -e -p preline -f /usr/local/bin/maildrop > EOF Teraz przygotujemy trzy aliasy dla użytkownika admin. qmail umożliwia tworzenie aliasów także samemu użytkownikowi niekoniecznie w katalogu /var/qmail/alias. Aliasy te rozszerzają identyfikator użytkownika. Tak więc plik.qmail-test w katalogu /home/admin to dyrektywy dla aliasu admin-test. Alias specjalny -default przechwytuje pozostałe listy do admin-*. Aliasy admin-spam oraz adminham służą do nauczania filtru. Wysyłając na te aliasy otrzymywane przez nas listy (za pomocą opcji redirect/ przekieruj lub bounce/odbij w programie pocztowym uwaga: nie mylić z opcją forward/przekaż dalej) możemy dalej uczyć Bogofiltra lub poprawiać jego błędy (jeśli list zostanie źle sklasyfikowany w przeciwnym wypadku Bogofilter będzie robił coraz więcej pomyłek). $ cat >.qmail-spam <<EOF > /usr/local/bin/bogofilter -Ns > EOF $ cat >.qmail-ham <<EOF > /usr/local/bin/bogofilter -Sn > EOF $ ln -s.qmail.qmail-default Listing 6. Instalacja TMDA # cd /usr/src # tar -xzf tmda-1.0.1.tar.gz # mv tmda-1.0.1 /usr/local/tmda # cd /usr/local/tmda #./compileall # ln -s /usr/local/tmda/bin/tmda-address /usr/local/bin W tej chwili mamy już system ochrony antyspamowej na poziomie MDA. Listy rozpoznane jako spam są tagowane i użytkownik może sam zdecydować, co z nimi robić kasować, przerzucać do innego katalogu itp. Na tym etapie również możemy zakończyć proces instalacji, traktując system challenge-response jako rozwiązanie opcjonalne. Możemy również samodzielnie zainstalować program SpamAssassin i korzystać z niego tak samo, jak z Bogofiltra. SpamAssassin umożliwi stosowanie zarówno analizy heurystycznej, jak i bayesowskiej, a także sieci antyspamowych i DNSBL. Jest jednak, w przeciwieństwie do Bogofiltra, bardzo zasobożerny. Instalacja i konfiguracja systemu challenge-response TMDA jest napisany w Pythonie. Do jego zastosowania potrzebujemy Pythona w wersji co najmniej 2.1 (sugerowana: 2.3). Interpreter jest dostępny w większości najnowszych dystrybucji Linuksa; jeśli jednak stosujemy starszą dystrybucję, być może będziemy musieli go doinstalować lub zaktualizować. Instalacja TMDA polega na rozpakowaniu skryptów do wybranego katalogu (przykładowo: /usr/local/ tmda) i skompilowaniu (patrz Listing 6). Następnie tworzymy symboliczne dowiązania do plików binar- # ln -s /usr/local/tmda/bin/tmda-check-address /usr/local/bin # ln -s /usr/local/tmda/bin/tmda-filter /usr/local/bin # ln -s /usr/local/tmda/bin/tmda-inject /usr/local/bin # ln -s /usr/local/tmda/bin/tmda-keygen /usr/local/bin # ln -s /usr/local/tmda/bin/tmda-ofmipd /usr/local/bin # ln -s /usr/local/tmda/bin/tmda-pending /usr/local/bin # ln -s /usr/local/tmda/bin/tmda-rfilter /usr/local/bin # ln -s /usr/local/tmda/bin/tmda-sendmail /usr/local/bin 18 www.hakin9.org

Ochrona przed spamem na serwerze nych (nie wolno ich przenosić poza drzewo TMDA). Następnie, dla ułatwienia, skorzystajmy z gotowej konfiguracji TMDA. $ cd /usr/src $ cp tmda-config.tar.gz ~ $ tar xzf tmda-config.tar.gz Teraz musimy wygenerować klucz na podstawie którego TMDA będzie tworzyło tymczasowe adresy dla potwierdzeń. W tym celu wywołujemy polecenie: $ tmda-keygen W Sieci qmail Wygenerowany klucz kopiujemy do pliku ~/.tmda/crypt_key i zmieniamy prawa dostępu do pliku tak, by odczytać mógł go jedynie użytkownik: $ chmod 600.tmda/crypt_key Następnie musimy przejrzeć plik konfiguracyjny ~/.tmda/config i wprowadzić w nim niezbędne zmiany: prawidłową nazwę użytkownika, hasło, FQDN naszego serwera, adres serwera SMTP itp. Dokładny opis zmiennych konfiguracyjnych stosowanych przez TMDA znajdziemy na http://www.tmda.net. http://www.lifewithqmail.org/ najbardziej rozbudowany opis instalacji i konfiguracji qmaila http://www.flounder.net/qmail/qmail-howto.html szybki start z qmailem http://www.chrishardie.com/tech/qmail/qmail-antispam.html jak zwalczać spam za pomocą qmaila http://www.qmail.org/ biblioteka informacji nt. qmaila http://cr.yp.to/ strona domowa Prof. Dana J. Bernsteina autora qmaila, daemontools, ucspi-tcp, checkpassword. Szare listy http://greylisting.org/ strona poświęcona technice szarych list SPAMCONTROL http://www.fehcom.de/qmail/spamcontrol.html strona domowa SPAMCONTROL DNSBL http://www.declude.com/junkmail/support/ip4r.htm największa lista serwerów DNSBL wraz z opisami http://www.sdsc.edu/~jeff/spam/blacklists_compared.html porównanie DNSBL Bogofilter i techniki filtrów bayesowskich http://bogofilter.sourceforge.net/ strona domowa Bogofiltra http://www.bgl.nu/bogofilter/ informacje jak dostroić Bogofiltra by był jak najbardziej skuteczny http://www.paulgraham.com/spam.html artykuł Paula Grahama, który zapoczątkował rozwój filtrów bayesowskich TMDA i systemy challenge-response http://www.tmda.net/ strona domowa TMDA http://spamlinks.port5.com/filter-cr.htm biblioteka informacji nt. systemów challenge-response http://www.templetons.com/brad/spam/challengeresponse.html jak dobrze zaimplementować filtr challenge-response Przykładowa konfiguracja zakłada co następuje: każdy list, w którego nagłówkach znajduje się X-Bogosity: Yes (wstawione przez Bogofiltra) jest odrzucany jako spam. każdy list z adresu, który nie znajduje się na whiteliście (liście użytkowników lub domen, które zawsze mogą wysyłać do nas pocztę), musi być potwierdzony Zasady możemy oczywiście dopasować do własnych potrzeb modyfikując ~/.tmda/config oraz ~/.tmda/filters/incoming na podstawie dokumentacji. Możemy na przykład zdecydować, że wszystkie listy nieoznaczone przez Bogofiltra jako spam są przyjmowane bez potwierdzenia, a te wskazane przez Bogofiltra jako spam wymagają potwierdzenia. W takim wypadku wystarczy zmienić ostatnią linię w ~/.tmda/filters/incoming na: headers 'X-Bogosity: Yes' confirm i zmodyfikować ~/.tmda/config tak, by zawierał ACTION _ INCOMING = "ok". Na koniec modyfikujemy konfigurację MDA tak, by listy były filtrowane zarówno przez Bogofiltra jak i TMDA. $ cat >.qmail <<EOF > /usr/local/bin/bogofilter -u -e -p preline -f /usr/local/bin/tmda-filter > /usr/local/bin/bogofilter -u -e -p preline -f /usr/local/bin/maildrop > EOF Osiołkowi w żłoby dano Sposobów na walkę ze spamem jest, jak widać wiele. Miejmy jednak nadzieję, że z czasem prawo i stosowane dotychczas metody na tyle zniechęcą spamerów do zaprzestania działalności, by nie była konieczna implementacja coraz to nowych narzędzi. Dotychczasowe trendy wskazują jednak, że nadzieje są złudne i do życia ze spamem po prostu będziemy musieli się przyzwyczaić. www.hakin9.org 19