Linux

Es soll ja vorkommen, dass ein Server von extern z.B. mit sehr vielen HTTP-Anfragen lahmgelegt werden soll. In so einem Fall ist guter Rat teuer, um Schaden vom Server und der darauf laufenden Websites bzw. Applikationen abzuwenden. Oft hilft einem auch der ISP dabei, verlassen kann man sich darauf freilich nicht. So wurde kürzlich bei einem Fall der Kunde zwar sogar von Hetzner über die DDOS-Attacke informiert Gegenmaßnahmen wurden aber nicht getroffen. Im schlimmsten Fall droht sogar die Sperrung der IP seitens Hetzner, was natürlich zum Teil auch nachvollziehbar ist.

Serverseitig kann man aber auch etwas tun, z.B. das kleine Shell-Script (D)DoS Deflate laufen lassen. Dieses kleine Script prüft ganz einfach per netstat, welche IP eine in der Config definierte Anzahl von Verbindungen überschreitet und sperrt diese wirksam direkt via iptables (diese Variante bevorzuge ich, es wird einfach DROP auf alle Pakete von der Quell-IP angewendet) oder via apf (Advanced Policy Firewall). Das Script hilft natürlich nur, wenn der Server noch erreichbar ist und arbeitet, d.h. wenn die Attacke nicht die die komplette Bandbreite verbraucht oder zu extrem ist.

Zur "Installation", die im Wesentlichen aus ein paar Downloads via wget und der Einrichtung eines Cronjobs funktioniert, holt man sich einfach wie auf der Website angegeben das Script install.sh von einem Server. Alternativ habe ich das Ganze hier nochmals als Mirror hinterlegt: ddos.tar (20 KByte). Den Tarball einfach z.B. nach /usr/local/ entpacken und es kann losgehen.

In der ddos.conf kann man via NO_OF_CONNECTIONS angeben, ab wievielen Verbindungen eine IP gesperrt wird. Das muss man einfach testen bzw. es kommt sehr darauf an, was auf dem Server normalerweise los ist. Bei zu niedrigen Werten läuft man natürlich Gefahr, auch "normale" User zu sperren. Mit BAN_PERIOD legt man dann fest, wie lange die IP gesperrt werden soll. Die eigene IP kann man übrigens mit einem Eintrag (neue Zeile) in der Datei ignore.ip.list whitelisten, 127.0.0.1 ist default auf der Whitelist

Jetzt kann man direkt ./ddos.sh ausführen und sieht auch direkt den Output den im Script ausgeführten netstat, das konkret so aussieht:

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Alle IPs mit einer Connection-Anzahl > NO_OF_CONNECTIONS werden nun also für BAN_PERIOD Sekunden gesperrt. Ein Cronjob, der am besten im Abstand läuft, wie auch BAN_PERIOD gesetzt ist, rundet die Config ab.

Erfolge kann man dann ganz einfach z.B. via iptables -L -nv sehen. Diese recht rudimentäre Lösung kann bei kleineren Angriffen durchaus nützlich sein und hat sich schon mehrfach im Einsatz bewährt. Hilfreich sind übrigens auch weitere IP-Adressen und kurze TTL im DNS, um schnell reagieren zu können.

Sollte der Angriff nur auf einzelne Dienste wie z.B. Apache durchgeführt werden, lohnt auch ein Blick auf Fail2Ban.

Prozess-Informationen (ps oder pstree) und CPU- und Speicherauslastung eines Linux-Systems (top, vmstat oder free) gehören wohl zu den am häufigsten benutzten Kommandos eines Admin, der für Linux-Server verantwortlich ist. In den meisten Fällen schaut man nach einem SSH-Connect ja erstmal, was auf der Maschine so los ist, zu der man sich gerade verbunden hat.

Für mich ist das schon fast eine Obsession, schließlich bin ich Statistik-Fan. Neben dem auf jedem System vorhandenen top (welches man auch ganz gut anpassen kann) haben sich mit der Zeit noch ein paar andere Tools in meine tägliche Nutzung eingefügt, die auf keinem Server fehlen.

