Creating multiple bonding interfaces in Ubuntu 14.04 LTS


Hi,

I wanted to share some learnings about bonding configuration which I could not find elsewhere.

 

„Bonding, also called port trunking or link aggregation means combining several network interfaces (NICs) to a single link, providing either high-availability, load-balancing, maximum throughput, or a combination of these.“ [1]

Bonding is an essential technology for highly available Linux systems. Thankfully all major distributions support bonding in some way. In Ubuntu you can easily create a bonding interface in /etc/network/interfaces. But this is only supported for a single interface.

What if you need bond0 and bond1 or even more independent bonding interfaces, maybe with different modes of operation? Weiterlesen

Deduplizierender Storage mit dem ZFS-Filesystem


Hallo Kollegen,

wir sind auf der Suche nach einem bezahlbaren Storage-System, das Deduplizieren und Komprimieren kann, und gleichzeitig für hoch produktive Umgebungen geeignet ist. Von einigen Kunden kennen wir die Datadomain von (mittlerweile) EMC, die zwar verblüffend hohe Performance bei optimalen Deduplizier-Raten leistet, jedoch auch erst für entsprechend verblüffende Preise zu haben ist. Wir fragen uns, was zum Beispiel Opensource hier beitragen kann? Bekannte Projekte sind ZFS und Opendedup. Nachdem ZFS auch als Kernelmodul vorliegt und eine weitaus größeres Featureset aufweist, werden wir uns einige Zeit (es wurden mehrere Monate) mit ZFS beschäftigen. Dabei geht es in dieser Reihenfolge um ZFS-Verstehen, Best-Practise, Versuchsaufbau, Benchmarking/Tests, Setup und Hardware für produktive Maschinen und Deployment.

Ich nehme hier vorweg, dass unser Versuch mit ZFS gescheitert ist. Und zwar am letzten Punkt „Deployment“. Mehrmals haben wir nach erfolgreichen Tests Probleme im Live-betrieb feststellen müssen, die wir letztlich nicht lösen konnten. Aber dennoch ist ZFS grundsätzlich ein interessantes Filesystem, außerdem haben wir bei diesem Versuchsprojekt viele spannende Dinge gelernt. Weiterlesen

Monitoring Evolution


Seit unserem letzten Artikel „Quo vadis Nagios?“ über das Monitoring-System Nagios und die unterscheidlichen Alternativen, wie Icinga oder Shinken, sind schon wieder zwei Jahre vergangen. In dieser Zeit hat sich an den Entwicklungen um Nagios selbst nicht viel getan, sehr wohl aber bei vielen anderen Opensource Projekten, die mit Nagios kompatible Monitoring-Lösungen darstellen. Nachdem unsere eigene Nagios-Installation und die einiger Kunden mittlerweile in die Jahre gekommen ist und es einige Punkte gibt, bei denen wir mit unserem aktuellen Monitoring-System nicht mehr ganz zufrieden sind, haben wir uns nun Zeit genommen, um die zwei großen Opensource Projekte Shinken und Icinga noch einmal genauer unter die Lupe zu nehmen. Dazu haben wir beide Systeme parallel installiert und getestet. Unsere Erkenntnisse und Erfahrungen mit den beiden Systemen werden wir im folgenden Abschnitt näher erläutern.

 

Shinken & Skonf

Die grundsätzlichen Informationen über Shinken findet man bereits in unserem Artikel „Quo vadis Nagios?“, weshalb ich an dieser Stelle nicht weiter darauf eingehen werde.
Im Vergleich zum Nagios bringt Shinken ein eigenes, webbasiertes Konfigurationstool mit, das dem Benutzer die Konfiguartion seiner Shinken-Installation erleichtern soll. Ein interessantes Feature stellt dabei die selbstständige Service-Erkennung, beim Hinzufügen von neuen Hosts, dar. Die Oberfläche an sich wirkt recht schlicht und modern. Leider konnten wir Skonf für unsere Tests nicht verwenden, da es nach der Installation nic
ht von selbst funktionierte und wir es auch nach mehrmaligem Versuchen nicht geschafft haben, es richtig zu konfigurieren. Jegliche Änderungen im Skonf waren auch nach einem Neustart von Shinken nicht in der Konfiguration

