Wydajny filtr SMTP PRACA DYPLOMOWA INŻYNIERSKA. Katarzyna Ciechańska

Transkrypt

1 Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Instytut Informatyki Rok akademicki 2008/2009 PRACA DYPLOMOWA INŻYNIERSKA Katarzyna Ciechańska Wydajny filtr SMTP Opiekun pracy: dr inż. Grzegorz Blinowski Ocena Podpis Przewodniczącego Komisji Egzaminu Dyplomowego

2 Specjalność: Inżynieria Systemów Informatycznych Data urodzenia: 21 kwietnia 1985 r. Data rozpoczęcia studiów: 23 luty 2004 r. ŻYCIORYS Urodziłam się 21 kwietnia 1985r. w Warszawie. Po ukończeniu szkoły podstawowej nr 195 w Warszawie w roku 1999, kontynuowałam naukę w XIX Liceum Ogólnokształcącym im. Powstańców Warszawy w Warszawie. Uczęszczałam do klasy o profilu matematyczno - fizycznym z rozszerzonym językiem angielskim. W lutym 2004 r. rozpoczęłam studia na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. W roku 2006 wybrałam specjalność Inżynieria Systemów Informatycznych. Egzamin dyplomowy podpis studenta Złożyła egzamin dyplomowy w dn z wynikiem Ogólny wynik studiów Dodatkowe wnioski i uwagi Komisji

3 Streszczenie Przedmiotem niniejszej pracy jest przedstawienie projektu wydajnego narzędzia do filtrowania poczty elektronicznej, działającego jako aplikacyjne proxy SMTP (ang. Simple Mail Transfer Protocol). W pracy zawarto opis działania protokołu SMTP, ze szczególnym uwzględnieniem standardu MIME (ang. Multipurpose Internet Message Extensions). Ważną jej częścią jest rozdział poświęcony omówieniu struktury wiadomości . Przedstawiono koncepcję kontroli zawartości przesyłek elektronicznych oraz zaprezentowano stosowane obecnie metody takiej kontroli. Dokonano przeglądu dostępnego na rynku oprogramowania, realizującego funkcję content security. Integralną częścią pracy jest szkieletowy system filtrujący. Aplikacja umożliwia sprawdzenie wiadomości pod kątem zgodności z obowiązującymi standardami oraz klasyfikację do grupy przesyłek poprawnych, szkodliwych lub niepożądanych. Kluczowym modułem programu jest wydajny i stabilny parser wiadomości. Słowa kluczowe: , content security, SMTP, MIME, filtracja wiadomości, badanie zawartości, poczta elektroniczna, RFC, MTA, serwer pocztowy. THE EFFICIENT SMTP PROTOCOL FILTER Abstract This master thesis covers the concept of efficient electronic mail filtering tool, working as an SMTP (Simple Mail Transfer Protocol) protocol proxy. The dissertation contains description of SMTP protocol. MIME (Multipurpose Internet Message Extensions) extension was presented in detail. The chapter about message structure is one of the most important parts of the paper. Next the thesis investigates ways of controlling message content. It presents commonly used methods of content filtering and an overview of popular content filtering tools. Vital part of this work is a filtering application framework, which enables checking validity of messages acording to norms and standards. It s main functionality is to classify messages into groups of correct, harmful and unwanted messages. The efficient and stable parser is the key module of the application. Key words: , content security, SMTP, MIME, message filtering, content filtering, electronic mail, RFC, MTA, mail server.

4 Spis treści Wstęp 6 1. Wprowadzenie do tematyki filtrowania zawartości Cel pracy Zawartość merytoryczna i układ dokumentu Protokół SMTP Historia SMTP Komunikacja SMTP Architektura SMTP Komunikacja między serwerem i klientem SMTP Routing wiadomości Rozszerzenia protokołu Struktura wiadomości Standard MIME Content security Potrzeba filtrowania wiadomości Metody filtrowania zawartości Przegląd dostępnego oprogramowania, realizującego funkcję content security Założenia projektowe tworzonego systemu Wymagania funkcjonalne Wymagania niefunkcjonalne Ograniczenia zakresu realizacji zadania Projekt i implementacja filtru Architektura aplikacji Obsługa protokołu SMTP Obsługa sesji SMTP Komunikacja sieciowa Badanie zawartości wiadomości Reprezentacja wiadomości Parsowanie wiadomości Filtrowanie i klasyfikacja wiadomości Watch Dog Obsługa sytuacji nietypowych Problem wyczerpania się pamięci Brak połączenia z serwerem docelowym i

5 SPIS TREŚCI 4.6 Dokumentacja użytkownika Instalacja programu Konfiguracja programu Plik dziennika zdarzeń Pliki wiadomości oczekujących na wysłanie Pliki wiadomości znajdujących się w kwarantannie Testy 60 Środowisko testowe Automatyczne testy modułowe Pomiary wydajności Podsumowanie 61 A Zebrana gramatyka, opisująca strukturę wiadomości 62 B Spis tablic, rysunków i wydruków 67 Spis wydruków Spis rysunków Spis tablic ii

6 Wstęp Początki poczty elektronicznej sięgają lat 60 ubiegłego wieku. Pierwsze jej implementacje pozwalały na przekazywanie wiadomości jedynie pomiędzy użytkownikami tej samej maszyny. W chwili obecnej usługa umożliwia przepływ informacji między nadawcami i odbiorcami na całym świecie. Stała się jedną z podstawowych, jeśli nie podstawową, formą komunikacji w dużych firmach i pomiędzy partnerami biznesowymi. Obok oczywistych korzyści, poczta elektroniczna niesie ze sobą zagrożenia. Szczególnie trudnym do zwalczenia problemem okazał się spam. Wg. Gartner Group [potrzebny odnośnik] przeciętny użytkownik Internetu spędza na segregowaniu i przeglądaniu wiadomości pocztowych około 15 minut dziennie, pracownik działu IT - 49 minut. Gdyby nie otrzymywali spamu, czas ten skróciłby się o blisko 30%. Spam nie tylko utrudnia korzystanie z poczty elektronicznej, ale także stwarza ryzyko zniszczenia lub uszkodzenia ważnych danych. Do masowo wysyłanych wiadomości często załączane jest złośliwe oprogramowanie. Ofiarą zakażenia wirusem, koniem trojańskim czy programem szpiegowskim nie musi paść tylko pojedyncza stacja robocza. Czasem nieopatrznie uruchomiony plik wykonywalny może poskutkować sparaliżowaniem sieci całej korporacji. Oprócz wymienionych, do wad spamu należą: ograniczanie przepustowości łącz, a niekiedy nawet ich blokowanie, oraz spowalnianie pracy niepotrzebnie przetwarzających spam serwerów pocztowych. Niechciane listy w skrzynce pocztowej to efekt braku kontroli nad treścią wiadomości przychodzących. Podobna trudność wiąże się z pocztą wychodzącą, która jest potencjalnym źródłem wycieku informacji. Stanowi to poważny problem, zwłaszcza dla dużych organizacji, dla których ważne jest zabezpieczenie przed kradzieżą własności intelektualnej oraz ochrona poufnych informacji, np. danych personalnych, stosowanych rozwiązań albo raportów dotyczących planowanych kierunków rozwoju. Łamanie polityki bezpieczeństwa firmy może mieć miejsce w dwóch przypadkach - gdy zastrzeżone informacje przedostają się poza obręb przedsiębiorstwa oraz gdy ma do nich wgląd nieuprawniony personel. Zdarza się także, że pracownicy, wykorzystując służbowe skrzynki pocztowe, dopuszczają się czynów karalnych, np. rozpowszechniając nielegalne oprogramowanie 6

7 WSTĘP lub inne materiały, np. o treściach pornograficznych. Dlatego na rynku IT bardzo poszukiwane są rozwiązania uniemożliwiające przesyłanie niepożądanych treści. 1. Wprowadzenie do tematyki filtrowania zawartości Wymiana informacji za pomocą poczty elektronicznej opiera się na rozpowszechnionych od lat standardach. Szeroko stosowany jest prosty tekstowy protokół SMTP (ang. Simple Mail Transfer Protocol). Mimo, że jest stale uzupełniany o rozszerzenia (np. w pażdzierniku 2008 r. wprowadzono aktualizację specyfikacji standardu [potrzebny odnośnik] ), pozostaje mało odporny na ataki spamerów. Dzieje się tak, ponieważ jego twórcy nie przewidzieli problemów spamu czy wycieku informacji, a nie wszystkie serwery pocztowe obsługują odpowiednie rozszerzenia protokołu. Należy także zauważyć, że wiele z nich w ogóle nie reaguje na niezgodności ze standardem SMTP, jakich dopuszcza się klient w czasie komunikacji. Często ignorowane są rozbieżności w konstrukcji nagłówków koperty oraz nagłówków samych przesyłanych wiadomości. Ponieważ w chwili obecnej nie są znane dobre metody eliminujące ten problem na poziomie protokołu komunikacyjnego, należy szukać ich rozwiązania w oprogramowaniu działającym jako warstwa znajdująca się ponad takim protokołem. Funkcjonalność ta jest realizowana za pomocą aplikacji wyposażonych w funkcje filtrowania listów na podstawie badania ich zawartości, czyli tzw. content security. Oprogramowanie content security łączy w sobie analizę przebiegu sesji SMTP z kontrolą treści przesyłki pocztowej. Na podstawie obserwacji protokołu można sprawdzić tożsamość nadawców poczty, zidentyfikować wiadomości wysyłane do ukrytych lub nie znanych odbiorców, zapewnić zgodność jej przesyłania ze standardem SMTP itp.. Badanie treści polega na wyodrębnianiu z wiadomości poszczególnych części, które poddawane są następnie właściwej analizie. Wynikiem może być np. rozpoznanie błędów w strukturze wiadomości, skategoryzowanie wiadomości na podstawie analizy kontekstowej użytych słów lub wykrycie złośliwego oprogramowania. Wraz z narzędziami monitorującymi ruch wchodzący do i wychodzący z sieci lokalnej oraz z odpowiednio sformułowaną polityką bezpieczeństwa, oprogramowanie content security tworzy skuteczny firewall firmy. 7

8 WSTĘP 2. Cel pracy Celem niniejszej pracy jest przedstawienie koncepcji wydajnego filtra protokołu SMTP, realizującego funkcje content security oraz zaimplementowanie szkieletowej aplikacji, spełniającej to wymaganie. Filtr ma umożliwiać zbadanie zawartości przesyłanych za pomocą wspomnianego protokołu wiadomości, klasyfikowanie ich oraz przeprowadzanie na nich określonych akcji, takich jak: poddanie kwarantannie, odrzucenie, przekierowanie do innego serwera. Realizowane oprogramowanie ma działać jako aplikacyjne proxy i przechwytywać ruch pocztowy pomiędzy klientem a serwerem. Typowe zastosowania programu obejmują filtrowanie wiadomości po stronie serwera pocztowego lub po stronie klienta protokołu SMTP. Projekt ma charakter otwarty. Ponieważ istnieje wiele rozbudowanych narzędzi do filtracji korespondencji elektronicznej, implementowana aplikacja powinna posiadać pewne szczególne cechy, wyróżniające ją spośród innych produktów. Działanie istniejących aplikacji sprowadza się do analizy samej treści listów. Tworzone oprogramowanie ma zostać wzbogacone względem nich o rozpoznawanie błędnie skonstruowanych pól nagłówkowych (tzn. takich, które stoją w sprzeczności ze specyfikacją zawartą w odpowiednich dokumentach RFC). Rozpoznawane będą także nagłówki koperty wiadomości, czyli filtracja będzie się odbywać już na poziomie protokołu SMTP. Ponieważ analiza metadanych jest szybka, może znacznie ułatwić wykrycie niepożądanych wiadomości. Stosowane dziś produkty są często wyposażone w dużą ilość przydatnych, dodatkowych funkcji, czasem kosztem jakości wykonywania się ich podstawowych zadań. Znane luki w działaniu takich programów dotyczą ich: niezawodności, szybkości działania, skalowalności. Budowany system ma być wolny od wymienionych wad. Wśród wymagań, stawianych projektowi znajdują się: niezawodność, dobra wydajność i jakość od strony programistycznej. Dostępne oprogramowanie content security, w którego działanie autor miał wgląd, jest w większości stworzone z użyciem języków interpretowanych, takich jak Perl, lub przy pomocy zaawansowanych platform programistycznych, jakimi są.net albo Java. Stosunkowo mało jest aplikacji napisanych w językach kompilowanych wysokiego poziomu, np. w C++. Obecnie istniejące implementacje nie są rozwiązaniami przejrzystymi lub nie w pełni wykorzystują możliwości języka. Tworzone rozwiązanie przyczyni się do wypełnienia tej luki. Ze względu na obiektowy charakter, będzie mogło być łatwo rozbudowane o dodatkową funkcjonalność. 8

