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

Weiße Weste

Einem befugten Nutzer gestattet SSH Guard mit seiner Arbeitsweise genügend Versuche, sich an sein Passwort zu erinnern. Möchte der Administrator jedoch etwa in einem sicheren LAN gezielt einen bestimmten Rechner von sämtlichen Strafmaßnahmen ausnehmen, übergibt er dessen IP-Adresse »sshguard« mit dem Parameter »-w« :

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

In diesem Beispiel landet der Computer mit der IP-Adresse 192.168.0.101 auf der internen Whitelist von SSH Guard und hat ab sofort beliebig viele Login-Versuche frei. Sollen mehrere Adressen auf die Whitelist, hängt der Admin sie jeweils mit einem weiteren »-w« an:

sudo sshguard -l /var/log/auth.log -w 192.168.0.101 -w 192.168.0.102 -w 192.168.0.103

Einen Adressenbereich gibt er in CIDR-Notation an. Das nachfolgende Beispiel setzt alle IP-Adressen von 192.168.0.1 bis 192.168.0.255 auf die Whitelist:

sudo sshguard -l /var/log/auth.log -w 192.168.0/24

Alternativ sind natürlich auch Hostnamen erlaubt:

sudo sshguard -l /var/log/auth.log -w freund.example.com

Hier landen alle IP-Adressen auf der Whitelist, auf die das DNS den Namen »freund.example.com« auflöst.

Ist ein LAN recht groß, mutiert der SSH-Guard-Aufruf schnell zu einem unübersichtlichen Bandwurm. Aus diesem Grund kann der Administrator alle Whitelist-Adressen in einer Textdatei speichern. Sie muss in jeder Zeile eine IP-Adresse, einen Adressbereich in CIDR-Notation oder einen Domainnamen enthalten. Zeilen mit einer Raute ignoriert das Tool. Listing 1 zeigt ein Beispiel für eine Whitelist-Datei. Heißt die Datei »whitelist.txt« , übergibt der Administrator sie an SSH Guard einfach via »-w« :

Listing 1

Whitelist-Beispiel

 

sudo sshguard -l /var/log/auth.log -w /etc/whitelist.txt -w 192.168.0.103

Wie das Beispiel außerdem zeigt, darf er noch beliebig viele weitere Adressen zusätzlich angeben.

Arbeitet SSH Guard wie geplant, kann der Administrator das Werkzeug in die Startskripte aufnehmen. Hierbei ist er allerdings wieder auf sich allein gestellt. Noch nicht einmal eine Vorlage für das verbreitete Sys-V-Init liegt dem SSH-Guard-Archiv bei. Wie er selbst ein solches Skript schreibt, verrät ihm unter anderem eine kleine Artikelserie des Schwestermagazins "LinuxUser" [8] .

Fazit

SSH Guard verhindert effektiv Brute-Force-Angriffe – nicht mehr und nicht weniger. Die Liste der unterstützten Dienste ist zudem noch recht kurz. Das Werkzeug kann folglich kein echtes Intrusion-Detection-System ersetzen, aber mitunter sinnvoll ergänzen. Dann punktet es mit einer einfachen und schnellen Installation – vorausgesetzt der Admin verheddert sich nicht in den Einstellungen der eigenen Firewall.

Log Validation

Syslog und Syslog NG schreiben vor jeden Log-Eintrag die Identifikationsnummer (PID) des zugehörigen Prozesses. Diese Information kann SSH Guard nutzen, um die Herkunft der Log-Meldungen zu verifizieren. Ein hinterhältiger lokaler Nutzer kann dann nicht mehr falsche Log-Meldungen einschleusen und so SSH Guard absichtlich den Rechner eines Kollegen sperren lassen. Diese Maßnahme ist aber nur bei Syslog- und Syslog-NG-Dateien notwendig, die Informationen von verschiedenen Diensten einsammeln. Generiert ein Daemon seine eigene Logdatei, genügt es bereits, die Zugriffsrechte auf den Benutzer Root einzuschränken.

Dummerweise stolpert der mit Version 1.5 eingeführte Log Sucker über die Log Validation: Bis der Log Sucker einen neuen Log-Eintrag bemerkt und eingelesen hat, vergeht eine kurze Zeit. Dies führt in einigen Fällen dazu, dass SSH Guard fälschlicherweise einen manipulierten Eintrag annimmt. Das Problem wollen die Entwickler erst in einer der nächsten SSH-Guard-Versionen angehen, bis dahin raten sie von einem gemeinsamen Einsatz von Log Sucker und Log Validation ab.

Wer die Log Validation unbedingt nutzen möchte, muss zunächst sein System so einrichten, dass es SSH Guard über die Standardeingabe mit Logs füttert. Anschließend schlägt er unter [7] den zu seinem Dienst passenden Servercode nach. Der SSH-Daemon besitzt beispielsweise die Nummer 100.

Anschließend benötigt er noch den Speicherort seiner PID-Datei. Unter Ubuntu 10.10 wäre dies »/var/run/ssh.pid« . Diese beiden Informationen übergibt der Administrator an SSH Guard als Parameter:

sshguard -f 100:/var/run/ssh.pid

Nach dem gleichen Schema hängt er weitere PIDs an. Wichtig ist der jetzt fehlende Parameter »-l« (für den L og Sucker), ohne den SSH Guard die Logs über die Standardeingabe entgegennimmt.

Infos

  1. SSH Guard: http://www.sshguard.net/
  2. Angriffsmuster einreichen: http://www.sshguard.net/support/attacks/submit/
  3. Installationshinweise für alle unterstützten Firewalls: http://www.sshguard.net/docs/setup/
  4. Firewall-Einstellungen speichern unter Ubuntu: https://help.ubuntu.com/community/IptablesHowTo
  5. Firewall-Einstellungen speichern unter Debian: http://www.debian-administration.org/articles/445
  6. Angriffssignaturen: http://www.sshguard.net/docs/reference/attack-signatures/
  7. Service-Codes: http://www.sshguard.net/docs/reference/service-codes/
  8. Tim Schürmann, "Der Nächste, bitte! – Sys-V-Init und die Runlevel": LinuxUser 12/2010

Der Autor

Tim Schürmann ist selbstständiger Diplom-Informatiker und derzeit als freier Autor unterwegs. Zu seinen Büchern gesellen sich zahlreiche Artikel, die in Zeitschriften und auf Internetseiten in mehreren Ländern erscheinen.

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

SSHGuard 2.1 veröffentlicht

Eine neue Version der Abwehrsoftware steht zum Download bereit.

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