 |
HSC |
|
SSH und FTP Brute-Force Attacken
EinführungWer einen Service im Internet zur Verfügung stellt, der durch Authentisierungsverfahren zwar vor unberechtigtem Zugang geschützt, aber eben gerade für die Authentisierung für alle offensteht, wird früher oder später zahlreiche Versuche bemerken, in offenbar zufälliger Manier Zugang zu dem geschützten Dienst zu erhalten. Die Log-Dateien füllen sich mit Einträgen wie "Invalid user XXX from Y.Y.Y.Y" oder "User xxx: Login incorrect", die oftmals in Wellen auftreten und vom gleichen Rechner ausgehen. Offenbar wird gezielt versucht, ein gültiger Benutzer und dessen Passwort zu finden um Zugang zu erhalten. Die so angegriffenen Dienste sind wahrscheinlich auch gar nie publiziert worden sonden nur einem kleinen Kreis von Leuten bekannt - offenbar wird vor dem eigentlichen Angriff gezielt nach möglichen Opfern (in diesem Fall spezifische Dienste auf gewissen Rechnern) gesucht: Port-Scanning und andere Discovery-Technologien werden dabei eingesetzt. Der wesentliche Aspekt unserer Betrachtung ist die verwendete Technologie der Authentisierung: Es sind herkömmliche Passwort-Verfahren, wo der Benutzer seinen Benutzernamen (aka. Login) und sein Passwort präsentiert und nach erfolgreicher Prüfung zugelassen wird. Der Benutzer kann durchaus ein Programm sein, wie etwa ein automatisierter Datei-Transfer oder eine Backup-Software. Die Brute-Force MethodeEine Brute-Force Attacke ist der Angriff auf einen Dienst mittels roher Gewalt (brute force), gerichtet auf die unterliegende Authentisierungs-Methode. Durch zahllose Versuche mit Login/Passwort-Kombinationen wird versucht, ein gültiges Paar zu finden - die Verifizierung erfolgt dabei direkt am System und dieses wird deshalb in der Regel diese massierten Anmelde-Versuche problemlos bemerken und auch in Log-Dateien verzeichnen. Während früher entsprechende Attacken innerhalb kurzer Zeiträume mit möglichst vielen Versuchen durchgeführt wurden, was zu Denial-Of-Service ähnlichen Auswirkungen führte, sind sie heute wesentlich subtiler und die Versuche erfolgen in moderateren Zeitabständen - die Zugriffskurve wird deutlich flacher. Ebenfalls benötigt wird ein Mechanismus zum Erstellen möglicher Benutzernamen, diese sind ja in der Regel nicht bekannt. Hier wird einerseits ebenfalls auf ein Wörterbuch zurückgegriffen (Liste häufig benutzter Vor- und Nachnamen), andererseits auch auf die Standart-Benutzer des Betriebssystems zurückgegriffen, die ja bereits konfiguriert und meist auch aktiviert sind. Beliebte Namen sind auch häufig verwendete Test-Akronyme (test, test1, debug) und administrative Kontos (root,admin,.). Zeitverhalten und QuellenAuch das Zeitverhalten von Attacken ist ein interessantes Phänomen. Ist man geneigt, auf den ersten Blick eine möglichst schnell abfolgende, sequenzielle Reihe von Login-Versuchen zu vermuten, zeigt die Analyse von Log-Daten teilweise ein anderes Bild: Die Versuche erfolgen zwar regelmässig, aber mit Abständen von einigen Sekunden und ohne genaues Timing. Das beschriebene Verhalten lässt mehrere Schlüsse zu: Einerseits kann dahinter vermutet werden, dass eine Massierung der Verbindungen verhindert werden soll um einer Firewall keinen Anlass zu geben, eine DOS-Attacke zu vermuten oder eine unüblich hohe Anzahl von Verbindungs-Versuchen zu detektieren - andererseits kann es aber auch sein, dass mehrere verschiedene Ziele quasi-parallel attackiert werden und die generierten Kombinationen Login/Passwort nicht nur für ein Zielsystem probiert werden. Dies führt im weiteren zur Frage nach koordinierten Attacken und verteilten Systemen, wie man sie bereits aus dem Bereich SPAM mithilfe von Bot-Netzen kennt. Es wäre ein leichtes, entsprechenden Code in einem Botnetz zu verteilen. Aufgrund fehlender Daten kann aber keine Aussage gemacht werden, ob dies bereits geschieht. Praxisfall: SSH und FTP Das eigentliche Ziel der Attacke, der Authentisierungs-Mechanismus, wird über diese Services angegriffen, da sie durch das Design des Anmeldevorgangs quasi direkten Zugriff auf die Prüfung von Benutzername und Passwort erlauben Beide Services kennen in der Mehrheit der Implementationen zwar Beschränkungen im Verbrauch der Ressourcen (wie zum Beispiel ein maximale Anzahl Verbindungen bzw Sessions pro Remote Host), eine Einschränkung der möglichen Benutzer, die den Service überhaupt ansprechen dürfen (beispielsweise AllowUsers bei OpenSSH) oder Limits bei der Anzahl möglicher Loginversuche (nach denen die aktuelle Verbindung terminiert wird, eine Neuverbindung ist aber jederzeit möglich), können jedoch nicht die Grundproblematik der verwendeten Authentisierung lösen. SSHOpenSSH erlaubt die Einschränkung möglicher Login-Versuche und damit Brute-Force-Versuche durch folgende Parameter (in sshd_config):
Als eigentliche Authentisierungs-Schicht kommt das Betriebssytem bzw. dessen Module (PAM) zum Einsatz. Es ist auch anzumerken, dass eine Anmeldung per Benutzername und Passwort durch die Einschränkung möglicher Authentisierungsarten ganz verhindert werden kann. FTPDer verbreitete FTP-Server proftp erlaubt ebenfalls Einschränkungen im Bereich der Authentisierung (Limiten, nach denen in Normalfall die Verbindung beendet wird):
Ebenfalls ist eine separate Benutzerverwaltung möglich, die unabhängig vom Betriebssystem funktioniert. StrategienEines gleich vorne hinweg: Das grundsätzliche Problem der Authentisierungsmethode Benutzername/Passwort kann nicht gelöst werden, da es system-inherent und vom Design vorgegeben ist. Vielmehr können Strategien zur Eindämmung des Problems im Bereich möglicher Zugriffe auf das System, strikte Limits und Überwachung des Datenflusses und dynamisches Aussperren von Kommunikationspartnern, die durch fehlgeschlagene Logins auffallen. Eine grobe Klassifizierung möglicher Strategien ergibt folgende Einteilungen:
Ändern der AuthentisierungDies ist ganz klar die favorisierte Lösung, aber in der Praxis oft nicht anwendbar, da den Benutzern keine andere Technologie zugemutet werden soll. OpenSSH bietet beispielsweise die elegante Authentisierung mittels eines Schlüsselpaares (Public/Private Key), bei FTP kann als Alternative SSL und die Benutzung von Zertifikaten eingesetzt werden. Neben Schlüsselpaaren und Signaturen können aber auch Tokens (SecureID als Beispiel) oder Einmal-Passwörter sowie zentralisierte Systeme (wie etwa Kerberos) zum Einsatz kommen. Erhöhte Sicherheit kann mit einer 2-Faktor-Authentisierung garantiert werden, die zum Beispiel ein Passwort und ein Token beeinhaltet. Wird ein generischer Authentisierungs-Mechanismus wie etwa PAM (pluggable authentication module) verwendet, so kann unter Umständen ohne Wissen der Services auch der bestehende Mechanismus von Benutzername/Passwort so erweitert werden, dass im Hintergrund eine stärkere Authentisierung zur Anwendung kommt: Der Benutzer gibt dann im Feld Passwort zum Beispiel die Kombination von Passwort und Token ein - die Eingabe wird vom Authentisierungs-Modul wieder aufgesplittet und separat verwendet. Die Einschränkung ist aber unter Umständen gross: Challenge-Response Systeme sind so nicht machbar.</p> Einschränkung der KommunikationspartnerDie möglichen Benutzer der Services werden aufgrund netzwerk-technischer Merkmale eingeschränkt und nicht zugelassene Partner erhalten gar keine Möglichkeiten zur Interaktion mit dem System. Die IP-Adresse bietet sich hier exemplarisch an, je nach Netz-Topologie sind aber auch weitere Attribute vorstellbar. Analogien sind im Bereich ACL (access control list) zu finden. TCP-Wrapper ist eine Implementation dieses Schemas. Basierend auf der Konfiguration (meist /etc/hosts.allow und /etc/hostss.deny) erlaubt es den Zugriff auf einen Netzwerk-Dienst basierend auf IP-Adressen. Während inetd beziehungsweise xinetd diese Funktion von sich aus direkt unterstützen (und damit alle Dienste, die damit gestartet werden), lässt sich die Bibliothek für weitere Services meist optional einbinden - OpenSSH nutzt dies via libwrap. Firewall-Technologien sind eine weitere Möglichkeit (iptables, pf, ..) und bieten grundsätzlich dieselbe Funktionalität. Diese können sowohl auf dem Host selbst als auch auf einem Gateway aktiv sein und ebenfalls mögliche Kommunikations-partner nach Kriterien beurteilen und zulassen oder blockieren. Auch dieser Ansatz ist oft wenig praktikabel, da der Zugriff auf die Dienste gerade eben von überall her garantiert werden soll und die möglichen Kommunikationspartner durchaus auch mit dynamischen IP-Adressen ausgestattet sind, man denke an Breitbandanschlüsse von zuhause (ADSL, Kabel) und sogenannte Dial-Up Benutzer. Programm sshwatchEine vollkommen andere Strategie verfolgen Programme wie etwa sshwatch: Statt nach fixen Zugangs-Listen zu arbeiten, reagieren sie dynamisch auf fehlgeschlagene Authentisierungs-Versuche und sperren die Kommunikationspartner für eine gewisse Zeit mit einer dynamischen Firewall-Regel aus. Dabei werden die Log-Informationen der Services laufend ausgewertet und nach Patterns durchforscht, die Fehlversuche aufzeigen. Die IP-Adresse des Verbindungspartners wird extrahiert und eine neue Firewall-Regel erstellt, die alle Kommunikationsversuche von dieser Adresse unterdrücken. Ist eine gewisse Zeitspanne verstrichen, so wird die Regel wieder gestrichen und weitere Kommunikation ist möglich. Diese reaktive Lösung zeigt schnelle Erfolge und hat den Nebeneffekt, dass die dyanmischen Regeln für alle Services gelten und somit identifizierte Angreifer komplett blockieren, nicht nur für den einen Service. Es sind keine Anpassungen an den beteiligten Services nötig, da nur deren Log-Informationen ausgewertet werden und die erstellten Regeln auf tiefer Ebene greifen. Um das Blockieren von "unschuldigen" Partnern zu verhindern, die effektiv auf fehlerhafte interaktive Eingabe von Login oder Passwort zurückzuführen sind, wird zusätzlich ein Zeitintervall verwendet, innerhalb dem eine gewisse Anzahl fehlgeschlagener Versuche detektiert werden müssen, um den Verbindungspartner zu blockieren. Ist die Attacke aber über einen grossen Zeitraum verteilt (siehe oben unter Zeitverhalten), so führt gerade dieses Intervall wieder dazu, dass der Angriff nicht gesehen wird: Hier ist also ein klassischer Kompromiss zwischen Sicherheit und Funktionalität nötig. Es sei hier nicht verschwiegen, dass die Strategie dieser Methode eine potentielle Gefahr birgt: Jedwelche dynamisch erstellten Regeln erlauben im Prinzip einen Denial-of-Service Angriff, dann nämlich, wenn die Identifikation des vermeintlichen Angreifers fingiert werden kann. Für TCP-Verbindungen ist dies allerdings sehr unwahrscheinlich und die Software greift nur dann, wenn ein fehlgeschlagener Authentisierungs-Versuch diagnostiziert wurde, ein Vorgang, der einen kompletten Hand-Shake sowohl auf der TCP-Ebene als auch auf der Ebene der Applikation benötigt und ein sogenanntes Spoofing quasi verunmöglicht. |
|
|
Last Modified: 20.01.2008 17:18 | Copyright © 2003-2024 by tor.ch | Top
|
|
Die
benutzten Passwörter für diese Art von Attacke werden meist mithilfe
eines Wörterbuchs generiert, das die Grundlage für eine Vielzahl von
Permutationen bietet - eine Wörterbuch-Attacke (Dictionnary Attack).
Daher rührt auch die Warnung etlicher Betriebssysteme bei der Qualitätsprüfung
von neuen Passworten, dass das neue Passwörter oder Teile davon in
einem Wörterbuch vorkommen und daher nicht empfehlenswert seien.
Die
beiden Services SSH und FTP bieten sich als gutes Praxisbeispiel an,
da sie häufig in produktiven Umgebungen und auch bei Webhostern anzutreffen
sind, die sowohl administrativen Zugang via SSH als auch File-Transfer
mittels FTP anbieten. 