Klarer Favorit und inzwischen nahezu 100%iger Ersatz für top ist für mich htop. Grafisch ansprechender aufbereitet zeigt es die Auslastung der einzelnen CPU-Cores live mit einem Balken an und fühlt sich generell irgendwie moderner an. Ein weiterer Vorteil ist, dass htop schneller startet als top, da top erst einige Daten sammelt. Weitere Unterschiede sind hier aufgelistet. In Debian und CentOS ist es aus der Distribution problemlos zu installieren.

Das Schweizer Taschenmesser der "Tops" ist aber atop. Es zeichnet sich vor Allem dadurch aus, dass es deutlich mehr Statistiken und Daten liefert als top, nämlich z.B. "Disk Utilization" und "Network Utilization" je Prozess. Außerdem loggt atop periodisch diverse Systemparameter, die sich dann mit dem mitgelieferten Tool atopsar darstellen lassen. Dafür läuft dann allerdings permanent ein atop Prozess auf dem System.

Wer keinen eigenen Dienst laufen lassen möchte oder atop nicht nutzt, die Systemlast aber trotzdem permanent überwachen möchte, kann sich atsar mal anschauen. Hier wird im Grunde wie bei atop der Zustand periodisch geloggt und man kann im sich problemlos die Loadavg oder Disk Utilization der letzten Tage anschauen.

Weitere Live-Tools für diverse Anwendungsfälle, die ich häufig sinnvoll einsetze sind zum Beispiel apachetop, womit sich live sehen lässt, welche Dateien am häufigsten aufgerufen werden, oder iotop. Mit iotop kann man schön sehen, was gerade an I/O auf den Platten los ist und welche Prozesse dafür verantwortlich sind.

Zum Schluss noch der Hinweis auf ein "grafisches" Tool auf der Shell, womit sich der Traffic von Netzwerk-Interfaces ziemlich gut darstellen lässt: nload. Hiermit sieht man recht gut, was gerade an Traffic über ein bestimmtes Interface geht samt Durchschnittswerten.

Natürlich gibt es noch dutzende weiterer Tools. Hinweise oder Tipps in den Kommentaren dazu sind natürlich erwünscht

Nachdem meine Synology DS207 mit ihren 2x1TB (RAID1) Platten zu klein und auch generell zu langsam wurde, musste eine Neuerung her. Möglichst auch mit Verschlüsselung und mehr Kontrolle über das eigentliche System. Denn neben den Änderungen von Apple in der AFP-Implementation und der Tatsache, dass ältere Netatalk-Versionen dann plötzlich nicht mehr mit Lion reden wollten, nervte die Abhängigkeit vom Hersteller Synology schon extrem. Klar, nach ein paar Wochen kam dann das Update, so dass TimeMachine und AFP wieder korrekt funktionierten, mit einer eigenen Lösung hätte man das aber deutlich schneller hinbekommen.

Also fiel die Wahl auf einen "Home-Server" mit Atom-CPU, konkret auf den Acer EasyStore H341. Das Gehäuse ist mit 4 HDD Plätzen ausgestattet, so dass ich in meiner Ausbaustufe mit 4x2 TB Platten (Seagate Barracuda LP, ST32000542AS) auf 8 TB Plattenplatz komme. Die Intel Atom D410 mit 2 Threads und 1.66 Ghz samt 2 GB RAM ist zwar nicht der Renner, erschien aber erstmal ausreichend. Leider verfügt das Board nur über einen einzigen LAN-Anschluss (Realtek, GBit).

Viel schlimmer ist aber die Tatsache, dass kein VGA-Anschluss im Auslieferungszustand vorhanden ist. Somit ist es natürlich sehr schwer, andere Betriebssysteme als das bereits auf einer internen USB Disk (256 MB) vorhandenen Windows zu installieren. Abhilfe schafft ein optionaler VGA-Adapter (ca. 30 EUR bei Amazon), der samt Low-Profile-Adapter recht einfach in das Gehäuse gesteckt wird. Klappte hier sofort ohne Probleme. Außerdem sollte man wissen, dass nur USB und kein PS-2 vorhanden ist. Eine USB Tastatur sollte man also auch besitzen.

