Problematik IP-basierter Sperren

[heisenberg]

Hi,

ich hatte gestern einen Fall, bei dem ein Benutzer seine Webseite nicht anschauen konnte.

Ursache war wohl das fail2ban, dass auch mit f2b-loop konfiguriert war, d. h. bei wiederholter
Störererkennung greifen drastischere Massnahmen. Im vorliegenden Fall, werden bei
wiederholter Sperre alle Mailports, sowie http+https gesperrt.

Bei der Protokollbegutachtung hat sich ergeben, dass von zahlreichen IPs(IPv4),
auch Passwortrateversuche gekommen sind, die mit Sicherheit nicht von obigem
Benutzer kamen.

Ich vermute mal, dass das eine Auswirkung der IPv4-Knappheit ist im Zusammen-
spiel mit Carrier Grade NAT: Einer sehr grossen Menge von Internetbenutzern steht
nur eine begrenzte Mengen von realen, öffentlichen IPv4-Adressen zur Verfügung.

D. h. IMHO sind wir bei IP-basierten Sperren bei IPv4 langsam bei dem Punkt
angekommen, bei dem die dadurch verursachten Störungen die Nützlichkeit
übersteigt.

[MSfree]

Bei der Protokollbegutachtung hat sich ergeben, dass von zahlreichen IPs(IPv4),
auch Passwortrateversuche gekommen sind...

Ich vermute mal, dass das eine Auswirkung der IPv4-Knappheit ist im Zusammen-
spiel mit Carrier Grade NAT

Bei Carrier Grade NAT wären die Passwortrateversuche aber von der selben IPv4 Adresse gekommen, nämlich der des NAT-Routers.

OK, die Carrier, die Carrier Grade NAT einsetzen (in erster Linie Mobilfunkanbieter), haben wahrscheinlich mehr als einen NAT-Router, so daß sich die Aussage im ersten Satz relativiert.

Als zunehmend nutzlos würde ich Fail2ban trotzdem nicht sehen, es schützt immerhin die hinter der Schranke liegenden Dienste vor Brute-Force-Attacken. Welche Möglichkeiten der nachgeschalteten Gefahrenabwehr hätte man denn sonst? Natürlich kann man Sicherheitsmechanismen vorschalten, z.B. Port/Ping-Knocking, für den Zugang zu öffentlichen Servern (Mail, HTTP, FTP...) ist das aber weitgehend unpraktikabel, weil es unbequem ist und Knocker nicht für jedes OS zur Verfügung stehen. Two-Factor-Auth reduziert zwar die Wahrscheinlichkeit, daß sich ein Cracker mit gestohlenen Zugangsdaten einlogt, es verhindert aber nicht, daß man eventuell vorhandene Sicherheitslücken im Server ausnutzt.

[heisenberg]

D. h. IMHO sind wir bei IP-basierten Sperren bei IPv4 langsam bei dem Punkt
angekommen, bei dem die dadurch verursachten Störungen die Nützlichkeit
übersteigt.

Naja, das war jetzt vielleicht etwas übertrieben ausgedrückt. Aber sehr lange wird es wohl nicht mehr dauern....

[bluestar]

Ursache war wohl das fail2ban, dass auch mit f2b-loop konfiguriert war, d. h. bei wiederholter
Störererkennung greifen drastischere Massnahmen. Im vorliegenden Fall, werden bei
wiederholter Sperre alle Mailports, sowie http+https gesperrt.

Da stellt sich für mich erst einmal die Frage nach dem Charakter des Nutzers, bei einem Privatnutzer mit dynamischer IP kann ich das Problem durchaus verstehen. Handelt es sich um einen professionellen Nutzer, dann würde ich von selbigem eine feste IP-Adresse auf Client-Seite erwarten und dann würde das Problem auch nicht bestehen.

[Lord_Carlos]

Ist ein f2b Bann normal nicht auf Zeit begrenzt? Also hat jemand in den letzten XX Minuten die gleiche IP bekommen wie jemand der seinen Server angegriffen hat?
Was ist ein professioneller Nutzer?

[heisenberg]

Ist ein f2b Bann normal nicht auf Zeit begrenzt? Also hat jemand in den letzten XX Minuten die gleiche IP bekommen wie jemand der seinen Server angegriffen hat?

