dynaperl

Bei dem Munin Plugin “vserver_cpu_” gibt es einen Bug bei mehr als 10 CPU Kernen (0-9). Hier passt dann das grep <cpu> bei Kern 1 nicht nur auf den ersten Kern sondern auch auf alle zwischen 10 und 19.

# diff /usr/share/munin/plugins/vserver_cpu_ /tmp/vserver_cpu_
247,248c247,248
< 				USERCPU=`cat /proc/virtual/$i/sched |grep "cpu $j:"| cut -d' ' -f3`
< 				SYSCPU=`cat /proc/virtual/$i/sched |grep "cpu $j:"| cut -d' ' -f4`
---
> 				USERCPU=`cat /proc/virtual/$i/sched |grep "cpu $j"| cut -d' ' -f3`
> 				SYSCPU=`cat /proc/virtual/$i/sched |grep "cpu $j"| cut -d' ' -f4`

Bei dem Munin Plugin "vserver_cpu_" gibt es einen Bug bei mehr als 10 CPU Kernen (0-9). Hier passt dann das grep &lt;cpu&gt; bei Kern 1 nicht nur auf den ersten Kern sondern auch auf alle zwischen 10 und 19. # diff /usr/share/munin/plugins/vserver_cpu_ /tmp/vserver_cpu_ 247,248c247,248 &lt; USERCPU=`cat /proc/virtual/$i/sched |grep "cpu $j:"| cut -d' ' -f3` &lt; SYSCPU=`cat /proc/virtual/$i/sched |grep "cpu $j:"| cut -d' ' -f4` --- &gt; USERCPU=`cat /proc/virtual/$i/sched |grep "cpu $j"| cut -d' ' -f3` &gt; SYSCPU=`cat /proc/virtual/$i/sched |grep "cpu $j"| cut -d' ' -f4`

Kann man eigentlich Xen und KVM auf dem gleichen Host parallel betreiben? Oder Linux vServer in einem KVM oder Xen Gast? Oder vServer und KVM auf dem gleichen Host? Und kann bei auf einem Host unter Debian Lenny ein vServer Debian Squeeze Gast installieren?

Und wie so will man so was überhaupt tun?

Letzteres beantwortet vermutlich jeder etwas anders nach seinen Vorlieben. Ich persönlich bin ein Fan von Linux vServer. vServer schlägt alle anderen Techniken in Sachen Performance und Resourcen Ausnutzung um Längen und mit den Nachteilen (u.a. kein eigenes Loopback, alle Gäste der gleiche Kernel wie der Host) kann ich super leben. Vorteile sind für mich vor allem die Möglichkeit die Hardware optimal auszunutzen und ein unglaublicher Gewinn an Flexibilität.

Zum Beispiel könnte man auf einem Linux Server ein Windows als KVM-Gast betreiben weil es eine bestimmte Software nur unter Windows gibt man aber eigentlich alles andere unter Linux betreiben möchte. Nun will man aber bestimmte Dienste etwas mehr von einander abschotten um sie später ohne größere Änderungen auf mehrere Server verteilen zu können. Dazu würde ich nun auf dem KVM Host einen Linux vServer Kernel installieren. Nun haben ich die Möglichkeit weitere Linux Gäste zu installiere die sich Arbeitsspeicher und Festplattenlplatz mit dem Host teilen. Ich verwende also KVM und Linux vServer auf dem gleichen Host.

FAQ

Q: KVM und Linux vServer auf dem gleichen Host?
A: Ja

Q: Linux vServer Host in einem KVM oder Xen Gast?
A: Ja, bei Xen muß auf dem Host noch der vServer Kernel installiert werden. Dieser wird dann in der Gast Konfig angegeben.

Q: KVM und VMWare auf dem gleichen Host?
A: Nein,  So lange die Kernel Module kvm und kvm_intel geladen sind erzeugt das Starten eines VMWare Gastes die Fehlermeldung failed to initialize monitor device.