9 WSTĘP 3. Zawartość merytoryczna i układ dokumentu Aby stworzyć spójną wizję systemu odrzucającego niechcianą pocztę, zbadano słabe punkty w działaniu protokołu SMTP. W rozdziale pierwszym zaprezentowano jego historię i działanie, ze szczególnym zwróceniem uwagi na jego wady. Ważnym elementem rozdziału jest część poświęcona opisowi struktury wiadomości. W dalszej częsci rozdziału wymieniono i krótko opisano rozszerzenia protokołu, będące odpowiedzią na problemy, jakie rozwinęły się wraz z rozpowszechnieniem się komunikacji z użyciem poczty elektronicznej. Przedstawiono rozszerzenie MIME, definiujace standard tworzenia wiadomości elektronicznych zawierająch załączniki. Celem rozdziału drugiego jest przedstawienie powszechnie stosowanych metod filtrowania zawartości. Zwrócono uwagę na takie aspekty jak: skuteczność, szybkość działania, zużycie zasobów. W rozdziale dokonano krótkiego przeglądu dostępnych narzędzi, które umożliwiają badanie treści przesyłek, z uwzględnieniem ich słabych punktów oraz preferowanych metod walki ze spamem i wyciekiem informacji. Rozdział trzeci przedstawia założenia, przyjęte w stosunku do tworzonego oprogramowania. Spełnienie wymagań jest podstawowym celem projektu, gdyż powoduje, że budowane oprogramowanie będzie się wyróżniało spośród innych aplikacji tego typu. Rozdział uzupełniono o opis przyjętych konwencji konstruowania aplikacji, które stworzone zostały z myślą o tworzeniu czytelnego i łatwego w utrzymaniu kodu. Szczegółowy opis stworzonego rozwiązania oraz implementacji najważniejszych jego elementów zawarto w rozdziale czwartym. Do zrozumienia działania systemu wystarczy zapoznanie się z częścią dotyczącą architektury aplikacji. Dobry pogląd na sposób korzystania z programu daje załączona do rozdziału dokumentacja użytkownika, w której przedstawiono m.in. sposób instalacji programu, tak, aby współpracował z przykładowym serwerem pocztowym oraz wymagania systemowe i sprzętowe. Ostatni rozdział stanowi podsumowanie pracy. Dokonano w nim oceny działania aplikacji, bazując na wynikach szeregu testów. Określono stopień spełnienia postawionych systemowi wymagań. Porównano jakość i funkcjonalność oprogramowania z innymi istniejącymi rozwiązaniami oraz przedstawiono możliwości jego rozwijania. 9

10 Rozdział 1 Protokół SMTP SMTP (ang. Simple Mail Transfer Protocol) to prosty tekstowy protokół komunikacyjny, odpowiedzialny za dystrybucję poczty elektronicznej. Chociaż protokół został stworzony w drugiej połowie lat 70-tych dwudziestego wieku, jest używany obecnie w niewiele zmienionej formie. Zachowane zostały założenia, jakimi kierowano się podczas budowania standardu SMTP. Są nimi: stworzenie nadrzędnego poziomu komunikacji, znajdującego się ponad warstwą protokołów transportowych modelu ISO/OSI, takich jak TCP/IP, który ułatwiałby i ujednolicał przesyłanie poczty elektronicznej, zapewnienie niezawodnej transmisji wiadomości, uproszczenie procesu implementacji aplikacji komunikujących się, założenie, że nadawca listu nie ma powodu oszukiwać odbiorców. Dwa ostatnie założenia sprawiły, że protokół SMTP jest słabo odporny na nadużycia. Bez rozszerzeń nie gwarantuje nawet funkcji uwierzytelniania się klientów przed serwerami pocztowymi. Dlatego stał się najbardziej podatnym na ataki elementem w procesie przetwarzania wiadomości przez systemy pocztowe. Niniejszy rozdział jest wprowadzeniem w historię i zasadę działania protokołu SMTP. Opisano w nim znane wady protokołu SMTP oraz próby ich usuwania za pomocą rozszerzeń protokołu. Szczegółowo zaprezentowano standard MIME, który stworzono z myślą o eliminacji ograniczeń, jakie niesie ze sobą protokół SMTP. Znajomość protokołu MIME jest konieczna do poprawnego zbudowania narzędzia analizującego ciało wiadomości. 10

11 ROZDZIAŁ 1. PROTOKÓŁ SMTP 1.1 Historia SMTP Pomysł przesyłania listów w formie elektronicznej (electronic mail, czyli ) narodził się zanim jeszcze powstały sieci komputerowe. Pierwsze systemy elektronicznej poczty były zaimplementowane na tradycyjnych komputerach typu mainframe. 1 Były to komputery wielozadaniowe z podziałem czasu. Stacje te obsługiwały wielu użytkowników poprzez połączone terminale. Całą obsługą poczty elektronicznej zajmowało się oprogramowanie zainstalowane na komputerze mainframe. Każdy użytkownik posiadał na nim skrzynkę pocztową, będącą katalogiem. Dostarczanie poczty polegało na przenoszeniu wiadomości z jednego folderu do drugiego. Wiadomości można było odczytać, korzystając z programu klienckiego. Poczta elektroniczna rozumiana w sensie, w jakim funkcjonuje obecnie, pojawiła się wraz z Internetem. Internet był efektem ubocznym prac nad stworzeniem i rozwojem sieci ARPAnet. ARPAnet to pierwsza sieć komputerowa, stworzona z inicjatywy Agencji Departamentu Obrony Stanów Zjednoczonych Ameryki Północnej (ARPA). ARPA (ang. Advanced Research Projects Agency), której nazwę uzupełniono później o literę D (DARPA, Defense Advanced Research Projects Agency) została powołana do istnienia w późnych latach 50-tych XX wieku w celu wspierania rozwoju nowych technologii. Agencja powstała w odpowiedzi na potrzebę szybkiego rozwoju technologicznego wojska amerykańskiego w czasie Zimnej Wojny. Bezpośrednią przyczyną jej utworzenia była udana próba wystrzelenia na orbitę pierwszego sztucznego satelity Ziemi Sputnik I w roku Amerykanie, zaniepokojeni sukcesami ZSRR, podjęli dynamiczne kroki w celu usprawnienia obrony oraz osiągnięcia przewagi technologicznej wojska. ARPA zrzeszała badaczy z różnych środowisk naukowych i akademickich. Istniała między nimi potrzeba niezawodnej wymiany informacji i zasobów. Tak powstał pomysł zbudowania sieci ARPAnet, która miała posłużyć do umożliwienia dostępu do usług i programów, istniejących na komputerach, oddalonych od siebie geograficznie. Pierwsze koncepcje sieci polegały na stworzeniu systemu, w którym użytkownik mógłby logować się do zdalnego komputera, na którym pracowały aplikacje lub znajdowały się zasoby, jakich potrzebował. Planiści ARPAnetu mieli nadzieję, że współdzielenie zasobów pozwoli uniknąć wykonywania tej samej pracy przez różnych naukowców oraz że przyczyni się do zetknięcia się nowych pomysłów, co zaowocuje szybszym postępem. Sieć miała więc posłużyć dystrybucji zasobów technicznych. Nie myślano o użyciu jej w celach komunikacji interpersonalnej [przypis]. 1 Należy zaznaczyć, że tamte komputery miały niewiele wspólnego z obecnie używanymi superkomputerami o architekturze mainframe. Nazwa mainframe została od nich zapożyczona ze względu na ich duże rozmiary. 11

12 ROZDZIAŁ 1. PROTOKÓŁ SMTP Pierwsze wzmianki na temat połączenia komputerów w sieć, za pomocą szerokopasmowych linii dostępowych, zawarł w pracy Man-computer symbiosis z 1960 roku [zrodlo] Joseph Carl Robnett Licklider, ówczesny wiceprezes firmy BBN (Bolt, Beranek and Newman, obecnie BBN Technologies). J.C.R Licklider był inicjatorem realizacji pomysłu sieci maszyn, oferującej prosty interfejs komunikacyjny. Pierwszą koncepcję zdecentralizowanej sieci pakietowej przedstawił w 1962r Paul Baran z firmy RAND (Research and Development, obecnie Rand Corporation). Prace nad siecią ruszyły w 1967 roku. Odbyło się wtedy pierwsze Sympozjum Systemów Operacyjnych ACM (ang. ACM Symposium on Operating Systems SOSP) [zrodlo sosp.org], na którym ujawniono pomysły realizacji rozległej sieci komputerowej o rozproszonym zarządzaniu. Na konferencji dyskutowano nad możliwością skonstruowania infrastruktury telekomunikacyjnej, która nie wymagałaby scentralizowanych węzłów komunikacyjnych. Węzły takie mogłyby być łatwym celem potencjalnych ataków. Alex McKenize zaproponował rozwiązanie polegające na przesyłaniu danych wraz z adresem hosta docelowego, które podróżując po sieci, same szukałyby swojego odbiorcy. Tak powstała koncepcja sieci z komutacją pakietów, która miała się później rozwinąć w protokół TCP/IP. Plany zbudowania sieci zaczęły się krystalizować w II połowie lat 70-tych XX wieku. W roku 1968 wydano oficjalny dokument, opisujący schemat budowy sieci 2. Rok później podpisano z firmą BBN kontrakt na budowę fizycznej sieci. Pierwsze na świecie połączenie sieciowe zrealizowano 29 października 1969r pomiędzy Uniwersytetem Kalifornijskim w Los Angeles i ośrodkiem badawczym Stanford Research Institute na Uniwersytecie Stanford w Nowym Yorku. Pierwsza na świecie sieć była gotowa jeszcze w tym samym roku, w którym rozpoczęto jej realizację. Składała się z czterech routerów (których rolę pełniły minikomputery IMP, ang. Interface Message Processors), umieszczonych w lokalizacjach: 1. UCLA (ang. University of California, Los Angeles), Uniwersytet Kalifornijski 2. UCSB (ang. University of California, Santa Barbara), Uniwersytet Kalifornijski 3. SRI (ang. Stanford Research Institute), Uniwersytet w Stanford 4. Uniwersytet w Utah. W latach sieć obejmowała coraz większy obszar. Aby umożliwić wymianę wyników badań poszczególnych ośrodków naukowych, grupa NWG (ang. Network Working Group) opracowała format dokumentu RFC (ang. Request For Comments) [zrodlo rfc 3]. W początkach lat 2 ARPA Program Plan No. 723 Resource sharing computer network, Lawrence G.Roberts 12

