[Erledigt] Was wurde aus SSHGUARD ?

[level20peon]

Im Trac gibt es den Hinweis auf das Paket SSHGUARD, im Trunk ist davon aber keine Spur zu finden... kann mich jemand auf die richtige Fährte schicken?

 

[PeterPawn]

Was willst Du denn damit (jenseits der von AVM umgesetzten Maßnahmen) auf der FRITZ!Box beschützen?

Die dynamische Filterung eingehender Requests anhand der Absenderadresse ist nicht vorgesehen ... auch für Portweiterleitungen ins LAN ist da keine "richtige Firewall mit DPI" vorhanden.

Wenn da am Ende ohnehin das TCP-SYN-Paket über die FRITZ!Box bis zum Dienst vordringt (egal ob auf oder hinter der FRITZ!Box), kannst Du den auch einfach über einen TCP-Wrapper absichern.

 

[level20peon]

Ich würde gerne den sshd auf der Box schützen. Ich nutze zwar publickeys zur Authentifizierung, aber würde gerne zusätzlich noch hosts, die zu oft unauthentifiziert verbinden, via hosts.deny blocken.

 

[unrealzocker]

Anderen SSH-Port hält schonmal einen Großteil ab.

 

[PeterPawn]

OK, da ist dann ja schon der erwähnte TCP-Wrapper. Welchen benutzt Du denn, das "tcp_wrappers"-Paket aus Freetz?

Welcher SSH-Daemon ist es bei Dir und protokolliert der auch fehlgeschlagene Versuche irgendwo hin? Wenn ja, wo und wie? Ohne entsprechendes Protokoll ist da ein Patch für den SSH-Daemon bei fehlgeschlagenem Login (einen Blacklist-Eintrag erzeugen) ja fast einfacher. Der "dropbear" bietet z.B. m.W. gar keine TCP-Wrapper-Unterstützung von sich aus an, da muß man also ohnehin selbst ran mit einem Ersetzen durch den tcpd.

Das Problem bei solchen Lösungen ist es i.d.R., die Einträge nach einer gewissen Zeit auch wieder verfallen zu lassen, damit man sich nicht versehentlich mal selbst komplett aussperrt.

Ansonsten kannst Du auch erst einmal nur einen "logread -f"-Prozess irgendwo starten und dessen Ausgabe in einen FIFO umleiten. Aus diesem liest dann ein Prozess die Nachrichten des sshd (i.d.R. schon am Prozessnamen zu identifizieren) und erzeugt einen Sperreintrag in der hosts.deny.

Das Problem ist - wie gesagt - das Abräumen verfallener Sperren, ansonsten wächst die Liste "gegen unendlich" und mit einem einzigen /24-Netz kann man Dir schon 256 zu prüfende Adressen vor einem SSH-Verbindungsaufbau unterjubeln. Das dann mit mehreren Subnetzen ausgeführt und Dein Service reagiert auch bei Deinen eigenen Anfragen nicht mehr mit der erwarteten Geschwindigkeit, weil das Prüfen der ACLs zu lange braucht.

Da ist das "Verstecken" des SSH-Servers unter einem nicht-standardisierten Port die bessere Lösung.

Schon ein SSH-Handshake für die Feststellung, daß da ein Zugriff nicht erlaubt ist (also die "pubkey"-Authentifizierung nicht funktioniert, geschweige denn "password"), verlangt der Box sicherlich einiges ab (einfach mal mitstoppen) und das Arsenal der "Schwachstellen-Scanner" aus dem Internet umfaßt sehr selten nur einen einzigen Server mit einer einzigen Adresse.

Wenn man also seinen SSH-Daemon auf Port 22 laufen läßt, lädt man solche Leute praktisch zu einem SSH-(D)DoS-Angriff ein - entweder durch den Prozessoraufwand beim absehbar unnötigen Handshake oder durch den Prozessoraufwand beim Durchforsten einer "hosts.allow" (oder auch "hosts.deny", was SSHGuard aber m.W. ohnehin nicht nutzt), die mehrere tausend Einträge enthält.

Da muß dann wirklich ein Packet-Filter ran und der "log watcher" bzw. der Regelgenerator muß auch so intelligent sein, daß er Zusammenfassungen von sich aus vornimmt. Es ist eben ein Unterschied, ob man 192.168.1.1, 192.168.1.2, usw. einzeln blockt oder gleich 192.168.1.0/24. Ich weiß nicht, wie "sophisticated" der SSHGuard da arbeitet ... aber mangels Packetfilter ist das auch bei einer FRITZ!Box nicht so richtig effektiv.

