Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
|
tux:blockhosts [2011/04/22 13:43] wikisysop [Testen der Konfiguration] |
tux:blockhosts [2011/04/22 14:50] (aktuell) wikisysop [Server Dienst Zugangskontrolle: BlockHosts Skript] |
||
|---|---|---|---|
| Zeile 4: | Zeile 4: | ||
| 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. | 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. | + | 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 in Verbindung mit dem freien FTP-Server [[:tux/vsftpd|»vsftpd«]]((http://vsftpd.beasts.org/)). |
| ==== Vorraussetzungen: ==== | ==== Vorraussetzungen: ==== | ||
| Zeile 63: | Zeile 63: | ||
| ==== Konfiguration ==== | ==== 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 sich selbst versehentlich selbst aussperrt. 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. | + | 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: | Kommentieren Sie in der Datei <fc #008000>/etc/blockhosts.cfg</fc> folgende Zeilen aus: | ||
| Zeile 166: | Zeile 166: | ||
| === false positive === | === 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 Blau markiert) aus der <fc #008000>/etc/hosts.allow</fc> zu löschen: | + | 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: |
| - | <box round|/etc/hosts.allow> | + | <code xorg_conf|/etc/hosts.allow> |
| #---- BlockHosts Additions | #---- BlockHosts Additions | ||
| - | <fc #0000FF>ALL: 192.168.172.1 : deny | + | ALL: 192.168.172.1 : deny # ← DELETE |
| - | #bh: ip: 192.168.172.1 : 8 : 2010-04-25 02:29:46 CEST</fc> | + | #bh: ip: 192.168.172.1 : 8 : 2010-04-25 02:29:46 CEST # ← DELETE |
| #bh: logfile: /var/log/secure | #bh: logfile: /var/log/secure | ||