13 ROZDZIAŁ 1. PROTOKÓŁ SMTP siedemdziesiątych XX wieku do dystrybucji dokumentów używano list fizycznych adresów hostów. Ich opis można znaleźć w RFC 95, RFC 155. To m.in. potrzeba sprawnego przesyłania biuletynów RFC zmobilizowała twórców TCP/IP do wytężonej pracy nad systemem rozprowadzania poczty elektronicznej. Pierwszym dokumentem opisującym transport był prawdopodobnie RFC 196, wydany w 1971r. Opisano w nim protokół Mail Box. Był to bardzo prymitywny protokół, przeznaczony do przesyłania dokumentów do zdalnych drukarek. Uaktualniano go kilkakrotnie, aż w połowie lat 70 opracowano bardziej uniwersalną metodę implementacji poczty elektronicznej, opartą na protokole FTP. Pierwszy sieciowy wysłano w 1971 roku. Jego twórca Ray Tomlison (inżynier w firmie BBN) przesłał go między dwoma komputerami, połączonymi siecią ARPAnet. List nie posiadał istotnej treści. Jaka była naprawdę nie pamięta nawet sam twórca. Prawdopodobnie zawierała znaki qwertyuiop albo Testing [zródło]. Druga wiadomość elektroniczna w sieci była nieco ciekawsza. Tomlison rozesłał ją do kolegów ze swojego zespołu programistycznego. Ogłosił w niej, że poczta elektroniczna zaczęła istnieć w sieci oraz przekazał instrukcje, w jaki sposób adresować listy do użytkowników z innych hostów. Do oddzielenia nazwy odbiorcy od docelowego adresu hosta użył (małpa). Tomlison nazwał swój program sieciowy SNDMSG (ang. Send Message). Powstał on na bazie dwóch starszych programów: wersji SNDMSG do lokalnej dystrybucji poczty i aplikacji CPYNET (ang. Copy Network) do kopiowania plików w sieci. Lokalny SNDMSG został stworzony jako oprogramowanie na komputery PDP-10 dla środowiska TENEX, które było popularnym systemem operacyjnym z podziałem czasu, rozwijanym przez firmę BBN. SNDMSG służył do wysyłania listów do odbiorców, których skrzynki znajdowały się na lokalnej maszynie. Był prostym edytorem tekstu, który przetwarzał nazwy odbiorców i tekst wiadomości, a następnie dopisywał te informacje do specjalnego pliku, będącego docelową skrzynką odbiorczą. Tomlison połączył funkcjonalność aplikacji z możliwościami programu CPYNET. Pozwoliło to na stworzenie usługi, która przetwarzała pocztę wysyłaną do zdalnych hostów w taki sam sposób, jak do użytkowników lokalnych. Sieciowy SNDMSG kopiował wiadomości z hosta lokalnego na zdalny i dopisywał je do skrzynki pocztowej odbiorcy. Równolegle do SNDMSG rozwijał się program READMAIL (ang. Read Mail). Służył do odczytywania wiadomości. Jedyną usługą, jaką oferował było wyświetlanie kolejnych wiadomości. READMAIL nie wydzielał z listów żadnych metainformacji i, w związku z tym, nie potrafił 13

14 ROZDZIAŁ 1. PROTOKÓŁ SMTP ich w żaden sposób posegregować. Z inicjatywy Lawrence a Robertsa i Steve a Crockera z organizacji IPTO został zmodyfikowany do postaci programu RD (ang. Read). RD poszerzył funkcjonalność programu READMAIL o umiejętność budowania listy wiadomości. Listy te można było indeksować wg tematu lub daty. Użytkownicy mogli od tej chwili porządkować swoje skrzynki pocztowe. Dopisano także funkcje do zapisywania wiadomości w pamięci trwałej oraz usuwania ich ze skrzynek. Barry Wessler dodał do RD możliwość usuwania tylko wybranych wiadomości. Nazwał swój program NRD. Jakiś czas później Marty Yonke zintegrował funkcjonalność programów SNDMSG i NRD w uniwersalny interfejs do wysyłania i odbierania poczty elektronicznej o nazwie WRD, który rozwinął się w program BANANARD. Pomysł Yonke a został poszerzony przez Johna Vittal a z BBN w ramach programu MSG o przekazywanie poczty (forwarding) oraz o tworzenie poprawnie skonstruowanych odpowiedzi na nadesłaną wiadomość. Równocześnie rozwijany był bardziej złożony program do obsługi poczty HERMES. Programy MSG i jego poprzednicy były powszechnie używane w sieci ARPAnet przed rokiem Istnienie tak wielu systemów pocztowych spowodowało podjęcie próby stworzenia standardów, ujednolicających implementację przesyłania i dostarczania poczty w ramach sieci. Początkowo praca ta sprowadzała się do zaadaptowania już istniejących protokołów transportowych, w tym FTP (ang. File Transfer Protocol). Do FTP dodano komendy MAIL i MLFL, służące do transmisji korespondencji . FTP potrafił wysłać oddzielną kopię wiadomości do różnych odbiorców. Używany był mniej więcej do roku 1980, kiedy ukazał się RFC 772, wyjaśniający działanie protokołu MTP (ang. Mail Transfer Protocol). MTP oparto na regułach zapożyczonych z protokołu zdalnego dostępu Telnet oraz z FTP. MTP definiował zbiór komend i procedur za pomocą których dwie maszyny, połączone siecią, mogły się komunikować w celu przekazania sobie poczty. Komendy MTP były praktycznie niezmienionymi komendami FTP. Sformułowanie protokołu MTP jako opakowania dla protokołu FTP spowodowało, że MTP był z założenia ograniczony do możliwości FTP, a przez to trudno go było modyfikować lub rozwijać przez dodawanie usług, specyficznych dla poczty elektronicznej. Potrzebny był protokół, który uniezależniłby schemat wysyłania i odbierania listów od implementacji tego procesu. Standard taki powstał w październiku roku SMTP, zdefiniowany po raz pierwszy w RFC 788 przez Jonathan a B. Postel a, był krokiem milowym w rozwoju poczty elektronicznej. Podstawowe pomysły realizacji dystrybucji przesyłek pocztowych nie zmieniły się od tego czasu do dziś. Postel zawarł w nowym standardzie szczegółowe informacje precyzujące w jaki sposób poczta może być transportowana pomiędzy hostami SMTP bez potrzeby używania FTP ani innych technik 14

15 ROZDZIAŁ 1. PROTOKÓŁ SMTP transferu plików. W RFC 788 opisano metody przesyłania wiadomości rozumianej jako połączenie tekstowej treści i ustrukturyzowanego zbioru nagłówków, zdefiniowane w dokumencie RFC 733. Nazwa (ang. Simple Mail Transfer Protocol) sugeruje, że nowy protokół SMTP był mniej skomplikowany niż jego poprzednik MTP. Z pewnością oferował rozwiązania bardziej jasne i przejrzyste. Został zaprojektowany specjalnie w celu umożliwienia transportu poczty elektronicznej. Mimo, że istnieją w nim pewne zbieżności z FTP, był i jest protokołem niezależnym od konkretnych implementacji protokołów do przesyłania danych. Również sam sposób przesyłania korespondencji w sieci za jego pomocą jest stosunkowo nieskomplikowany, przynajmniej w porównaniu do niektórych protokołów. Protokół SMTP był szeroko używany od lat 80-tych XX wieku. Jednym z pierwszych systemów pocztowych, służących do przechowywania i przekazywania poczty (system typu store-andforward), wykorzystujących SMTP był sendmail. Sendmail autorstwa Erica Allmana z Uniwersytetu Kalifornijskiego, Berkeley, powstał jako oprogramowanie dedykowane dla systemu Unix BSD, rozwijanego w Berkeley. Program wbudowano w i rozprowadzano wraz z systemem operacyjnym BSD Unix. W ten sposób sendmail przyczynił się do rozpowszechnienia SMTP. Protokół SMTP oraz strukturę modelowej wiadomości kilkakrotnie modyfikowano. W 1982 roku David H. Crocker uaktualnił RFC 733 do nowej wersji standardu RFC 822. Po raz pierwszy opisano w nim strukturę nazw domenowych. W tym samym roku Jonathan B. Postel sprecyzował działanie protokołu SMTP w nowym dokumencie RFC 821. W roku 1980 ARPA zdecydowała się oddzielić część wojskową sieci od środowisk akademickich, które nazwały siebie Internetem. Sieć Internet rozrastała się bardzo szybko. Protokół SMTP stawał się najpopularniejszym standardem wymiany korespondencji elektronicznej. Przez szereg lat używano go w niezmienionej postaci. Sytuacja zmieniła się w 1993 roku, kiedy wydano RFC Był to standard, definiujący proces tworzenia nowych usług, rozszerzających funkcjonalność SMTP. Aktualny taki standard opisano w RFC Rozszerzenia nie mogły powodować konfliktów ze starymi wersjami protokołu. Wymaga się od nich zgodności wstecz. SMTP z rozszerzeniami zyskało nazwę ESMTP (ang. Extended SMTP). Stworzenie możliwości dodawania rozszerzeń do SMTP zaowocowało spisaniem szeregu nowych dokumentów RFC, definiujących komendy ESMTP. W roku 1996 powstał standard MIME (ang. Multipurpose Internet Mail Extensions), w którym zaprezentowano sposób na przesyłanie przy pomocy SMTP wiadomości zakodowanych inaczej niż w standardowym zestawie znaków ASCII, 15

16 ROZDZIAŁ 1. PROTOKÓŁ SMTP co umożliwiło przesyłanie za pomocą poczty elektronicznej obrazków, multimediów i innego rodzaju załączników. Nowy standard SMTP zdefiniowano w 2001 roku w RFC Był on rozwinięciem poprzednich standardów, które okazały się niewystarczająco szczegółowe lub zawierały niepraktyczne rozwiązania. Aktualny standard SMTP wydano w październiku zeszłego roku jako RFC W stosunku do RFC 2821 dokonano w nim poprawek edytorskich oraz uszczegółowiono sekcje opisowe. Obowiązującym standardem budowy wiadomości , czyli IMF (ang. Internet Message Format) jest RFC Istnieje ekpserymentalne rozszerzenie IMF do wersji zinternacjonalizowanej. Definiuje je RFC SMTP jest najczęściej stosowanym obecnie protokołem wymiany poczty. Profesor D. J. Bernstein, autor qmaila, stworzył protokół QMTP (ang. Quick Mail Transfer Protocol), który miał zastąpić SMTP. W QMTP usunięto niektóre z ograniczeń lub innego rodzaju problemów SMTP. Choć QMTP nie rozpowszechnił się ze względu na brak zgodności ze swoim poprzednikiem, jest wykorzystywany w praktyce np. przez serwery pocztowe Wirtualnej Polski. 1.2 Komunikacja SMTP Architektura SMTP Jedną z najistotniejszych koncepcji, jaka powstała w procesie tworzenia systemów do dystrybucji poczty elektronicznej, jest wydzielenie dwóch rodzajów usług pocztowych. Jedną z nich jest przesyłanie wiadomości do i pomiędzy serwerami pocztowymi, drugą odbieranie wiadomości przez użytkowników końcowych. Używając porównania do standardowej poczty, inne systemy odpowiadają za rozprowadzanie poczty pomiędzy urzędami pocztowymi (do tego właśnie celu służy SMTP), a inne zajmują się dostarczaniem przesyłek do mieszkańców określonych dzielnic (listonosze to np. pop3 lub imap). Taki podział ma na celu umożliwienie przesłania wiadomości do odbiorców nie podłączonych do Internetu w chwili, gdy był wysyłany. Dzięki temu nadawca (użytkownik lub serwer) może wysłać wiadomość w dowolnym momencie, a odbiorca (użytkownik) odczytać wiadomości z opóźnieniem w stosunku do ich nadania. Do przesłania poczty nie trzeba zestawiać łącza nadawca odbiorca. Achitektura oparta na protokole SMTP wyróżnia kilka rodzajów węzłów komunikacyjnych do wymiany wiadomości. Najważniejsze ich rodzaje to: MUA, MTA i MDA. 16