Q: Xen und VMWare auf dem gleichen Host?
A: todo

Q: Xen Host als VMWare Gast?
A: todo

Q: KVM Host als VMWare Gast?
A: todo

Q: Linux vServer Host in einem VMWare Gast?
A: Ja

Q: Auf einem Debian Squeeze vServer Host (kernel 2.6.32) einen Etch oder Lenny Gast starten?
A: Ja

Q: Auf einem Debian Lenny vServer Host (Kernel 2.6.26) einen Etch oder Squeeze Gast starten?
A: Ja

Kann man eigentlich Xen und KVM auf dem gleichen Host parallel betreiben? Oder Linux vServer in einem KVM oder Xen Gast? Oder vServer und KVM auf dem gleichen Host? Und kann bei auf einem Host unter Debian Lenny ein vServer Debian Squeeze Gast installieren? Und wie so will man so was überhaupt tun? Letzteres beantwortet vermutlich jeder etwas anders nach seinen Vorlieben. Ich persönlich bin ein Fan von Linux vServer. vServer schlägt alle anderen Techniken in Sachen Performance und Resourcen Ausnutzung um Längen und mit den Nachteilen (u.a. kein eigenes Loopback, alle Gäste der gleiche Kernel wie der Host) kann ich super leben. Vorteile sind für mich vor allem die Möglichkeit die Hardware optimal auszunutzen und ein unglaublicher Gewinn an Flexibilität. Zum Beispiel könnte man auf einem Linux Server ein Windows als KVM-Gast betreiben weil es eine bestimmte Software nur unter Windows gibt man aber eigentlich alles andere unter Linux betreiben möchte. Nun will man aber bestimmte Dienste etwas mehr von einander abschotten um sie später ohne größere Änderungen auf mehrere Server verteilen zu können. Dazu würde ich nun auf dem KVM Host einen Linux vServer Kernel installieren. Nun haben ich die Möglichkeit weitere Linux Gäste zu installiere die sich Arbeitsspeicher und Festplattenlplatz mit dem Host teilen. Ich verwende also KVM und Linux vServer auf dem gleichen Host. FAQ Q: KVM und Linux vServer auf dem gleichen Host? A: Ja Q: Linux vServer Host in einem KVM oder Xen Gast? A: Ja, bei Xen muß auf dem Host noch der vServer Kernel installiert werden. Dieser wird dann in der Gast Konfig angegeben. Q: KVM und VMWare auf dem gleichen Host? A: Nein,  So lange die Kernel Module kvm und kvm_intel geladen sind erzeugt das Starten eines VMWare Gastes die Fehlermeldung failed to initialize monitor device. Q: Xen und VMWare auf dem gleichen Host? A: todo Q: Xen Host als VMWare Gast? A: todo Q: KVM Host als VMWare Gast? A: todo Q: Linux vServer Host in einem VMWare Gast? A: Ja Q: Auf einem Debian Squeeze vServer Host (kernel 2.6.32) einen Etch oder Lenny Gast starten? A: Ja Q: Auf einem Debian Lenny vServer Host (Kernel 2.6.26) einen Etch oder Squeeze Gast starten? A: Ja &nbsp;

Damit Webalizer die Logfile Reports auf deutsch erstellt (ja es gibt Leute die das wollen) installiert man das Debian Paket locales und stellt de_DE@euro als Standard ein (oder setzt LC_ALL vor dem Aufruf von Webalizer).

Webalizer V2.01-10 (Linux 2.6.18-6-xen-amd64) locale: C
Using logfile /var/log/apache2/access.log.1 (clf)

apt-get install locales

Webalizer V2.01-10 (Linux 2.6.18-6-xen-amd64) locale: de_DE@euro
Verwende Protokolldatei /var/log/apache2/access.log.1 (clf)

