Thematischer Schwerpunkt dieser Ausgabe ist die kontinuierliche Überwachung von Servern, Clients und anderen Geräten im Netzwerk: mit dem IPMI-Plugin, dem ... (mehr)

Einfache Log-Beobachtung

Dank Log Sucker entfällt die umständliche Konfiguration, wie sie in früheren SSH-Guard-Versionen notwendig war. Dort waren Syslog & Co. so einzurichten, dass sie SSH Guard ihre Logs zuspielten. Stattdessen muss der Administrator nun nur noch herausfinden, in welcher Datei die Logdaten der unterstützten Dienste liegen. Unter Debian und Ubuntu landen beispielsweise alle Meldungen über fehlgeschlagene SSH-Logins in »/var/log/auth.log« , während Open Suse 11.3 sie unter »/var/log/messages« sammelt. Den gesamten Pfad zur Logdatei übergibt man mit dem Parameter »-l« :

sudo sshguard -l /var/log/auth.log

Dieser beobachtet jetzt beständig die »auth.log« und entdeckt dabei zwangsläufig auch fehlgeschlagene SSH-Logins. Sollten diese überhand nehmen, setzt SSH Guard eine entsprechende Firewallregel ab. Sofern die anderen Dienste ebenfalls ihre Logdaten in »auth.log« ablegen, berücksichtigt SSH Guard auch sie. Eine explizite Konfiguration von FTP & Co. ist somit nicht notwendig.

Soll SSH Guard mehrere Logdateien im Auge behalten, erfährt es die Pfade einfach über weitere »-l« -Parameter. In

sudo sshguard -l /var/log/auth.log -l -

dient das »-« -Zeichen dazu, es über die Standardeingabe mit Daten zu füttern.

Drum prüfe, wer sich bindet

Nun sollte der Admin prüfen, ob die Blockade reibungslos funktioniert. Im Folgenden geschieht dies am Beispiel von SSH, die anderen von SSH Guard beobachteten Dienste prüft er nach dem gleichen Prinzip. Da auf Debian und Ubuntu standardmäßig kein SSH-Daemon läuft, ist dort gegebenenfalls noch das Paket »openssh-server« zu installieren. Open Suse installiert zwar den »sshd« , sperrt aber den Zugriff mit seiner eigenen Firewall. Um ihn freizuschalten, wählt der Administrator in Yast im Bereich »Sicherheit und Benutzer« die »Firewall« , wechselt im Fenster aus Abbildung 3 zu »Erlaubte Dienste« , stellt unter »Zu erlaubender Dienst« den »Secure Shell-Server« ein und klickt auf »Hinzufügen« . Abschließend startet er noch den SSH-Daemon:

Abbildung 3: Unter Open Suse muss der Administrator zunächst in Yast unter dem Punkt Konfiguration der Firewall: Erlaubte Dienste den Zugriff auf den SSH-Dienst freischalten.
sudo /etc/init.d/sshd start

Um nun SSH Guard auf die Probe zu stellen, loggt der Admin sich von einem anderen Rechner aus per SSH mehrfach mit einem bewusst falschen Passwort ein. Nach fünf Login-Versuchen blockt SSH Guard den Client für ein paar Sekunden. Diesen Vorgang protokolliert das Werkzeug in der zugehörigen Logdatei, unter Debian und Ubuntu also in »/var/log/auth.log« , bei Open Suse in »/var/log/messages« ( Abbildung 4 ). Darüber hinaus zeigt »sudo ipconfig -L« eine neue Firewallregel an, die den Rechner des SSH-Clients aussperrt ( Abbildung 5 ). Für diesen sieht es wiederum so aus, als würde der Server nicht mehr auf seine Anfrage reagieren oder als sei die Verbindung unterbrochen worden.

Abbildung 4: SSH Guard hat einen Angriff entdeckt und den Client für einige Minuten blockiert. Das protokolliert der Daemon selbst in der Logdatei auth.log (hell hervorgehoben).
Abbildung 5: Wie iptables -L in diesem Beispiel verrät, blockiert SSH Guard gerade einen Client (hell hervorgehoben). Den Grund muss der Admin der entsprechenden Logdatei entnehmen.

Je häufiger sich jemand einzuloggen versucht, desto länger dauert die Zwangspause. Irgendwann ist sie so lang, dass sich der Angreifer faktisch ausgesperrt hat. Blacklisting, also eine schwarze Liste mit gesperrten IP-Adressen, ist daher nicht mehr notwendig. Wer dennoch an den Zeiten schrauben möchte, wirft einen Blick in den Kasten "Eingriff" .

Eingriff

Ähnlich wie bei der Verkehrssünderkartei in Flensburg belegt auch SSH Guard jeden Angriffsversuch mit einem bestimmten Punktewert, der Dangerousness. Welche Aktion wie viele Punkte bringt, verrät die SSH-Guard-Homepage [6] . Dort steht auch, welche Log-Einträge SSH Guard als konkreten Angriffsversuch wertet. Die meisten Angriffe bringen zehn Punkte, ab 40 Punkten greift SSH Guard ein. Soll diese Schmerzgrenze höher liegen, erfährt das Werkzeug dies über den Parameter »-a« . Ein

sshguard -l /var/log/auth.log -a 60

schraubt die Dangerousness auf 60 Punkte hoch. Der Parameter »-p« bestimmt, wie viele Sekunden der Angreifer nach der ersten Blockade mindestens warten muss, bis er wieder Zugriff erhält. So würde

sshguard -l /var/log/auth.log -p 15

den Angreifer mindestens 15 Sekunden aussperren. Die tatsächliche Wartezeit bestimmt SSH Guard, sie liegt bei mindestens 15, höchstens bei 3/2 * 15 Sekunden. Zuletzt regelt »-s« , nach wie vielen Sekunden SSH Guard die IP-Adresse des Angreifers wieder vergisst. Wenn bei

sshguard -l /var/log/auth.log -s 20

der Angreifer nach jedem Versuch 20 Sekunden wartet, würde ihn SSH Guard niemals blocken. All diese Parameter darf der Administrator nach eigenem Bedarf beliebig kombinieren.

Bei einem erkannten Angriffsversuch erstellt SSH Guard eine neue Firewallregel, welche die IP-Adresse des Angreifers nur für den unter Beschuss stehenden Dienst blockiert. Wenn sich also jemand wiederholt beispielsweise per SSH einzuloggen versucht, könnte er dies nach der Sperrung auch weiterhin noch per FTP tun. Im Extremfall würde ein Angreifer somit erst nach und nach von allen Diensten und Zugriffen ausgesperrt.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023