Artikel-Schlagworte: „Fedora“

In letzter Zeit häufen sich mal wieder die Angriffe auf Webseiten, bevorzugt Shops. Die Masche der Erpresser läuft meist so, den DDoS Angriff per Email anzukündigen um vorab ein “Schutzgeld” zu erpressen. Näheres wusste bereits der Spiegel unter http://www.spiegel.de/netzwelt/web/0,1518,701879,00.html zu berichten.

Im Gegensatz zum Spiegel Artikel, welcher meist von Säberasseln ausgeht, und eher auf die Trittbrettfahrer abzielt, ist die Bedrohung durchaus real, da sich bereits mit einem Server und ein wenig Perl entsprechend ungeschützte Webserver aus dem Rennen nehmen lassen. Einer der Vertreter dieser Angriffsschnecken, wie ich sie nenne, ist Slowloris, aber es gibt auch andere die ähnlich arbeiten.

Da Slowloris ohne Probleme frei verfügbar ist unter http://ha.ckers.org/slowloris/ , kann jeder halbwegs versierte ITler so einen Angriff starten, sei es zu Kontrollzwecken ob die eigene Infrastruktur vor solchen Angriffen geschützt ist, oder auch zu kriminellen Zwecken, wie der oben genannten Erpressungsweise. Anfällig für solche Angriffe sind zum Beispiel die meisten Apache Server, alte Nginx Versionen und auch diverse andere Webserverplattformen.


In größeren lastverteilten Systemen welche Hardware Balancer nutzen und die korrekt konfiguriert sind, tritt das Problem eher weniger auf, da diese meist von Haus auf ein sogenanntes Late Binding vornehmen, und gegen die meisten dieser Angriffe schützen. Anders sieht es bei alleine im Netz stehenden Servern aus, oder lastverteilten Systemen welche eine Direktverbindung zum Webserver auf dem zum Beispiel ein Apache Server läuft zulassen (IPVS als Beispiel).

Für die letzteren Varianten gibt es aber dennoch diverse Schutzmöglichkeiten. In einem kompletten Setup mit Balancing kann man zum Beispiel als Eintrittstor einen aktuellen NGINX Server nehmen, der auch gleich das SSL Offloading übernehmen kann, aufgrund seiner sehr guten Performance. Dieser greift auf einen HAPROXY zu welcher das Balancing übernimmt. Die eigentlichen Webserver sind am Ende Apache Webserver, welche jedoch mit mod_qos laufen, welches zum Beispiel SLOWLORIS sehr gut abfangen kann.

Die einzelnen Elemente dieser Setups und genauerer Beschreibungen findet man unter den folgenden Links:

Mit diesen Komponenten kann man seine Infrastruktur relativ gut gegen diese Form von Angriffen schützen. Natürlich sollten bei Linuxsystemen von Haus auf zusätzlich TCP_SYNCOOKIES aktiviert sein, um eine andere Angriffsform abzudecken. Distributionen wie aktuelle Fedora oder CentOS haben diesen Parameter bereits als Standardeinstellung aktiviert.

Dann mal erfolgreiches Schützen!



  • Zum Testen wollte ich in den letzten Tagen mal mit XEN Kerneln und entsprechenden virtuellen Maschinen arbeiten. Hierfür hatte ich eine Teststellung in einer VMWare bei der alles ohne Probleme funktionert, allerdings auch keine speziellen Eigenheiten was die generelle Konfiguration der VMWare angeht. Das heißt, keinerlei RAID oder LVM im Dom0 System oder sonstige außergewöhnliche Dinge.

    Also, gings auf das echte Testsystem, ein HP Server, die einzigen Unterschiede zur Test VMWare waren ein RAID1 als / Partition (dev/md0) und natürlich physische Hardware. Die Maschine scheitert beim booten an einer XEN Panic. Da ich leider erst wieder am Dienstag vor Ort bin, und die Sache remote gemacht habe, kann ich noch nicht ersehen wo das Problem wirklich liegt.

    Derzeit vermute ich zwei Ursache. Der XEN Kernel an sich ist eine ältere Version als der aktuelle baremetall Kernel, vielleicht hat der XEN Kernel in dieser Version von Haus auf Probleme mit der HP Hardware, was ich allerdings für unwahrscheinlich halte. Die zweite Ursache wäre, daß der XEN Kernel Probleme hat mit einem RAID Root zu starten, da er entweder a) keine Module laden kann, oder b) die Module für RAID nicht einkompiliert hat, und somit nicht nach der Initial Ramdisk ins System booten kann.

    Sobald ich herausgefunden habe woran es liegt, poste ich die Neuigkeiten.

    Im Rahmen eines Projektes lautete die Kundenanforderung, ein Reverseproxysystem zur Verfügung zu stellen, welches dahinterliegende Webanwendungen mit einer eigenen autonomen Benutzerverwaltung schützt. Im ersten Augenblick eigentlich ein Fall für die diversen Autorisierungsmodule des Apachen. Jedoch sollte zum einen der Login nicht dieses übliche “Unauthorized” Kästchen des jeweilgen Browsers sein, sondern eine hübsche Anmeldeseite. Außerdem sollte es nicht möglich sein über einen direkten Link auf die Seite ohne Anmeldung zuzugreifen.

    Da mir keine Möglichkeit bekannt ist, dies mit den Standardmodulen zu realisieren, hab ich mich auf der Suche nach einer Lösung gemacht, und bin fündig geworden. Das entsprechende Apache2-Modul nennt sich ‘mod_auth_form’ und liegt leider nicht bei den Standardmodulen des Apachen dabei.

    ‘ mod_auth_form’ basiert auf mod_auth_mysql und mod_auth_sim. Ein Auszug der Funktionsweise in Englisch von der Projekthomepage:

    The mechanics of the module works in the following way. A web client (user) requests for a restricted page/directory. The module sends back a ‘Page Has Moved’ error, pointing the client to the page containing a login form. Through server-side scripting, a session is created in the MySQL database and the client (i.e. cookies or query string). The session itself consists of a unique, random, and temporary ID that is associated with a user. The client then makes the same request along with the session ID (SID) and the user ID (UID). The module compares and validates the two IDs against the IDs stored in the MySQL database. If successful, the module sends back the requested page; otherwise, the module once again sends back the ‘Page Has Moved’ error page. In addition (if specified), the module will also validate the user’s group membership and act accordingly.

    Bei Gelegenheit poste ich eventuell demnächst mal ein Tutorial zum Einsatz. Da es das Modul nicht als RPM gibt, habe ich mal eins für Fedora 8 erstellt, welches nachstehend zum Download bereit steht.
    mod_auth_form-2.05-1.NWE.fc8.i386.rpm