Walczymy ze spamem

od redakcji: Tonid próbuje opracować koncepcję skutecznego systemu pomagającego w walce ze spamem. Za jego zgodą przedrukowujemy wstępną koncepcję, którą opublikował na swoim blogu. Przy okazji zapraszamy naszych czytelników do podzielenia się swoimi uwagami i pomysłami. Mamy nadzieję, że dzięki temu 7thGuard stanie się nie tylko serwisem informacyjnym, lecz również miejscem, w którym można podyskutować na temat swoich projektów…

Od kilku dni zastanawiam się nad koncepcją stworzenia systemu antyspamowego łączącego pewne zalety serwerów DNSBL i systemów rozproszonych takich jak Vipul’s Razor czy Pyzor, przypominającego rozwiązanie proponowane przez firmę Mujica. Założeniem tego systemu byłoby określenie reputacji danego adresu IP na podstawie raportów zgłaszanych przez użytkowników. Chciałbym podzielić się z Wami swoimi pomysłami oraz poprosić o opinie.

Najważniejsze wady tradycyjnych DNSBL-i, które ten system miałby pomóc ominąć, to:

• Agresywność. Większość DNSBL-i działa na zasadzie, że jeśli z adresu IP przyszedł choć jeden spam, to adres jest dodawany do bazy. Takie rozwiązanie gwarantuje sporą skuteczność, ale jednocześnie może powodować nadmierną liczbę fałszywych alarmów (czyli przypadków odrzucenia niewinnego listu). Przez to serwery DNSBL nie nadają się do zastosowań firmowych. Jest bowiem zbyt duże prawdopodobieństwo, że zostanie odrzucony ważny list.
• Automatyzacja. Wiele DNSBL-i zbudowanych jest w oparciu o automaty, np. tzw. „spamtrapy”, czyli adresy e-mailowe przeznaczone do wychwytywania spamu. Z adresów tych nie korzysta żaden człowiek, istnieją tylko po to by spam na nie przychodzący był automatycznie analizowany i by adres IP z którego przyszedł mógł zostać dodany do bazy.
• Stronniczość. Niektóre DNSBL-e prowadzone są przez jedną osobę, lub zespół osób który decyduje o tym, jaki adres znajdzie się w bazie a jaki nie. W związku z tym istnieją podejrzenia o stronniczość prowadzących, może też zaistnieć sytuacja konfliktu interesów.
• Trudność usunięcia adresu z bazy. W wielu przypadkach, nawet jeśli błąd komputera powodujący możliwość wykorzystania go do rozsyłania spamu został naprawiony, usunięcie adresu IP z bazy jest trudne i wymaga sporo zachodu.
• Karanie niewinnych. W przypadku adresów przyznawanych dynamicznie, często ktoś kto „odziedziczył” dany adres po spamerze (lub komputerze wykorzystanym przez spamera) odkrywa, że jego adres jest blokowany przez niektóre serwery.
• Niewielka skuteczność przy adresach dynamicznych. Po dodaniu dynamicznie nadawanego adresu IP do bazy może okazać się, że już po paru godzinach spam wychodzi z innego adresu (tego samego komputera, ale o innym adresie). Musi więc zostać ponownie wychwycony i dodany do bazy. Z kolei dodawanie do bazy ogromnych zakresów IP należących do dostawców skutkuje karaniem niewinnych (w tym często stałych adresów IP w tym samym zakresie, jak to ma miejsce np. w przypadku Neostrady i Internet DSL).

Moja propozycja miałaby przynajmniej spróbować zniwelować powyższe wady, opierając się na istniejących koncepcjach, ale składając je w jedną, spójną całość. Byłaby to rozproszona sieć zgłaszających powiązana z centralnymi serwerami DNSBL. Coś w rodzaju Spamcopa, ale w trochę innym wydaniu. Założeniem byłaby łatwość użycia dla każdego, możliwość zbudowania w oparciu o ten system własnej bazy, a także możliwość częściowej automatyzacji (bez efektów ubocznych).

Element 1: mechanizm analizy listów — „mailnalyzer”

Zadania mailnalyzera byłyby następujące:

