Re: TPSA władcą internetu (blokada portu 25) - moja korekta

Autor: Sergiusz Rozanski <write-only-with-spf_at_sergiusz.com>
Data: Sun 06 Dec 2009 - 21:38:09 MET
Message-ID: <slrnhho4t1.1mn.write-only-with-spf@dns.media-lab.com.pl>
Content-Type: text/plain; charset=iso-8859-2

Dnia 06.12.2009 Sylwester Zarębski <zbieracz@isp.net.pl> napisał/a:
> Dnia Sun, 6 Dec 2009 10:46:58 +0000 (UTC), Sergiusz Rozanski napisał(a):
>
>> Dnia 06.12.2009 Sylwester Zarębski <zbieracz@isp.net.pl> napisał/a:
>>> Przemyśl więc to co napisałem wcześniej:
>>> Wycięcie SMTP z neo jest *impulsem do zmian* w botnetach, tym bardziej
>>> im więcej zysku z niej mieli ich właściciele. Jest potrzeba, będzie
>>> zmiana. Chyba, że wierzysz, że zdarzy się cud i będzie inaczej?
>> Nie, neo+ to za mało aby to zmienić. Za to wystarczające aby klasy tpsa
>> wyschły w rblach.
>
> Mam nadzieję, że masz rację, chociaż w to nie wierzę. Mogę nawet pójść w
> zakład, jeśli do końca 2010 nie pojawi się odpowiedni botnet, to stawiam
> dobrą flaszkę whiskacza, Chivas może być?

Może być ;), ale ciężko będzie, bo zapewne wielu operatorów chętnie poblokuje 25
również a to może przechylić szlę na niekożyść flaszki ;)

>>> Różnica pomiędzy przypadkiem/zdarzeniem jednostkowym, a regułą jest
>>> ogromna. Wycięcie SMTP z Neo spowoduje przerzucenie ruchu na
>>> zautoryzowany submission.
>> To nie łatwiej wtedy im będzie na autoryzowany imap? I od razu pchać
>> w skrzynke odbiorczą?
>
> Nie ta ilość, nie ten zysk. Nadawcy != odbiorcy.

Tak, wiem, ale piszesz z punktu widzenia postmastera, a nie operatora.
Dostawca łącza nie powinien ingerować w sesje. Przy skali molocha jest
to niebywały koszt finansowy i lagi itd, aby analizować ruch, którego
efektem i tak może być tylko drop pakietu.
Postmaster może odpowiedzieć sensownie w sesji że np przekroczono limit
wysyłanych wiadomości na min/h/dzień, a zrobienie statów nawet per user
nie jest wysokim kosztem, a na pewno mniejszym niż skanowanie smieci ze
150k neostrad-zombie.

>>> Już ktoś pisał, że będzie łatwo wyciąć danego nadawcę. Oczywiście, w ten
>>> sposób wytnie się swojego klienta. Z pewnością ułatwia mi to pracę.
>>> Jak już napisałem, cała odpowiedzialność spada w tej chwili na admina
>>> serwera, który dostaje po dupie z każdej strony:
>>> 1 - od klienta, któremu blokuje konta, zmienia hasła, generalnie *robi
>>> problem* klientowi, który nie jest świadomy, iż kiedyś np. miał wirusa
>> Sorry że zapytam "kiedyś"? Co ile wymagasz zmiany hasła od userów?
>
> Wcale. Klient, który dużo płaci ma swoje wymagania.

Dobrze płacący klient powinien być dopieszczony, mieć wdrożoną sensowną
politykę bezpieczeństwa - być świadomym że jego emaile nie wyciekają przez
skradzione konta itd. 'Swobodę' niezmieniania konta to na freekrytkach
1GB+110+587 w nieciekawej mass domenie.
Komercyjne konto to imo teraz 993+995+465+587tls+kilkaGB.

>>> 2 - ze świata, bo wystawia swój IP na pastwę odbiorców poczty, dla
>>> których taki serwer nie będzie się wiele różnić od open-relay (bo
>>> mnóstwo jego userów będzie w bazach do kupienia za parę miedziaków).
>> Już widze te wirusy wyjmujące hasła z kilkunastu popularnych mua we
>> fafnastu wersjach.
>
> Skoro mogą wyjmować adresy z wiadomości pocztowych, to hasełka będzie
> wielokrotnie prościej.

Ale będzie je wielkorotnie trudniej użyć. Biorąc pod uwagę dodatkowo fakt,
że wykradzione hasło zapamiętane w mua nie jest nikomu znane (bo user
nie pamięta) a odwirusowanie/odtrojanowanie w 90% wypadków to format c:
więc klient robi odzyskaj hasło - czyli defakto - wygeneruj nowe.

>>> 3 - od strony szefostwa, bo musi kupić lepszą maszynę, skuteczniejszy
>>> antyspam (sam spamassassin już nie wystarcza), etc
>> Od żony bo wiecej w pracy siedzisz ;)
>
> No i zaczynamy rozumować tym samym tokiem ;).

:)

-- 
*** rozanski.at.sergiusz.dot.com sq3bkn ***
***       http://www.4x4.kalisz.pl      ***
$ You have new spam in /home/serek/maildir/
Received on Sun Dec 6 21:30:02 2009

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Sun 06 Dec 2009 - 21:40:03 MET