17 ROZDZIAŁ 1. PROTOKÓŁ SMTP Rysunek 1.1: Schemat architektury SMTP. Nadawca wysyła do odbiorcy 1. MUA (ang. Mail User Agent) współpracuje z użytkownikiem lokalnym. Realizuje: wysłanie wiadomości; przekazuje je do MTA, odebranie wiadomości; dostarcza je do skrzynki lokalnej użytkownika. Przykładowe aplikacje MUA to klienty pocztowe: pine, elm, Outlook, Mozilla Thunderbird i inne. 2. MTA (ang. Mail Transfer Agent) to router wiadomości, odpowiedzialny za logikę transferu i. Do jego funkcji należą: 17

18 ROZDZIAŁ 1. PROTOKÓŁ SMTP przyjęcie wiadomości przesłanej do niego przez MUA lub inny MTA, przesłanie wiadomości do MTA, który zna jej odbiorcę lub wie, jak go odnaleźć, przesłanie wiadomości do MDA, który prześle ją do odpowiedniego MUA na żądanie klienta, za pomocą właściwej metody transportu. MTA określa się inaczej jako serwery pocztowe. qmail, postfix, Novell, Microsoft Exchange. Przykładowe MTA to: sendmail, exim, 3. MDA (ang. Mail Delivery Agent) przechowuje wiadomości do czasu, dopóki nie skontaktuje się z nim klient, który chce je odebrać. Jego zadania to: przyjęcie wiadomości od MTA przechowanie wiadomości, dostarczenie wiadomości do klienta, na jego żądanie. Przykłady MDA: procmail, spamassasin. W założeniu twórców poczty elektronicznej list miał być transportowany przez sieć w niezmienionej postaci. Serwerom MTA nie wolno modyfikować otrzymanych przesyłek. Z MTA wydzielono dodatkową, pośrednią warstwę komunikacji, która przejęła obowiązek odbierania wiadomości od użytkownika lokalnego MUA i dostarczania jej do serwera pocztowego MTA. Warstwa ta to MSA. Agent MSA umożliwia poprawienie wiadomości przed jej wprowadzeniem do sieci. Poprawki dotyczą np. uzupełnienia wiadomości o brakujący wymagany nagłówek Date. MSA może także zgłosić błąd dotyczący niepoprawnej konstrukcji a. Agent MTA, który musi zapewnić niezawodną transmisję, nie mógłby odrzucić wiadomości tylko na podstawie jej błędnej konstrukcji. Wsród wyżej wymienionych warstw protokół SMTP jest wykorzystywany do: przyjęcia poczty od użytkownika (MUA) i przesłania jej do innego serwera (MTA), przyjęcia poczty od jednego serwera (MTA) i przesłania jej do drugiego serwera (MTA). Za pomocą SMTP nie można pobierać wiadomości ze zdalnego serwera. 18

19 ROZDZIAŁ 1. PROTOKÓŁ SMTP Komunikacja między serwerem i klientem SMTP Protokół SMTP jest niezależny od protokołów warstwy sieciowej i transportowej. Do jego implementacji najczęściej stosowany jest protokół TCP/IP. Standardowym portem, na jakim odbywa się komunikacja, jest port 25. Protokół SMTP działa w oparciu o model architektury klient - serwer. Aby przesłać wiadomość, nadawca klient SMTP musi połączyć się z odbiorcą serwerem SMTP. Serwer SMTP powinien nieustannie nasłuchiwać na połączenia od klientów. Wymagane jest, aby potrafił obsługiwać wielu klientów naraz. Klient SMTP to jeden lub więcej procesów, które okresowo próbują przesłać na serwer wiadomości. Jeśli wiadomość nie może zostać wysłana natychmiast, powinna trafić, wraz z informacjami o nadawcy i odbiorcy, do kolejki wiadomości oczekujących na wysłanie. Kolejki takie powinny być cyklicznie przeglądane. Próby wysłania wiadomości oczekującej muszą być podejmowane, dopóki list nie zostanie dostarczony do serwera lub klient nie zrezygnuje. Ten drugi scenariusz następuje standardowo po 4 5 dniach. Klient powinien przechowywać listę hostów, z którymi nie może się połączyć oraz pamiętać przyczyny, dla jakich wysłanie przesyłki zakończyło się porażką. Klient może ustanawiać kilka równolegle działających sesji z serwerami. Jednak jeśli wysyła pojedynczą wiadomość do wielu adresatów, powinien ją kierować do pojedynczego serwera. Klient komunikuje się z serwerem za pośrednictwem ustalonych komend. Serwer przesyła mu w odpowiedzi napis złożony z trzycyfrowego kodu, opcjonalnego napisu wyjaśniającego kod oraz ewentualnych parametrów. Kod przesyłany wraz z odpowiedzią służy do powiadomienia oprogramowania klienckiego o reakcji serwera na żądanie klienta. Pierwsza cyfra informuje, czy odpowiedź jest pozytywna, negatywna lub czy serwer nie oczekuje na doprecyzowanie komendy. Druga cyfra to specyfikacja błędu. Trzecia przekazuje najbardziej szczegółowe informacje o rodzaju i znaczeniu błędu. Żądania i odpowiedzi mają ustaloną kolejność. Serwer musi odpowiedzieć na każde żądanie. Klient nie powinien wysyłać kolejnych komend, jeśli nie otrzymał informacji od serwera (wyjątkiem jest sytuacja, gdy serwer potrafi obsłużyć rozszerzenie protokołu: pipelining). Stroną inicjującą połączenie SMTP jest klient. Serwer w odpowiedzi przesyła klientowi wiadomość powitalną. Następnie klient żąda zainicjowania sesji poprzez wysłanie komendy EHLO (ang. Extended Helo), po której podaje pełną nazwę domeny klienta (FQDN). Każdy serwer powinien umieć obsłużyć polecenie EHLO. Starsze serwery mogą jednak nie rozumieć tej komendy. W takim przypadku klient powinien przywitać się za pomocą komendy HELO (ang. Hello). Po otrzymaniu 19

20 ROZDZIAŁ 1. PROTOKÓŁ SMTP zgody ( 250 OK ), klient może rozpocząć przesyłanie wiadomości. W pierwszej kolejności wysyła polecenie MAIL FROM:<adres>. Adres identyfikuje nadawcę wiadomości. Jeśli serwer nie jest gotowy, wysyła odpowiedź specyfikującą dlaczego działanie nie może zostać zrealizowane. Jeśli serwer działa poprawnie, odpowie 250 OK. Jest to znak dla klienta, że może powiadomić serwer o tym, kim są odbiorcy wiadomości. Korzysta w tym celu z żądania RCPT TO:<adres>. Jeśli wiadomość ma być rozesłana do wielu odbiorców, dla każdego z nich wysyłane jest oddzielne polecenie RCPT TO. Serwer musi potwierdzić gotowość do dalszej transmisji pozytywnym komunikatem. Jeśli przesłano z sukcesem dane wszystkich odbiorców wiadomości, klient wysyła komendę DATA. To znak dla serwera, że za chwilę otrzyma ciąg linii, reprezentujących treść wiadomości. Wiadomość składa się z 7-bitowych znaków ASCII. Jeśli zawiera załączniki, muszą zostać przekonwertowane do takiej postaci. Jeżeli klient otrzymał od serwera odpowiedź gotowości do przyjęcia listu (kod 354), rozpoczyna transmisję danych a. Dane muszą być zakończone znacznikiem end of line, tzn. sekwencją znaków <CR><LF><.><CR><LF>. Po zakończeniu procesu przesyłania treści listu, klient może zainicjować transmisję następnej wiadomości, zakończyć sesję lub zadawać serwerowi pytania. Komenda QUIT, potwierdzona odpowiedzią 221 Closing zamyka sesję. Implementacja SMTP musi obsługiwać co najmniej komendy: EHLO, MAIL, RCPT, DATA, RSET, VRFY, EXPN, HELP, NOOP, QUIT. Opis komend zamieszczono w tabeli Routing wiadomości Serwery pocztowe MTA mogą być serwerami docelowymi na drodze wiadomości lub przekazywać listy dalej innym serwerom. Dzielą się na kilka grup, w zależności od roli, jaką odgrywają w transporcie wiadomości. Przekaźniki pocztowe (ang. relay servers) odbierają wiadomości od klienta SMTP i przekazują je w niezmodyfikowanej postaci do innego serwera SMTP. Bramki SMTP (ang. gateway servers) odbierają wiadomości, dostarczane innym systemem transportu poczty niż ten którym prześlą je dalej, przy czym któryś z tych systemów to SMTP. Gdy serwer SMTP odbierze wiadomość od klienta, bierze odpowiedzialność za dostarczenie listu do odbiorcy. Serwer SMTP może być serwerem docelowym, który zna takiego użytkownika, lub serwerem pośrednim. Wiadomość może przejść przez wiele serwerów w drodze do docelowego MTA. Z reguły ich liczba nie przekracza jednak dwóch. Zapobieganie powstawaniu pętli na drodze wiadomości jest zrealizowane poprez routing wiadomości. Routing, czyli zasady przesyłania wiadomości, definiuje, co stanie się dalej z odebraną przez MTA przesyłką. 20

21 ROZDZIAŁ 1. PROTOKÓŁ SMTP Polecenie EHLO MAIL FROM:<adres> RCPT TO:<adres> DATA VRFY user EXPN list-name HELP NOOP QUIT Tablica 1.1: Polecenia SMTP Opis Za pomocą tego polecenia klient przedstawia się serwerowi informuje go, że potrafi obsługiwać rozszerzenia ESMTP. Prosi serwer o listę rozszerzeń, które są na nim dostępne. Rozpoczyna się nowa transakcja. Serwer powienien wyczyścić swoje wewnętrzne bufory. Klient powiadamia serwer kto jest nadawcą wiadomości. Klient identyfikuje odbiorcę wiadomości. Za chwilę rozpocznie się transmisja ciała wiadomości. Żądanie weryfikacji użytkownika. Obsługa tego polecenia powinna być zablokowana ze względu na ochronę prywatności danych. Żądanie rozwinięcia listy adresów owych. Obsługa tego polecenia powinna być zablokowana ze względu na ochronę prywatności danych. Prośba o wysłanie informacji pomocy. Podtrzymanie połączenia. Serwer powinien odpowiedzieć na tę komendę pozytywnie. Klient kończy połączenie. Zasadniczą rolę w routingu odgrywa system rozwiązywania nazw domen DNS (ang. Domain Name System) [odnosnik]. Istnieją dwa rekordy DNS, używane do rozpoznawania serwerów pocztowych: MX i A. Rekord MX RR (ang. Mail exchanger Resource Record) definiuje, kim jest odbierający MTA. Rekord A RR (ang. Address Resource Record) służy do mapowania w pełni kwalifikowanej nazwy domeny (FQDN, ang. Fully Qualified Domain Name) na adres IPv4. Aby powiązać domenę poczty z nazwą domeny serwera pocztowego, należy ustawić nazwę wskazywaną przez rekord MX domeny poczty na nazwę domeny serwera. Przy próbie odnalezienia adresu serwera, rekord MX wskaże nazwę serwera, która będzie potem mapowana na jego adres. Aby dało się to zrealizować, serwer SMTP musi mieć ustawiony rekord adresu na swój adres IP. Możliwa jest sytuacja, w której domena poczty nie ma ustawionego rekordu MX, a zamiast niego ustawiono rekord A. Wtedy za niejawny, domyślny serwer poczty ( implicit MX ) uznawany jest adres wskazywany przez jej rekord A. Dokumenty RFC 2821 i 5321 uznają ten adres (lub adresy jeśli odczytano listę) za adres IP serwera obsługującego domenę. Z perspektywy klienta SMTP, routing wygląda następująco. Po odczytaniu nazwy domeny odbiorcy listu, MTA, który realizuje teraz funkcję klienta SMTP, wysyła do DNS żądanie przemapowania nazwy domeny na adres fizyczny serwera pocztowego. Nazwa domeny musi być w pełni kwalifikowana. DNS próbuje znaleźć rekord MX powiązany z nazwą. Jeśli odnalazł rekord 21

