Hallo Gruppe. Ich mache mir Gedanken darüber, ob es sinnvoll sein könnte, den sshd mit fail2ban, denyhosts etc. vor Brute Force Attacken zu schützen. Es ist ja häufig zu lesen, daß dies die Sicherheit erhöhe. Könnte mir jemand bitte erklären, warum das so ist? Ich bin der Meinung, daß das nicht stimmt, denn: 1. Angriffe mit falschen Paßwort kann der sshd selbst abwehren. Evtl. hat man Paßwörter sowieso abgeschaltet, und erlaubt nur Keys. 2. Um fail2ban zu installieren, brauche ich Python. Die Code-Basis des Systems verbreitert sich also ganz erheblich, dazu kommt dann noch fail2ban selbst. 3. Wenn es möglich ist, den sshd durch einen geschickten Verbindungsversuch zu überwinden, dann klappt das doch auch schon beim ersten Versuch, d.h. wenn fail2ban nach dem 5. Versuch sperrt, dann ist das zu spät. Ich bitte um Hinweise. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Thu, 8. February 2007 13:52:34 Andre Tann wrote:
Hallo Gruppe.
Ich mache mir Gedanken darüber, ob es sinnvoll sein könnte, den sshd mit fail2ban, denyhosts etc. vor Brute Force Attacken zu schützen. Es ist ja häufig zu lesen, daß dies die Sicherheit erhöhe.
Könnte mir jemand bitte erklären, warum das so ist? Ich bin der Meinung, daß das nicht stimmt, denn:
1. Angriffe mit falschen Paßwort kann der sshd selbst abwehren. Evtl. hat man Paßwörter sowieso abgeschaltet, und erlaubt nur Keys. Das "Evtl." würde ich heutzutage durch ein "Natürlich" ersetzen. Alles andere entspricht nicht der gebotenen Sorgfaltspflicht und ist fahrlässig, meine unbedeutende Meinung.
2. Um fail2ban zu installieren, brauche ich Python. Die Code-Basis des Systems verbreitert sich also ganz erheblich, dazu kommt dann noch fail2ban selbst.
3. Wenn es möglich ist, den sshd durch einen geschickten Verbindungsversuch zu überwinden, dann klappt das doch auch schon beim ersten Versuch, d.h. wenn fail2ban nach dem 5. Versuch sperrt, dann ist das zu spät. Was wieder ein zusätzliches Argument für public-key authentification ist.
4. Man verwendet port-knocking Mechanismen. Damit ist von aussen kein ssh port sichtbar, erst nachdem eine Anklopf-Sequenz an unterschiedlichste Ports empfangen wurde öffnet sich ein ssh port für eine Anmeldung. Es spricht nichts dagegen jetzt noch wie gewohnt weitere Sicherheitsmechanismen zu verwenden. knockd - small port-knock daemon A port-knock server that listens to all traffic on a given network interface (only Ethernet and PPP are currently supported), looking for a special "knock" sequences of port-hits. A remote system makes these port-hits by sending a TCP (or UDP) packet to a port on the server. When the server detects a specific sequence of port-hits, it runs a command defined in its configuration file. This can be used to open up holes in a firewall for quick access. 5. Man nutzt xinetd anstatt inetd Mit xinetd kann man Dienste wie sshd an eine IP des lokalen Netzes binden, z.B. falls man gar kein ssh von aussen erlauben will. Ist wie ich denke eine bessere Lösung als per iptables ssh von aussen zu unterbinden. regards, thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Andre, hallo Leute, ich ergänze mal eine Betreffzeile ;-) Am Donnerstag, 8. Februar 2007 schrieb Andre Tann:
Ich mache mir Gedanken darüber, ob es sinnvoll sein könnte, den sshd mit fail2ban, denyhosts etc. vor Brute Force Attacken zu schützen. Es ist ja häufig zu lesen, daß dies die Sicherheit erhöhe.
Könnte mir jemand bitte erklären, warum das so ist? Ich bin der Meinung, daß das nicht stimmt, denn:
1. Angriffe mit falschen Paßwort kann der sshd selbst abwehren.
Und wenn zufällig der 529. Versuch das richtige Passwort trifft? Je öfter jemand probiert, desto größer werden die Trefferchancen.
Evtl. hat man Paßwörter sowieso abgeschaltet, und erlaubt nur Keys.
Das "evtl." habe ich auch längst gestrichen - aber auch ein 1024-bit-Key ist theoretisch mit einer ausreichenden (sehr hohen) Anzahl Versuche knackbar.
2. Um fail2ban zu installieren, brauche ich Python. Die Code-Basis des Systems verbreitert sich also ganz erheblich, dazu kommt dann noch fail2ban selbst.
Stimmt. Wobei das Risiko des zusätzlichen Codes gering ist, wenn man es mit AppArmor absichert.
3. Wenn es möglich ist, den sshd durch einen geschickten Verbindungsversuch zu überwinden, dann klappt das doch auch schon beim ersten Versuch, d.h. wenn fail2ban nach dem 5. Versuch sperrt, dann ist das zu spät.
Im Fall von Wörterbuch-Attacken (sprich: wir probieren mal tausende Passwörter, eins davon wird vielleicht akzeptiert) stimmt diese Aussage definitiv nicht. Falls SSH irgendwelche Sicherheitslücken hat, liegst Du natürlich richtig. Das dürfte jedoch deutlich seltener vorkommen als "zufällige" Treffer beim Passwort. Ich verwende übrigens eine Lösung, die ohne zusätzliche Software auskommt: ipt_recent in der Firewall, mit dem nur eine bestimmte Anzahl neue Verbindungen pro Minute erlaubt werden. Einziger Nachteil ist, dass es _alle_ Verbindungen zählt, nicht nur solche mit falschem Passwort. Für <= 10.1 brauchst Du dafür ein paar Zeilen "custom code" in SuSEfirewall, ab 10.2 ist ipt_recent-Support eingebaut. Konfigurationsbeispiel für /etc/sysconfig/SuSEfirewall2: FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=5,blockseconds=300,recentname=ssh" Das erlaubt max. 5 SSH-Logins pro IP in 300 Sekunden = 5 Minuten. Falls man viel mit CVS o. ä. arbeitet, empfiehlt sich die Reduzierung der blockseconds und/oder Erhöhung des hitcount - ansonsten sperrt man sich leicht mal für 5 Minuten aus. Gruß Christian Boltz PS: Den passenden Code für <= 10.1 suche ich bei Bedarf raus, sollte aber auch mehrfach im Listenarchiv zu finden sein. --
I'm running SUPER. I've a USB mouse attached. The mouse is too sensitive, the cursor is moving too fast which is out of my control. Even the mouse is performance enhanced, wow! [> Qingjia Zhu and Peter Flodin in opensuse] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Christian Boltz, Donnerstag, 8. Februar 2007 23:20:
ich ergänze mal eine Betreffzeile ;-)
Sei nicht so pingelig, ich hatte mein Versehen doch selbst bemerkt... ;)
1. Angriffe mit falschen Paßwort kann der sshd selbst abwehren.
Und wenn zufällig der 529. Versuch das richtige Passwort trifft? Je öfter jemand probiert, desto größer werden die Trefferchancen.
Klar. Aber um mein Beispiel von nebenan nochmal anders zu formulieren: Paßwort mit 20 Zeichen = 200 Bit = 10^60 Key mit 2048 Bit = 10^616 Hier liegen 550 Zehnerpotenzen dazwischen. Da ist es mir doch völlig egal, ob jemand einen Versuch pro Minute hat, wie bei Deiner Konfiguration, oder sagen wir zehn in der Sekunde = 60 pro Minute = nicht einmal zwei Zehnerpotenzen. Ich lasse einfach nur Keys zu, und dann fällt die zusätzliche Maßnahme, BF-Attacken auszubremsen, überhaupt nicht mehr ins Gewicht. Die Frage kann hier also nur lauten: ist der sshd wirklich vom Code her so sicher, daß obige Betrachtung stimmt? Oder gibt es nicht etwa Schwachstellen im Code, die einen viel einfacheren Angriff als BF zulassen? In diesem Fall wäre es natürlich schon sinnvoll, die Anzahl der Versuche zu begrenzen. Andererseits: Kenne ich die Schwachstelle und weiß, wie man sie ausnutzt, dann reicht mir doch schon ein einziger Versuch, und den habe ich ja immer.
Das "evtl." habe ich auch längst gestrichen - aber auch ein 1024-bit-Key ist theoretisch mit einer ausreichenden (sehr hohen) Anzahl Versuche knackbar.
2^1024 = 10^308. Da das Weltall nur 10^81 Atome hat, kommen mir Zweifel, ob diese Anzahl von Versuchen erreicht werden kann. Denn irgendwoher muß die Energie ja kommen für die ganzen Versuche. Man müßte also aus einem einzigen Atom ausreichend Energie für 10^227 Versuche gewinnen, und das scheint mir etwas viel.
3. Wenn es möglich ist, den sshd durch einen geschickten Verbindungsversuch zu überwinden, dann klappt das doch auch schon beim ersten Versuch, d.h. wenn fail2ban nach dem 5. Versuch sperrt, dann ist das zu spät.
Im Fall von Wörterbuch-Attacken (sprich: wir probieren mal tausende Passwörter, eins davon wird vielleicht akzeptiert) stimmt diese Aussage definitiv nicht.
Falls SSH irgendwelche Sicherheitslücken hat, liegst Du natürlich richtig. Das dürfte jedoch deutlich seltener vorkommen als "zufällige" Treffer beim Passwort.
Diesen letzteren Fall meinte ich.
Ich verwende übrigens eine Lösung, die ohne zusätzliche Software auskommt: ipt_recent in der Firewall, mit dem nur eine bestimmte Anzahl neue Verbindungen pro Minute erlaubt werden. Einziger Nachteil ist, dass es _alle_ Verbindungen zählt, nicht nur solche mit falschem Passwort.
S.o. - mE eine Maßnahme ohne ins Gewicht fallenden Effekt.
Für <= 10.1 brauchst Du dafür ein paar Zeilen "custom code" in SuSEfirewall, ab 10.2 ist ipt_recent-Support eingebaut. Konfigurationsbeispiel für /etc/sysconfig/SuSEfirewall2:
FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=5,blockseconds=300,r ecentname=ssh"
Das erlaubt max. 5 SSH-Logins pro IP in 300 Sekunden = 5 Minuten. Falls man viel mit CVS o. ä. arbeitet, empfiehlt sich die Reduzierung der blockseconds und/oder Erhöhung des hitcount - ansonsten sperrt man sich leicht mal für 5 Minuten aus.
Ist auch etwas blöd, wenn noch ein Webserver läuft, oder? -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (3)
-
Andre Tann
-
Christian Boltz
-
email.listen@googlemail.com