Zugriff nach Fehlversuchen einschränken

[gnude]

Hallo,
ich möchte meinen (Mail)Server gerne absichern und mir schwebt folgende Idee vor:
Nach einem fehlerhaften Anmeldeversuch möchte ich die Anmeldung erstmal (für eine gewisse Zeit oder ggf. dauerhaft) sperren.
Das soll sowohl die Anmeldung lokal bzw. per ssh (es sei denn hier kann man unterscheiden) als auch den Zugriff auf die Postfächer mittels Dovecot (IMAP) sowie Webmail sperren.
Damit möchte ich verhindern das mittels Brute-Force Angriff einfach alle Passwörter durchprobiert werden.
Ich weiss die Regel ist ziemlich streng und vielleicht aussergewöhnlich, aber kann ich das mit Linux realisieren?

[dirk11]

Nicht zielführend, weil Du dich damit u.U. selbst aussperrst. Ein Fehlversuch ist viel zu wenig. iptables wäre mein Stichwort dazu.

[cosinus]

Was ist daran außergewöhnlich? Diese Idee gibt es schon lange und wurde auch schon lange umgesetzt. Ich hatte früher mal denyhosts benutzt, mittlerweile bin ich bei fail2ban.

[irmgard24]

..
Das soll sowohl die Anmeldung lokal bzw. per ssh (es sei denn hier kann man unterscheiden) als auch den Zugriff auf die Postfächer mittels Dovecot (IMAP) sowie Webmail sperren.
Damit möchte ich verhindern das mittels Brute-Force Angriff einfach alle Passwörter durchprobiert werden.
..

Hallo

mit fail2ban sollte es gehen.

1x die IP Blocken und eine weitere Regel den User deaktivieren ( usermod --expiredate 1 username )

Dein Username sollte aber auf die Ausnahme liste

Und ssh login mit Username + Passwort nicht erlauben! ( nur mit KEy )

[gnude]

Also erstmal verstehe ich das Risiko das ich mich aussperre... das wöre ich aber bereit zu tragen. Daher ist die Frage.... wie kann ich das Einstellen?
Es muss ja die Anmeldung per ssh, über imap als auch dem Webinterface sperren. Das Webinterface läuft ja lokal.


Fail2ban habe ich so konfiguriert.... aber das klappt (noch) nicht

Code: Alles auswählen

[scanlogd]
logpath = %(syslog_local0)s
banaction = %(banaction_allports)s

[dovecot-pop3imap]
enabled = true
filter = dovecot-pop3imap
action = iptables-multiport[name=dovecot-pop3imap, port="pop3,imap", protocol=tcp]
logpath = /var/log/mail.log
maxretry = 2
findtime = 1200
bantime = 1200

[sasl]
enabled  = true
port     = smtp
filter   = postfix-sasl
logpath  = /var/log/mail.log
maxretry = 2

[MSfree]

Damit möchte ich verhindern das mittels Brute-Force Angriff einfach alle Passwörter durchprobiert werden.

Ich kenne nur einen, der schon alle Passworte durchprobiert hat: Chuck Norris.

*SCNR*

[gnude]

Damit möchte ich verhindern das mittels Brute-Force Angriff einfach alle Passwörter durchprobiert werden.

Ich kenne nur einen, der schon alle Passworte durchprobiert hat: Chuck Norris.

*SCNR*

Der war nicht schlecht.... ich musste lachen.

[cosinus]

Ich kenne nur einen, der schon alle Passworte durchprobiert hat: Chuck Norris.

Der hat auch schon 2x bis unendlich gezählt und geht durch Wände. Firewall zwecklos!

[uname]