Mit einem USB-DVD ging es dann also an die Installation. Testweise kam erstmal Freenas 7 zum Einsatz, welches locker auf die interne 256 MB USB-Disk passte. Da aber in Freenas 7 die AFP-Implementation leider veraltet ist, war dies wirklich nur ein kurzer Test. Keine Chance, TimeMachine lauffähig zu bekommen. Außerdem war mit Freenas 7 und einem verschlüsselten ZFS-Volume die Performance grauenvoll, was wohl an der schwachen CPU lag (nur gut 15 MB/s Durchsatz!). Mit der kürzlich veröffentlichten Version 8 von Freenas - von einem 2 GB USB-Stick gebootet - ging zwar AFP reibungslos, leider ist dort aber noch keine Verschlüsselung implementiert. Außerdem hat Freenas grundsätzlich das gleiche Problem wie eine "fertige" NAS, nämlich die Abhängigkeit seitens der Herausgeber.

Daher fiel die Wahl nach den ganzen Freenas-Experimenten zuerst auf Debian Squeeze. Der Kernel wollte aber leider nicht mit der Hardware zusammenarbeiten (USB ging nicht, somit auch keine Tastatur etc.), so dass dann doch Ubuntu Server zum Einsatz kam. Hier lief die Installation sofort problemlos und die Hardware wurde komplett erkannt.

Bei der Installation entschied ich mich wegen der schwachen CPU ohne Hardware-AES-Support gegen komplett verschlüsselte Platten. Es kommen nunmehr mehrere "kleine" Crypto-Container mit je 1-10 GB zum Einsatz, die an die entsprechenden Stellen gemountet werden. Somit sind nur wirklich wichtige Sachen verschlüsselt und die Performance passt. Die Platten wurden in einem Software-RAID10 zusammengefasst und mit ext4 formatiert. Wegen der hohen Schreibrate durch Backups etc. erschien das hier als die bessere Wahl gegenüber RAID5, zumal 4 TB netto immernoch genug Speicherplatz sind. Zur Performance später mehr.

Nach der Installation des Grundsystems ging es an die Serverdienste. Hier standen in erster Linie AFP für die Macs und Samba für die Windows-Kisten zur Debatte. Samba war leicht konfiguriert, schließlich sollten nur 2-3 Shares eingerichtet werden. Die Nutzer wurden jeweils als normale Linux-User eingerichtet, wogegen sich dann die Dienste authentifizieren.

Ein wenig schwieriger war hingegen die Installation von netatalk für AFP. Wegen der Kompatibilität musste es unbedingt die neueste Version 2.1.1 sein, die natürlich nicht in der Distribution verfügbar war. Zum Glück stellt Stefano Rivera auf Launchpad fertige Pakete der neuesten Version für Ubuntu bereit, die sich problemlos installieren ließen. Ein paar Shares inklusive TimeMachine waren dann schnell eingerichtet und es funktionierte sofort problemlos. Und zwar genau so, wie ich es wollte, also mit Freigaben auf Gruppen- und Userebene.

Dank "avahi-daemon" wird die NAS auch von Macs als Server erkannt und kann direkt im Finder angesprochen werden. Außerdem wird die NAS noch als OpenVPN Gateway benutzt, was auch problemlos geht und unter Freenas schon ein kleiner Krampf war. Zur Überwachung kommt mdadm samt smartd zum Einsatz, womit sich Festplatten-Ausfälle zeitnah erkennen lassen sollten. Im Idealfall können ja in der RAID10-Konstellation sogar 2 der 4 Platten ausfallen.