Damit Webalizer die Logfile Reports auf deutsch erstellt (ja es gibt Leute die das wollen) installiert man das Debian Paket locales und stellt de_DE@euro als Standard ein (oder setzt LC_ALL vor dem Aufruf von Webalizer). Webalizer V2.01-10 (Linux 2.6.18-6-xen-amd64) locale: C Using logfile /var/log/apache2/access.log.1 (clf) apt-get install locales Webalizer V2.01-10 (Linux 2.6.18-6-xen-amd64) locale: de_DE@euro Verwende Protokolldatei /var/log/apache2/access.log.1 (clf)

Wie ich schon mal geschrieben habe funktioniert unter Debian Xen und Bonding nicht da das Xen Netzwerk Script nicht mit dem Bond-Interface umgehen kann. Eigentlich hatte ich gedacht das sie diesen offensichtlichen Fehler unter Lenny gefixt haben. Bin ich denn der einzige der auf seinen Xen Servern Bonding verwendet?

Hier gibt es den neuen Patch

Wie ich schon mal geschrieben habe funktioniert unter Debian Xen und Bonding nicht da das Xen Netzwerk Script nicht mit dem Bond-Interface umgehen kann. Eigentlich hatte ich gedacht das sie diesen offensichtlichen Fehler unter Lenny gefixt haben. Bin ich denn der einzige der auf seinen Xen Servern Bonding verwendet? Hier gibt es den neuen Patch

Die Dell R300 Server haben auf dem Board zwei Broadcom NetXtreme Netzwerkkarten für die der Debian Etch Treiber tg3 nicht funktioniert. Die Quellen kann man sich bei Broadcom besorgen und folgendermaßen kompilieren.

apt-get install linux-headers-2.6.18-6-xen-amd64
unzip linux-3.92n.zip
tar xzf tg3-3.92n.tar.gz
cd tg3-3.92n
make KVER=2.6.18-6-xen-amd64
insmod ./tg3.ko
dmesg|tail

Eine weitere Besonderheit ist das die OMSA Tools  (Version 5.5) auf den R300 keinen Storage Controller finden. Für die Lösung ist das Tool lsiutil nötig welches man wie folgt kompiliert.

wget ftp://ftp.lsil.com/HostAdapterDrivers/linux/lsiutil/lsiutil.tar.gz tar xvfz lsiutil.tar.gz
cd lsiutil
rm lsiutil
make
cp lsiutil /usr/local/bin/

Nun kann man mit dem Tool die Laufwerke scannen und nach einem OMSA-Neustart findet OMSA die Laufwerke.

lsiutil -s; /etc/init.d/dataeng restart;

Damit das auch nach einem Neustart funktioniert habe ich mir lsiutil -s am Anfang mit in die /etc/init.d/dataeng gepackt.

Die Dell R300 Server haben auf dem Board zwei Broadcom NetXtreme Netzwerkkarten für die der Debian Etch Treiber tg3 nicht funktioniert. Die Quellen kann man sich bei Broadcom besorgen und folgendermaßen kompilieren. apt-get install linux-headers-2.6.18-6-xen-amd64 unzip linux-3.92n.zip tar xzf tg3-3.92n.tar.gz cd tg3-3.92n make KVER=2.6.18-6-xen-amd64 insmod ./tg3.ko dmesg|tail Eine weitere Besonderheit ist das die OMSA Tools  (Version 5.5) auf den R300 keinen Storage Controller finden. Für die Lösung ist das Tool lsiutil nötig welches man wie folgt kompiliert. wget ftp://ftp.lsil.com/HostAdapterDrivers/linux/lsiutil/lsiutil.tar.gz tar xvfz lsiutil.tar.gz cd lsiutil rm lsiutil make cp lsiutil /usr/local/bin/ Nun kann man mit dem Tool die Laufwerke scannen und nach einem OMSA-Neustart findet OMSA die Laufwerke. lsiutil -s; /etc/init.d/dataeng restart; Damit das auch nach einem Neustart funktioniert habe ich mir lsiutil -s am Anfang mit in die /etc/init.d/dataeng gepackt.