zu sehen. Eine Dokumentation ist zwar im offiziellen Wiki vorhanden, dort sind aber nicht alle Features, Konfigurationsmöglichkeiten und Probleme aufzufinden und die Community ist aktuell zudem noch recht klein. Insgesamt fanden wir den Ansatz aber durchaus interessant und hoffen, dass wir das Skonf-Interface in Zukunft auch mal funktionierend ausprobieren können.

shinken-ui

Detail-Ansicht eines Hosts in der Shinken UI


Icinga

Icinga ist einer der wohl bekanntesten Nagios-Forks und zeichnet sich vor allem durch seine aktive Entwicklung und Kompatibilität zur Nagios-Konfiguration aus. Genau so, wie auch bei Shinken, kann man prinzipiell einfach seine bestehende Nagios-Konfiguration importieren und weiter verwenden. Außerdem hat das Icinga Team im Laufe der Jahre viele der nervigen Nagios-Bugs behoben und damit das Gesamtsystem etwas stabiler gemacht. Ein großer Vorteil im Vergleich zu Shinken sind die vorhandenen Dabian-Pakete für die einfache Installation und Wartung von Icinga und seinem Zubehör.

Icinga-Legacy

Detail-Ansicht eines Hosts in der Icinga Classic-UI


Icinga-Web

Abgesehen von der altbekannten Nagios-Weboberfläche bringt Icinga auch noch eine neue, auf Ajax basierende und schicke Weboberfläche mit. Sie benötigt die Verwendung eine IDO-Datenbank, welche als Schnittstelle zwischen dem Webinterface und der eigentlichen Icinga-Installation dient. Diese neue Oberfläche sorgt für eine übersichtliche und strukturierte Darstellung der aktuellen Zustände und bietet außerdem die Möglichkeit, bestimmte Befehle an den Icinga-Daemon zu senden, um beispielsweise die aktiven Checks oder die Benachrichtungen zu aktivieren. Falls man zusätzlich zum Monitoring auch noch ein Reporting-System, wie beispielsweise Jasper, einsetzt, kann man dieses sehr einfach in Icinga und Icinga-Web integrieren.

Icinga-Web

Service-Status Ansicht von Icinga-Web


Shinken vs. Icinga

Durch viele Versuche, die wir mit beiden Systemem durchgeführt haben und Dinge, die wir mit den beiden Systemen getestet haben, haben wir viele neue Erfahrungen gesammelt.

Der Einrichtugngsaufwand ist bei Shinken zwar etwas höher, als bei Icinga, aber insgesamt machen beide Monitoring-Systeme nach der Installation auf den ersten Blick einen guten Eindruck. Die Integration von PNP4Nagios, NagiosQL, etc. ist bei beiden prinzipiell möglich, allerdings gibt es dabei beim Einrichtungsaufwand einige Unterschiede. Shinken hat aktuell eine kleine Community und die Dokumentation ist sehr knapp. Das erschwert vor allem Neulingen, tiefer in die Konfiguration und das Funktionsprinzip der Software einzusteigen und man ist daher bei Problemen mehr auf sich selbst angewiesen. Die Erst-Einrichtung gestaltet sich daher bei Shinken wesentlich aufwändiger und schwieriger, als bei Icinga. Im laufenden Betrieb funktionierte Shinken zwar ohne größere Probleme, aber der Konkurrent Icinga lief merklich stabiler und arbeitete besser mit den zusätzlich installierten Plugins/Add-Ons zusammen. Näheres zu den zwei wichtigsten Plugins gibt es in den folgenden Absätzen.


PNP4Nagios

Auch das Plugin zur Erfassung und Darstellung von Performance-Daten, der Nagiosgrapher ist mittlerweile in die Jahre gekommen und wird nicht mehr aktiv weiterentwickelt. Daher haben wir uns auch hier eine Alternative gesucht und uns für das Tool PNP4Nagios entschieden, welches eine eigene Weboberfläche bietet und zudem gut mit Icinga oder Shinken zusammenarbeitet. Wie auch bei Nagiosgrapher werden die Monitoring-Daten in einer RRD-Datei gespeichert und anschließend graphisch aufbereitet und angezeit. Ob es sich bei den Daten um die CPU-Auslastung oder die Werte eines Temperatursensors handelt, ist dabei vollkommen unerheblich. Die Graphen können im Anschluss komfortabel für bestimmte Zeiträume generiert und auch als PDF exportiert werden.