22 ROZDZIAŁ 1. PROTOKÓŁ SMTP CNAME (ang. Canonical Name), przeszukuje DNS od nowa, tym razem biorąc jako parametr nazwę, będącą wartością rekordu CNAME. Jeśli okaże się, że MTA, który zadał pytanie, jest serwerem obsługującym odbiorcę wiadomości, wiadomość jest dostarczana do jego skrzynki pocztowej. Jeśli MTA nie jest serwerem docelowym, próbuje przesłać wiadomość dalej, do adresu, zwróconego przez DNS. Jeśli DNS zwrócił listę adresów, próbuje wysłać wiadomość do każdego adresu z listy. Adresy te są uporządkowane według priorytetów. Procedura routowania wiadomości jest w rzeczywistości bardziej złożona, ale opiera się na podobnym schemacie. Nie są dozwolone inne formy routingu. RFC 5321 uznaje wcześniej dozwolony trace-routing za przestarzały. 1.3 Rozszerzenia protokołu SMTP został stworzony, aby zapewnić wydajny i niezawodny transport wiadomości. Umożliwia przesyłanie wiadomości przy pomocy prostego interfejsu. Ma jednak zasadniczą wadę. Po wysłaniu listu, nadawca nie otrzymuje żadnej informacji na temat dostarczenia przesyłki. Standard 5321 przewiduje powiadomienie nadawcy o porażce, jeśli wystąpił błąd transmisji i wiadomość nie mogła być dostarczona. Do adresu, spod którego wysłano , jest w takim przypadku dostarczany specjalny list. Jednak standard nie definiuje żadnej konkretnej formy takich wiadomości i z reguły nie niosą one dość informacji, aby nadawca mógł poprawnie ustalić co spowodowało błąd. Standaryzacja powiadomień o błędach pojawiła się dopiero jako rozszerzenie protokołu. Od czasu powstania protokołu SMTP powstało wiele jego rozszerzeń, składających się na ESMTP (ang. Extended SMTP), czyli rozbudowany SMTP. Większość służyła ułatwieniu procesu przesyłania poczty elektronicznej. Część była odpowiedzią na braki protokołu. SMTP jest protokołem prawie trzydziestoletnim. Jego twórcy nie przewidzieli problemu spamu. Dlatego SMTP nie oferuje żadnych metod uwierzytelniania nadawcy listu. W efekcie łatwo znaleźć w Internecie serwery MTA przekazujące pocztę nadesłaną przez dowolnego klienta. Są to tzw. serwery open relay, które nie zabezpieczają się w żaden sposób przed nieautoryzowanym dostępem. Stają się łatwym celem dla spamerów. Wprawdzie problem open relay wynika z błędów konfiguracji MTA, które zwykle popełniają niedoświadczeni administratorzy, a które stosunkowo łatwo wyeliminować, nawet kilka dni pracy serwera w takim trybie może przynieść wiele szkód. W dodatku korespondencję elektroniczną łatwo sfałszować. Najprostszym sposobem na wysłanie 22

23 ROZDZIAŁ 1. PROTOKÓŁ SMTP Tablica 1.2: Polecenia ESMTP Polecenie Opis AUTH (ang. Authenticated SMTP) Mechanizmy uwierzytelnienia klienta SMTP. Klient uwierzytelnia się za pomocą loginu i hasła, zakodowanych za pomocą kodowania base64. DSN (ang. Delivery Status Notification) Powiadamianie o statusie doręczenia wiadomości. ETRN (ang. Extended Turn) Żądanie natychmiastowego przekazania przechowywanych listów do podłączającego się serwera. PIPELINING (ang. Command Pipelining) Wysyłanie i obsługę kilku żądań na raz. CHUNKING i komenda BDAT Przesyłanie ciała wiadomości partiami. STARTTLS (ang. Start Transport Bezpieczne przesyłanie danych przy pomocy Layer Security) metody TLS ang. Transport Layer Security). SIZE Określenie całkowitej wielkości wiadomości. 8BITMIME Wsparcie dla kodowania wiadomości na ośmiobitowych znakach. RESTART Wznowienie przesyłania wiadomości po zerwaniu sesji. niechcianej poczty jest przekazanie jej przez serwer open relay z podaniem nieprawidłowych adresów zwrotnych. Do wad SMTP należy także zaliczyć brak zabezpieczeń w czasie transmisji danych. Rozszerzenia ESMTP usuwają niektóre z tych braków. Najbardziej popularne krótko opisano w tabeli Struktura wiadomości Standardowy format przesyłki jest zdefiniowany w standardzie RFC 2822, uzupełnionym i zaktualizowanym przez RFC Wiadomości, przesyłane protokołem SMTP, składają się tak jak tradycyjne listy, z koperty i zawartości. Na kopertę składają się adres nadawcy i lista adresów odbiorców. Adres nadawcy jest przesyłany nie tylko po to, aby odbiorca znał autora listu. Pod ten adres serwery pośredniczące w transmisji przesyłki przesyłają informacje o błędach. Z informacji zawartych w kopercie wiadomości, korzystają wszystkie węzły architektury SMTP. Zawartość wiadomości jest zbudowana ze zbioru nagłówków i treści, oddzielonej od nich białą linią. Treść jest opcjonalna. Pola nagłówka są przeznaczone do interpretacji dla MUA. Wiadomość składa się z linii. Linia to ciąg znaków, zakończony sekwencją CR LF, czyli znakiem powrotu karetki (kod ASCII: 13) i znakiem nowej linii (kod ASCII: 10). Długość linii nie 23

24 ROZDZIAŁ 1. PROTOKÓŁ SMTP powinna przekraczać liczby 80 znaków, wliczając w to znaki CR LF. Linia nie może składać się z więcej niż 1000 znaków. Nagłówki dzielą się na ustrukturyzowane i nie. Oba rodzaje są zbudowane wg tego samego schematu: Po nazwie nagłówka występuje znak dwukropka, a bezpośrednio po nim tekst nagłówka. Ustrukturyzowane nagłówki należą do kilka podstawowych grup. Nagłówki typu adres są reprezentowane np. przez From, To, Cc. Adresy w nich zawarte są zbudowane z części lokalnej, identyfikującej skrzynkę pocztową użytkownika adresu, i domeny, w której użytkownik posiada skrzynkę. Części są rozdzielone (małpa). W dalszej części dokumentu adresy tego typu będą określane jako adresy pojedyncze. Nagłówki mogą przechowywać listy adresów pojedynczych. Do tej grupy pól można wliczyć także nagłówki do reprezentacji identyfikatora wiadomości lub list takich identyfikatorów. Identyfikator jest bowiem definiowany tak samo jak pojedynczy adres, przy czym w miejsce części lokalnej wstawiany jest unikalny tekst, wyróżniający list, zaś domeną jest domena, w jakiej znajduje się maszyna, która wygenerowała identyfikator. Jeśli nie zrobi tego MUA, zostaje opatrzony identyfikatorem przez pierwsze MTA, do jakiego zostanie skierowany. Identyfikatorem wiadomości najczęściej staje się data i czas przesłania jej przez MTA dalej. Reprezentantem nagłówków typu data jest Date. Data określona w polu Date nie musi pokrywać się z faktyczną datą napisania wiadomości. Jeśli program pocztowy kolejkuje wiadomości, będzie się ona różnić od daty wysłania listu. Nagłówki, specyfikujące trasę, jaką odbyła wiadomość, np. Received, mają własną specjalną konstrukcję. Zostanie opisana w dalszej części rozdziału. Ostatnią grupą nagłówków o określonej strukturze są nagłówki MIME, złożone z list parametrów, np. Content-Type. Parametr to nazwa i wartość. Nagłówki nie ustrukturyzowane są zbudowane z sekwencji znaków. Mają znaczenie informacyjne. Przykładem nagłówka bez struktury jest Subject. Można definiować własne nagłówki, których nazwa zaczyna się od sekwencji X-. Takie nagłówki będą traktowane przez systemy pocztowe jako nie ustrukturyzowane. Jedynymi nagłówkami, które muszą wystąpić w poprawnie zbudowanej wiadomości, są Date i From. W dodatku [odnosnik] zamieszczono obowiązującą gramatykę, opisującą strukturę wiadomości i jej nagłówków. Szczególnie istotne dla diagnozowania problemów w transporcie listów elektronicznych, są nagłówki trasy. Każdy MTA, przez który przejdzie w swojej drodze do odbiorcy wiadomość, dodaje na jej początku pojedynczy nagłówek Received. Pierwszy MTA, który otrzymał wiadomość, jest wymieniony w ostatnim nagłówku Received. Pole to określa kiedy odebrano wiadomość, 24

25 ROZDZIAŁ 1. PROTOKÓŁ SMTP kto ją odebrał (wymagana jest nazwa i IP hosta), od kogo została odebrana (jak poprzednio). Na podstawie tych informacji można określić, na którym etapie transportu, wystąpił błąd. Ostatni MTA, który odpowiada za dostarczenie przesyłki do odbiorcy, lub pełni rolę bramki do innego systemu transportu elektronicznego, dodatkowo dodaje do wiadomości nagłówek Return-Path. Zamieszcza w nim informacje, które otrzymał od klienta w poleceniu MAIL FROM, specyfikujące nadawcę wiadomości. Pole Return-Path określa do kogo ma zostać wysłana wiadomość z informacją o błędzie w razie napotkania problemu z dostarczeniem poczty. Utworzenie takiego listu zwrotnego określa się jako odbicie wiadomości do nadawcy. MTA, który odbił wiadomość, ustawia jej Return- Path na pustą wartość. Zapobiega w ten sposób tworzeniu się pętli wiadomości odbitych od już odbitych wiadomości. Dzięki informacjom o trasie można wykryć prymitywne próby sfałszowania listu. Mają one miejsce, gdy klient serwera wysyłającego wiadomość przedstawia się serwerowi odbierającemu nazwą, której DNS nie potrafi powiązać z jego adresem IP. Pierwotnie tekst nagłówków i treści mógł składać się wyłącznie ze znaków US ASCII zakodowanych na 7 bitach. Wraz z pojawieniem się rozszerzenia MIME (ang. Multipurpose Internet Mail Extensions), został wzbogacony o możliwość przesyłania danych binarnych oraz znaków diaktrycznych Standard MIME Standard MIME wprowadzono w 1996 roku. Jest on rozszerzeniem specyfikacji konstrukcji wiadomości z RFC Standard składa się z zestawu dokumentów RFC , uzupełnionego później o RFC 2112, 2183 i inne. Rozszerzenie MIME wprowadziło: możliwość przesyłania w korespondencji znaków kodowanych na więcej niż 7 bitach, w tym danych binarnych i znaków narodowych, definicję nowych pól nagłówkowych, zaczynających się ciągiem znaków Content- oraz nagłówek MIME-Version, określający, że wiadomość spełnia wymagania standardu, możliwość dodawania do listu załączników, w tym zagnieżdżonych wiadomości. MIME zniosło ograniczenia listu związane z używaniem w treści wyłącznie 7-bitowego kodowania ASCII. Zapis danych na 7 bitach był wystarczający w początkach istnienia poczty elektronicznej, 25