Der Postfix Policy Daemon Policyd-Weight hat in letzter Zeit einige Änderungen erfahren. So wurde er bei mir in der letzten Version noch durch Postfix gestartet (aus der master.cf) wohingegen er nun als Daemon läuft. Weiterhin gibt es einen Cache-Mechanismus der bei mir auch gleich Probleme bereitete. Bei Tests ist wohl ein Lockfile (/tmp/.policyd-weight/cache_lock) übrig geblieben das nach einem Neustart folgende Fehlermeldung im Mail.log erzeugte:

postfix/policyd-weight[22463]: warning: cache_query: $csock couln’t be created: connect: No such file or directory, calling spawn_cache()

Laut Aussage des Autors sollte besagtes Verzeichnis wenn überhaupt nur ganz kurz existieren (ein Lock eben). Nach dem Löschen des Verzeichnisses gings dann auch.

IPv6 Support gibt es übrigens leider noch nicht. Bei einer IPv6 Mail fällt die Software auf DUNNO (nichts tun) zurück. Gleiches gilt übrigens für die neue Version 2 des postfix-policyd Greylisting Daemons. Allerdings gehen hier die Mails gar nicht durch. Es gibt die Fehlermeldung: ERROR: Protocol data validation error, required parameter ‘client_address’ was not found or invalid format. Die alte 1er Version kommt mit IPv6 Adressen zurecht. Die Adressen werden zwar etwas verstümmelt in der Datenbanktabelle abgelegt aber es funktioniert trotzdem.

Der Postfix Policy Daemon Policyd-Weight hat in letzter Zeit einige Änderungen erfahren. So wurde er bei mir in der letzten Version noch durch Postfix gestartet (aus der master.cf) wohingegen er nun als Daemon läuft. Weiterhin gibt es einen Cache-Mechanismus der bei mir auch gleich Probleme bereitete. Bei Tests ist wohl ein Lockfile (/tmp/.policyd-weight/cache_lock) übrig geblieben das nach einem Neustart folgende Fehlermeldung im Mail.log erzeugte: postfix/policyd-weight[22463]: warning: cache_query: $csock couln't be created: connect: No such file or directory, calling spawn_cache() Laut Aussage des Autors sollte besagtes Verzeichnis wenn überhaupt nur ganz kurz existieren (ein Lock eben). Nach dem Löschen des Verzeichnisses gings dann auch. IPv6 Support gibt es übrigens leider noch nicht. Bei einer IPv6 Mail fällt die Software auf DUNNO (nichts tun) zurück. Gleiches gilt übrigens für die neue Version 2 des postfix-policyd Greylisting Daemons. Allerdings gehen hier die Mails gar nicht durch. Es gibt die Fehlermeldung: ERROR: Protocol data validation error, required parameter 'client_address' was not found or invalid format. Die alte 1er Version kommt mit IPv6 Adressen zurecht. Die Adressen werden zwar etwas verstümmelt in der Datenbanktabelle abgelegt aber es funktioniert trotzdem.

Bei SourceForge gibt es eine ziemlich alte aber gut funktionierende Websieve Version.  In dem Archiv ist auch ein Perl Modul (Sieve.pm) enthalten. Nach dem Update auf Lenny scheint dieses Perl Modul ein Problem mit der neuen Sasl Bibliothek zu haben. Das Perl Modul hängt an den Base64 kodierten String aus Username und Passwort immer noch ein Nullbyte an. Daran stört sich Sasl gibt folgende Fehlermeldung aus:

cyrus/sieve[20978]: badlogin: localhost[127.0.0.1] PLAIN error base64 decoding string

Als Lösung übergibt man der encoding Funktion einen leeren Zeilentrenner. Hier der Patch:

--- Sieve.pm    2008-12-18 17:41:56.779613529 +0100
+++ Sieve_neu.pm        2008-12-18 17:41:46.679333247 +0100
@@ -127,7 +127,8 @@
        $self->{'Capability'}=$_;
     }
     $userpass = "$self->{'Proxy'}\x00".$self->{'Login'}."\x00".$self->{'Password'};