PNP4Nagios

Ansicht des Ping-Graphs in der PNP4Nagios Weboberfläche


NagiosQL und Nconf

NagiosQL ist ein graphisches Konfigurationstool, mit dem man über ein Webinterface die Nagios-/Icinga-/Shinken-Konfiguration erstellen und anpassen kann. Dadurch spart man sich die Arbeit mit den vielen verschiedenen Konfiguratiosndateien und kann dadurch schnell und gezielt Änderungen vornehmen. Im Handumdrehen lassen sich so neue Servicechecks, Hosts, Escalations oder auch Benachrichtungen hinzufügen und bestehende bearbeiten.

NagiosQL ist in PHP geschrieben und läuft auf jedem Apache-Webserver. Es benötigt lediglich eine zusätzliche MySQL Datenbank, um die Konfiguration zu speichern. Nach der erfolgreichen Änderung der Einstellungen werden dann jeweils die Nagios-kompatiblen Konfigurationsdateien generiert und das Monitoringsystem neugestartet, sodass die neue Konfiguration wirksam wird.

NagiosQL

Service-Übersicht von NagiosQL

Die Installation und Konfiguartion von NagiosQL selbst ist etwas komplizierter, aber wenn es dann einmal fertig eingerichtet ist, funktioniert es wurnderbar. In unserem Test war die Integration ind Shinken etwas umständlicher und es war ein bisschen Handarbeit nötig, um das ganze dann vollständig zum Laufen zu bekommen. NagiosQL ist aber ohne weiteres mit Icinga kompatibel und die Installation klappt ohne größere Probleme.
Außerdem haben wir auch das Tool Nconf einmal etwas genauer betrachtet und gestestet. Dabei mussten wir allerdings recht schnell feststellen, dass Nconf keinen mit NagiosQL vergleichbaren Funktionsumfang bietet und wir es noch mit eigenen Lösungen ergänzen müssten.
Für uns stellt daher NagiosQL, trotz seiner etwas altbacken wirkenden Oberfläche, einen vernünftigen Ersatz für die schon deutlich in die Jahre gekommene, bisherige Lösung dar. Das Projekt ist Opensource und wird aktiv entwickelt, weshalb wir das Tool natürlich besonders gerne verwenden.


Fazit

Shinken machte für uns insgesamt einen eher unfertigen und durchwachsenen Eindruck, weshalb wir der noch relativ jungen Software vor dem produktiven Einsatz noch etwas Zeit zur Entwicklung lassen. Einen sehr positiven Eindruck macht dagegen die Nagios-Alternative Icinga. Das Zusammenspiel mit NagiosQL und PNP4Nagios, deren Integration ins Gesamtsystem und der normale Betrieb funktionierten ohne Probleme. Abgesehen von kleineren Konfigurationsunterschieden im Vergleich zum alten Nagios, läuft Icinga sehr stabil und macht alles in allem einen soliden Gesamteindruck.

Aus diesem Grund haben wir Icinga, zusammen mit einigen weiteren Komponenten, als Hauptbestandteil für unseren „Monitoring-Server 2013“ gewählt. Damit bieten wir unseren Kunden ein modulares und skalierbares System, das sich vor allem durch Stabilität, Aktualität und eine komfortable Bedienung auszeichnet.

IT bleibt spannend!

Euer Andreas Erhard

Storage Benchmarking mit fio


Graphische Darstellung einer fio Testreihe

Neue Storage Systeme brauchen neue Benchmark-Tools. Unser Testaufbau bestand aus vier schnelldrehenden  Western Digital 1TB Platten, die eine Geschwindigkeit von 10.000 U/m erreichen. Diese sind zusammen mit zwei SSDs, die rein für das Cache benutzt werden, in einem Raid 10 Verbund. Dieser Testaufbau wurde übrigens später weiterentwickelt zu einem sehr schnellen Storage-System für unsere eigenen Hosting-Angebote, aber dazu mehr in einem weiteren Artikel.

Die ersten Versuche, entstanden mit dem Tool bonnie++ diese führten zu widersprüchlichen Ergebnissen. Nach längerem recherchieren, sind wir darauf gestoßen das bonnie++ nicht genügend Last erzeugen kann um Tests in dieser Größenordnung durchzuführen. Die Grenze der zu messenden IOs liegt hier bei 8000.