Das Verstecken des Ports (es muß ja nicht unbedingt 10022 sein, weil sich der so leicht merken läßt, so schlau sind Angreifer inzwischen auch) ist da der effektivere Weg ... jedenfalls nach meiner Erfahrung und wenn man keinen Packetfilter hat. Wenn ich auf meiner FRITZ!Box (mit fester IP, daher eher seltener angegriffen) den SSH-Service auf 22 freigebe, habe ich ab und an mal ein paar fehlgeschlagene SSH-Loginversuche (bei mir allerdings auf einem Service hinter der FRITZ!Box). Verwende ich dafür einen anderen Port, kommt da praktisch nichts ... erstens gehen die meisten Scans gar nicht erst in den Bereich der unprivilegierten Ports und zweitens erkennen die wenigsten Scans dann direkt beim SYN einen SSH-Service, den man mit einem Handshake malträtieren könnte.

 

[level20peon]

OK, da ist dann ja schon der erwähnte TCP-Wrapper. Welchen benutzt Du denn, das "tcp_wrappers"-Paket aus Freetz?

Noch keinen, aber das Freetz tcp_wrappers Paket sieht schonmal prinzipiell interessant aus. Da müsste ich dann nur noch ein script schreiben, das seinen output (fehlgeschlagene Loginversuche) liest und dann Einträge in hosts.deny vornimmt (oder ?). Das wär damit dann gerade direkt mein Favorit.

Welcher SSH-Daemon ist es bei Dir und protokolliert der auch fehlgeschlagene Versuche irgendwo hin? Wenn ja, wo und wie? Ohne entsprechendes Protokoll ist da ein Patch für den SSH-Daemon bei fehlgeschlagenem Login (einen Blacklist-Eintrag erzeugen) ja fast einfacher. Der "dropbear" bietet z.B. m.W. gar keine TCP-Wrapper-Unterstützung von sich aus an, da muß man also ohnehin selbst ran mit einem Ersetzen durch den tcpd.

OpenSSH, und es logged ins syslog. Auch hier könnte man natürlich einfach das log parsen, aber ich bin nicht sicher, ob es standardmäßig eine hosts.deny "Funktion" in OpenSSH gibt, oder ob ich nicht eh tcp_wrappers dafür brauchen würde ? Eine hosts.deny konnte ich (ohne tcp_wrappers) nicht auf der Box finden.

Das Problem bei solchen Lösungen ist es i.d.R., die Einträge nach einer gewissen Zeit auch wieder verfallen zu lassen, damit man sich nicht versehentlich mal selbst komplett aussperrt.

Da ich eh alle 24 Stunden eine neue externe IP bekomme und ein entsprechendes script das erkennt und Aktionen ausführt, könnte ich hier einfach zusätzlich alle bestehenden Einträge löschen. Die Frage wär hier nur, ob "Angreifer" nicht auf einen DNS Namen (via reverse DNS) zugreifen können und die (meine) IP somit eh irrelevant wäre, was das Löschen der bestehenden Einträge dann zu einer schlechten Idee machen könnte ? (Sich selbst aussperren schließe ich in dem Szenario erstmal aus)

Ansonsten kannst Du auch erst einmal nur einen "logread -f"-Prozess irgendwo starten und dessen Ausgabe in einen FIFO umleiten. Aus diesem liest dann ein Prozess die Nachrichten des sshd (i.d.R. schon am Prozessnamen zu identifizieren) und erzeugt einen Sperreintrag in der hosts.deny.

Siehe oben (gibt es überhaupt eine hosts.deny ?)

Das Problem ist - wie gesagt - das Abräumen verfallener Sperren, ansonsten wächst die Liste "gegen unendlich" und mit einem einzigen /24-Netz kann man Dir schon 256 zu prüfende Adressen vor einem SSH-Verbindungsaufbau unterjubeln. Das dann mit mehreren Subnetzen ausgeführt und Dein Service reagiert auch bei Deinen eigenen Anfragen nicht mehr mit der erwarteten Geschwindigkeit, weil das Prüfen der ACLs zu lange braucht.

Siehe oben.

Da ist das "Verstecken" des SSH-Servers unter einem nicht-standardisierten Port die bessere Lösung.