Ja. fail2ban ist in der Grundeinstellung begrenzt. Nur wenn jemand nicht Ruhe gibt, und es immer wieder probiert, dann wird er bei mir mit steigender Sperrzeit ausgeschlossen. Siehe auch: http://blog.shanock.com/fail2ban-increa ... offenders/ . In dem vorliegenden Szenario wo sich viele Geräte wenige IPs teilen führt das tendenziell dazu, dass alle IPs eines Providers der Carrier-Grade-NAT verwendet gesperrt werden, wenn nur wenige schwarze Schafe dabei sind.

Was ist ein professioneller Nutzer?

Das verstehe ich auch nicht. Ich rede hier von einem Hosting-Nutzer - ein normaler Mensch, der seine E-Mail abruft und seine Homepage bearbeitet und hochlädt. Das tut er über einen sehr gewöhnlichen privaten oder gerne auch gewerblichen DSL/Kabelanschluss. Statische IPs sind da die absolute Ausnahme.

[bluestar]

Was ist ein professioneller Nutzer?

Ich schließe hier einfach mal den Otto-Normal-Privatnutzer aus. Professionell wäre in dem Falle jemand, der den wirtschaftlichen Vorteil in der Nutzung von statischen IP-Adressen sieht und somit auch gewillt ist den Mehrpreis für diesen Service zu zahlen.
Selbstverstänldich heißt das für mich nicht, das es nicht auch professionelle User mit dynamischen IP-Adressen gibt, allerdings sollten sich diese Nutzer möglicher Probleme auf Grund der dynamischen Adresse bewusst sein.

Aber ja ich gebe euch natürlich recht, statische IPs sind die Ausnahme.... Leider!

[DynaBlaster]

Ich denke auch, das heisenberg da sicher ein Problem beschrieben hat, das in Zukunft eher zunehmen wird. Gerade im Hosting-Bereich von Webseiten via HTTP und HTTPS wird man wohl auf IPV4-basierte Bans verzichten müssen. In Zeiten des "Internets der Dinge" werden Botnetze in Anzahl und Umfang der gekaperten Endgeräte weiter zunehmen und damit auch die Anzahl und Effektivität von Bruteforce-Attacken zunehmen. Fail2Ban und Co. helfen da dann nur bedingt weiter, selbst wenn der Webseitenbesitzer über eine statische IP verfügt und diese dann "ge-whitelisted" werden könnte. I.d.R. betreibt der Webseitenbesitzer sein Angebot aber nicht für sich selbst und findet es sicher ziemlich unlustig, wenn er zwar selbst auf die Inhalte zugreifen kann, aber alle Smartphones und Co. hinter "Carrier Grade NAT"-Routern ausgeschlossen werden. Da würde ich also tatsächlich auf ein IP-basiertes Blocking verzichten.

Was bleibt also zur Absicherung von ungewünschtem Verhalten wie Brute-Force-Attacken? Eigentlich nur die Absicherung der Authentifizierungsmechanismen der Dienste - und das heisst für mich dann letzlich die Deaktivierung von passwort-basierten Logins. Authentifizierung folglich nur noch via SSH-Key oder Client-Zertifikaten.