Nach dieser ernüchternden Erkenntnis, haben wir begonnen mit fio zu testen und bis auf die Ausgabe hat uns dieses Tool voll und ganz überzeugt.

Die Vor- und Nachteile von fio:

  • Erzeugt mehr Last durch das Angeben der Prozesse die  gestartet werden
  • Unterscheidet zwischen dem Modus, der Blöckgröße, der Testdateigröße sowie die Anzahl der Prozesse die gestartet werden
  • Auch für Stresstests und Hardware-Verifikation geeignet
  • Kann gut Automatisiert werden
  • Wenn ein stark unter Last stehendes System getestet wird, wird es mit fio nicht so stark belastet, da die Datenmenge mit der getestet wird geringer wird je stärker das System beansprucht ist, das Problem der Überlastung wird daher umgangen
  • Der Output ist sehr detailliert, um die Testergebnisse auszuwerten jedoch schlecht lesbar
  • Unter Ubuntu-Linux einfach zu installieren (apt-get install fio)

Dieser Programmcode ist unser automatisierter fio Test, mit der dazugehörigen Überschrift. Diese Daten werden anschließend an unser Perl Programm übergeben um die Ausgewerteten Daten lesbar zu machen.

#! /bin/bash

DEVICE=$1
SIZE=$2

ARGS1="--direct=1  --runtime=30 "
ARGS2="--filename=$DEVICE --size=$SIZE "

#  fio --filename=/dev/sdb1 --direct=1 --rw=read --bs=512 --size=4G 
#      --runtime=60 --name=job1 --name=job2 --name=job3 --name=job4 
#      --name=job5 --name=job6

(
echo "     DEVICE;  SIZE;     MODE; BLOCKSIZE; NUMJOBS;  READMB; WRITEMB; READIOS; WRITEIOS"
# for mode in rw read randrw randread; do
for mode in randread; do
   for blocksize in 4k 16M ; do
      ARGS3="--bs=$blocksize --rw=$mode "
      for jobs in 1 2 3 4 6 8 10 12 16 20; do
         ARGS4=""
         i=0
         while [ $i -lt $jobs ]; do
            let i=$i+1
            ARGS4="$ARGS4 --name=job$i"
         done
         #echo -n "$DEVICE;$SIZE;$mode;$blocksize;$jobs;"
         printf "%12s %6s %8s %10s %8s" "$DEVICE;" "$SIZE;" "$mode;" "$blocksize;" "$jobs;"
         fio $ARGS1 $ARGS2 $ARGS3 $ARGS4 | /usr/local/tools/fio_parser.pl
      done
   done
done
) | tee /tmp/fio-result-`/bin/date +%Y-%m-%d--%H-%M-%s`-`/bin/hostname`.csv


#! /usr/bin/perl

while ( $s =  ) {
# egrep "READ:|WRITE:|^  [a-z].*ios="
#   READ: io=4965MB, aggrb=84611KB/s, minb=13880KB/s, maxb=15064KB/s,
#         mint=60055msec, maxt=60088msec
#  WRITE: io=5015MB, aggrb=85463KB/s, minb=13999KB/s, maxb=15155KB/s,
#         mint=60055msec, maxt=60088msec
#  sdb: ios=9946/10014, merge=0/0, ticks=344830/329890,
#       in_queue=674820, util=99.93%

   chomp($s);
   if ( $s =~ / READ: /) {
      $ReadBandwidth = $s;
      $ReadBandwidth =~ s/^.*aggrb=//;
      $ReadBandwidth =~ s/B.*$//;
      $ReadUnit=chop($ReadBandwidth);
      if ($ReadUnit eq "M") {
         $ReadBandwidth=$ReadBandwidth*1024;
      } elsif ($ReadUnit eq "G") {
         $ReadBandwidth=$ReadBandwidth*1024*1024;
      }

      $Time = $s;
      $Time =~ s/^.*maxt=//;
      $Time =~ s/msec.*$//;
   } elsif ( $s =~ / WRITE: /) {
      $WriteBandwidth = $s;
      $WriteBandwidth =~ s/^.*aggrb=//;
      $WriteBandwidth =~ s/B.*$//;
      $WriteUnit=chop($ReadBandwidth);
      if ($WriteUnit eq "M") {
         $WriteBandwidth=$WriteBandwidth*1024;
      } elsif ($WriteUnit eq "G") {
         $WriteBandwidth=$WriteBandwidth*1024*1024;
      }

      if ($Time == undef ) {
         $Time = $s;
         $Time =~ s/^.*maxt=//;
         $Time =~ s/msec.*$//;
      }
   } elsif ( $s =~ /^  [a-z].*ios=/ ) {
      $ReadIOS = $s;
      $ReadIOS =~ s/^.*ios=//;
      $ReadIOS =~ s/\/.*$//;
      $WriteIOS = $s;
      $WriteIOS =~ s/^.*ios=[0-9]+\///;
      $WriteIOS =~ s/\,.*$//;
   }
}