26 ROZDZIAŁ 1. PROTOKÓŁ SMTP Tablica 1.3: Typy encji MIME Kategoria typu Typ danych Podtyp danych Podstawowy text plain, html, enriched Podstawowy image jpeg, gif Podstawowy audio basic Podstawowy video mpeg Podstawowy application octet-stream, post-script Złożony multipart mixed, alternative, parallel, digest Złożony message rfc822, partial, external-body kiedy posługiwali się nią wyłącznie Amerykanie. Alfabet angielski oraz znaki kontrolne dało się bowiem zapisać w zakresie 128 znaków. Z chwilą, gdy Internet, razem z pocztą elektroniczną, objął inne państwa, pojawiła się potrzeba poprawnego przesyłania znaków diaktrycznych. Do ich zapisu używano większej ilości bitów 3, dlatego potrzebne było zdefiniowanie metod konwersji do 7-bitowego ASCII. MIME dostarczyło dwóch takich technik: quoted printable i base64. Quoted printable służy do kodowania wiadomości składających się przede wszystkim z tekstu ASCII. Pozostałe znaki są zapisywane jako sekwencje =xx, gdzie x to znaki w reprezentacji oktalnej. Base64 dokonuje przekodowania całego tekstu wejściowego. Konwertuje każde trzy kolejne znaki, złożone w sumie z 24 bitów po 8 bitów na znak, na cztery 6-cio bitowe liczby. Powstałe w ten sposób liczy są mapowane na znaki drukowalne z zakresu A-Za-z0-9+/. Oprócz wymienionych MIME definiuje trzy dodatkowe sposoby kodowania wiadomości: 7bit na oznaczenie standardowego kodowania US ASCII, 8bit dla danych zapisanych w bajtach i binary dla danych binarnych. Kolejną nowością, jaką zaproponowano w standardzie MIME było określenie typu zawartości listu. Wiadomość mogła odtąd zawierać w sobie złożone struktury, w tym inną wiadomość. W ten sposób został zdefiniowany jako hierarchia elementów. Podstawową jednostkę tej hierarchii nazwano encją. Encja to wiadomość w sensie RFC 822, złożona z nagłówków i ciała. Typ takich encji określono jako prosty. Encjami są również struktury, zawierające w sobie inne encje, czyli encje złożonego typu. Dzięki zastosowaniu typów do wiadomości można było dodać załączniki, w postaci plików przesyłanych razem z listem. W tabeli 1.3 przedstawiono podstawowe typy MIME. Każda encja posiada własny (być może domyślny) typ zawartości, opisywany przez specjalny nagłówek Content-Type. Pole Content-Type, oprócz informacji o zawartości encji, zawiera parametr specyfikujący napis, który będzie wydzielał z tekstu wiadomości części składowe encji. Napis ten nazwano boundary. Ciało encji zaczyna się tuż po pierwszym wystąpieniu w tekście sekwencji znaków z boundary, poprzedzonej dwoma znakami myślnika: -- boundary, a kończy sekwencją 3 Najdłuższymi znakami świata są litery alfabetu chińskiego. Do reprezentacji niektórych potrzeba aż 21 bitów. 26

27 ROZDZIAŁ 1. PROTOKÓŁ SMTP znaków -- boundary --. Jeśli encja składa się z kilku sekcji, rozdzielone są one liniami - - boundary. Standard MIME definiuje również inne typy nagłówków, m.in Content-Transfer-Encoding dla oznaczenia użytego kodowania. Wraz z późniejszymi rozszerzeniami takimi jak dodanie nagłówka Content-Disposition, pozwala na budowanie i poprawne rozpoznawanie przez systemy pocztowe bardzo skomplikowanych struktur wiadomości. Standard MIME nie określa żadnych metod zabezpieczenia przed fałszowaniem informacji zawartych w liście. Dla przykładu możliwa jest sytuacja, gdy typ encji jest sprzeczny z jej zawartością. Jeśli Content-Type określa typ załączonego do wiadomości niebezpiecznego pliku jako nieznany, użytkownik może przez przypadek zainstalować wirus. Dlatego stworzono nowy standard S/MIME (ang. Secure Multipurpose Internet Mail Extensions), który definiuje w jaki sposób zabezpieczać korespondencję przy użyciu metod kryptograficznych. Proponuje szyfrowanie wiadomości algorytmem RSA z użyciem klucza publicznego. W praktyce szyfrowanie poczty jest wykorzystywane tylko przez duże firmy. Trwają prace nad umożliwieniem pełnej internacjonalizacji treści przesyłek pocztowych. We wrześniu 2008 roku wydano RFC 5335, będący rozszerzeniem standardu RFC Rozszerzenie nosi nazwę UTF8SMTP. Dokument ma status eksperymentalny. Zezwala ono klientom serwerów, obsługujących UTF8SMTP, na przesyłanie tekstu nagłówków zakodowanego kodowaniem Unicode (ang. Universal Character Set), zamiast standardowego US ASCII. Wykorzystywany jest format UTF-8 (ang. 8-bit Unicode Transformation Format). 27

28 Rozdział 2 Content security 2.1 Potrzeba filtrowania wiadomości Nieścisłości lub luki w standardach SMTP i MIME są znane od kilku lat. Mimo powstawania nowych metod walki z nimi, problemem pozostaje zmieniający się sposób ich wykorzystywania przez hakerów i spamerów. Np. aktualnymi trendami w rozpowszechnianiu spamu są: ataki ukierunkowane na konkretną grupę odbiorców, informacje o których zbierane są przez analizę ich ruchu pocztowego, spam obrazkowy, coraz mniej popularny spam w załącznikach o rozszerzeniu pdf, spam w wiadomościach odbitych. 1 Spamerzy często wykorzystują wirusy do rozsyłania niepożądanych informacji. Z drugiej strony, spam jest używany do rozpowszechniania w sieci wirusów. Pomijając aspekt niebezpieczeństwa, jakie ze sobą niesie, przeglądanie niepożądanej poczty wiąże się ze stratą czasu, co, w przypadku pracowników firm, przekłada się na stratę pieniędzy. Niepożądanymi zjawiskami, które wiążą się ze spamem, są tzw. phishing i joe-job. Phishing (inaczej spoofing) polega na fałszowaniu danych nadawcy wiadomości. Można w ten sposób utajnić prawdziwą tożsamość hosta wysyłającego list lub podszyć się pod godną zaufania instytucję 1 Spamerzy zakładają konta na darmowych portalach pocztowych. Konfigurują ich autorespondery tak, aby w odpowiedzi na przychodzące wiadomości, rozsyłały spam. Następnie wysyłają do tych adresów sfałszowane listy. Nadawcy, pod których adresy podszyli się, podczas wysyłania listu, spamerzy, dostają wiadomość zwrotną zawierającą niechcianą treść. 28

29 ROZDZIAŁ 2. CONTENT SECURITY np. w celu wyłudzenia poufnych informacji. Najprostszą formą phishingu jest zmiana adresu w poleceniu MAIL FROM. Joe-job to wysyłanie listów z adresu sfałszowanego w taki sposób, aby spam obciążył niewinną osobę. Problemy spamu i phishingu zniknęłyby wraz z wprowadzeniem wiarygodnej metody uwierzytelniania nadawców. Podejmowano próby zdefiniowania takiej metody. Niestety żadna ze znanych autorowi, nie jest w pełni bezpieczna, a jeśli zapewnia wysoki poziom bezpieczeństwa, wymaga zmiany istniejącej infrastruktury systemów pocztowych. Najpopularniejsze metody uwierzytelniania nadawcy listu elektronicznego to: SPF, Sender ID, DomainKeys, TEOS, CSV, przy czym SPF ma zdecydowanie najwięcej zwolenników. Używana jest np. przez serwery SMTP domen interia.pl i gazeta.pl. SPF (ang. Sender Policy Framework, pierwotnie Sender Permitted Form) polega na sprawdzeniu, czy host, próbujący wysłać list, ma uprawnienia do wykorzystania adresu, jakim się posługuje. W tym celu MTA wysyła do DNS zapytanie, które serwery mogą korzystać z domeny, którą nadawca podał w kopercie wiadomości. Informacje te mogą być zapisane w rekordach TXT (Text) DNS-u, jeśli dana domena publikuje rekordy SPF. SPF, choć popierana przez wielu użytkowników poczty, ma zatwardziałych przeciwników. Podstawową wadą tej metody jest jej niezgodność ze standardem dystrybucji poczty (RFC 2821). Metoda SPF opiera się na błędnym założeniu, że będą z niej korzystać wszystkie komunikujące się strony. Ponadto wymaga, aby użytkownik poczty korzystał z serwera SMTP, należącego do jego dostawcy pocztowego. Dla przykładu: mimo, że SMTP zezwala na wysyłanie poczty przez nadawcę przykladowy@gmail.pl za pośrednictwem serwera w domenie gazeta.pl, obsługujący SPF serwer pocztowy, do którego trafi przesyłka, odrzuci ją, ponieważ adres, podany w kopercie, nie jest zarejestrowany w rejestrach SPF domeny gazeta.pl. Z opisanym problemem wiąże się uniemożliwienie przekierowywania poczty przed jej dostarczeniem. Naiwnym rozwiązaniem tej niedogodności jest SRS (ang. Sender Rewriting Scheme), który polega na przepisaniu adresu nadawcy w kopercie listu przez serwer przekierowujący. Nowy adres składa się ze starego adresu i adresu serwera przekierowującego. Wystarczy kilka przekierowań i liczba znaków w polu MAIL FROM wykracza poza dozwoloną liczbę sześćdziesięciu czterech. SPF może przysłużyć się do ograniczenia phishingu. Nie proponuje jednak żadnego rozwiązania problemu spamu. Ponadto dyskryminuje pocztę przychodzącą z niechronionych domen, narażając serwery na odrzucanie pożądanych przesyłek, co jest niezgodne z ideą SMTP. Mimo tak istotnych wad, SPF jest dość szeroko stosowane. Popularność zawdzięcza w dużym stopniu firmie Microsoft i jej projektowi Sender ID, opartemu na SPF. Sender ID rozbudowuje ideę SPF o sprawdzanie nagłówków samej wiadomości (From, Sender itd). 29

