Archive for the ‘Linux’ Category
Bruteforce Attacken blocken
Nachdem ich heute einmal meine Logfiles durchgegangen war, ist mir aufgefallen, wie viele verschiedene Hosts mitlerweile permanent damit beschäftigt sind Bruteforce-Attacken auf meinen SSH-Port durchzuführen. Echt unterhaltsam zu sehen, welche Logins hier teilweise durchprobiert werden. Um diese Hosts nun zu blocken bin ich im Internet auf mehrere Möglichkeiten gestossen. Ich wollte es eigentlich sportlich sehen und selber etwas scripten, bin dann aber auf ein Tool Namens »fail2ban« gestossen, welches in den Debian- und Ubuntu-Repositories enthalten ist und ganz einfach über
1 | aptitude install fail2ban whois |
installiert werden kann. »Whois« wird hier als optionale Abhängigkeit gleich mit installiert und bei dem Versand von Mails dazu genutzt, nützliche Informationen über den Angreifer-Host mitzuliefern, hierzu gleich mehr. Kurz überprüft ob der Daemon auch gestartet wurde, ist nun im Prinzip schon alles Wichtige getan. Administratoren mehrerer Server können so also sehr schnell zusätzliche Sicherheit in ihre Systeme bringen.
Iptables deaktivieren
Auf Systemen, auf denen »iptables« schon eingesetzt wird, bzw. ein anderes Firewall-Script die Hoheit über das durchaus schnell chaotisch wirkende Regelwerk hat, kann es sinnvoll sein, von »iptables« auf die »/etc/hosts.deny«-Methode auszuweichen. Jeder Host, der z.B. zu viele SSH-Anfragen getätigt hat, wird dann über die »/etc/hosts.deny« komplett geblockt. Hierzu kann die Datei »/etc/fail2ban/jail.conf« in Zeile 45 folgendermassen verändert werden:
1 | banaction = hostsdeny |
Mailversand aktivieren
Es ist natürlich jedem selbst überlassen, ob er bei jedem Ban mit E-Mails belästigt werden möchte. Per Default ist es erst einmal deaktiviert und das ist sicher auch gut so, wenn ich sehe was bei mir hier momentan alles eingeht. Die Tätigkeiten von »fail2ban« werden lückenlos in der Datei »/var/log/fail2ban.log« protokoliert, wer trotzdem per Mail informiert werden möchte kann dies in der Datei »/etc/fail2ban/jail.conf« in Zeile 34 und 72 aktivieren:
1 2 | destemail = my@mailaddress.xyz action = %(action_mwl)s |
»action_mwl« bewirkt, dass neben dem Whois-Report über den Angreifer auch alle relevanten Logeinträge angehängt werden
Sollte jemand Erfahrungen mit anderen Tools gesammelt haben, evtl. auch richtigen »IDS«, die schnell und ohne großen Anpassungsaufwand eingesetzt werden können, würde ich mich über einen Kommentar freuen.
Ping auf einen TCP-Port
Da soll also ein kritischer Server, der unter VMWare in der DMZ läuft, per VMotion verschoben werden. Nur wie wird das Ganze überwacht? Im Normalfall lasse ich hier einen Ping laufen, einfach um zu sehen, dass das Zielnetz auf dem neuen Host auch vernünftig durchgereicht wird und der Server durchgehend erreichbar bleibt. Per ICMP-Echo ist die gute Maschine in der DMZ aber nicht erreichbar, also per WHILE-Schleife ein »Ping« auf Port 80. So die einfache Idee, leicht erweitert sollte das folgende Script in keiner Tools-Sammlung fehlen:
tcpping.sh:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | #!/bin/sh if [ $# != 2 ]; then echo "Usage: $0 <HOST> <PORT>" exit 1 fi i=0 while (true) do TIME=`date +%s%N| cut -c -13` SCAN=`nmap -P0 -p$2 $1` if [ $? != 0 ]; then exit 1; fi echo $SCAN |grep open >/dev/null if [ $? != 0 ]; then echo tcp ping from $1 port $2: tcp_seq\=$i time\=$(($((`date +%s%N| cut -c -13`-$TIME))))ms timeout else echo tcp ping from $1 port $2: tcp_seq\=$i time\=$(($((`date +%s%N| cut -c -13`-$TIME))))ms fi sleep 1 i=$((i+1)) done |
j-zero, der bei der Umsetzung geholfen hat, wird das Script sicherlich noch um das eine oder andere Feature erweitern.
Ubuntu Hardy auf IBM Blade HS21 XM (7995)
Wer Ubuntu Hardy (8.04) nativ auf einem IBM Blade vom Typ HS21 XM (7995) einsetzt, sollte einmal überpüfen, ob das System bei Volllast nicht unerwartet in einen Freeze läuft. Bei uns ist dies nun zum 2. Mal aufgetreten (siehe Bild), beim ersten Mal hatte der Blank-Screen den Absturzgrund erfolgreich verstecken können, Logeinträge bleiben hier natürlich ebenfalls aus. Da es sich um keinen Hardwarefehler handelt, hüllt sich ebenfalls auch das Eventlog vom Bladecenter in Schweigen.
Der »Konsolen-Bildschirmschoner« lässt sich über folgenden Eintrag in der »/etc/rc.local« abschalten (hinterher muss natürlich entweder neu gestartet oder »/etc/rc.local« einmalig manuell über tty1 ausgeführt werden):
1 | /bin/sh -c 'setterm -blank 0 -powersave off -powerdown 0 < /dev/console > /dev/console 2>&1' |
Kurze Zeit später ist der Fehler erneut aufgetreten, das hängende »htop« hat noch 3 CPU-Kerne auf 100% angezeigt, in der Console war folgender Fehler zu erkennen (siehe auch Bild):
1 2 3 4 5 6 | Uhhuh. NMI received for unknown reason 00 on CPU 2. Do you have a strange power saving mode enabled? Dazed and confused, but trying to continue Uhhuh. NMI received for unknown reason 00 on CPU 3. Do you have a strange power saving mode enabled? Dazed and confused, but trying to continue |
Um den Fehler nun zu umgehen, wird der Kernelaufruf um die Parameter »nmi_watchdog=0 nohpet« ergänzt. Die Kernelparameter werden dafür in der Datei »/boot/grub/menu.lst« folgendermassen editiert:
1 | # kopt=nmi_watchdog=0 nohpet root=UUID=abcdefgh-ijkl-1234-mnop-qrstuvwxyz ro |
Im Anschluss wird die menu.lst über »update-grub« aktualisiert, das System kann neu gestartet werden und sollte nun auch unter Volllast stabil laufen. Bei mir tut es dies nun seit 3 Tagen.
You are currently browsing the archives for the Linux category.