printf( "%8s;", sprintf ("%.3f", $ReadBandwidth/1024) );
#print ";";
printf( "%8s;", sprintf ("%.3f", $WriteBandwidth/1024) );
#print ";";
printf ("%8i", int($ReadIOS*1000/$Time) );
print ";";
printf ("%9i", int($WriteIOS*1000/$Time) );
print "\n";


Und hier einmal eine Ausgabe.

DEVICE SIZE MODE BLOCKSIZE NUMJOBS READMB WRITEMB READIOS WRITEIOS
/dev/sdb1 49G randread 512 1 1624 0 3317 0
/dev/sdb1 49G randread 512 2 2926 0 5974 0
/dev/sdb1 49G randread 512 3 4363 0 8910 0
/dev/sdb1 49G randread 512 4 5572 0 11379 0
/dev/sdb1 49G randread 512 5 5918 0 12085 0
/dev/sdb1 49G randread 512 6 6396 0 13061 0
/dev/sdb1 49G randread 512 7 7076 0 14449 0
/dev/sdb1 49G randread 512 8 7647 0 15615 0
/dev/sdb1 49G randread 4k 1 12473 0 3193 0
/dev/sdb1 49G randread 4k 2 23147 0 5907 0
/dev/sdb1 49G randread 4k 3 33905 0 8656 0
/dev/sdb1 49G randread 4k 4 41183 0 10520 0
/dev/sdb1 49G randread 4k 5 43572 0 11122 0
/dev/sdb1 49G randread 4k 6 46203 0 11794 0
/dev/sdb1 49G randread 4k 7 48973 0 12501 0
/dev/sdb1 49G randread 4k 8 54445 0 13898 0
/dev/sdb1 49G randread 64k 1 106146 0 1693 0
/dev/sdb1 49G randread 64k 2 134256 0 2142 0
/dev/sdb1 49G randread 64k 3 184783 0 2949 0
/dev/sdb1 49G randread 64k 4 223165 0 3562 0
/dev/sdb1 49G randread 64k 5 250008 0 3991 0
/dev/sdb1 49G randread 64k 6 267242 0 4266 0
/dev/sdb1 49G randread 64k 7 282166 0 4504 0
/dev/sdb1 49G randread 64k 8 293171 0 4680 0
/dev/sdb1 49G randread 1M 1 267873 0 534 0
/dev/sdb1 49G randread 1M 2 314568 0 627 0
/dev/sdb1 49G randread 1M 3 290241 0 578 0
/dev/sdb1 49G randread 1M 4 297634 0 593 0
/dev/sdb1 49G randread 1M 5 247376 0 492 0
/dev/sdb1 49G randread 1M 6 263334 0 526 0
/dev/sdb1 49G randread 1M 7 269112 0 536 0
/dev/sdb1 49G randread 1M 8 269197 0 537 0

fail2ban gegen schwache Passwörter


Beim Betrieb von Serverdiensten im Rechenzentrum werden zwangsläufig auch diverse Ports für das Internet freigeschalten, um Benutzern und Admins Zugang zu ermöglichen. Trotz sorgfältig eingesetzter Firewalltechnik können dabei schwache Passwörter von einem Angreifer aus dem Internet ggf. leicht erraten werden (Brute Force Attacke).
Wir schließen diese Lücke mit dem Programm fail2ban.
Es funktioniert nach dem Prinzip: erfolglose Loginversuche erkennen und nach einer festgelegten Anzahl die IP-Adresse sperren. Fail2ban ist für Posix-Betriebssysteme erhältlich, so ist z.B. bei SuSE- und Ubuntu-Linux ein vorkonfiguriertes Paket in der Distribution enthalten. Es lassen sich mehrere Dienste (auch gleichzeitig) damit überwachen, u.a. Apache, Lighttpd, sshd, vsftpd, qmail, Postfix und Courier Mail Server. Dabei werden die Logausgaben vom fail2ban-Daemon laufend überwacht und im Falle einer Attacke der oder die Angreifer per IP-Tables Regel verbannt.
Fail2ban ist auf allen gehosteten Servern unserer Kunden, die mit einem Wartungsvertrag ausgestattet sind, sowie unseren Eigenen im Einsatz. Dank der einfachen Handhabung entsteht dabei kaum administrativer Aufwand.

