Immer größere Datenmassen sicher zu speichern ist eine Herausforderung für jede IT-Infrastruktur. Schon mit Gigabit-Ethernet lassen sich aber ... (mehr)

Schritt 2: Load Balancer und Firewalls

Eines der ersten Probleme, mit denen ein Angreifer sich herumschlagen muss, tritt bei Sites mit Load Balancern, Intrusion-Prevention-Systemen (IPS) und (Application) Firewalls auf. Wer eine Site mit einem Load Balancer angreift, wird vermutlich einmal beim dahinter stehenden Server A, nächstes Mal aber bei Server B landen, was die Erfolgsaussichten schmälert. Wenn ein IPS oder eine aktive Firewall läuft, wird sie weitere Angriffe vielleicht blockieren.

Wie kann man nun das Vorhandensein solcher Abwehrsoftware erkennen und sie umgehen? Load Balancer sind normalerweise nicht so ausgelegt, dass sie sich verbergen. Wenn ein System zum Beispiel den DNS Name Service fürs Load Balancing verwendet, findet man dies leicht mit einem Tool wie »dig« heraus. Alternativ können Programme wie Nmap auch Load Balancer an ihrem TCP/IP-Fingerabdruck erkennen.

Web Applications Firewalls zu erkennen ist ebenfalls nicht schwer. Es genügt, einen bekannten Angriff auf die Site von einem anderen Rechner aus oder per Tor zu starten, dann wird man schon sehen, ob die Verbindung abgebrochen und zukünftige Versuche gleich geblockt werden. Wer erfahren möchte, wie es die Penetration-Test-Profis machen, sollte sich die Dojosec-Präsentation von Joseph McRay genauer ansehen [2].

Solche Hürden zu überwinden ist natürlich möglich, die Betreiber sollten sich also nicht in falscher Sicherheit wiegen. Im Fall eines Load Balancer genügt es, statt des Hostnamens die IP-Adresse eines der beiden Knoten zu verwenden, um sicherzustellen, dass man immer das gleiche System angreift. Bei Firewalls steht häufig noch der Weg über Web- oder E-Mail-Ports offen, den die meisten nicht blockieren.

Früher war das auch kein Problem, denn Webseiten und E-Mail waren mehr oder weniger das Gleiche: statische Inhalte mit rudimentärer Formatierung. Seither hat sich das eher ins Gegenteil verkehrt. Die meisten Mailclients beherrschen nun auch HTML, und HTML wurde um eine Menge ausführbarer Technologien bereichert, allen voran Javascript.

Viele Programme beherrschen nun Javascript: Webbrowser, Mailprogramme, ja sogar der Adobe-PDF-Reader. Somit müssen Sie sich nicht nur um Buffer Overflows, die mit Bildern eingeschleust werden, Sorgen machen, sondern um eine komplette Turing-Maschine, die in vielen Programmen auf Schadcode wartet. Weil fast niemand Javascript ausschaltet oder zuverlässig blockt – damit würde vieles auch nicht mehr funktionieren –, eignet es sich hervorragend zum Angriff auf eine Vielzahl von Programmen.

Schritt 3: Scanner und Exploits

Einige wenige Angriffsmethoden funktionieren bei den meisten gegenwärtigen Netzwerk-Setups und dem typischen Anwenderverhalten. Die erste ist der Angriff auf exponierte Server wie DNS. Die zweite richtet sich gegen Webserver, die heute ja meist komplexe Anwendungsserver sind. Die dritte nimmt schließlich E-Mail ins Visier – die die meisten Anwender de facto auch als File-Sharing-Dienst heranziehen.

Im ersten Fall verwenden Angreifer meistens einen Vulnerability-Scanner wie Nmap oder Nessus und verwenden dann vorgefertigen Exploit-Code entweder von Hand oder mit einem Toolkit wie Metasploit [3]. Am Ende kommt dabei nur zu oft heraus, dass der Einbrecher auf der betroffenen Maschine Code ausführen und schließlich eine Root-Shell ausführen kann.

Um herauszufinden, welche Software welche Lücken hat, bieten sich einschlägige Sites wie CVE [4] und OSVDB [5] an, die in ihren Reports auch Links zu weiteren Online-Ressourcen führen. Exploit-Code gibt es bei Milw0rm ([6], Abbildung 3) und Packetstorm Security ([7], Abbildung 4).

Abbildung 3: Suchergebnisse für SQL-Injections auf der Milw0rm-Site.
Abbildung 4: Die Beschreibung eines Exploit auf Packetstorm Security.

Metasploit selbst enthält vergleichsweise wenige Exploits, nach letzter Zählung nur etwa 300. Packetstorm dagegen listet schon pro Monat 300 bis 400 Exploits auf. Wenn auf einem Webserver veraltete Software läuft, ist die Wahrscheinlichkeit recht hoch, dass sich auf einer der Sites entweder ein Exploit findet oder zumindest weitere Hinweise dazu.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021