Server Dienst Zugangskontrolle: BlockHosts Skript [prontosystems.org]

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
[[:tux|{{ :linux.png?40|}}]]
===== Server Dienst Zugangskontrolle: BlockHosts Skript =====

Wer zB einen öffentlich zugänglichen FTP-Server betreibt, kennt das Szenario: Beim checken der Server Logs wird das Logfiles mit zahlreichen fehlgeschlagenen Anmeldeversuchen förmlich zugespammt. Ich konnte zB auf unseren Servern in Spitzenzeiten mehrere Hunderttausend fehlgeschlagener Anmeldeversuche in einer Nacht feststellen. Meist harmlos, weil da einfach mittels Brute Force((http://de.wikipedia.org/wiki/Brute-Force-Methode)) versucht wird das Passwort zu knacken. IdR ist dies ein Zeichen dafür, dass harmlose Script Kiddies ihr Unwesen treiben. Der unangenehme Nebeneffekt dieser Aktionen besteht allerdings darin, dass das Logfile nicht mehr vernünftig ausgewertet werden kann und die Gefahr steigt, zwischen den endlosen Zeilen doch mal eine wichtige Meldung zu übersehen. Dazu gesellt sich noch die nicht zu unterschätzende Last am Server und der meist begrenzten Internet Bandbreite.

Man kann diese Art eines Angriffs abwehren, in dem man bei jedem Anmeldeversuch die Logfiles der zu schützenden Dienste nach fehlerhaften Anmeldeversuchen durchsucht und bei einer bestimmten Anzahl fehlerhaften Anmeldeversuche die IP-Adresse des Angreifers für einen bestimmten Zeitraum blockiert. Eine mögliche Variante für dieses Szenario ist das Phyton Script <fc #008000>BlockHosts</fc>((http://www.aczoom.com/cms/blockhosts)). Die IP Adresse des Angreifers wird nach Erreichen einer bestimmten Anzahl fehlerhaften Anmeldeversuche entweder vorübergehend in die Datei <fc #008000>/etc/hosts.allow</fc>((http://linux.die.net/man/5/hosts.allow)) mit dem <fc #008000>deny-Flag</fc> eingetragen oder die Systemfirewall <fc #008000>iptables</fc> wird mit einer <fc #008000>Drop Regel</fc> konfiguriert bzw. es kann ein <fc #008000>Null-Routing</fc> konfiguriert werden, um die TCP-Pakete des Angreifers im Nirvana verschwinden zu lassen. Dieses Tutorial beschränkt sich auf die hosts.allow Variante.  

==== Vorraussetzungen: ====
  * Python 2.3 oder neuer
  * Die zu überwachenden Dienste müssen über den TCP-Wrapper((http://en.wikipedia.org/wiki/TCP_Wrapper)) gestartet werden

Überprüfen Sie ob >>Python<< auf dem System vorhanden ist:

<xterm>vmdebian3:/etc/# <fc #008000>which python</fc>
/usr/bin/python
vmdebian3:/etc/# <fc #008000>python <nowiki>--version</nowiki></fc>
Python 2.5.2
</xterm>

==== Installation: ====

Laden Sie sich den Quellcode des BlockHost Skripts von der Webseite herunter und entpacken es:

<xterm>vmdebian3:/etc# <fc #008000>cd /tmp/</fc>
vmdebian3:/tmp# <fc #008000>wget <nowiki>http://www.aczoom.com/tools/blockhosts/BlockHosts-2.4.0.tar.gz</nowiki></fc>
vmdebian3:/tmp# <fc #008000>tar -xvf BlockHosts-2.4.0.tar.gz</fc>
vmdebian3:/tmp# <fc #008000>ls -l</fc>
insgesamt 76
drwxr-xr-x 5  500 users  4096 18. Mai 2008  BlockHosts-2.4.0
-rw-r--r-- 1 root root  57467 18. Mai 2008  BlockHosts-2.4.0.tar.gz
vmdebian3:/tmp# <fc #008000>cd BlockHosts-2.4.0</fc>
vmdebian3:/tmp/BlockHosts-2.4.0# <fc #008000>ls</fc>
bhrss.html  blockhosts.cfg   blockhosts.py  <fc #0000FF>INSTALL</fc>  logrotate.d  MANIFEST  README  <fc #0000FF>setup.py</fc>  test_data
bhrss.py    blockhosts.html  CHANGES	    LICENSE  logwatch	  PKG-INFO  setup.cfg  test_blockhosts.py
</xterm> 
\\ 
Führen Sie für eine Neuinstallation das Python Skript <fc #008000>setup.py</fc> aus. Für detaillierte Information lesen Sie bitte das <fc #008000>INSTALL</fc> File im BlockHosts Verzeichnis:

<xterm>vmdebian3:/tmp/BlockHosts-2.4.0# <fc #008000>python setup.py install <nowiki>--force</nowiki></fc>
running install
running build
running build_scripts
creating build
creating build/scripts-2.5
copying and adjusting blockhosts.py -> build/scripts-2.5
copying and adjusting bhrss.py -> build/scripts-2.5
changing mode of build/scripts-2.5/blockhosts.py from 644 to 755
changing mode of build/scripts-2.5/bhrss.py from 644 to 755
running install_scripts
copying build/scripts-2.5/bhrss.py -> /usr/bin
copying build/scripts-2.5/blockhosts.py -> /usr/bin
changing mode of /usr/bin/bhrss.py to 755
changing mode of /usr/bin/blockhosts.py to 755
running install_data
copying blockhosts.cfg -> /etc
copying logrotate.d/blockhosts -> /etc/logrotate.d
running install_egg_info
Writing /usr/lib/python2.5/site-packages/BlockHosts-2.4.0.egg-info
vmdebian3:/tmp/BlockHosts-2.4.0#
</xterm>


==== Konfiguration ====

Die zentrale Konfigurations-Datei von BlockHosts ist <fc #008000>/etc/blockhosts.cfg</fc>. Hier werden wir das Skript unseren Bedürfnissen anpassen. Des Weiteren ist die <fc #008000>/etc/hosts.allow</fc> das zentrale Blockhost File. Hier ist es sinnvoll auch eine Whitelist anzulegen, um zu verhindern, dass wichtige Kunden oder möglicherweise sogar Sie selbst versehentlich ausgesperrt werden. Letzteres wäre vor allem bei SSH peinlich. Da der TCP-Wrapper bei jedem Aufruf eines Dienstes diese Datei auswertet, wird auch hier der Aufruf des BlockHosts Skripts platziert. So wird sichergestellt, dass das Skript bei jedem Aufruf eines Dienstes die Logfiles der konfigurierten Dienste überprüft werden und ggf die Sperrliste aktualisiert wird.

Kommentieren Sie in der Datei <fc #008000>/etc/blockhosts.cfg</fc> folgende Zeilen aus:

<code xorg_conf|/etc/blockhosts.cfg>
HOSTS_BLOCKFILE = "/etc/hosts.allow"
HOST_BLOCKLINE = ["ALL: ", " : deny"]
COUNT_THRESHOLD = 7
AGE_THRESHOLD = 12
LOGFILES = [ "/var/log/vsftpd.log", ]
</code> 

Fügen Sie in der Datei <fc #008000>/etc/hosts.allow</fc> folgende Zeilen am Ende ein:

<code xorg_conf|/etc/hosts.allow>
#---- BlockHosts Additions
#---- BlockHosts Additions

vsftpd: ALL: spawn (/usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow
</code>

Führen Sie das Script <fc #008000>blockhosts.py <nowiki>--verbose</nowiki></fc> im entpackten BlockHosts Paket aus. Dadurch werden die konfigurierten Logfiles das erste mal ausgewertet und der Offset festgelegt, ab wann das Logfile gelesen werden soll. Dadurch wird verhindert, dass bei bereits laufenden Servern beim ersten produktiven Lauf sämtliche FAIL LOGIN Einträge auswertet und alle bislang bestehenden Hosts mit fehlerhaften Logins auf einmal gesperrt werden. Des Weiteren werden weitere Tags in die Datei <fc #008000>/etc/hosts.allow</fc> eingefügt.

<xterm>vmdebian3:~# <fc #008000>cd /tmp/BlockHosts-2.4.0/</fc>
vmdebian3:/tmp/BlockHosts-2.4.0# <fc #008000>blockhosts.py <nowiki>--verbose</nowiki></fc>
blockhosts 2.4.0 started: 2010-04-25 02:02:07 CEST
 ... loaded /etc/hosts.allow, starting counts: blocked 0, watched 0
 ... loading log file /var/log/secure, offset: 0
 ... loading log file /var/log/vsftpd.log, <fc #0000FF>offset: 4621</fc>
 ... discarding all host entries older than  2010-04-24 14:02:07 CEST
 ... final counts: blocked 0, watched 0
</xterm>

**Fertig**

==== Testen der Konfiguration ====

Eine Blockhosts konfigurierte <fc #008000>/etc/hosts.allow</fc> ohne bisher fehlerhaften Anmeldung sieht folgendermaßen aus:

<code xorg_conf|/etc/hosts.allow>
#---- BlockHosts Additions

#bh: logfile: /var/log/vsftpd.log
#bh: offset: 4621
#bh: first line:Sat Apr 24 21:42:16 2010 [pid 3363] CONNECT: Client "127.0.0.1"

#---- BlockHosts Additions

vsftpd: ALL: spawn (/usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow
</code>

Beim ersten fehlerhaften Anmeldeversuch eines Clients wird dem Blockhost Abschnitt folgender Eintrag hinzugefügt:

<code xorg_conf|/etc/hosts.allow>
#---- BlockHosts Additions
#bh: ip:   192.168.172.1 :   1 : 2010-04-25 02:19:55 CEST

#bh: logfile: /var/log/secure
#bh: offset: 0
#bh: first line:

#bh: logfile: /var/log/vsftpd.log
#bh: offset: 4837
#bh: first line:Sat Apr 24 21:42:16 2010 [pid 3363] CONNECT: Client "127.0.0.1"

#---- BlockHosts Additions

vsftpd: ALL: spawn (/usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow
</code> 

<note important>Beachten Sie, dass die Datei <fc #008000>/etc/hosts.allow</fc> immer nur beim **Aufruf** eines Dienstes ausgewertet wird. Ist dem FTP-Server in seiner Konfiguration kein Limit bei den fehlerhaften Logins gesetzt, laufen alle Login Versuche in **einer Session** ab. Solange der Angreifer seinen Versuch nicht abbricht, wird BlockHosts diesen Angriff nicht abwehren können. Konsultieren Sie hierfür die Konfigurations-Datei Ihres FTP-Servers. Ein Beispiel finden Sie hier: [[:tux:vsftpd#konfiguration|-> vsftpd Konfiguration]]</note>

Wird die konfigurierte Anzahl der fehlerhaften Anmeldeversuche - in unserem Beispiel 7 (+1) weil die Auswertung des Skripts immer einen Anmeldeversuch hinterher hinkt - erreicht, die sich idR noch mit der in der FTP-Server Konfiguration eingestellten Anzahl fehlerhaften Anmeldungen - in meiner vsftpd.conf sind das 3 - multipliziert, wird nach spätestens 24 fehlerhaften Logins für den Client der Zugang zu allen Diensten (ALL:) für die in der blockhosts.cfg konfigurierten Zeit (hier 12 Std.) untersagt. Es ist nicht sinnvoll eine längere Zeit einzustellen oder weniger FAIL LOGINs zu konfigurieren, da meiner Erfahrung nach Angriffe sehr schnell wieder aufgegeben werden, wenn solche Schutzmechanismen festgestellt werden und weiterhin noch immer noch genügend Kunden geblockt werden. Der Eintrag in der <fc #008000>/etc/hosts.allow</fc> sieht bei einem geblockten Host wie folgt aus:

<code xorg_conf|/etc/hosts.allow>
ALL:   192.168.172.1 : deny

#bh: ip:   192.168.172.1 :   8 : 2010-04-25 02:29:46 CEST

#bh: logfile: /var/log/secure
#bh: offset: 0
#bh: first line:

#bh: logfile: /var/log/vsftpd.log
#bh: offset: 5423
#bh: first line:Sat Apr 24 21:42:16 2010 [pid 3363] CONNECT: Client "127.0.0.1"

#---- BlockHosts Additions

vsftpd: ALL: spawn (/usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow
</code>

Der Login am Server sieht für den Angreifer dann wie folgt aus:

<xterm>$ <fc #008000>ftp 192.168.172.132</fc>
Connected to 192.168.172.132.
<fc #0000FF>421 Service not available, remote server has closed connection.</fc>
</xterm>

**Note:** Testen Sie Ihre Konfiguration nicht auf der lokalen Maschine, weil der <fc #008000>localhost</fc> in einer Whitelist steht und nicht vom BlockHosts Skript berücksichtigt wird!

=== false positive ===

Häufig genug kommt es vor, dass auch Kunden oder gar Mitarbeiter in der <fc #008000>/etc/hosts.allow</fc> geparkt werden. Das bekommen Sie relativ rasch mit, wenn sich Support Anfragen in dieser Richtung häufen. Es reicht dann aus die beiden dazugehörigen Zeilen (hier mit <fc #008000># ← DELETE</fc>) aus der <fc #008000>/etc/hosts.allow</fc> zu löschen:

<code xorg_conf|/etc/hosts.allow>
#---- BlockHosts Additions
ALL:   192.168.172.1 : deny # ← DELETE

#bh: ip:   192.168.172.1 :   8 : 2010-04-25 02:29:46 CEST # ← DELETE

#bh: logfile: /var/log/secure
#bh: offset: 0
#bh: first line:

#bh: logfile: /var/log/vsftpd.log
#bh: offset: 5423
#bh: first line:Sat Apr 24 21:42:16 2010 [pid 3363] CONNECT: Client "127.0.0.1"

#---- BlockHosts Additions

vsftpd: ALL: spawn (/usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 )& : allow
</code>

Sie können auch hergehen und bekannte Kunden mit zB fester IP Adresse direkt whitelisten, diese werden vom BlockHosts Skript dann ignoriert. Fügen Sie dazu in der Datei <fc #008000>/etc/hosts.allow</fc> vor dem BlockHosts Abschnitte einfach die IP Adresse ($Customer_IP) nach folgenden Muster ein:

<code xorg_conf|/etc/hosts.allow>
$Customer_IP : allow
#---- BlockHosts Additions
#---- BlockHosts Additions
</code>

==== Probleme ====

Die deny-Anweisung für ALL:, was alle Services betrifft, kann uU von einem Angreifer missbraucht werden, um Sie selbst oder Ihr ganzes Unternehmen zu blockieren. Stellen Sie sich folgendes Szenario vor: Sie betreiben einen eigenen DNS-Server, der von den Clients Ihres Unternehmens zur Auflösung der Internet URL Anfragen verwendet wird. Auf diesen Server betreiben Sie zur Absicherung des SSH Zugangs das Blockhost Script, mit einer finalen ALL: IP: deny Regel. Der Angreifer könnte jetzt hergehen und Ihre öffentliche IP Adresse Ihres Unternehmens spoofen (d.h. Ihre IP Adresse als eigene Absender Adresse zu verwenden) und solange mit dieser IP Adresse Ihr BlockHost Skript auf den DNS-Server mit fehlgeschlagenen Anmeldeversuchen zu provozieren, bis seine (bzw. Ihre) IP-Adresse von Ihrem DNS-Server geblockt wird. Und mit der ALL: Anweisung für jeden Dienst, was auch DNS bedeutet. Das Ende der Aktion ist, dass Sie Ihr eigener DNS Server blockiert, was zur Folge hat, dass Sie das Internet nicht mehr benutzen können und für die konfigurierte Zeit auch nicht mehr per SSH auf den DNS Server kommen um, das Problem zu beseitigen. Sie werden aber vermutlich schon die Halbe Zeit mit der Fehlersuche verbringen. Die Lösung für dieses Szenario wäre in der Datei /etc/hosts.allow nur die Dienste zu blockieren, die angegriffen werden. Nur mal so im Hinterkopf behalten... 

**have fun and enjoy**
\\ 
**Verwandte Artikel:**
[[:tux:fail2ban|-> Server Zugangskontrolle: fail2ban]]
[[:tux:vsftpd|-> VSFTP Installation und Konfiguration]]
[[:tux:ftp_script|-> FTP Session automatisieren]]
[[:it:ftp_smtp|-> E-Mail vs FTP]]

 --- //pronto 2010/04/25 02:33//
{{keywords>/etc/hosts.allow script login anmeldeversuche fehlgeschlagen linux debian ftp ssh}}