IT bleibt spannend!

Viele Grüße
Hannes Wilhelm

 

Quellen:

http://www.fail2ban.org/wiki/index.php/Main_Page
http://de.wikipedia.org/wiki/Fail2ban

G wie Groupware und Giraffe


Was haben Giraffen mit Groupware-Systemen gemein?

Der „Vernetzte Welt Cast“ verrät es!

Es war einmal  in einem Land vor unserer Zeit – das übrigens heute Sudan heißt – ein Vize-König namens Muhammad Ali Pascha. Dieser wollte seinem Freund, dem Karl X, seines Zeichens König von Frankreich, eine Freude bereiten und ließ eine junge Giraffe einfangen und nach Europa bringen. Dort wurde sie von ihrem glücklichen Besitzer in Empfang genommen und nach dem arabischen Wort für Giraffe benannt:  „Zarafa“.

Zarafa lebte in Paris ein erfülltes Leben und starb mit 20 Jahren an Altersschwäche.  Das war damals im Januar 1845.

Gut 150 Jahre später waren ein paar Holländer von der gängigen Groupware von Microsoft derart genervt, dass sie kurzerhand beschlossen, eine Alternative dazu zu entwickelten. Diese Software ist heute eine ausgewachsene, fullfeatured Enterprise-Lösung für MAPI-basierte Groupware-Systeme und auch bekanntermaßen eine der wenigen, die problemlos einen Exchangeserver ersetzen kann.
Wie die Entwickler allerdings auf den Namen „Zarafa“  für Ihr Projekt gekommen sind, weiß kein Mensch.

Was wir an Zarafa mögen:

  • Lizenzierung ist ca. halb so teuer wie bei MS Exchange, bei sehr ähnlichem Funktionsumfang.
  • Zarafa ist Leistungsfähiger als Exchange und sehr gut skalierbar.
  • Zarafa ist ein offenes System, das auf Basis gängiger opensource Software entwickelt wird.
  • Es läuft auf Linux.

Deshalb ist WorNet jetzt „Certified Zarafa Partner“ und hilft aktiv mit beim Suchen und Ersetzen von geeigneten Exchangeservern.
Wir nehmen gerne jeden Hinweis entgegen.

Was ein Zarafa-Server alles außerdem noch kann, erfährt man am besten auf der Zarafa-Webseite.

IT bleibt spannend!
Hannes Wilhelm

Endlich neues Webstatistik Tool


WorNet stellt allen Kunden ein neues Webstatistik-Tool zur Verfügung. Nachdem unser altes „Webstats“ bereits arg in die Jahre gekommen ist, haben wir uns nach neuer Technik umgesehen und sind fündig geworden.
Das Tool heiß Piwik und ist für jeden Webserver-Kunden kostenlos benutzbar.

Das mit Google-Analytics vergleichbare Piwik ist sehr modern und umfangreich, trotzdem intuitiv bedienbar. Damit es auch Ihre Webseite erfassen kann, lassen Sie sich von uns ein Codefragment zusenden, dass Sie in Ihre Seite einfügen. Zusätzlich bekommen Sie einen Account auf dem Piwik-Server wo Sie die Daten ausführlich auswerten können.

Mehr Information zu Piwik.

DDOS-Attacke Teil III – Auswirkung und Abhilfe


Letzter Teil der DDOS-Story:

wie gut hat der böse Plan funktioniert und was konnten wir dagegen tun?

Selbstverständlich haben wir unsere Spamfilter nicht abschalten müssen! 🙂 Trotzdem hat die Attacke für etwas Aufregung gesorgt.