-    $encode=encode_base64($userpass);
+#    $encode=encode_base64($userpass);
+    $encode=encode_base64($userpass, '');
     $len=length($encode);
     print $fh "AUTHENTICATE \"PLAIN\" {$len+}\r\n";

Bei SourceForge gibt es eine ziemlich alte aber gut funktionierende Websieve Version.  In dem Archiv ist auch ein Perl Modul (Sieve.pm) enthalten. Nach dem Update auf Lenny scheint dieses Perl Modul ein Problem mit der neuen Sasl Bibliothek zu haben. Das Perl Modul hängt an den Base64 kodierten String aus Username und Passwort immer noch ein Nullbyte an. Daran stört sich Sasl gibt folgende Fehlermeldung aus: cyrus/sieve[20978]: badlogin: localhost[127.0.0.1] PLAIN error base64 decoding string Als Lösung übergibt man der encoding Funktion einen leeren Zeilentrenner. Hier der Patch: --- Sieve.pm 2008-12-18 17:41:56.779613529 +0100 +++ Sieve_neu.pm 2008-12-18 17:41:46.679333247 +0100 @@ -127,7 +127,8 @@ $self-&gt;{'Capability'}=$_; } $userpass = "$self-&gt;{'Proxy'}\x00".$self-&gt;{'Login'}."\x00".$self-&gt;{'Password'}; - $encode=encode_base64($userpass); +# $encode=encode_base64($userpass); + $encode=encode_base64($userpass, ''); $len=length($encode); print $fh "AUTHENTICATE \"PLAIN\" {$len+}\r\n";

Bisher hatten wir einige Kalender mit Apache_moddav realisiert. Das führte aber immer wieder zu Problemen beim gleichzeitigen Zugriff mehrer Clients auf einen Kalender. Dabei kam dann teilweise die ICS-Datei abhanden.

Ich habe mir jetzt mal freie CalDav Server angeguckt (die Java basierenden Versionen Cosmo und Bedework habe ich gleich außen vorgelassen). DAViCal macht einen ganz interessanten Eindruck setzt aber PostgreSQL als Backend voraus. Zudem war die Liste der Abhängigkeiten (Apache + tausende Perl und Php Pakete) mir etwas zu lang. Positiv fällt allerdings auf das man Davical unter Lenny einfach als Paket installieren kann.

Ich habe mich jetzt für den Darwin Calendar Server entschieden. Der ist in Python geschrieben und unter Lenny als Debian Paket zu beziehen. Abgesehen von den unangenehmen plist Konfigurationsdateien ist mir noch nichts negatives aufgefallen. Über zwei Dateien sind schnell User und Gruppen (/etc/caldavd/accounts.xml) angelegt, x509 Zertifikat installiert und SSL aktiviert  (/etc/caldavd/caldavd.plist). Schon kann es los gehen.

Auf der Projekte Website ist die Konfiguration der Gängigen Clients beschrieben. Was hilfreich ist da sich die richtige URL zwischen Apple-iCal und Sunbird unterscheidet. Dabei ist noch anzumerken das Apples iCal die Verbindung verweigert wenn man SSL mit einem selbst signierten Zertifikat verwendet. Bevor die Anmeldung kalppt muß man sein Root-CA (oder das von cacert wenn man hier ein Zertifikat geordert hat) in der Schlüsselbundverwaltung importieren. Dazu zieht man die PAM kodierte Zertifikats Datei auf Schlüsselbunde/Anmeldung, öffnet das Zertifikat mit einem Doppelklick, öffnet den Punkt vertrauen und stellt die Auswahl auf immer vertrauen.