Es ist ein Unterschied, ob man eine gehashte Passwortdatenbank entwendet und mit Millionen von Versuchen pro Sekunde die Passwörter hackt oder ob man mit einer doch sehr unperformanten Anwendung wie z. B. IMAP die Passwörter einzeln ausprobiert. Insgesamt halte ich die Bemühungen für unnötig. Mehr als dass der Server durch die Dauerlast abstürzt wird nicht passieren. Im Übrigen auch ein Grund, warum komplexe Passwörter überbewertet werden. Wie lange braucht IMAP für eine Millionen Versuche? Probiere das doch erst mal aus. Ein Passwort aus 4 Zeichen (Zahlen und kleinen Buchstaben ohne Sonderzeichen) hat schon 1.6 Millionern Kombinationen. Wie lange braucht dein Server das abzuarbeiten? Bei einer Anfrage pro Sekunde ist das mehr als ein Jahr.

Chuck Norris errät alle Passwörter beim ersten Versuch.

[dirk11]

Und ssh login mit Username + Passwort nicht erlauben! ( nur mit KEy )

Das halte ich für vollkommen überbewertet, eine trügerische Sicherheit! Diese führt dazu, dass die Leute sich einfach überall Keys hinterlegen. Ein Key ist aber als kompromittiert anzusehen, sobald auch nur einmal jemand anderes darauf möglichen(!) Zugriff hatte. Zugriff mit Key habe ich tatsächlich nur für meine Rechner im LAN, damit ich dort nicht ständig ein Passwort eingeben muss.

Ein ausgefallener Username (also kein Vorname oder sowas) und ein hinreichend komplexes Passwort halte ich für vollkommen ausreichend - und ich laufe nicht Gefahr, dass ich es irgendwo liegen lasse, außer der Kopf ist irgendwann nicht mehr am Rumpf befestigt...

Dann noch Regeln erstellen wie beispielsweise, dass ab dem vierten Login eine Wartezeit abläuft, welche sich bei jedem Fehlversuch von dieser Quelle verdoppelt, und schon war's das mit automatisiertem "Brute Force".

[thoerb]

Ein ausgefallener Username (also kein Vorname oder sowas) und ein hinreichend komplexes Passwort halte ich für vollkommen ausreichend - und ich laufe nicht Gefahr, dass ich es irgendwo liegen lasse, außer der Kopf ist irgendwann nicht mehr am Rumpf befestigt...

Den Key hat man auf dem Rechner und den Rechner sperrt man, sobald man den Arbeitsplatz verlässt. In den meisten Firmen, in denen ich gearbeitet habe, war das Pflicht.

[dirk11]

Ja. Einmal vergessen, weil man dringend "nur mal kurz auf's Klo" musste, und alle Keys sind als kompromittiert zu betrachten und auszutauschen - das wäre dann genauso "Pflicht". Dein "Pflicht"-Einwand überzeugt mich genausowenig wie das Argument, dass man ja nur Auto fahren kann, wenn man einen Führerschein hat.

[thoerb]

Aber du löschst jedes mal die .bash_history, damit keiner an deinen ausgefallenen Usernamen kommt?

[MSfree]

Insgesamt halte ich die Bemühungen für unnötig.

Einspruch.

Mehr als dass der Server durch die Dauerlast abstürzt wird nicht passieren.

Abstürze bedeuten oft aber, daß Pufferüberläufe existieren, und die sind ausnutzbar z.B. zum Einschleusen von Schadsoftware.

Durch reine CPU-Last ist jedenfalls noch kein Programm abgestürzt.

Im Übrigen auch ein Grund, warum komplexe Passwörter überbewertet werden. Wie lange braucht IMAP für eine Millionen Versuche

Selbst, wenn Dovecot (oder welcher Imap-server auch immer) nur 100 Passworte pro Sekunde verifizieren könnte (es dürften deutlich mehr sein), ergeben sich nur 3 Stunden, um 1 Mio auszuprobieren.

Bei einer Anfrage pro Sekunde ist das mehr als ein Jahr.

Server schaffen eher eine Million pro Sekunde. Schließlich kann jede Low-End CPU (Atom Dual-Core, 1.6GHZ) schon über 3 Milliarden Opperationen pro Sekunde. Bei 3000 CPU-Operationen pro Passwort hast du deine Million pro Sekunde. Heutzutage sind aber 32 Kerner mit 4GHz Takt auch keine Seltenheit mehr, und die setzen 40 mal mehr durch.