Siehe oben (ist ein reverse DNS Eintrag bei ISPs beständig ?)

Schon ein SSH-Handshake für die Feststellung, daß da ein Zugriff nicht erlaubt ist (also die "pubkey"-Authentifizierung nicht funktioniert, geschweige denn "password"), verlangt der Box sicherlich einiges ab (einfach mal mitstoppen) und das Arsenal der "Schwachstellen-Scanner" aus dem Internet umfaßt sehr selten nur einen einzigen Server mit einer einzigen Adresse.

Wenn man also seinen SSH-Daemon auf Port 22 laufen läßt, lädt man solche Leute praktisch zu einem SSH-(D)DoS-Angriff ein - entweder durch den Prozessoraufwand beim absehbar unnötigen Handshake oder durch den Prozessoraufwand beim Durchforsten einer "hosts.allow" (oder auch "hosts.deny", was SSHGuard aber m.W. ohnehin nicht nutzt), die mehrere tausend Einträge enthält.

Da muß dann wirklich ein Packet-Filter ran und der "log watcher" bzw. der Regelgenerator muß auch so intelligent sein, daß er Zusammenfassungen von sich aus vornimmt. Es ist eben ein Unterschied, ob man 192.168.1.1, 192.168.1.2, usw. einzeln blockt oder gleich 192.168.1.0/24. Ich weiß nicht, wie "sophisticated" der SSHGuard da arbeitet ... aber mangels Packetfilter ist das auch bei einer FRITZ!Box nicht so richtig effektiv.

Das Verstecken des Ports (es muß ja nicht unbedingt 10022 sein, weil sich der so leicht merken läßt, so schlau sind Angreifer inzwischen auch) ist da der effektivere Weg ... jedenfalls nach meiner Erfahrung und wenn man keinen Packetfilter hat. Wenn ich auf meiner FRITZ!Box (mit fester IP, daher eher seltener angegriffen) den SSH-Service auf 22 freigebe, habe ich ab und an mal ein paar fehlgeschlagene SSH-Loginversuche (bei mir allerdings auf einem Service hinter der FRITZ!Box). Verwende ich dafür einen anderen Port, kommt da praktisch nichts ... erstens gehen die meisten Scans gar nicht erst in den Bereich der unprivilegierten Ports und zweitens erkennen die wenigsten Scans dann direkt beim SYN einen SSH-Service, den man mit einem Handshake malträtieren könnte.

Ja gut, ich betreibe keinen NSA-Server hinter der FritzBox, sondern möchte mich lediglich -sowie es der Aufwand noch rechtfertig- ein wenig schützen

 

[sf3978]

Da müsste ich dann nur noch ein script schreiben, das seinen output (fehlgeschlagene Loginversuche) liest und dann Einträge in hosts.deny vornimmt (oder ?).

Evtl. geht das auch ohne sshguard, wenn der sshd gegen die libwrap gelinkt ist (ldd $(which sshd) | grep -i libwrap) und mit einer Blacklist in der /etc/hosts.allow und dort mit folgender Syntax (Eintrag):

sshd : /<Pfad>/blist.txt : deny

In der Blacklist kann man auch diverse unerwünschte TLDs eintragen. Z. B.: ".by" oder ".cn"., aber auch die IPs, denn nicht jede IP von dort, macht auch rDNS auf die TLD.

 

[PeterPawn]

sondern möchte mich lediglich -sowie es der Aufwand noch rechtfertig- ein wenig schützen

Dann bleibt der einfachste (und unter Betrachtung des Verhältnisses von Aufwand und Nutzen auch der effektivste) Schutz das "Verstecken" des Ports. Alles andere, was ich dazu geschrieben habe, diente nur der Begründung. Solange Du den Port kennst und ein "Scanner" nicht, ist alles im grünen Bereich.

Andere Lösungen (z.B. auch "port knocking") funktionieren auf der FRITZ!Box zwar prinzipiell auch, aber mit entschieden höherem Aufwand. Wenn Du ohnehin alle 24 h eine neue IP-Adresse erhältst, bist Du offenbar in einem Subnetz bei einem Provider, der dynamisch die Adressen vergibt und in solchen Segmenten scannen Angreifer dann i.d.R. wirklich nicht oberhalb der privilegierten Ports - einfach zu viele Ports (ca. 64.000 pro Adresse) und viel zu viele Adressen in solchen Segmenten. Wenn man dann alle 65.535 Ports einer Adresse abgegrast hat (nicht überall kommt ein "administratively down" per ICMP zurück und pro Port müßte man UDP und TCP testen), dann wechselt ggf. wieder die Adresse.