• Przyjmowanie na wejściu listów w formatach:
  • forwardu listów w standardzie MIME,
  • załączników do regularnego listu (w formacie .msg lub .eml),
  • listów przesłanych za pomocą funkcji takich jak „Redirect” czy „Bounce”.

  Miałoby to na celu umożliwienie zgłaszania zarówno użytkownikom dojrzałych, porządnych programów pocztowych (które oferują opcję przesłania listu dalej), a także użytkownikom popularnych i niedoskonałych programów takich jak Outlook Express (poprzez forwardowanie). Umożliwiłoby to też częściową automatyzację tego procesu, np. zgłaszanie listów wcześniej przetworzonych i zaklasyfikowanych przez filtr bayesowski (jak bogofilter).

• Zwracanie wyniku w postaci jednego adresu IP, czyli adresu z którego nasz serwer pocztowy przyjął list.

Bardzo ważną kwestią byłoby zbudowanie tego analizatora tak, aby brał pod uwagę możliwość redirectowania (bounce’owania) listów, a więc by np. nie zwracał adresu naszego serwera lokalnego (przez który został przekierowany list), tylko faktycznego nadawcy spamu. Program mógłby zostać napisany w dowolnym języku, ale najlepiej nieinterpretowanym. Sam zastanawiam się, czy nie napiszę takiego programu w przyszłości (jeśli będę mógł) w OCAML-u w ramach zaliczenia jednego przedmiotu (OCAML powinien się do takich zastosowań w miarę dobrze nadać, nieprawdaż?).

Element 2: klient zgłaszający — „maileporter”

Zadania maileportera byłyby następujące:

• Przyjmowanie na wejściu adresu IP „wyłuskanego” przez mailnalyzera oraz informacji, czy adres jest odpowiedzialny za spam czy za ham.
• Uzyskiwanie z bazy IP WHOIS zakresu, do którego należy ten adres.
• Uwierzytelnianie w wybranym serwerze zgłoszeń (skonfigurowanym przez użytkownika).
• Przekazywanie zgłoszenia do serwera (zakresu IP uzyskanego z serwera WHOIS oraz informacji, czy z tego zakresu przyszedł spam, czy ham).
• Nie zwracanie niczego na wyjściu.

Nie mam jeszcze pomysłu na to, jakiego protokołu użyć do uwierzytelniania i przekazywania zgłoszenia. Może udałoby się użyć XMPP? Użytkownik musiałby zarejestrować się w serwerze XMPP służącym tylko do odbierania zgłoszeń, a następnie mógłby wysyłać te zgłoszenia ze swojego JID. Unikniętoby w ten sposób tworzenia nowego protokołu i umożliwiono przyszłą współpracę innych programów (dzięki otwartemu protokołowi). Przy okazji, zarówno serwer jak i klient mogłyby korzystać z gotowych bibliotek, co z pewnością ułatwiłoby ich oprogramowanie.

Element 3: serwer przyjmujący dane — „maileceiver”

Zadania maileceivera byłyby następujące:

• Nieprzyjmowanie żadnych informacji na wejściu lokalnym.
• Przyjmowanie z sieci zgłoszeń wysyłanych tylko przez uwierzytelnionych użytkowników.
• Przekazywanie na wyjściu zgłoszonego zakresu IP oraz informacji, czy zgłoszenie dotyczy spamu czy hamu.

W przypadku użycia serwera XMPP, mógłby to być plugin lub transport do serwera, czy też rozszerzenie/modyfikacja istniejącego serwera. Jedynym zadaniem tego elementu byłoby działanie jako interfejs między siecią zgłaszających a systemem lokalnym.

Element 4: baza danych zgłoszeń — „mailatabase”

Zadania mailatabase byłyby następujące:

• Przyjmowanie na lokalnym wejściu zakresu IP oraz informacji, czy zgłoszenie dotyczy spamu czy hamu.
• Jeśli zakres nie istniałby w bazie, dopisanie go.
• Jeśli zakres istniałby w bazie, odpowiednie zwiększenie licznika otrzymanych z niego listów będących spamem lub hamem.
• Jeśli zgłoszony zakres nie istniałby w bazie, ale istniałby zakres szerszy, automatyczne zdublowanie/rozdzielenie większego zakresu (np. jeśli dostawca wprowadził podział we WHOIS).
• Jeśli zgłoszony zakres nie istniałby w bazie, ale istniałby zakres węższy, automatyczne dopisanie pozostałego zakresu do bazy i podniesienie licznika dla obu (istniejącego i nowego).