Es zeigte sich ein seltsames Bild auf den SecuMail-Servern:
Kaum Maildurchsatz, ein größer immer werdender Mail-Stau aber nahezu keine Last.
Erst nach einigem Grübeln und einem sehr nützlichem Tool namens TCP-Dump, war es uns dann gelungen die Ursache fest zu stellen:
Die Maschinen langweilten sich untätig, während sie vergeblich auf DNS-Antworten der russischen Fake-Domains warteten.
Nach sehr kurzer Zeit waren alle SecuMail-Prozesse auf diese Weise mit „nichts tun“ beschäftigt, so dass kaum noch eMails ausgeliefert werden konnten.


Kann denn eine DNS-Abfrage den kompletten Betrieb aufhalten?

Nein, so einfach ist das nicht möglich. Aber Kleinvieh macht auch Mist und erst recht haufenweise davon!
Was passierte also genau:

Beim Versuch, alle im Mail-Text enthaltenen Linkurls per DNS aufzulösen, haben die SecuMail Prozesse
nie eine Antwort erhalten und nach ca. 3 Sekunden aufgegeben. Wenn jedoch nicht einmal Fehlermeldungen von DNS-Server zurück kommen, wird dieser als „unerreichbar“ eingestuft und anschließend das Glück beim nächsten, im System eingetragenen DNS-Server versucht, was in diesem Falle natürlich ebenfalls keine Aussichten auf Erfolg haben konnte.
In der Regel sind auf unseren Servern drei DNS-Server eingetragen.

~~~
http://keineantwort.russischedomain.ru
http://auchkeineantwort.russischedomain.ru
http://nieantwort.andere-russischedomain.ru
http://stumm.andere-russischedomain.ru
http://sagkeinwort.andere-russischedomain.ru

~~~

Nach Adam Riese wären das insgesamt:
(durchschnittlich) fünf Link-URLs im Text (siehe oben), für die jeweils drei Nameserver mindestens drei Sekunden lang auf DNS-Antworten warten.
Macht ganze 45 Sekunden Wartezeit pro Mail (!). Damit wäre der langsame Maildurchsatz bei geringer Last erklärt.

Wie haben wir dieses Ungemach bekämpft?
Als erste Sofortmaßnahme haben wir die Anzahl der eingetragenen DNS-Server auf einen reduziert und damit die Wartezeit pro Mail
deutlich reduzieren können. Danach wurde es schwieriger weitere Maßnahmen zu finden. Blacklists oder manuelle Domain-Einträge auf unserem DNS-Server scheideten wegen der großen Anzahl an Einträgen, die nötig gewesen wären, aus. Den „Url-Resolver“ komplett zu deaktivieren kam für uns nicht in Frage, da er als wichtiger Bestandteil der Spam-Erkennung kaum entbehrlich ist.

Die Lösung heißt „negative caching“.
Dabei sollen die Ergebnisse der DNS-Abfragen einfach zwischen gespeichert werden, so dass pro Link-Url nur genau einmal abgefragt werden muss. Leider zeigte sich dabei, dass unsere Nameserver (Bind) trotz aktiviertem negative caching nicht in der Lage waren, durch Timeout abgebrochene Anfragen zu cachen. Das chaching funktioniert nur für regulär erhaltene DNS-Antworten, nicht aber, wenn der DNS-Server nicht antwortet.
Es gibt da auf Linux Systemen jedoch noch einen unscheinbaren Dienst namens nscd (Name Service Caching Daemon), welcher bisher kaum jemals unsere Aufmerksamkeit erregt hatte. Und dieser ist auch in der Lage sich eine zeitlang zu merken, ob ein Server überhaupt antwortet. Weil die Menge der im Text verlinkten Urls nicht unendlich groß sein kann, haben sich selbige nach kurzer Zeit fast vollständig in den NSCD-Caches eingefunden und damit einen Scanvorgang in normaler Geschwindigkeit ermöglicht.

Wenig später waren alle eMails in der Warteschlange abgearbeitet. Abgesehen von der verzögerten Auslieferung haben unsere Kunden nichts von alledem mitbekommen.

Fazit:
Die Bekämpfung von Spam bleibt ein mühsames „Katz und Maus Spiel“.
Mit einem flexiblen und offenen Filter-System in der eigenen Hand, das man zeitig anpassen und erweitern kann, ist man allerdings gut für den Kampf gerüstet.

Viele Grüße
Hannes Wilhelm

DDOS-Attacke Teil II – Funktionsweise und Motivation