Also geht man da einfach hin und testet eben den SSH-Port an allen in Frage kommenden Adressen ... da, wo der offen ist, probiert man dann ein SSH-Login mit wechselnden Credentials. Findet der Scanner Deinen SSH-Port nicht, bist Du auch nicht Ziel weiterer Login-Versuche. Alles andere ist ohne Packetfilter (der ist nun mal an der Stelle genau dafür gedacht und deshalb ziemlich effektiv beim "matching", solange man da nicht - wie oben beschrieben - ein ungünstiges Regelwerk verwendet) nur ungeheurer Aufwand mit sehr geringem Effekt ... als "ich will das aber mal versuchen" vielleicht ein lohnendes Projekt, aber aus dem Blickwinkel der Effizienz ein Alb.

 

[level20peon]

Evtl. geht das auch ohne sshguard, wenn der sshd gegen die libwrap gelinkt ist (ldd $(which sshd) | grep -i libwrap)[...]

Ist er nicht, wie linke ich ihn denn... würde das denn funktionieren, ohne tcp_wrappers einzubauen ? Wenn ja, wie ?

Dann bleibt der einfachste (und unter Betrachtung des Verhältnisses von Aufwand und Nutzen auch der effektivste) Schutz das "Verstecken" des Ports. Alles andere, was ich dazu geschrieben habe, diente nur der Begründung. Solange Du den Port kennst und ein "Scanner" nicht, ist alles im grünen Bereich.
[...]
Alles andere ist ohne Packetfilter (der ist nun mal an der Stelle genau dafür gedacht und deshalb ziemlich effektiv beim "matching", solange man da nicht - wie oben beschrieben - ein ungünstiges Regelwerk verwendet) nur ungeheurer Aufwand mit sehr geringem Effekt ... als "ich will das aber mal versuchen" vielleicht ein lohnendes Projekt, aber aus dem Blickwinkel der Effizienz ein Alb.

Natürlich hast du Recht, aber so ein bisschen (!) rumbasteln macht mir sehr viel Spaß und ist für mich eine gute Freizeitbeschäftigung

 

[level20peon]

Ist er nicht, wie linke ich ihn denn... würde das denn funktionieren, ohne tcp_wrappers einzubauen ? Wenn ja, wie ?

ok, ich habe nun mal ein wenig recherchiert und gelesen, dass es zwei Möglichkeiten gibt TCP Wrapper zu "betreiben". Die eine Möglichkeit ist, wie beschrieben, das Ganze in den jeweiligen Dienst (in diesem Fall OpenSSH) einzubauen / zu linken, und die andere Möglichkeit ist den tcpd zu verwenden (das tcp_wrappers Paket).

Ich versuche nun die zweite Möglichkeit umzusetzen - bisher erfolglos.

Nachdem ich den OpenSSH Starttyp auf "Inetd" gesetzt habe, habe ich noch folgende Zeile in die inetd Konfiguration eingetragen:

ssh	stream	tcp	nowait	root	/sbin/tcpd	/usr/sbin/sshd -i -f /var/mod/etc/openssh.conf

Der sshd wird nun gestartet und ist auch erreichbar, jedoch wird tcpd nicht gestartet. Außerdem ist mir nicht so ganz klar, wie ich die "/etc/hosts.allow" und "/etc/hosts.deny" anlegen / bearbeiten könnte. Wenn ich sie mit ins image einbaue, sind sie nicht editierbar und wenn ich sie zur Laufzeit anlegen möchte, bekomme ich natürlich den Hinweis auf das "read-only filesystem". Gibt es da einen Trick?

 

[sf3978]

Außerdem ist mir nicht so ganz klar, wie ich die "/etc/hosts.allow" und "/etc/hosts.deny" anlegen / bearbeiten könnte. Wenn ich sie mit ins image einbaue, sind sie nicht editierbar und wenn ich sie zur Laufzeit anlegen möchte, bekomme ich natürlich den Hinweis auf das "read-only filesystem". Gibt es da einen Trick?

Hast Du das schon versucht? Ist die "/etc/hosts.allow" nicht nur ein symlink? Wenn das nicht der Fall ist, dann so anlegen.

 

[level20peon]

ok, ich habe es geschafft - vielen Dank für die Hilfe!