Der Server legt jeden Termin als eigene ics-Datei ab. Als Index verwendet er ein SQL-light Datenbank File. So funktionieren auch gleichzeitige Änderungen an einem Kalender problemlos. Ändern mal zwei Sunbird-Clients auch noch den gleichen Termin bekommt der eine von beiden (der langsamere) eine Warnung das sich der Eintrag in der Zwischenzeit geändert hat. Man hat nun die Auswahl seine Änderungen zu verwerfen oder die fremden Änderungen zu überschreiben.  Apples iCal gibt keine Warnung aus. Die Änderung geht verlohren.

Leider unterstützt der Darwin Calendar Server noch kein IPv6:

twisted.internet.error.CannotListenError: Couldn’t listen on [2001:7f0:23::42]:80: (-2, ‘Name or service not known’).

Update:

Der Server erkennt Änderungen an dem accounts.xml und liest das File neu ein. Das ist blöd wenn man einen Syntaxfehler gemacht hat und schön da man sich ein reload spart.

Offensichtlich kann man auch eine Directory Service wie LDAP oder Active Directory als Usersdatenbank verwenden. Das gucke ich mir dann als nächstes an.

Bisher hatten wir einige Kalender mit Apache_moddav realisiert. Das führte aber immer wieder zu Problemen beim gleichzeitigen Zugriff mehrer Clients auf einen Kalender. Dabei kam dann teilweise die ICS-Datei abhanden. Ich habe mir jetzt mal freie CalDav Server angeguckt (die Java basierenden Versionen Cosmo und Bedework habe ich gleich außen vorgelassen). DAViCal macht einen ganz interessanten Eindruck setzt aber PostgreSQL als Backend voraus. Zudem war die Liste der Abhängigkeiten (Apache + tausende Perl und Php Pakete) mir etwas zu lang. Positiv fällt allerdings auf das man Davical unter Lenny einfach als Paket installieren kann. Ich habe mich jetzt für den Darwin Calendar Server entschieden. Der ist in Python geschrieben und unter Lenny als Debian Paket zu beziehen. Abgesehen von den unangenehmen plist Konfigurationsdateien ist mir noch nichts negatives aufgefallen. Über zwei Dateien sind schnell User und Gruppen (/etc/caldavd/accounts.xml) angelegt, x509 Zertifikat installiert und SSL aktiviert  (/etc/caldavd/caldavd.plist). Schon kann es los gehen. Auf der Projekte Website ist die Konfiguration der Gängigen Clients beschrieben. Was hilfreich ist da sich die richtige URL zwischen Apple-iCal und Sunbird unterscheidet. Dabei ist noch anzumerken das Apples iCal die Verbindung verweigert wenn man SSL mit einem selbst signierten Zertifikat verwendet. Bevor die Anmeldung kalppt muß man sein Root-CA (oder das von cacert wenn man hier ein Zertifikat geordert hat) in der Schlüsselbundverwaltung importieren. Dazu zieht man die PAM kodierte Zertifikats Datei auf Schlüsselbunde/Anmeldung, öffnet das Zertifikat mit einem Doppelklick, öffnet den Punkt vertrauen und stellt die Auswahl auf immer vertrauen. Der Server legt jeden Termin als eigene ics-Datei ab. Als Index verwendet er ein SQL-light Datenbank File. So funktionieren auch gleichzeitige Änderungen an einem Kalender problemlos. Ändern mal zwei Sunbird-Clients auch noch den gleichen Termin bekommt der eine von beiden (der langsamere) eine Warnung das sich der Eintrag in der Zwischenzeit geändert hat. Man hat nun die Auswahl seine Änderungen zu verwerfen oder die fremden Änderungen zu überschreiben.  Apples iCal gibt keine Warnung aus. Die Änderung geht verlohren. Leider unterstützt der Darwin Calendar Server noch kein IPv6: twisted.internet.error.CannotListenError: Couldn't listen on [2001:7f0:23::42]:80: (-2, 'Name or service not known'). Update: Der Server erkennt Änderungen an dem accounts.xml und liest das File neu ein. Das ist blöd wenn man einen Syntaxfehler gemacht hat und schön da man sich ein reload spart. Offensichtlich kann man auch eine Directory Service wie LDAP oder Active Directory als Usersdatenbank verwenden. Das gucke ich mir dann als nächstes an. :-)