Zur Performance kann ich mich weitestgehend positiv äußern. Nachdem der initiale Raid-Sync nach 30h (!) abgeschlossen war, erreiche ich bei lokalen Tests mit "dd" eine Schreibrate von über 140 MB/s im groben Schnitt. Via AFP sind es über GBit-LAN immernoch ausreichende 60 MB/s im Schnitt. Zu SMB liegen keine Messwerte vor, langsam erscheint es aber von Windows-PCs aus nicht. Das sind Werte, von denen ich mit der alten Synology-NAS nur träumen konnte.

Klar, die CPU könnte schon stärker sein. Bei simultanen Zugriffen merkt man schon, dass das der Flaschenhals ist. Für den Heimbereich oder, wie bei uns, im Büroeinsatz ist das Gerät aber ansich durchaus zu empfehlen. Denn für unter 500 EUR inkl. Platten hat man eine redundante, einigermaßen flotte und komplett selbst verwaltbare NAS-Lösung mit einem Linux-System, was sich perfekt anpassen lässt - so regeln z.B. diverse Cronjobs via "rsync" bei uns das Backup auf entfernte Server etc.

Ansich also eine durchaus empfehlenswerte Lösung. Es soll wohl einen Nachfolger (?) namens von Acer H342 geben, der dann eine Dualcore CPU hat. Scheint aber nur in den USA verfügbar zu sein. Zumindest gab es nirgends konkrete Infos oder Preise.

PS: Sollte Interesse an der konkreten Config unserer NAS bestehen, reichen wir diese gern nach und freuen uns über Kommentare.

Viele unserer (Web)Server loggen auf einen zentralen Logging-Server, der via syslog-ng die Logdaten einsammelt und einheitlich zur Verfügung stellt. Besonders bei Webclustern, wo ein Loadbalancer die Anfragen auf diverse Server verteilt, ist z.B. ein zentrales Apache-Logfile u.A. für die Logfile-Auswertung wünschenswert. Außerdem kann man dann mit logcheck nette Security-Auswertungen etc. für alle Server gemeinsam machen und muss dies nicht auf jeder Kiste einzeln tun.

Bisher lief der Logging-Server auf Linux-Basis, nachts wurden die zig GByte großen Logfiles des letzten Tages dann komprimiert. Das hat soweit auch ganz gut funktioniert, nur leider wird es an der Stelle nervig, wenn man in den Logfiles der letzten Monate etwas sucht und dann beispielsweise 200 GByte an GZIP-Files durchsuchen muss. Ganz davon abgesehen sorgte die nächtliche Komprimierung via logrotate (GZIP) doch für eine ordentliche Serverlast über Stunden hinweg (CPU und I/O gleichermaßen).

Als Lösung fiel die Wahl jetzt auf FreeBSD 8.1 als OS für den Loghost. Filesystem ist, wie könnte es anders sein, nun ZFS! Und dank "eingebauter" Komprimierung ist die Verwaltung der Logfiles jetzt deutlich angenehmer. Auf Filesystem-Ebene via GZIP komprimiert ergibt sich für den Nutzer kein Nachteil, die CPU-Last wird nicht mehr auf die Nacht verteilt, sondern permanent beim Schreiben der Files - aber eben kaum merklich, da konstant und minimal. Die Kompressionsrate ist identisch mit der früheren Kompression unter Linux. Neben GZIP stand noch LZJB als Methode zur Auswahl. Das soll wohl schneller sein, komprimiert aber nicht so akkurat wie GZIP.


Wie erstellt man nun ein solch komprimiertes Filesystem via ZFS?

Man erstellt einen zpool z.B. als RAID-1 via:

zpool create data mirror /dev/da1 /dev/da2

Nun erstellt man das Filesystem via:

zfs create -o compression=gzip -o mountpoint=legacy data/varlog

Mit -o gibt man die Optionen an, hier gzip. Default ist die Kompression auf Stufe 6 (=ausgewogen) eingestellt, man könnte aber auch gzip-9 für maximale Kompression verwenden.