30 ROZDZIAŁ 2. CONTENT SECURITY Inną możliwość autoryzacji nadawcy proponuje Yahoo!. Opracowane prze nie rozwiązanie nosi nazwę DomainKeys i jest dość podobne do SPF. Tak samo jak SPF opiera się na usługach DNS. Wprowadza jednak dodatkowy poziom bezpieczeństwa, wymagając podpisywania wiadomości wychodzących z serwera pocztowego za pomocą kluczy asymetrycznych algorytmów kryptograficznych. Podpis umieszczany jest w specjalnym nagłówku: DomainKeys-Signature. Obsługa szyfrowania listów obciąża w dość dużym stopniu serwery pocztowe. CSV (ang. Certified Server Validation) to proste zabezpieczenie przed modyfikacjami wiadomości. Adres IP hosta łączącego się z serwerem MTA jest sprawdzany z nazwą domeny, podaną przez niego w poleceniu HELO lub EHLO. CSV korzysta w tym celu z informacji podawanych przez DNS. Warto w tym miejscu wspomnieć, że protokół DNS nie jest bezpiecznym protokołem. Stosunkowo łatwo sfałszować rekordy serwerów DNS. Oprócz wymienionych, istnieje jeszcze jeden sposób na zabezpieczenie wiadomości przed sfałszowaniem. Definiuje go projekt TEOS (ang. Trusted Open Standard). TEOS proponuje wprowadzenie kilku dodatkowych poziomów sprawdzania integralności przesyłki. Celowi temu miałoby służyć m.in. wprowadzenie specjalnych cyfrowych certyfikatów, razem z którymi przesyłana byłaby poczta, oraz uzupełnienie funkcji serwerów pocztowych o mechanizmy do badania jej poprawności. TEOS nie przyjął się, ponieważ wymaga zmian w infrastrukturze SMTP. Mimo podejmowania prób uzupełnienia protokołu SMTP o funkcje zapewniające bezpieczeństwo przesyłanej poczty, zjawisko spamu jest powszechne. Jedyną możliwością rozpoznawania niepożądanych przesyłek jest filtrowanie poczty. Ponieważ nie da się go wbudować w interfejs serwerów pocztowych, a żadne z możliwych rozszerzeń funkcjonalności MTA nie przyjęło się w skali całego Internetu, wiadomości muszą być klasyfikowane za pomocą specjalnie do tego przeznaczonego oprogramowania. Stosowane są różne metody identyfikowania wiadomości. Warto wspomnieć o czarnych listach nadawców spamu DNSBL, odrzucaniu wiadomości od nierozpoznanych hostów, czyli greylisting u oraz o systemie challenge - response (CR), który polega na wysyłaniu żądania potwierdzenia nadania listu do klienta, przesyłającego . Najlepsze wyniki osiągane są, gdy powyższe techniki połączy się z kontrolą treści korespondencji elektronicznej. Badanie zawartości wiadomości wraz z inspekcją jej nagłówków nosi nazwę content security. 30

31 ROZDZIAŁ 2. CONTENT SECURITY 2.2 Metody filtrowania zawartości Analiza treści listu elektronicznego polega na sprawdzeniu czy nie występują w nim prawidłowości, pozwalające zaklasyfikować go do pewnej z góry określonej grupy. Najczęściej wyróżnia się spam, wiadomości zawierające złośliwy kod, wirusy itp. oraz wiadomości prawidłowe. Pierwszą historycznie metodą, jaką stosowano do filtracji poczty, była prymitywna analiza językowa. Polegała ona na wyszukiwaniu w treści przesyłki konkretnych wyrażeń. Początkowo przeglądano wiadomość pod kątem występowania w nagłówkach znanych adresów nadawców niechcianej poczty oraz pojawiania się w jej treści fraz, ewidentnie oznaczających spam. Niedługo później pojawiły się filtry porównujące treść listu z przesyłkami, tworzonymi przez znanych spamerów. Powstawały bazy danych słów i wyrażeń kojarzonych ze spamem, na podstawie których pierwsze filtry dopasowywały wiadomości do wzorca spamu. Współczesną wersją tego sposobu jest filtrowanie przez znakowanie listu. Na każdej otrzymanej wiadomości wykonywane są pewne określone obliczenia. Ich wyniki porównuje się z bazą znanych wiadomości spam. Pod koniec lat 90-tych dwudziestego wieku zaczęto stosować filtrowanie heurystyczne. Kieruje się ono zbiorem reguł. Reguły określają na podstawie jakich cech rozpoznawać wiadomość jako spam oraz jakie cechy musi mieć wiadomość poprawna. Filtry heurystyczne wyszukują w wiadomości charakterystyczne wzorce. Możliwe jest budowanie zaawansowanych reguł, które dają większe możliwości podejmowania decyzji. Jednym z pierwszych programów, który zaimplementował filtr heurystyczny, był SpamAssasin. Innego rodzaju techniką są filtry adaptacyjne. Do identyfikowania spamu używa się sieci wywiadowczej, np. zbioru danych leksykalnych, opisujących jego cechy. Najbardziej zaawansowane filtry to filtry Bayesa. Umożliwiają rozpoznawanie typu wiadomości na podstawie wyszukiwania słów kluczowych. Są uznawane za najbardziej skuteczne. Filtr Bayesa opiera się na regułach prawdopodobieństwa. Wzór Bayesa ma postać: P ( T i X ) = P (T i)p ( X T i ) P (X) (2.1) Oznaczenia: P (T i ) - prawdopodobieństwo, że wiadomość jest spamem. P (T i X) - prawdopodobieństwo, że wiadomość jest spamem, pod warunkiem, że pojawia się w niej wyraz X. 31

32 ROZDZIAŁ 2. CONTENT SECURITY P (X T i ) - prawdopodobieństwo wystąpienia wyrazu X w spamie. P (X) - prawdopodobieństwo wystąpienia wyrazu X w wiadomości. Filtry Bayesa trzeba nauczyć rozpoznawania spamu. Nauka polega na podaniu im na wejściu kolekcji wiadomości poprawnych oraz listy wiadomości niepożądanych. Filtr wyznacza prawdopodobieństwo wystąpienia w wiadomości prawidłowej oraz prawdopodobieństwo wystąpienia w spamie każdego przetwarzanego wyrazu. Po nadejściu do tak przygotowanego filtru nowego listu, umie on obliczyć prawdopodobieństwo, że list należy do którejś z wymienionych grup. Skuteczność filtrów Bayesa sięga 99% dla wiadomości tekstowych. Spam zawarty w obrazkach można wykryć przy pomocy narzędzi OCR (ang. Optical Character Recognition). Do metod filtrowania zawartości należy także zaliczyć: blokowanie załączników określonych typów, blokowanie części wiadomości zakodowanych określonymi typami znaków (charset), filtrowanie tekstu zakodowanego przy pomocy html lub JavaScript, w którym może być ukryty złośliwy kod. Funkcjonalność aplikacji, implementujących content security nie sprowadza się wyłącznie do standardowych metod badania treści wiadomości. Oprogramowanie content security realizuje następujące funkcje: kontroluje, czy klient skonstruował wiadomość zgodnie ze standardem SMTP / MIME, umożliwia sprawdzenie, czy klient podał prawidłowe pola nagłówkowe koperty wiadomości, bada, czy nagłówki wiadomości zostały skonstruowane wg reguł określonych w odpowiednim dokumencie RFC, analizuje treść nagłówków wiadomości, treść samej wiadomości oraz jej załączników (stosując któreś z opisanych wyżej metod, np. wyszukując słowa kluczowe), kontroluje rozmiar wiadomości i jej załączników, rozpoznaje typy załączników, 32

33 ROZDZIAŁ 2. CONTENT SECURITY klasyfikuje wiadomości jako poprawne i niechciane, dokonuje odpowiednich akcji na wiadomościach, w zależności od grupy, do której zaklasyfikowano przesyłkę. 2.3 Przegląd dostępnego oprogramowania, realizującego funkcję content security Na rynku IT znajduje się wiele systemów filtrowania poczty elektronicznej. Dostępne są zarówno kompleksowe zestawy narzędzi do zabezpieczania oprogramowania w obrębie całych sieci lokalnych, jak i oprogramowanie dedykowane na pojedyncze komputery klienckie. Większość aplikacji wchodzi w skład płatnych pakietów. Spośród znanych lub ciekawych pod względem wykonania aplikacji, warto wymienić produkty: Clearswift MIMESweeper, Aladdin esafe Mail, Sophos Security And Control, SurfControl Mail Filter i SpamAssasin. Poniżej omówiono niektóre z nich. Clearswift MIMESweeper to część większego systemu zabezpieczeń, stworzonego do ochrony infrastruktury sieciowej całych przedsiębiorstw. Oprogramowanie można zainstalować na maszynie dedykowanej do tego celu, w strefie DMZ bez połączenia z internetem lub na serwerze SMTP. MIMESweeper oferuje funkcjonalność w zakresie: analizy ruchu SMTP, blokowania poczty z określonych hostów, ochrony antyspamowej, realizowanej przez połączenie wyszukiwania wzorców z filtrami Bayesa i listami RBL, skanowania antywirusowego załączników, blokowania lub usuwania załączników określonego typu, rozpoznawanego wg zawartości pliku, klasyfikowania wiadomości przychodzących i wychodzących i być może blokowania lub usuwania ich, archiwizacji wiadomości, przechodzących przez obsługiwaną sieć, innych zastosowań. 33

34 ROZDZIAŁ 2. CONTENT SECURITY Oprogramowanie firmy Clearswift zrealizowano w architekturze, złożonej z niezależnych warstw. Należą do nich moduły: monitorowania ruchu sieciowego, odbierania wiadomości, dostarczania listów odbiorcom, klasyfikowania przesyłki, śledzenia zdarzeń w systemie, obsługi konfiguracji, tworzenia raportów i audytów. MIMESweeper to oprogramowanie, realizujące założenia, na których wzorowano się przy tworzeniu autorskiego rozwiązania. Aladdin esafe Mail to kompleksowe oprogramowanie do zabezpieczania poczty elektronicznej przedsiębiorstwa. Podobnie jak MIMESweeper oferuje skuteczną ochronę przed spamem, wirusami, złośliwym kodem, spoofingiem oraz atakami hakerskimi na serwery. W dziedzinie badania zawartości przesyłki , Aladdin esafe Mail łączy metody filtrowania heurystycznego, znakowanie wiadomości i sprawdzanie sygnatur listów. Narzędzie oparto na silniku Dual-Engine Security, który potrafi uwierzytelniać nadawcę i klasyfikować przesyłane przez niego wiadomości w czasie rzeczywistym. SpamAssasin to darmowy program open-source do badania zawartości listu . Najczęściej konfiguruje się go do współpracy z silnikiem antywirusowym np. clamav. SpamAssasin jest jednym z najstarszych narzędzi filtrujących pocztę. Analiza wiadomości jest wynikiem połączenia metod wyszukiwania słów i fraz kluczowych, filtrowania Bayesa, sprawdzania zgodności adresów nadawców z czarnymi listami DNS oraz porównywania listu z bazami danych spamu. SpamAssasin nie potrafi usuwać ani przekierowywać spamu. Nie przekazuje przesyłki dalej. Służy wyłącznie do klasyfikowania wiadomości. Klasyfikacja ma postać nadania wiadomości punktów, które określają prawdopodobieństwo, z jakim wiadomość jest spamem. Interpretacja wyniku należy do zewnętrznych programów. 34

35 Rozdział 3 Założenia projektowe tworzonego systemu Stworzenie aplikacji, dorównującej funkcjonalnością opisanym w poprzednim rozdziale narzędziom wykracza poza ramy tej pracy. Każde z nich było rozwijane przez lata przez specjalistów. Projektowany system ma jednak wyróżniać się spośród dostępnego oprogramowania jakością i czystością rozwiązania. Dlatego postawione mu wymagania oraz przyjęte na początku procesu jego tworzenia założenia zostały sformułowane w taki sposób, aby umożliwić zaimplementowanie 3.1 Wymagania funkcjonalne 1. Rozpoznawanie struktury poleceń SMTP i odpowiednia reakcja na ich błędy. 2. Przechwytywanie wiadomości przekazywanych przez protokół SMTP. W systemie będzie się odbywało na poziomie protokołu SMTP (proxy aplikacyjne). 3. Wydzielanie z wiadomości nagłówków, właściwej treści i załączników i przechowywanie ich w wygodnej do przeglądania formie. Wymagana jest umiejętność dekodowania i kodowania części wiadomości. 4. Filtrowanie wiadomości. Będzie wykonywane na podstawie reguł zapisanych w postaci wyrażeń regularnych w pliku XML. Każda wiadomość będzie analizowana pod kątem każdej reguły i oceniana względem stopnia jej spełnienia. Suma z wystawionych ocen stworzy końcową ocenę wiadomości. 5. Klasyfikacja wiadomości. Wiadomości mogą trafić do grup: listów pożądanych, spamu, który powinien trafić do kwarantanny lub zagrożeń, przeznaczonych do usunięcia. 35

