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