Quoting Andre Tann
Erhard Schwenk, Mittwoch, 28. Dezember 2005 11:11:
siehe oben. Eventuell kommt noch Verlegen des sshd auf einen anderen Port oder Port Knocking in Betracht, aber beides tendiert in Richtung "Security by Obscurity", was grundsätzlich als wirkungslos bis gefährlich zu betrachten ist.
Was ist daran gefährlich?
Zunächst einmal ist es wirkungslos. Falsche SSH-Logins ablehnen kann SSH ganz alleine, da braucht man nicht noch irgendwas davor. Es erhöht aber die Komplexität, erschwert die eigene Diagnose - und schafft damit potentielle Fehlerquellen, die per se eine Gefahr für die Sicherheit darstellen.
Wenn der sshd an Port 30000 statt an Port 22 lauscht, dann ergibt sich doch kein Risikounterschied. Worin besteht die Gefahr beim Portknocking?
Portknocking ist nichts anderes als der Versuch, eine Abfolge von Ports als Schlüssel zu verwenden. Mehr als ein gescheites Passwort ohnehin erreicht, kann man damit prinzipell nicht gewinnen. Allerdings wird dieser "Schlüssel" bei Portknocking ungesichert übertragen (jeder kann den "Schlüssel" mit einem einfachen IP-Sniffer mitlesen), und es wird auf beiden Seiten der Verbindung deutlich komplexere Logik gebraucht als bei einer Passwort- oder Public-Key-Prüfung. Zusätzliche Komplexität bedeutet zwangsläufig zusätzliche Fehlerquellen und damit zusätzliches Risiko. Anstatt umständlich Portknocking aufzusetzen, ist es viel einfacher und aus Sicherheitsgesichtspunkten wirkungsvoller, die verwendeten Passwörter zu verlängern oder die Länge des Public Key.
Wohl aber sind die Maßnahmen keineswegs wirkungslos:
Doch, natürlich sind sie das.
ich beobachte, daß die Anzahl der Unterhaltungsversuche mit dem sshd gegen Null geht,
Die Anzahl der Unterhaltungs_versuche_ mit Deinem SSH ist aus Sicherheitsgesichtspunkten völlig irrelevant. Relevant wäre einzig und alleine die Anzahl der unauthorisierten Logins und die der erfolgreichen Exploits. Die verändert sich aber bei Verschieben auf einen anderen Port oder Portknocking erstmal nicht. Das maximale was bei abgewiesenen SSH-Connects passieren kann ist ein Log-Überlauf. Dagegen muß man sich aber ohnehin absichern - und das geht am besten mit quotas und logrotate oder durch Verlagern von /var/log auf ein eigenes Volume.
sobald ich irgend einen hohen Port einstelle. Und das ist doch schon mal was, und wenn es nur die Übersichtlichkeit des Logfiles ist.
Die Übersichtlichkeit des Logfiles schfft man sich bei Bedarf mit grep. Ob da noch ein bißchen SSH-Rauschen gefiltert wird, ist sowas von egal.
Davon abgesehen: Die Verwendung eines Paßwortes oder eines Public Keys ist letztlich auch nur Security by Obscurity.
*seufz* [ ] Du hast verstanden, was "Security by Obscurity" bedeutet. -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx it-dienstleistungen - http://www.k-itx.net