Letztlich ist es immer sinnvoll, die Loginversuche durch Throttling zu verlangsamen. Nach dem dritten Fehlversuch wird man meist erstmal für 5 Sekunden ausgesperrt. Das reduziert die Anzahl der Versuche schonmal auf 4 pro 5 Sekunden.

Eine Sperrung nach dem ersten Fehlversuch halte ich aber auch für falsch. Jeder von uns hat schonmal bei versehentlich aktiviertem CAPSLOCK sein Passwort falsch eingegeben. Meistens gibt man es dann nochmal mit versehentlich aktiviertem CAPSLOCK ein, weil man dachte, man hätte sich nur vertippt. Erst dann schaut man vielleicht mal auf die Tastatur-LEDs, schaltet CAPSLOCK ab und tippt es schließlich korrekt ein.

Hier im Geschäft wird man nach dreimaliger Falscheingabe für 20 Minuten gesperrt. Ich denke, das ist eine vernünftige Methode um ausprobieren zu verhindern, ohne daß man Konten komplett deaktiviert und ein Admin sich der Sache annehmen muß.

Chuck Norris errät alle Passwörter beim ersten Versuch.

Stimmt, hatte ich gar nicht mehr dran gedacht.

[cosinus]

Stimmt, hatte ich gar nicht mehr dran gedacht.

Chuck Norris muss keine Passwörter erraten, er weiß einfach alle!

[uname]

Selbst, wenn Dovecot (oder welcher Imap-server auch immer) nur 100 Passworte pro Sekunde verifizieren könnte (es dürften deutlich mehr sein), ergeben sich nur 3 Stunden, um 1 Mio auszuprobieren.

Ok. Aber bei 8-stelligen Passwörtern ist man schon bei fast 3 Billionen Kombinationen. Ohne Sonderzeichen.

Letztlich ist es immer sinnvoll, die Loginversuche durch Throttling zu verlangsamen. Nach dem dritten Fehlversuch wird man meist erstmal für 5 Sekunden ausgesperrt. Das reduziert die Anzahl der Versuche schonmal auf 4 pro 5 Sekunden.

Das ist ok. Wobei eine Verlagsamung nach sagen wir 100 Versuchen (im Interesse des eigentlichen Anwenders) vollkommen ausreichend wäre.

Eine Sperrung nach dem ersten Fehlversuch halte ich aber auch für falsch.

Selbst nach 1000 Fehlversuchen ist die Sperre noch nicht sinnvoll sowohl bei 4- als auch 8-stelligen Passwörtern.

Chuck Norris muss keine Passwörter erraten, er weiß einfach alle!

[dirk11]

Aber du löschst jedes mal die .bash_history, damit keiner an deinen ausgefallenen Usernamen kommt?

Was ist denn das für ein lächerliches ad hominem "Argument"? Es geht doch nicht darum, dass niemand meinen Usernamen kennt, sondern dass Brute-Force von außerhalb schon daran scheitert, dass a) der sshd sowieso nur auf bestimmte Usernamen hört und b) dieser nicht "erratbar" ist. Wenn mein User Klaus heißt und das beim Durchprobieren "erwischt" wird, ist das erste Kriterium bereits erfüllt. Heißt der User stattdessen Kl_us (das ist nur ein ganz simples Beispiel!), so wird das sicherlich nicht so leicht durch eine solche Attacke gefunden.
Bei mir werden root-Login Versuche schon dadurch abgelehnt, weil root sich überhaupt nicht anmelden darf.

[cosinus]

Selbst nach 1000 Fehlversuchen ist die Sperre noch nicht sinnvoll sowohl bei 4- als auch 8-stelligen Passwörtern.

Wo issen das Problem? Ist doch kein großer Aufwand, fail2ban einzurichten, v.a. für ssh finde ich das schon sinnvoll. Man kann auch nicht immer ssh so konfigurieren, dass man nur noch per Key reindarf.

[thoerb]

Was ist denn das für ein lächerliches ad hominem "Argument"? Es geht doch nicht darum, ...