Zweiter Teil der DDOS-Story:

Wie hat es funktioniert und wofür machen sich die Spamer nur all die Mühe?

Diese Spam-Attacke kam sogar mehrfach „verteilt“ daher:
Unzählige unerwünschte eMails wurden in üblicher Spam Manier an zahlreiche Adressen unserer Kunden versandt. Klar, dass dabei sowohl Absender-Adressen, als auch die IP-Adressen der Absender, ständig wechselten, um ein leichtes Ausfiltern durch SecuMail an dieser Stelle zu verhindern. Bis hierher sollte sich die Angelegenheit noch nicht weiter vom Alltag eines Spamfilters unterscheiden. Außergewöhnlich war allerdings der Inhalt der eMails:
Neben ein paar Zeilen Random-Text enthielt dieser nämlich eine Reihe von HTML-Links, deren Urls auf seltsame Domains zeigten. Diese Urls waren stets nach folgendem Strickmuster aufgebaut: x743h.russische-domain.ru, wobei „x743h“ als scheinbar zufällige Zeichenkombination den unzähligen russischen Domains, angehängt wurde. Natürlich tauchte dabei kaum eine Kombination mehr als einmal auf, was die manuelle Filterung praktisch ausschließt.

Der böse Plan hinter all dem sah vor, dass die Nameserver, auf welchen die russischen Domains gehostet wurden, so eingestellt waren, dass Anfragen auf Sublevel-Domains nie beantwortet wurden. Das bedeutet wiederum, dass jede Anfrage in einem DNS-Timeout endet. Ein guter Spamfilter untersucht jedoch alle Links, die er im eMail-Text findet und prüft, ob diese im DNS aufgelöst werden können oder ob es sich um bekannte Spam-Urls handelt.
Ziel des Plans war also, dass die Filterserver während der Untersuchung der eMails extrem viele DNS-Abfragen tätigen müssen, um sie dabei auch noch möglichst lange hinhalten zu können. Die extreme Häufigkeit dieser Wartezeiten sollte dann für einen Stillstand der eMail-Verarbeitung sorgen.
Auf derartige Ausfälle bei der eMail Zustellung reagieren Administratoren dann in der Regel mit dem kleineren Übel, nämlich mit dem Abschalten der Spam-Filter Funktion. Und damit hätte der Spamer freie und ungebremste Fahrt, direkt in die Postfächer der Adressaten – unserer Kunden!

Ob und wie dieser Plan zum Erfolg führte, erfahren Sie im dritten Teil.

Viele Grüße

Hannes Wilhelm

DDOS – SecuMail und die Distributed-Denial-of-Service-Attacke


Teil I

Anfang Juni dieses Jahres wurden die SecuMail Server – so wie vermutlich alle schlaueren Spamfilter – Opfer einer DDOS Attacke.
Wenngleich sich der entstandene Schaden im Fall SecuMail auf lediglich wenige Stunden mit stark verzögerter Auslieferungszeit beschränkt hat, ist es doch ein interessanter und erwähnenswerter Fall.

Weil ich Ihnen nicht zu viel Stoff auf einmal zumuten möchte, kommt die ganze Story auf drei Einträge verteilt in den „Vernetzte-Welt-Cast“. Dies ist der erste Teil.

Was ist eine DDOS-Attacke überhaupt?
Bei einer sog. Distributed-Denial-Of-Service Attacke (zu deutsch: Verteilter Dienst-Verweigerungs Angriff) wird ein Dienst im Internet von einer Vielzahl anderer, im Netz verteilter Rechner zeitlich koordiniert, mit derart vielen und oder aufwändig zu bearbeitenden Anfragen belastet, so dass er deren Abarbeitung nicht mehr bewältigen kann und damit zwangsläufig auch reguläre Anfragen nicht mehr beantwortet werden können. Auf diese Weise können böse Häcker nahezu beliebige Webpräsenzen oder Web-Dienste zeitweise vom Netz nehmen. Einen einfachen Schutz gibt es nicht.

Genau so etwas ist mit unserem Antispam-Service SecuMail versucht worden.

In den kommenden beiden Teilen beschreibe ich die Funktionsweise und Motivation des Angriffes bzw. die Auswirkung und Gegenmaßnahmen.

Viele Grüße
und bis bald

Hannes Wilhelm