Komentarze do wpisu 'Spam. Analiza.' http://michal.osmenda.com/2006/12/07/spam-analiza/ Z Irlandii, po polsku Sat, 22 Nov 2008 00:30:52 +0000 http://wordpress.org/?v=2.6.3 Przez: Michał Osmenda http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15483 Michał Osmenda Mon, 11 Dec 2006 20:20:24 +0000 http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15483 @Al Beut: masz swieta racja, uzylem skrotu myslowego. Chcialem napisac, ze to na FQDN nie wyglada ... @Al Beut: masz swieta racja, uzylem skrotu myslowego. Chcialem napisac, ze to na FQDN nie wyglada …

]]> Przez: Al Beut http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15479 Al Beut Mon, 11 Dec 2006 17:50:58 +0000 http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15479 "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 ;) “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 ;)

]]> Przez: ptashek http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15413 ptashek Sun, 10 Dec 2006 23:48:18 +0000 http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15413 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. 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.

]]> Przez: vermin http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15333 vermin Sun, 10 Dec 2006 00:14:58 +0000 http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15333 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 :| 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 :|

]]> Przez: ptashek http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15283 ptashek Sat, 09 Dec 2006 03:38:55 +0000 http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15283 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. 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.

]]> Przez: vermin http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15242 vermin Fri, 08 Dec 2006 20:41:11 +0000 http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15242 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... 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…

]]> Przez: Mike http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15197 Mike Fri, 08 Dec 2006 13:11:37 +0000 http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15197 @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. @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.

]]> Przez: vermin http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15161 vermin Fri, 08 Dec 2006 01:32:48 +0000 http://michal.osmenda.com/2006/12/07/spam-analiza/#comment-15161 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. 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.

]]>