Frage zu Vorgehen bei Problemen (gehackter Account)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Frage zu Vorgehen bei Problemen (gehackter Account)

Dr. Peer-Joachim Koch
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 ?
           (In so einem Fall macht es ja wenig Sinn die IP oder den
Account für eine Zeitspanne zu sperren)

Quasi die evergreen Frage: Was kann man automatisieren und was nicht ;)

Freue mich auf eure Erfahrungen und Anregungen ... ;)

--
Ciao,
     Peer
________________________________________________________

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



smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Frage zu Vorgehen bei Problemen (gehackter Account)

Stefan Förster-4
* "Dr. Peer-Joachim Koch" <[hidden email]>:
>Quasi die evergreen Frage: Was kann man automatisieren und was nicht ;)

MSA-Logs mit datenschutzkonformer Anonymisierung in ein Elasticsearch,
von da aus dann einfach schauen, wie viele Treffer es pro Zeiteinheit
gibt und wenn es zu viele sind, Alarm auslösen (WARN) oder direkt
Account sperren (CRIT).

Statt ES und kompletten Logs kannst Du natürlich auch ein
Graphite/InfluxDB oder eine andere TSDB benutzen und dann nur die
Metriken pro Account abgreifen, wir hatten damals nur noch keine solche
Lösung.
Reply | Threaded
Open this post in threaded view
|

Re: Frage zu Vorgehen bei Problemen (gehackter Account)

Florian Pritz
In reply to this post by Dr. Peer-Joachim Koch
On 16.11.2017 09:41, Dr. Peer-Joachim Koch wrote:
>            Gibt es verlässliche Automatismen, die die Reaktionszeit
> verkürzen ?
>            (In so einem Fall macht es ja wenig Sinn die IP oder den
> Account für eine Zeitspanne zu sperren)

Warum macht das wenig Sinn? Die automatische Sperre verhindert, dass
mehr passieren kann und du hast weniger Zeitdruck auf das Problem zu
reagieren. Du kannst auch, statt den Account zu sperren, die Mails in
der queue halten (HOLD), dann dauert eben die Zustellung länger, aber du
hast halt eventuell auch unnötigen Aufwand mit Durchschauen/Aufräumen.

postfwd config Beispiel wie man sowas machen kann:
http://postfix.1071664.n5.nabble.com/ot-monitoring-for-spam-breaches-cleanup-woes-tp71890p72069.html

Abgesehen davon kannst du deine ausgehenden Mails durch einen Spamfilter
schicken, aber ein Limit würde ich immer zusätzlich einstellen.

Florian


signature.asc (875 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Frage zu Vorgehen bei Problemen (gehackter Account)

Patrick Ben Koetter-2
In reply to this post by Dr. Peer-Joachim Koch
* Dr. Peer-Joachim Koch <[hidden email]>:

> 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@... 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@rick


--
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
 
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>:
>> 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@... 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@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



smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Frage zu Vorgehen bei Problemen (gehackter Account)

Max Grobecker
Hallo,

wir scannen bei uns ausgehende E-Mails auf verschiedene Auffälligkeiten wie natürlich infizierte Anhänge, URLS in DNSBL, bekannte Phishing-URLs gegen DNSBL und so weiter.
Das geschieht über eine eigene Policy-Bank in Amavis - die Mails werden dabei nicht getagged oder abgewiesen. Noja, doch, wenn infizierte Anhänge gefunden werden, aber...
Jedenfalls erzeugt das Einträge im Log auf die man dann mit Fail2ban suchen und den Account sperren kann.
Das hat in den letzten Jahren lediglich einen False Positive erzeugt, da der Nutzer unbedingt in seiner Signatur eine Short-URL nutzen musste, deren Dienst auf einer Blacklist gelandet war.

Zusätzlich verwenden wir in Postfix die smtpd_client_message_rate_limit und smtpd_client_recipient_rate_limit, womit ein massiver Ausbruch wenigstens eingedämmt werden kann.
Die Werte sind hier etwa 5x so hoch konfiguriert, wie das normale Peak-Mailvolumen. Diese Limits greifen also nur, wenn jemand den Mailserver ganz übel flutet.
Das erzeugt ebenfalls Logeinträge für Fail2ban und hilft zudem, den Mailserver vor Flooding durch einzelne Clients zu schützen.
Leider greifen die nicht pro Benutzer sondern pro Client (also IP-Basiert). Wenn da also von hunderten IP-Adressen der Account missbraucht wird, hilft dir das im Zweifel nur wenig.


Max


signature.asc (849 bytes) Download Attachment