Postanowiłem dzisiaj wyłowić spośród dziesiątków spam emaili jeden, który chciałem przeanalizować. Oto wyniki.
Zaczynamy od góry nagłówków wiadomości.
Return-Path: < This@geminis.com>
To jest adres zwrotny, w normalnej poczcie elektronicznej to jest adres nadawcy, w spamowej to adres najczęściej losowy, często z losowymi znakami alfabetu przed znakiem at (@). Natomiast domena istnieje, oto rezultat zapytania whois:
domain: GEMINIS.COM
[wycięte]
nserver: DNS1.CELEONET.COM
nserver: DNS2.CELEONET.COM
[wycięte]
person: Szkolnik Delphine
organisation: CELEONET SARL
address: 55 rue Boissonade
address: Paris, 75 75014
adresse: FR
phone: 0610508497
fax: 0140476505
[wycięte]
Czyli, póki co jesteśmy w Paryżu. Następna linia:
Received: from host83-103.pool8290.interbusiness.it (host83-103.pool8290.interbusiness.it [82.90.103.83]) by mail5.servage.net (Postfix) with ESMTP id 82A10121002F for ; Thu, 7 Dec 2006 08:22:43 +0000 (GMT)
De facto były to 3 linie, skompresowałem i zmieniłem co trzeba było zmienić, by w oczy nie kłuło (spamerów oczywiście). Z tej linii wynika, że serwerem pocztowym był host host83-103.pool8290.interbusiness.it o adresie IP 82.90.103.83. Sprawdźmy więc gdzie ten serwer się znajduje (po domenie można się sugerować, że we Włoszech):
inetnum: 82.88.0.0 - 82.91.255.255
org: ORG-TIWS1-RIPE
netname: IT-TIWS-20030506
descr: Telecom Italia Wireline Services
descr: PROVIDER
country: IT
[wycięte]
org-name: Telecom Italia Wireline Services
org-type: LIR
address: VIA DI VAL CANNUTA 250
address: 00166
address: Rome
address: Italy
phone: +39 06 36881
fax-no: +39 06 36885566
[wycięte]
Czyli póki co, serwer pocztowy we Włoszech wysłał do mnie pocztę z adresu zarejestrowanego przez podmiot we Francji.
Następna linia (znów 3 skompresowane do jednej i odpowiednio ocenzurowane):
Received: from UVYU (unknown [163.195.62.120]) by geminis.com with ESMTP id E8B896877714 for ; Thu, 7 Dec 2006 09:23:29 +0100 (GMT)
Sprawdźmy to IP, bo nazwa hosta UVYU raczej routowalną FQDN nie jest, a bardziej wygląda jak host windowsowy (o tym nieco niżej).
inetnum: 163.195.0.0 - 163.195.255.255
netname: CPA
descr: Cape Provincial Administration
descr: Wale Street
descr: Cape Town 8000
country: ZA
admin-c: JE2-AFRINIC
tech-c: JE2-AFRINIC
status: ASSIGNED PI
mnt-by: TF-163-195-MNT
mnt-lower: TF-163-195-MNT
[wycięte]
person: John Engelbrecht
address: Cape Provincial Administration
address: Wale Street
address: Cape
address: Town
address: 8000
address: US
phone: +27 21 462 2780
[wycięte]
Witamy w Republice Południowej Afryki, w budynkach administracji rządowej (jak można wnioskować po nazwie rejestratora). Zanim przejdę do wniosków, chciałbym jeszcze zerknąć na kilka pozostałych linii, a w szczególności:
Message-ID: < 000c01c719d8$e7bb2360$00000000@Puntok>
i
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Opierając się na RFC definiującego Message-ID można przypuszczać, że Puntok to nazwa hosta z którego email został wysłany. Natomiast wspomniana powyżej nazwa UVYU równie dobrze może być nazwą hosta lub nazwą losową. To co jest pewne to sygnaturka Microsoft Outlook Express 6.0 jako program pocztowy, z którego spam został wysłany.
Podsumowanie
Z komputera, na którym działał Outlook Express 6.0, o nazwie Puntok i adresie 163.195.62.120, znajdującego się w Republice Południowej Afryki poprzez serwer pocztowy o nazwie host83-103.pool8290.interbusiness.it o adresie 82.90.103.83 została wysłana wiadomość pocztowa, której nadawcą była osoba powiązana z podmiotem w Paryżu.
Wnioski
Systemy antyspamowe oparte na blacklistach adresów pocztowych w odniesieniu do tej analizy są kompletnie chybionym rozwiązaniem. Z powyższego wniosku widać, że adres nadawcy może być kompletnie losowy - najważniejsze są: adres IP nadawcy i adres IP serwera SMTP, przez który wiadomość została wysłana. Widać tutaj dokładnie, że jeśli prawie pewnym jest, że serwer SMTP był niedostatecznie zabezpieczony, ew. był to system na którym działało oprogramowanie typu malware będące silnikiem SMTP (mógłbym się o tym przekonać dość szybko skanując porty komputera), o tyle system z którego wiadomość została zapoczątkowana był na pewno używany przez malware (wnioskując choćby po specyfice instytucji, choć i tu zapewne może być sytuacja odmienna).
Przeanalizowałem dzisiaj 7 wiadomości, które były spamem. Oto sumaryczne zestawienie wnisków:
- 6 wiadomości zostało wysłanych z użyciem Microsoft Outlook 2003/Outlook Express 6.0
- 1 wiadomość pochodziła z The Bat!
- we wszystkich przypadkach serwerem SMTP był serwer u publicznego providera Internetu (jak powyżej Telecom Italia), jednym z nich była Telekomunikacja Polska S.A.
- w jednym z przypadków na 100% jestem pewien, że serwerem SMTP był Windows (prawdopodobnie w wersji desktop), jako że jego nazwą było billgates
- w kolejnym przypadku jestem prawie w 100% pewien, że serwerem była maszyna linuxo-podobna (charakterystyczne localhost.localdomain dla nieskonfigurowanej instalacji)
Naukę wyciągnijcie sami.
Eee… no to jestem w ostrej kropce. W 6 na 7 przypadków nie używać Windows? Gdzie Ty pracujesz ponoć?
BTW, jedną z fajniejszych rzeczy widziałem w sieci publicznej fińskiego dostawcy netu. Pozwalał na połączenia smtp tylko w fi, nie puszczając portu 25 poza własną sieć. Dzięki temu mnóstwo spambotów było skazanych na porażkę… ale to wciąż nie jest to. Dopóki nie zmieni się smtp, wymuszając jakiegoś typu autoryzację, spf czy inne coś (oczywiście zostawiając bezpłatnoć poczty) to spam nadal będzie miał się dobrze, niestety.
@vermin: gratuluje nowego pakietu!
A co do analizy, to nie twierdze by windowsow nie uzywac, a jedynie byc swiadomym zagrozen i sie przed nimi odpowiednio zabezpieczac. gdyby ta ogranizacja rzadowa w RPA miala filtr na ruch wychodzacy zalozony na porcie 25 problemu by nie bylo. Linux w rekach osob nie majacych wyobrazni moze stac sie rownie dobra maszynka do rozsylania spamu.
Dziękować
Co do linuxa - nie powiedziałbym dobrą - lepszą!
Bo o ile MTA w windows natywnie pojawił sie dopiero w 2k3sp1 to w linuxach od dawna był w standardowej instalce… (jakby procmail sobie nie potrafił poradzic w sytuacji lokalnego mail delivery, no)
Tak więc zgodzę się, że każdy system jest wrażliwy i kazdy źle skonfigurowany system popełnia błędy (nawet ISA w złej konfiguracji padnie). No ale jeśli protokół jest defective by design, to cóż… Swoją drogą to dziwne, że np. SNMP ewoluuje i wspiera w końcu (v3) autoryzację i parę innych bajerów a SMTP jakoś nie bałdzo…
Analiza analiza, a kolega zapomnial, ze naglowki mozna sobie konstruowac dowolnie i wedle uznania. Szczegolnie gdy kontroluje sie “serwer” SMTP. Pierwszy “Received from” dodawany przez “serwer” wcale nie musi wskazywac na hosta, z ktorego mail wyszedl. To raz.
Dwa, to “user agent”. Spamerzy dodaja ten naglowek aby obejsc filtry, ktore usuwaja wiadomosci bez niego, lub z nie pasujacym do zadnej ze znanych sygnatur.
Trzy, to cala reszta.
Jedynym w miare skutecznym rozwiazaniem jest graylisting, ktory zreszta stosuje Servage. Na podobnej zasadzie dziala postgrey (http://isg.ee.ethz.ch/tools/postgrey/), ktory odbija mail do nadawcy z informacja o tymczasowym bledzie. Znakomita wiekszosc spamerskich serwerow nie sprobuje ponownie dostarczyc wiadomosci, choc zgodnie z RFC tak sie stac powinno. Po jakims czasie mail usuwany jest z kolejki i ostatecznie konczy w /dev/null.
Inny prosty sposob: wymuszanie sciagniecia poczty, przed wyslaniem. Wiekszosc MUA tak dziala “by design”. Problem w tym, ze nie dziala to w przypadku hubow pocztowych (posrednikow), ktore z reguly o POP3/IMAP nie wiedza.
Ptashek: są dwa warianty - wysyłanie i odbieranie
Odbieranie, cóż, greylisting to nie jest idealne rozwiązanie - niektóre normalne serwery nie są zgodne z RFC i pomijają coś takiego. Ponadto wyobraź sobie klimat, że wysyłam pocztę, kolejka na serwerze przebiega circa co godzinę - więc godzinę czekam na maila (ale ja już do Państwa wysłałem) np. z danymi do oferty, gdzie trzeba dane do przetargu złożyć za kwadrans… Ciekawe kto zapłaci za straty. Ponadto znowuż zgodnie z RFC poczta do lokalnego konta powinna zostać zaakceptowana (de facto wszelkie filtry to już RFC łamanie ;-))
Jeśli chodzi o wysyłanie, to co do POP-before-SMTP to jasne, ryzyko dużo mniejsze. Wspiera to nawet Outlook 2003. Niemniej to także otwarcie się na świat, (ograniczam się tylko do IP na określony czas - ale jednak). Najlepsza tu jest autoryzacja - i to jest jedyne wyjście. Nawet przy SPF - gdyby każda domena coś takiego miała i jednocześnie odrzucalibyśmy pewne adresy IP, to co szkodzi zarejestrować domenę buhaha.spam.jetst.ok.cc dodac do niej spf i rozsyłać SPAM? A jutro nazwać ją podobnie? I oczywiście przekierować na dowolnego przejętgo hosta? SMTP jest po prostu wadliwe.
Im dłużej przy tym grzebie tym bardziej zdaje sobie sprawę, że podobnie jak chwastów, tego do końca wyplenić się nie da. Czysty internet? To se ne wrati Pane Havranek
Jesli chodzi o greylisting jest to najlepsze rozwiazanie jakie dotad widzialem, a ze wprowadza opoznienie w dostarczeniu maila… coz, jestem to w stanie przelknac jesli bede mial czysto w skrzynce. SPF mnie nie przekonuje i wg. mnie w sumie nic nie wnosi, z powodow ktore wlasnie wymieniles. Pewnie za malo interesowalem sie tematem zeby dac sie przekonac.
SMTP jest wadliwe, ale widzisz jakas konkretna alternatywe?
Podstawa sukcesu e-mail byl fakt, ze kazdy moze napisac do kazdego. Idealnym rozwiazaniem moglaby byc jedynie autentyfikacja na podstawie np. klucza publicznego/certyfikatu przy kazdej transakcji klienta z serwerem i pomiedzy serwerami. Takie drastyczne rozwiniecie SPF, az po samego uzytkownika koncowego.
Zreszta, niech sie inni martwia
Ja wole zajmowac sie innymi sprawami.
“Sprawdźmy to IP, bo nazwa hosta UVYU raczej routowalną nie jest”
Nie ma czegoś takiego jak rutowalna nazwa hosta. Rutowalne mogą być protokoły. Tyle pamiętam z kursu CCNA
@Al Beut: masz swieta racja, uzylem skrotu myslowego. Chcialem napisac, ze to na FQDN nie wyglada …