Der FTP-Server sollte also so konfiguriert werden (können), das er beim Login auf ein valides Clientzertifikat gegen eine vertrauenswürdige CA prüft, das gleiche gilt für einen Mailserver für ausgehende Mails an andere MTA`s usw.. Komfort sieht sicher anders aus. Richtig problematisch wird es bei webbasierter Forensoftware, CMS-Systemen, usw.. Ich kann mir ad hoc bspw. keine Lösung für das debianforum vorstellen, die praktibale wäre. Aber sollte mein Account hier "gebruteforced" werden, könnte ich das wohl gearde noch so verkraften

Heisst im Umkehrschlussaber auch, das ich als Admin eine eigene CA verwalten muss und das Problem habe, das meine Hosting-Kunden selbstsignierten Zertfikaten vetrauen müssen.

Auf jeden Fall eine interessante Diskussion, hab dafür sogar meinen ziemlich verwaisten Account hier wieder reaktiviert

[bluestar]

... aber alle Smartphones und Co. hinter "Carrier Grade NAT"-Routern ausgeschlossen werden. Da würde ich also tatsächlich auf ein IP-basiertes Blocking verzichten.

Wenn man als Hosting-Betreiber konsequent auf Dual-Stack setzt, dann kommen die Besucher bestenfalls gar nicht mehr über das Carrier Grade NAT, sondern über natives IPv6. Natürlich müssen die Nutzer dies auch erst mal aktiviert haben, aber in dem Bereich tut sich ja langsam etwas.

Dann brauchen wir nur bald für eine Übergangszeit auch eine IPv6 fail2ban Konfiguration, parallel zu der IPv4 Konfiguration.

[heisenberg]

Mit IPv6 hat man das Problem des NAT nicht, das ist wahr, sondern nur das Problem, das IPv6 an sich mitbringt: Die unglaublich vielen IP-Adressen.

Für ein /48, was man problemlos bekommt, hat man da schon mal eine Menge von Adressen. Wenn man berücksichtigt, das üblicherweise ein Minimum von einem /64 einem Nutzer zugewiesen werden - von wenigen Ausnahmen abgesehen dann wäre das mal die kleinste Einheit mit der ich rechnen würde. Spamlistenbetreiber Spamhaus blockt da auch immer Minimum ein /64 - Netz. (Siehe: https://www.spamhaus.org/organization/statement/12/)

D. h. von dem erwähnten /48 kann man davon ausgehen, dass man, wenn man es in /64er Netze aufteilt ein jedes lediglich als 1 Adresse nutzen kann, wo dann also noch 16 Bits der Adresse für Netze übrig bleiben. Das wären dann also 2^16 = 32768 Netze von von /64 Grösse.

Mal angenommen mit jedem dieser Netze startet man dann vielleicht 3 Passwortrateversuche am Tag, womit man auf jeden Fall unter dem Radar der meisten Einbruchserkennungssysteme bleibt. Dann wäre man bei ca. 100.000 Rateversuchen pro Tag oder ca. 37 Millionen im Jahr. Das finde ich schon eine ganze Menge und damit bekommt man einfache Passwörter.

Auf der anderen Seite sehe ich aber nicht, wie man damit auch nur halbwegs sichere Passwörter knacken kann. Ich hatte mir das ja mal ausgerechnet. (http://www.linuxforen.de/forums/showthr ... ost1842718). Auch der kleine SSH-Honeypot, den ich mal für ein paar Monate laufen liess, der hat nicht gezeigt, dass da wirklich Bruteforce mässig durchprobiert wird. Sondern eher mit simpelsten Benutzer/Passwortlisten gearbeitet wird, oder aber die Hashes abgegriffen werden, die man dann aber offline wirklich mit Hardware per BruteForce errechnet. Ebensowenig sehe ich, dass bei den von mir betreuten Servern kontinuierlich Passworte ausprobiert werden, also zumindest nicht in der Grösssenordnung eines tatsächlichen Bruteforce-Angriffes.

[hec_tech]

Mit /48 bist aber noch auf der kleinen Seite.
In der Firma haben wir /29. Die Anzahl an /64 ist da schon echt extrem.

Gegen Passwortraten hilft nur ein entsprechend sicheres Passwort alles andere wird nicht funktionieren.
Wenn man das ganze mit Docker macht kann das sicherlich jede Menge Versuche zusammenbringen.
3 Versuche pro Tag ist eher niedrig angesetzt - ich würde den Wert eher pro Stunde ansetzen. Ich weiß nicht wie es euch geht aber mir ist es schon öfters passiert mit Capslock oder sonst was gleich mal 3x hintereinander das "falsche" Passwort verwendet zu haben. Das ist aber innerhalb von Sekunden.
Deswegen wird mein Mailserver mich aber nicht sperren.

Mit IP Sperren erarbeitet man sich leider meist nur einen erhöhten Arbeitsaufwand weil Irgendwelche User immer anrufen warum sie sich nicht mehr anmelden können.
NAT im Providerumfeld ist wie schon angesprochen ein Drama. Ich hoffe auf eine ziemlich schnelle Migration auf IPv6 nur wird das bei der Hoffnung bleiben.