Yet another Web Blog

Um SSH erfolgreich gegen Bruteforce Attacken zu schützen bzw. diese abzuwehren, gibt es verschiedene Ansätze.

1. Logfile Analyse

SSH logged alle fehlgeschlagenen Login Versuche in eine Logdatei. Diese wird nach und untersucht und sollte eine bestimmte Anzahl ungültiger Logins durch die selbe IP gezählt worden sein, wird diese IP Adresse gesperrt.

Das bekannteste Tool für diese Aufgabe heißt Fail2Ban. Der Vorteil liegt darin, dass es zuverlässig funktioniert und auch für FTP, POP3, IMAP usw. verwendet werden kann.

2. Security through obscurity

Gewöhnlich werden Bruteforce Attacken von Zombi Servern im Internet ausgeführt. Die Bots scannen nach Port 22 und versuchen anschließend ihr Glück Username und Passwort zu erraten.

Um so schnell wie möglich, möglichst viele Server zu finden, gibt es kaum Bots die einen Rechner auf mehr als Port 22 testen. Daher ist es möglich den Rechner per Verlegen des SSH Ports vor diesen Bots zu bewahren. Natürlich besteht hierfür keinerlei Garantie und die Methodik Security through obscurity ist nicht als alleiniges Mittel anzusehen. Hierzu gibt es einen guten Wikipedia Eintrag.

3. Verzicht auf Passwort Authentifizierung

Es ist ohne Probleme möglich einen SSH Server zu konfigurieren, dass dieser zu einem erfolgreichem Login nur das Publiykey Verfahren zu lässt. Aufgrund der Tatsache dass dieses Verfahren als sehr sicher gilt, ist es die Beste Möglichkeit den SSH Server vor ungewünschten Logins zu schützen.

Kurze Zeit nach dem Letzten lokalen Root Exploit namens “h00lyshit” für den Linux Kernel, ermöglicht der nächste Bug im Linux Kernel “root” zu werden.

Somit sind nahezu alle ungepatchte 2.6er Linux Kernel mit einer Lücke versehen, die es einem lokalen Benutzer ermöglicht die Rechte des Superusers zu erlangen.

2.6.17 - 2.6.xx: h00lyshit.c
2.6.24.1 - 2.6.17: jessica_biel_naked_in_my_bed.c

Debian hat einen gepatchen Kernel released der die Lücke schließt.

Ansonsten hilft nur das Update auf den weiterhin zweifelhaften Vanilla Source Kernel 2.6.24.2

Es wird nur eine Frage der Zeit sein bis auch hier ein weiterer root Exploit folgen wird.

Im Moment ist stark unzuraten auf das Patch können der Distributionsentwickler zu setzen und die jeweils aktuellste Version des Distributionskernels zu verwenden, um sich tägliches Kernel kompilieren zu ersparen.

Viele Administratoren kämpfen mit Ausläufern von unsicheren PHP Scripten die es einem Angreifer ermöglichen in das System einzudringen, Spam zu versenden oder die Funktion des Servers anderweitig nach den Wünschen des Angreifers zu gestalten.

Dies ist nicht nur ärgerlich sondern zieht meist auch Konsequenzen nach sich, welchen hier keine weitere Erläuterung geschenkt werden soll.

Den Server dahingehend zu schützen oder absichern zu können ist ein schmaler Grad zwischen “geht” und “geht nicht” - gemeint sind hier diese diversen PHP Scripte.

Die wohl wichtigsten PHP Direktiven für Administratoren, die erreichen können eine relativ sichere Umgebung zu ermöglichen sind die Folgenden:

allow_url_fopen = off 
 
register_globals = off 
 
open_basedir = "/pfad/zum/user/homedir:/pfad/zu/pear:/pfad/zum/tmpdir:/pfad/zum/uploadir" 
 
disable_functions = dl, exec, shell_exec, system, passthru, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close, pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, escapeshellcmd, escapeshellarg, set_time_limit, show_source

Erst wenn diese Einstellungen so oder so ähnlich aussehen, würde meiner einer von wenigstens in Grundzügen sicheren Hosting Umgebung sprechen.

Wem das nicht genug ist, dem ist zu raten mittels mod_security die mit POST (oder anderweitig) zum Apache gesendeten Daten zu durchleuchten.

Die User danken es einem?

Wir viele User zu bedienen hat und damit viel PHP Software, wird schnell merken dass einige PHP Scripte mit den o.g. Einschränkungen nur teilweise oder im schlimmsten Fall gar nicht laufen, daher sollte man sein System einige Zeit nach einer solchen Änderung im Auge behalten => denn Schuld ist immer der Administrator auch wenn er seine User nur happy machen möchte.