mountpoint=legacy bedeutet, dass ZFS sich nicht um die Verwaltung des Mountpoints kümmert. Default würde dies sonst unter /data/varlog gemountet werden. Da wir aber /var/log haben möchten, behelfen wir uns mit diesem Eintrag in der /etc/fstab:

data/varlog /var/log zfs rw 1 0

Tricky war allerdings, dass der Installer selbst dies nicht zur Verfügung gestellt hat (zumindest haben wir es nicht gesehen..). Daher wurde normal mit UFS installiert und anschließend die neue Partition erstellt, gemountet und mit den Inhalten aus der alten UFS-Partition gefüllt. Eine etwas umständliche Methode, die allerdings problemlos funktioniert hat.

Die Kompression kann man via ls und du sehr gut nachvollziehen, da ls die ursprüngliche Dateigröße anzeigt. Mit du sieht man dann die tatsächliche Größe auf Platte:

# l -h apache_central.log-20110109
-rw------- 1 root wheel 3.9G Jan 9 06:25 apache_central.log-20110109

# du -sh apache_central.log-20110109
412M apache_central.log-20110109

Insgesamt ein sehr nettes Szenario, um Speicher zu sparen und Logfiles dauerhaft vorzuhalten, ohne sich durch viele GZIP-Files wühlen zu müssen. Die Performance ist ingesamt gut, es gibt eigentlich keine Probleme trotz sehr großer Logfiles, die täglich anfallen.

Den Reader less benutzt vermutlich jeder Admin mehr oder weniger oft für alle Arten von Textfiles. Für mit Gzip komprimierte Dateien gibt es dann noch zless, was immerhin das Entpacken spart. Manchmal weiss man allerdings nicht gleich, um was für ein File es sich handelt. Und jedes Mal file aufzurufen, ist auch nervig.

Aber dafür gibt es das kleine Bash-Script lesspipe, was zumindest auf Debian und CentOS vorinstalliert ist. Ich denke mal, andere Distributionen haben es auch vorinstalliert. Falls nicht, gibt es hier den Download.

Beim Aufruf spuckt lesspipe die benötigten Variablen aus, die gesetzt werden müssen, damit es funktioniert:

export LESSOPEN="| /usr/bin/lesspipe %s";
export LESSCLOSE="/usr/bin/lesspipe %s %s";

Schreibt man diese Zeilen oder eben "eval `lesspipe`" in seine .bashrc, kommt man in den Genuss mit dem gewohnten Aufruf von less eine Vielzahl von Dateitypen ansehen zu können. Eine Liste der Typen gibt es in der README.

Nun kann man sich also ein erstes Bild von Googles kommenden "Betriebssystems" ChromeOS machen, leider vorerst nur als Video-Präsentation. Für Entwickler gibt es hier den Sourcecode.

Ich finde die Idee ja eigentlich ganz nett, bin aber dennoch ein wenig enttäuscht. Ich sehe ein Linux mit Chrome als Browser und gleichzeitig einzigem aktivem Programm, mehr so richtig noch nicht. Klar, es bootet wohl in 7 Sekunden von einer SSD, auf die nur lesend zugegriffen werden kann, aber das schafft mein Mac aus dem Suspend to RAM auch. Und mal ehrlich: Die Boot-Time ist jetzt nicht unbedingt DAS Killerkriterium für ein Betriebssystem.

Der Trend, den Google hier geht, ist natürlich nicht von der Hand zu weisen, schließlich benutzt man wohl wirklich zu 90% oder sowas nur den Browser auf einem Rechner. Für Netbooks mag ChromeOS vielleicht eine Alternative sein, aber selbst dort will man doch nicht auf eine echte Bildbearbeitung sowie die lokale Speicherung von Daten verzichten, oder? Ohne Internet ist ein Rechner mit ChromeOS zumindest nutzlos. Das macht sich besonders schlecht, wenn man auf Reisen im Ausland unterwegs ist usw. - dann könnte man offenbar nicht einmal die Fotos von der eigenen Digicam auf ein ChromeOS-Netbook spielen und anschauen (maximal auf einen Stick..) - geht ja nur mit Internet und der Cloud.