Wir hatten heute auf eine Kundenseite ein Dos Angriff per TCP-Syn. Ich habe ein paar Minuten gebraucht um drauf zu kommen. Die beiden Webserver auf denen die Seite liegt ungewöhnlich wenig zu tun. Nur vereinzelnd verirrte sich ein Request ins Logfile. Tcpdump zeigte dann ungewöhnlich viele Syn Pakete. Ein blick auf den Traffic Graph zeigte dann auch 50Mbit/s eingehenden Traffic.

Ich habe dann tcpdump nach tcp-syn Paketen suchen lassen, die Zeile mit der IP-Adressen raus geschnitten, den Port entfernt, sortiert, doppelte IP’s entfernt und gezählt wie oft jede Adresse vor kommt.

tcpdump -pn -i bond0.204 'tcp[13] = 2' | cut -d " " -f 3 | cut -d "." -f 1-4 | sort | uniq -c | sort | tail -10
 
1086 87.181.77.64
7305 88.71.48.146
30695 87.209.6.253
35020 87.67.221.211
106085 69.111.79.128

Mit den IP’s wurde dann ein ipset gefüttert das die Jungs erstmal ausgesperrt hat. Es wäre wohl zu einfach gewesen wenn das Problem damit beseitigt worden wäre. Nach zwei Stunden ging es wieder los. Diesmal mit etwas mehr Source Adressen (ca. 300 anstatt nur 5).

Ich stellte mich also auf ein längeres Gastspiel ein und aktivierte auf den Webservern tcp_syncookies (was aber komischer weise nicht viel geholfen hat wie sich später raus stellte). Um halb zehn wurde ich von Nagios aus meinem verdienten Feierabend gerissen. Auf dem Router vor den Webservern war die Connection-Tracking Tabelle übergelaufen (nf_conntrack: table full, dropping packet). Also wurden die viel zu niedrigen default Werte erhöht und ein Script geschrieben das die lästigen Störer automatisch blockiert.

Default Werte erhöhen:
echo 262144 > /sys/module/nf_conntrack_ipv4/parameters/hashsize
echo 2097152 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max

Script:

for ip in $(ssh 192.168.100.102 'netstat -ant|grep SYN|sed -e "s/ \+/ /g" | cut -d " " -f 5|cut -d ":" -f 1|sort|uniq -c|sort -g | awk -F" " "\$1 > 30 {print \$2}"');
do
  ipset -T BAD_HOST $ip >/dev/null || {
    ipset -A BAD_HOST $ip;
    echo "ban Host $ip";
  }
done

Fazit
Bisher hat das jetzt gut funktioniert. Es gab früh morgens um halb eins noch mal einen Versuch von dem ich zum Glück nichts mitbekommen habe. Allerdings war der Angriff, wenn man ihn denn überhaupt so nennen darf, eher halbherzig. Zum einen gibt es in so einen Bot Netz wohl mehr als nur eine Handvoll Hosts und zum anderen hätten sie bei einem TCP-Syn Angriff die Quell Adressen fälschen können. Dann hätte ich mit meinem Script schön blöd ausgesehen. Für’s nächste Mal werde ich mir wohl was schönes einfallen lassen müssen.