System mailatabase mógłby być zrealizowany na dowolnej bazie danych. Możnaby więc stosować różne systemy w zależności od potrzeb (ważne, by sposób przekazywania parametrów przez maileceiver był stały, czyli np. zakres IP w formie X.X.X.X/X, a po spacji 0 jeśli ham, a 1 jeśli spam).

Element 5: serwer DNSBL — „mailacklist”

Zadania mailacklist byłyby następujące:

• Regularne (w niewielkich odstępach czasu, określonych przez administratora) pobieranie aktualnych informacji z bazy danych mailatabase.
• Dla każdego zakresu IP w bazie określanie procentu otrzymywanego z niego spamu i hamu (na podstawie ilości zgłoszeń zapisanych w bazie).
• Budowanie na podstawie tych informacji strefy (lub stref — patrz: poniżej) zawierającej adresy IP odpowiadające zakresom znajdującym się w bazie.
• Publikowanie tej strefy (lub str
  ef) w formacie stosowanym przez serwery DNSBL.

Tu pojawiłby się drobny problem. Jak bowiem przekazać klientowi DNSBL informacje o tym, jaki procent maili z danego adresu IP to spam, a jaki to ham? Proponowałbym to rozwiązać w następujący sposób:

• Stworzyć główną strefę, np. global.dnsbl.nowhere.com, w której przechowywane byłyby wszystkie adresy IP z bazy i na zapytanie zwracać odpowiedź w formacie 127.0.0.X, gdzie X byłoby liczbą od 1 do 101 (aby nie zwracać zera), odpowiadającą procentowi otrzymanych spamów + 1. Tak więc odpowiedź 127.0.0.33 ze strefy global.dnsbl.nowhere.com oznaczałaby, że 32% listów otrzymanych z zakresu do którego należy ten adres IP było spamem.
• Ponieważ jednak nie wszystkie implementacje klientów DNSBL są w stanie rozróżniać uzyskiwane odpowiedzi (niektóre opierają się tylko na tym, czy adres jest listowany, czy nie), dodatkowo stworzyć strefy 0.dnsbl.nowhere.com do 100.dnsbl.nowhere.com, w których przechowywane byłyby tylko i wyłącznie adresy IP należące do zakresów o danym lub większym procencie spamów (a zwracana byłaby zawsze odpowiedź 127.0.0.1). W ten sposób klient DNSBL korzystający ze strefy 50.dnsbl.nowhere.com uzyskiwałby informacje o adresach IP, które należą do zakresów, z których przychodziło 50 lub więcej procent spamu.

System mailacklist mógłby być zrealizowany jako interfejs współpracujący np. z serwerami BIND i rbldns (część djbdns), aby uniknąć konieczności oprogramowania serwera DNS.

Zalety rozwiązania

Taka implementacja serwera DNSBL miałaby moim zdaniem wiele zalet:

• Dawałaby jego użytkownikom możliwość samodzielnego decydowania, jaki poziom spamów z danego adresu IP uznają za dopuszczalny, by przyjmować z niego listy.
• Gwarantowałaby, że adresy nadawane dynamicznie byłyby traktowane w uczciwy sposób (czyli na podstawie wpisów we WHOIS — jeśli niedopracowanych przez dostawcę, to winny listowania zbyt szerokiego zakresu byłby tylko sam dostawca, który mógłby te wpisy po prostu zmienić aby przestały być listowane niewinne adresy).
• Nie wymagałaby pracy administratora (przygotowywania spamtrapów, ręcznego dopisywania czy usuwania adresów, reagowania na prośby o wypisanie itp.).
• Dawałaby możliwość łatwego „wypisania się” z DNSBL-a poprzez… wysyłanie maili nie będących spamem z danego IP (aby zmniejszyć procentowy stosunek spamu do hamu).
• Byłaby łatwa w użyciu również dla użytkowników Outlook Expressa. Ich lokalny administrator mógłby założyć adres do zgłaszania spamu, na który musieliby jedynie forwardować listy.
• Dawałaby możliwość stworzenia wielu serwerów, np. dla lokalnych społeczności.

Bardzo proszę o komentarze, uwagi dotyczące koncepcji, sugestie poprawek. Jeśli ktoś chciałby taką implementację zacząć sam tworzyć, prosiłbym o kontakt w tej sprawie. Bardzo chętnie doradzę, ewentualnie pomogę koncepcyjnie (w chwili obecnej niestety nie programistycznie).
Archiwalny news dodany przez użytkownika: tonid.
Kliknij tutaj by zobaczyć archiwalne komentarze.