Ganz davon abgesehen muss man sich fragen, ob mal der Cloud bzw. Google alle seine Daten anvertrauen will. So richtig gefällt mir der Gedanke ja nicht. Von POP3- bzw. IMAP-Support für meine eigenen Mailkonten habe ich auch noch nichts gesehen, es scheint ja auch keinen echten Mailclient zu geben. Das wäre für mich definitiv das KO-Kriterium, mal abgesehen von der Datensicherheit bzw. dem Datenschutz. Man kann wohl auch davon ausgehen, dass mit einem 0815-ADSL-Anschluss der Upload großer Datenmengen in die Cloud dann alles Andere als schnell geht.

Dennoch werde ich diese interesante Entwicklung natürlich weiter verfolgen. Ich bezweifle aber, dass ich in den nächsten Jahren ChromeOS einsetzen werde. Aber man sollte ja niemals nie sagen, nicht wahr? Bis dahin werden hier OSX sowie Linux (das "Echte" meine ich, also mit Gnome oder KDE) weiterhin zufriedenstellend ihre Dienste tun.


Ein erklärendes Video von Google auf YouTube gibt es hier: What is Google Chrome OS?

Seit einer Woche habe ich nun einen Hetzner Rootserver EQ4. Die haben derzeit einfach die besten Preise, denn wo bekomme ich sonst einen Quadcore mit 8GB RAM und 2x 750 Festplatten und nahazu unlimited Traffic (Drosselung ab 2 TB auf 10Mbit ist ok)? Da kann nichtmal der Low-Budget-Hoster Server4You mehr mithalten, wie es scheint. Klar, man muss erstmal 149 EUR Setup hinlegen, das hat sich bei dem niedrigen Preis aber schnell gerechnet. Und klar, es ist keine echte Server-Hardware, wie z.B. bei Strato oder Serverloft. Aber braucht man das wirklich? Oftmals nicht ..

Letzten Sonntag also bestellt, Montag früh um 7 war er fertig eingerichtet und ich konnte loslegen. Das nach meiner Wahl vorinstallierte Debian Lenny war eher nutzlos, da es nur aus einer großen Partition bestand. Da ich keine Lust auf abenteuerliche Resize-Geschichten mit dem Sofware-RAID 1 hatte, habe ich ihn also über das Rescue-System neu installiert. Dank einer Scriptsammlung, die von Hetzner unter dem Namen installimage bereitgestellt wird, ist das ein Kinderspiel. Man muss nur eine Config anpassen, wo Partitionierung etc. angegeben wird, und schon hat man ein Linux seiner Wahl auf dem Rootserver. Davon war ich wirklich begeistert und habe nun ein Debian Lenny mit den von mir gewünschten Partitionen, um ihn als Hosting-Server zu verwenden. Ein paar Tipps zur sicheren Einrichtungen mittels fcgi, suexec usw. wird demnächst hier veröffentlicht.

Die Anbindung scheint ebenfalls gut zu sein, Ping-Tests verliefen bisher positiv. Ich kann derzeit also Hetzner durchaus empfehlen, zumal der Robot eine angenehme Variante darstellt, um Domains, Handles und DNS-Einträge zu verwalten. Das Design ist zwar eher "schlicht", aber darum gehts ja an der Stelle nicht. Die Traffic-Stats sind nett aufbereitet, die Config der Benachrichtigungen bei Serverausfällen (ähnlich NAGIOS) ist eher frickelig. Könnte man sicher besser gestalten, aber naja.

Interessant wird es dann werden, wenn ich mal den techn. Support brauche, z.B. wenn eine Platte aussteigt. In der Vergangenheit hatte ich mit Hetzner allerdings ganz gute Erfahrungen, bis auf ein paar Stromausfälle vor einigen Jahren