Frage zu Vorgehen bei Problemen (gehackter Account)

[Dr. Peer-Joachim Koch]

Hört sich gut an. Allerdings hört sich das auch nach einer Lösung an, die
über einige Zeit schrittweise optimiert wurde. Muss ich mal sehen,
was ich hier in welcher Zeit umsetzen kann.
In vielen Fällen ist es schwierig zu sagen, was eigentlich "normal" ist, 
wenn man
sich schon über einen längeren Zeitpunkt diesen Parameter überwacht hat. 
Wenn man
solche Parameter hat wird vieles leichter.

Vielen Dank!

Ciao, Peer

On 16.11.2017 11:12, Patrick Ben Koetter wrote:
> * Dr. Peer-Joachim Koch <postfixbuch-users at listen.jpberlin.de>:
>> Hallo,
>>
>> wir hatten mal wieder den Fall das ein gehackter Account (wahrscheinlich
>> schwaches PW) benutzt wurde (werden sollte ;) )
>> um Phishing Mails über unseren SMTP-Server zu versenden (gültiger Account
>> mit richtigem PW...). Uns ist es aufgefallen,
>> weil wir die mail queue überwachen und so das sehr schnell mitbekommen
>> haben.
>> Das sperren des Accounts etc machen wir alles in Handarbeit.
>>
>> Frage: Wie macht ihr das ?
>>
>>            Gibt es verlässliche Automatismen, die die Reaktionszeit verkürzen
>> ?
> Wir nähern uns dem Thema über Anomalien.
>
> Dazu finden wir erst einmal durch Analysen des Mailverkehrs heraus, was normal
> ist.
>
> Erst mal kaufen wir uns dann Zeit und verringern den Impact, indem wir die
> Kombination Netz, Uhrzeit und Tag zu verschiedenen Rate Limits schmieden. Das
> verhindert schon mal, dass jemand Sonntag Nacht aus China Vollgas geben kann.
> Zur selben Zeit dürfte jemand aus der trusted IP Range die Ressourcen der
> Plattform ungehindert nutzen.
>
> Dann haben wir ein Tool, das bei wechselnden Geolocations derselben Identität
> bei einem Schwellwert den Account zumacht. Zusätzlich sehen wir uns die IP an.
> Wenn die innerhalb desselben Netzes zu oft wechselt gibt es auch einen
> Platzverweis. Dann setzen wir ein Flag 'abused' im Backend (LDAP, SQL) des
> Accounts.
>
> Das fragen wir on the fly mit check_sasl_access ab und liefern ein "4..
> abused" zurück. Und wir senden eine signierte Notification von abuse at ... an
> die Mailbox des Identity-Owners. Ausserdem landet der Account auf dem
> Monitoring Schirm im NOC und bei den Kundenbetreuern.
>
> Ein anderes Tool weiß welche Identität (zu dem Zeitpunkt in der DB nur ein
> Hash) welches typische Sendeverhalten (Zeit, Tag, Volumen) hat. Das hat auch
> noch mitzureden.
>
> Dann beobachten wir die Ablehnungsrate der Zielserver. Wenn die über einen
> Schwellwert steigt, gehen die E-Mails des Senders auf HOLD, ein Alarm wird
> ausgelöst und die Nachrichten werden genauer inspiziert. Ggf. sichern wir das
> Zeug dann mit https://github.com/sys4/postproof raus.
>
> Solche Mails laufen bei uns auch noch in pyzor rein und auf den MXen fragen
> wir unsere eigene DB ab, damit wir uns nicht selbst oder von anderen
> Plattformen den Kram reinschieben, den wir gerade identifiziert und
> rausgekratzt haben.
>
> Das funktioniert sehr gut, hat so gut wie nie FPs und läßt sich wunderbar
> automatisieren.
>
> p at rick
>
>

-- 
Mit freundlichen Grüßen,
     Peer-Joachim Koch
________________________________________________________

Max-Planck-Institut für Biogeochemie
Dr. Peer-Joachim Koch
Hans-Knöll Str.10            Telefon: ++49 3641 57-6705
D-07745 Jena                 Telefax: ++49 3641 57-7705


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 5224 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20171116/0862ce83/attachment.p7s>