Zugegeben, nachdem ich meinen Beitrag abgesendet hatte, bin ich dann auch selbst drauf gekommen, dass das Unsinn ist.

[dirk11]

Danke, @thoerb

[cosinus]

Aber du löschst jedes mal die .bash_history, damit keiner an deinen ausgefallenen Usernamen kommt?

Seit wann soll man denn Usernamen geheim halten?
Ich kenn das eher nur so, dass man Standardlogins verändert, also sowas wie root oder admin sperrt wenns geht, selbstverständlich keine Standardpasswörter nutzt und den sshserver aus der Schusslinie nimmt, indem er nicht mehr auf Port 22 lauscht.

[thoerb]

Aber du löschst jedes mal die .bash_history, damit keiner an deinen ausgefallenen Usernamen kommt?

Seit wann soll man denn Usernamen geheim halten?

Noch einmal, ich habe aus einem Missverständnis heraus Unsinn geschrieben und damit ist die Sache jetzt für mich beendet.

[heisenberg]

Server schaffen eher eine Million pro Sekunde. Schließlich kann jede Low-End CPU (Atom Dual-Core, 1.6GHZ) schon über 3 Milliarden Opperationen pro Sekunde. Bei 3000 CPU-Operationen pro Passwort hast du deine Million pro Sekunde. Heutzutage sind aber 32 Kerner mit 4GHz Takt auch keine Seltenheit mehr, und die setzen 40 mal mehr durch.

Ja. Der Dovecot kann theoretisch auf einer Server-CPU mit 1 Millionen Authentifizierungen pro Sekunde schaffen. Praktisch würde ich das vielleicht eher so bei 100 Authentifizierungsvorgängen pro Sekunde vermuten, vielleicht auch bei 1000 wenn es wirklich ein gut gebauter Mailserver ist. Also wegen dem Overhead den das Netzwerk erzeugt, wegen der max. Anzahlen an Verbindungen, die der Dovecot zulässt, etc. Wenn Du mehr denkst: Dann bastele doch mal kurz ein Skript, dass zeigt, wie viel der Dovecot im LAN schafft! (Parallelisiere so viel Du willst).

Auf einem großen Live-Mailserver sehe ich da bei mir ca. 300 fehlgeschlagene Authentifizierungen pro Stunde. (Fail2ban ist dort aktiv).

Der Vorgabewert für auth_failed_delay steht bei dovecot auf 2 Sekunden (postfix ähnlich). Zusammen mit dem default process limit von 500 bedeutet das, dass da max. 250 Authentifizierungen pro Sekunde ablaufen können. Das kann man natürlich nach Belieben verschärfen. Ein 10 Zeichen langes Passwort aus Kleinbuchstaben (26^10) wären da 141 Billionen Kombinationen. Bei 250 Authentifizierungen pro Sekunde wären das ~430.000 Jahre - bei komplettem maximal-parallelisiertem Dauerfeuer auf den Server. (Bei 6 Zeichen mit Klein-, Großbuchstaben und Ziffern sind es 56 Mio -> 7 Jahre).

Ich selbst habe in vielen Jahren noch kein absolutes parallelisiertes BruteForce-Abfragen an meinen Servern gesehen. Ab und an geht die Last, d. h. die Anzahl der Anfragen mal hoch. Das merkt man dann schon recht schnell, weil manchmal dann IMAP/POP3/SMTP-Erreichbarkeit flappt und spätestens dann gibt es entsprechende Reaktionen. Das setzt natürlich voraus, dass der Server kontinuierlich überwacht wird.

Insofern stimme ich uname da zu: gehashte Passwort-DB raustragen: Da sind wir bei den Millionen und Milliarden Hashes pro Sekunde und mehr, aber nicht via Internet bei dovecot und postfix.

Ich hatte mal eine Zeit lang einen SSH-Honeypot laufen und habe mal geschaut, was da für Passwörter ausgetestet werden. Das waren durch die Bank nur absolut primitivste und einfache Passwörter und user (admin, root, support). Da hat niemand per BruteForce Millionen verschiedenster komplexer Passwörter durchprobiert.