Wir hatten heute auf eine Kundenseite ein Dos Angriff per TCP-Syn. Ich habe ein paar Minuten gebraucht um drauf zu kommen. Die beiden Webserver auf denen die Seite liegt ungewöhnlich wenig zu tun. Nur vereinzelnd verirrte sich ein Request ins Logfile. Tcpdump zeigte dann ungewöhnlich viele Syn Pakete. Ein blick auf den Traffic Graph zeigte dann auch 50Mbit/s eingehenden Traffic. Ich habe dann tcpdump nach tcp-syn Paketen suchen lassen, die Zeile mit der IP-Adressen raus geschnitten, den Port entfernt, sortiert, doppelte IP's entfernt und gezählt wie oft jede Adresse vor kommt. tcpdump -pn -i bond0.204 'tcp[13] = 2' | cut -d " " -f 3 | cut -d "." -f 1-4 | sort | uniq -c | sort | tail -10 1086 87.181.77.64 7305 88.71.48.146 30695 87.209.6.253 35020 87.67.221.211 106085 69.111.79.128 Mit den IP's wurde dann ein ipset gefüttert das die Jungs erstmal ausgesperrt hat. Es wäre wohl zu einfach gewesen wenn das Problem damit beseitigt worden wäre. Nach zwei Stunden ging es wieder los. Diesmal mit etwas mehr Source Adressen (ca. 300 anstatt nur 5). Ich stellte mich also auf ein längeres Gastspiel ein und aktivierte auf den Webservern tcp_syncookies (was aber komischer weise nicht viel geholfen hat wie sich später raus stellte). Um halb zehn wurde ich von Nagios aus meinem verdienten Feierabend gerissen. Auf dem Router vor den Webservern war die Connection-Tracking Tabelle übergelaufen (nf_conntrack: table full, dropping packet). Also wurden die viel zu niedrigen default Werte erhöht und ein Script geschrieben das die lästigen Störer automatisch blockiert. Default Werte erhöhen: echo 262144 &gt; /sys/module/nf_conntrack_ipv4/parameters/hashsize echo 2097152 &gt; /proc/sys/net/ipv4/netfilter/ip_conntrack_max Script: for ip in $(ssh 192.168.100.102 'netstat -ant|grep SYN|sed -e "s/ \+/ /g" | cut -d " " -f 5|cut -d ":" -f 1|sort|uniq -c|sort -g | awk -F" " "\$1 &gt; 30 {print \$2}"'); do ipset -T BAD_HOST $ip &gt;/dev/null || { ipset -A BAD_HOST $ip; echo "ban Host $ip"; } done Fazit Bisher hat das jetzt gut funktioniert. Es gab früh morgens um halb eins noch mal einen Versuch von dem ich zum Glück nichts mitbekommen habe. Allerdings war der Angriff, wenn man ihn denn überhaupt so nennen darf, eher halbherzig. Zum einen gibt es in so einen Bot Netz wohl mehr als nur eine Handvoll Hosts und zum anderen hätten sie bei einem TCP-Syn Angriff die Quell Adressen fälschen können. Dann hätte ich mit meinem Script schön blöd ausgesehen. Für's nächste Mal werde ich mir wohl was schönes einfallen lassen müssen.

Die Webalizer Version 2.01.10 in Debian etch kommt mit IPv6 nicht klar. Vor dem ersten Doppelpunkt wird die Adresse abgeschnitten.

--> unresolved country for '2001' (GeoIP says (null):(null))

Allerdings gibt es bei bugs.debian.org schon einen Patch der das Problem behebt. Man kann also hoffen das wir in Lenny eine Version vorfinden die ipv6-ready ist. Mein AMD64-etch-Binary liegt hier. Nun gibt es nur noch ein Problem mit der GeoIP-Lib.

--> unresolved country for '2001:7f0:1000::2:13' (GeoIP says (null):(null))

Die Webalizer Version 2.01.10 in Debian etch kommt mit IPv6 nicht klar. Vor dem ersten Doppelpunkt wird die Adresse abgeschnitten. --&gt; unresolved country for '2001' (GeoIP says (null):(null)) Allerdings gibt es bei bugs.debian.org schon einen Patch der das Problem behebt. Man kann also hoffen das wir in Lenny eine Version vorfinden die ipv6-ready ist. Mein AMD64-etch-Binary liegt hier. Nun gibt es nur noch ein Problem mit der GeoIP-Lib. --&gt; unresolved country for '2001:7f0:1000::2:13' (GeoIP says (null):(null))