36 ROZDZIAŁ 3. ZAŁOŻENIA PROJEKTOWE TWORZONEGO SYSTEMU 6. Logowanie zdarzeń w celu wykrycia nieprawidłowości. 7. Przechowywanie wiadomości i innych danych w plikach. 3.2 Wymagania niefunkcjonalne 1. Stabilność i niezawodność System powinien zapewniać niezawodną pracę. Należy zrealizować obsługę wyjątków w celu reagowania na niespodziewane błędy. Wymagana jest poprawna reakcja na problem wyczerpania się pamięci. 2. Odporność na dane niezgodne z protokołem SMTP / MIME (określana przez pliki konfiguracyjne) System powinien być maksymalnie odporny na dane wejściowe, tzn. powinien przyjmować do analizy dowolne wiadomości. 3. Wydajność Podstawą wydajnej pracy będzie stabilny, szybki parser wiadomości. Aby zminimalizować konieczność powolnego dostępu do dysku twardego, wiadomości będą przechowywane w pamięci dopóki nie zakończy się proces ich przetwarzania. 4. Praca w środowisku linuksowym 5. Przejrzysta i jasna konstrukcja Zostanie zrealizowana poprzez podzielenie pracy na odrębne moduły, odpowiadające za konkretne zadania. 6. Czytelny, spójny, łatwy w utrzymaniu kod 3.3 Ograniczenia zakresu realizacji zadania System będzie obsługiwał protokół SMTP w formie podstawowej (nie ESMTP). Nie będą używane dodatkowe programy antywirusowe do badania załączników. Nie zostanie zaimplementowane filtrowanie Bayesa. Wymienione punkty, z których zrezygnowano przy tworzeniu obecnej wersji oprogramowania, zostaną dołączone do projektu, jeśli zostanie czas na ich realizację. 36

37 Rozdział 4 Projekt i implementacja filtru System jest zaimplementowany w języku C++ jako oprogramowanie dla środowisk linuksowych. Działa jako wielowątkowe proxy aplikacyjne. Przechwytuje ruch pomiędzy klientem SMTP a serwerem SMTP. Po odebraniu wiadomości, poddaje ją analizie i w zależności od jej wyniku, przesyła dalej lub wstrzymuje. Komunikacja z klientami i serwerami SMTP oraz przetwarzanie wiadomości zostały zrealizowane jako oddzielne wątki. Poprawność działania wątków kontroluje nadzorca (ang. Watch Dog). Wątki potrafią komunikować się z nim za pomocą komunikatów. Projekt składa się z kilku warstw, realizujących oddzielne funkcje systemu. Kod źródłowy poszczególnych części umieszczono w osobnych katalogach jak przedstawiono w tabeli 4.1.Wszystkie komponenty są zawarte we wspólnej przestrzeni nazw kc_sf, żeby ich nazwy nie kolidowały z innymi bibliotekami. Szczegółowa dokumentacja programistyczna w formacie HTML została umieszczona na płycie CD-ROM, dołączonej do pracy. 4.1 Architektura aplikacji System składa się z komunikujących się, ale niezależnych modułów: 1. moduł przechwytujący wiadomości (Receiver), 2. parser (Parser), 3. filtr zawartości (Filter), 4. klasyfikator wiadomości, inicjujący wykonanie akcji na wiadomości (Action Taker), 5. moduł wysyłający wiadomość do innego hosta (Sender), 37

38 ROZDZIAŁ 4. PROJEKT I IMPLEMENTACJA FILTRU Katalog config filter logs mime parser smtp system utils Tablica 4.1: Struktura katalogów projektu Opis Klasy do odczytu i interpretacji pliku konfiguracyjnego. Filtr zawartości listu oraz klasy określające reguły, na podstawie których ustala on akcję do wykonania na wiadomości. Obsługa dziennika zdarzeń. Struktura MIME wiadomości. Skaner i parser wiadomości oraz pomocnicze klasy do reprezentacji struktur wydzielanych przez skaner z tekstu. Wielowątkowy serwer oraz klient SMTP oraz pomocnicze klasy udostępniające niskopoziomowy, obiektowy interfejs do komunikacji TCP/IP przy pomocy gniazd BSD. Klasa wątku kontrolującego działanie całego systemu (Watch Dog). Klasy i funkcje ogólnego zastosowania, często używane w innych częściach systemu. Klasy kontenerowe: słownik obiektów, reprezentowanych przez nazwę, wektor. Interfejs uniwersalnych operacji do przekształcania napisów: zmiana wielkości liter, porównywanie napisów bez uwzględniania wielkości znaków, odnajdywanie wzorca w tekście, zmiana strony kodowej napisu. 6. moduł zapisujący wiadomość na dysku (Serializer), 7. Watch Dog (WD), 8. moduł do zapisywania zdarzeń związanych z przetwarzaniem wiadomości (Logger), 9. todo moduł do wysyłania wiadomości, przy których nie system nie mógł uzyskać połączenia z serwerem docelowym lub takie połączenie zostało zerwane (Resender). Moduły parsera, filtru i klasyfikatora realizują właściwą funkcjonalność systemu. Moduł Resender oznaczony napisem todo jest planowany do dodania do kolejnej wersji systemu. Na nadchodzące wiadomości czeka Receiver. Po odebraniu przesyłki, umieszcza ją w wejściowej kolejce wiadomości i powiadamia o tym zdarzeniu za pomocą specjalnej komendy WD. WD przenosi wiadomość do własnej wewnętrznej kolejki oraz próbuje zainicjować jej przetwarzanie. Jeżeli liczba wątków w systemie przekroczyłaby dozwoloną ilość, WD nie robi nic. Zostanie pobudzony do działania, gdy któryś z wątków przetwarzających zakończy działanie albo jeśli otrzyma powiadomienie o nadejściu nowej wiadomości. Jeśli w systemie nie działa zbyt dużo wątków, WD tworzy nowy wątek do analizy zawartości listu. Badanie zawartości wykonywane jest w następującej kolejności: 1. moduł parsera: 38

39 ROZDZIAŁ 4. PROJEKT I IMPLEMENTACJA FILTRU Rysunek 4.1: Podstawowe moduły systemu sprawdza wiadomość pod kątem poprawności, ewentualnie dokonuje drobnych poprawek w jej strukturze wydziela z wiadomości istotne dla dalszej analizy informacje powiadamia WD o wyniku pracy za pomocą specjalnej komendy 2. moduł filtra: sprawdza czy reguły filtru określone w pliku konfiguracyjnym są spełnione przez wiadomość ustala typ akcji, jaką należy wykonać na wiadomości powiadamia WD o wyniku pracy za pomocą specjalnej komendy 3. moduł podejmowania akcji ActionTaker: w zależności od wyniku działania filtru, próbuje wykonać określoną przez niego akcję: 39

40 ROZDZIAŁ 4. PROJEKT I IMPLEMENTACJA FILTRU a.) jeśli wiadomość ma zostać przesłana dalej, przekazuje ją do modułu wysyłającego (Sender) z powiadomieniem WD b.) jeśli wiadomość została oznaczona jako przeznaczona do usunięcia lub kwarantanny, przekazuje ją do modułu do serializacji (Sender) i powiadamia o tym WD 4.a moduł wysyłający Sender: próbuje wysłać wiadomość do adresata przesyła do WD informację o wyniku próby 4.b moduł zapisujący wiadomość na dysku Serializer: tworzy w określonych w konfiguracji katalogach na dysku pliki, do których zapisuje tekst wiadomości jeśli wiadomość trafiła do kwarantanny, tworzy skojarzony z nią plik, zawierający wydzielone przez parser informacje o strukturze wiadomości WD po odebraniu komunikatu od modułów przetwarzających wiadomość, odnajduje wiadomość w kolejce i oznacza ją odpowiednią flagą. Wiadomość nie jest usuwana, aż WD otrzyma informację, że przetwarzanie zostało ukończone (wiadomość wysłano lub zapisano na dysku) albo gdy moduł wysyłający powiadomi go, że nie może dostarczyć wiadomości. Jeśli tak się stanie, wiadomość jest zapisywana na dysku w wyznaczonym katalogu wiadomości niedoręczonych. Podczas pracy systemu, jeśli nie konfigurowano inaczej, zdarzenia zachodzące w systemie mogą być zapisywane w określonych plikach w pamięci trwałej. Zajmuje się tym Logger singleton, kontrolujący dostęp do pliku lub plików zdarzeń. Logger rozróżnia kilka poziomów ważności zdarzeń: NOTHING, FATAL, ERROR, INFO, DETAIL i ALL. 4.2 Obsługa protokołu SMTP Obsługa sesji SMTP Aplikacja działa jak proxy pośredniczące w komunikacji między lokalnym nadawcą poczty a siecią zewnętrzną lub między nadawcami z Internetu przesyłającymi wiadomości do lokalnych serwerów 40

41 ROZDZIAŁ 4. PROJEKT I IMPLEMENTACJA FILTRU bądź użytkowników. Wobec klienta, który połączył się z nią, staje się serwerem SMTP. Wobec serwera, z którym nawiązała połączenie, przyjmuje rolę klienta. Jako serwer SMTP potrafi poprawnie rozpoznawać żądania SMTP i niektóre komendy ESMTP oraz odpowiadać na nie w prawidłowy sposób. W przypadku napotkania nieznanej komendy lub polecenia o budowie niezgodnej z RFC 5321[odnosnik], zwróci odpowiedni kod błędu. Do obsługiwanych komend należą: HELO, EHLO, MAIL FROM, RCPT TO, DATA, NOOP, RSET, QUIT. Serwer SMTP przyjmuje wszystkie wiadomości. Zgodnie z dokumentami RFC[odnosnik], gwarantuje w ten sposób klientowi, że jest w stanie je dostarczyć. Decyzja o odrzuceniu lub przesłaniu przesyłki do docelowego serwera zostaje podjęta dopiero po przeanalizowaniu całej wiadomości. Dlatego nawet jeśli serwer podejmie decyzję o usunięciu wiadomości, klient nie będzie o tym wiedział. Rysunek 4.2: System jako proxy aplikacyjne Gdy odebrana wiadomość zostanie zaklasyfikowana jako przeznaczona do przesłania dalej, system nawiązuje połączenie z prawdziwym serwerem SMTP. Udając przed nim klienta, przesyła mu wiadomość. Klient SMTP zna i potrafi zinterpretować odpowiedź na komendy: EHLO, HELO, MAIL FROM, RCPT TO, DATA, QUIT. Funkcję serwera SMTP pełni moduł Receiver. Podstawowe informacje o każdej przechwyconej wiadomości (takie jak: informacje z pól envelope, data otrzymania wiadomości) są zapamiętywane w logach systemu w pamięci trwałej. Otrzymana wiadomość jest zapisywana w pamięci RAM w kolejce wiadomości. Jeśli wiadomość jest poprawna, co zostanie sprawdzone na etapie obsługi 41