Honeybox-Appliance von Secxtreme im Test

© Richard Blaker, Fotolia.com

Lockstoff

Intrusion Detection gilt Admins als wartungsintensive Technik, da sie viele Fehlalarme auslöst. Meldet sich hingegen ein Honeypot zu Wort, hat tatsächlich ein unberechtigter Zugriff stattgefunden. Bislang galten die klebrigen Fallen aber als aufwändig zu konfigurieren. Die Honeybox von Secxtreme tritt an, das zu ändern.
Immer größere Datenmassen sicher zu speichern ist eine Herausforderung für jede IT-Infrastruktur. Schon mit Gigabit-Ethernet lassen sich aber ... (mehr)

Seit spätestens 2006 ist es um Honeypots ruhig geworden. Der Hersteller Symantec beispielsweise hat sein kommerzielles Produkt Mantrap eingestellt [1] , andere betreiben noch Webseiten, auf denen Kunden veraltete Produkte aus dem Jahr 2004 bestellen können, oft für Windows. Ähnlich ist es den zahlreichen Open-Source-Varianten ergangen, die in dieser Zeit versucht haben, das damals vorhandene Verlangen nach den hippen Honeypots zu stillen [2] . Ihre Befürworter positionierten diese Technik als ein Werkzeug, um den Netzwerk-Perimeter, also den Übergang zwischen wohlbehütetem internen Netz und dem gefahrvollen Internet zu verteidigen.

Sie wollten Angreifer wie in einem Spionageroman beobachten. Doch bald kamen Netzverantwortliche zu dem Schluss, dass durch Extranets, mobile Benutzer und komplexe Internetanwendungen der Perimeter immer mehr an Bedeutung verliert. Schließlich gilt es, nicht primär den Netzübergang zu schützen, sondern die Daten, ganz egal, wo sie sind.

Mit martialischer Perimeter-Verteidigung war es aus – und auch fast mit den Honigtöpfen. Einzig das Honeyd-Projekt [3] hat überlebt und versucht sich in Literatur und experimenteller Praxis als Alternative zu herkömmlichen Intrusion-Detection- und Intrusion-Prevention-Systemen (IDS/IPS) zu definieren [4] .

Seit Anfang 2009 bietet das Münchner Unternehmen Secxtreme die auf dem Honeyd basierende Honeybox-Appliance an [5] . Sie versteht sich als Gegenentwurf zur Intrustion Detection. Der Hersteller behauptet, dass Netzadmins durch ihren Einsatz bessere Resultate bei niedrigeren Preisen erzielen als mit IDS/IPS-Systemen. Der Autor hat sich in seinem Testlabor eine Woche lang mit der Honeybox auseinandergesetzt, um das zu überprüfen.

Die Appliance (siehe Abbildung  1) setzt nach der Konfiguration eine Anzahl virtueller Low-Interaction-Honeypots auf (siehe Kasten "Honeypots in allen Geschmacksrichtungen" ). Dabei lassen sich auf einem physikalischem Sensorinterface mehrere Hundert virtuelle Honeypots mit jeweils eigenen IP-Adressen konfigurieren, die für den Angreifer zunächst wie echte Systeme aussehen.

Honeypots in allen Geschmacksrichtungen

Die Literatur teilt die verführerischen Fallen in mehrere Kategorien ein. Physikalische Honeypots sind konkrete Systeme, die keine Anwendungen emulieren. Alle Dienste, die potenzielle Angreifer anlocken, laufen tatsächlich auf dem System. Angreifer kommunizieren mit ihnen wie mit einem echten System. Im Gegenzug hat der neugierige Netzüberwacher die Möglichkeit, das Vorgehen und die Tools von Angreifern detailliert zu überwachen.

Obwohl Admins mittels Xen oder KVM pseudo-physikalische Honeypots vergleichsweise einfach einrichten und überwachen, stellt sich die Frage, wer ernsthaft daran interessiert ist, die Vorgehensweise von Angreifern zu erforschen. Da dies Zeit, Aufmerksamkeit und damit Geld kostet, ist die weite Verbreitung dieser Varianten ungewiss.

Virtuelle Honeypots simulieren reale Server. Low-Interaction-Honeypots beschränken sich dabei nur auf einen Teil eines echten Systems und emulieren zumeist den Networkstack, die MAC-Adresse und bestimmte Daemons. Sie lassen sich nicht dazu verwenden, um Angreifer auszuspionieren. Mit der Installation von Low-Interaction-Honeypots erkauft sich der Admin aber Zeit, die er dazu nutzen kann, um zum Beispiel seine Produktivumgebung in Sicherheit zu bringen: Während ein ungebetener Gast versucht einen erfolgreichen Angriff beim Honeypot zu landen, spielt der Admin schleunigst die fehlenden Sicherheitspatches ein. Wie lange sich der Angreifer mit einem Honeypot aufhält, hängt erfahrungsgemäß selten davon ab, ob es sich um einen virtuellen oder einen physikalischen Honeypot handelt.

Abbildung 1: Die Honeybox von Secxtreme gibt es als Software- und Hardware-Appliance. Das Standardmodell besitzt vier Netzwerkports.
Abbildung 2: Eingangs konfiguriert der Admin die Überwachungsports der Honeybox-Appliance. Interface eth0 ist das Out-of-Band-Interface für das Management, die anderen stehen als Sensoren zur Verfügung.

Die Erstinstallation der Honeybox erfolgt über das serielle Interface mit einem Setup-Tool, dessen Benutzerführung ähnlich einem Debian-Installer (die Appliance basiert auf Debian) oder Yast von Open Suse funktioniert. Als Hürde erwies sich, dass Debian mit UTF-8 als Zeichensatz arbeitet und die Masken und Menüs des Installers bei älteren Terminalprogrammen mit einem anderen Encoding nicht zu erkennen sind. Der Hersteller hat auf Nachfrage hier weitergeholfen und auf Seite  126 seines Handbuchs verwiesen. Netzwerk- und Sicherheitsadministratoren, die mit virtuellen Honeypots vertraut sind, konfigurieren die Honeybox danach ohne weitere Hürden.

Bis auf die Lizenz ist alles vorinstalliert und der Systemverwalter konfiguriert lediglich die Honeybox für ihre zukünftige Umgebung. Er richtet ein Out-of-Band-Administrationsinterface und bis zu drei Sensorinterfaces in dedizierte Subnetze ein. Abbildung  2 zeigt den Honeypot mit einem Out-of-Band-Interface mit deaktivierten Funktionen und einem aktiven Sensorinterface.

Wenn bei der Installation etwas schiefgeht, darf der Admin die Appliance mit dem mitgelieferten USB-Stick auf die Fabrikeinstellungen zurücksetzen. Ist die Installation geglückt, aktualisiert die Software der Appliance sich per HTTP vom Updateserver des Herstellers. Dazu benötigt sie natürlich eine bestehende Internetverbindung.

Fühler austrecken

Auf jedem Sensorinterface darf der Admin mehrere virtuelle Honeypots mit eigenen virtuellen IP-Adressen konfigurieren. Alle Honeypots auf einem Interface müssen sich dasselbe Subnetz teilen, können aber verschiedene Systeme emulieren. So lässt sich zum Beispiel eine Lockfalle konfigurieren, die einen IIS-Webserver vorgaukelt, und eine andere, die vorgibt, ein Cisco-Router zu sein. Der Admin bestimmt das durch das Zuweisen von Templates. In der getesteten Version 3.1-914 der Honeybox gab es 22 verschiedene Templates (siehe Tabelle  1).

Tabelle 1

Emulierte Profile

Menü

Emuliertes System

cisco

Cisco IOS 12.1

cray

Cray Super Computer

default

Generisches Default-Template

hplj

HP Laserjet Printer

hppc

HP Procurve Switch

stealth

Stealth-Template (antwortet nicht, simuliert eine Drop-Policy)

suse10

Suse Linux System, Version 10.0

suse7

Suse Linux System, Version 7.0

suse8

Suse Linux System, Version 8.0

suse82

Suse Linux System, Version 8.2

osx10

Macintosh mit Mac OS X

sol27

Sun Solaris 2.7 Host

sol28

Sun Solaris 2.8 Host

win2k2e

Windows 2000 Server mit SP2 und MS Exchange

win2k2

Windows 2000 Server mit SP2 und Default-Services

win2k3

Windows 2000 Server mit SP3 und Default-Services

win2k4i

Windows 2000 Server mit SP4 und IIS

win2k4

Windows 2000 Server mit SP4 und Default-Services

win2k1i

Windows 2000 Server mit SP1 und IIS5, SSH

win2k1s

Windows 2003 Server mit SP1 und SSHv2

win2k4ws

Windows 2000 Professional Workstation mit SP4

winxp1

Windows XP Workstation mit SP1

Laut Hersteller sollten Anwender Honeyboxen in demilitarisierten Zonen (DMZ), in der Nähe der Firewall oder in vertrauenswürdigen internen Segmenten des LAN einsetzen. Dort erkennt das Frühwarnsystem Angreifer, aktive Trojaner, Viren oder Würmer, sobald sie auf einen der virtuellen Köder anbeißen.

Aufgrund der Position im Netzwerk und des Prinzips von Honeypots meldet die Honeybox nur echte Angreifer, echte Viren oder Trojaner, die unerkannt im Netzwerk aktiv sind. Die Honeybox liefert also keine falschen Alarme. Im Gegensatz zu vielen IDS/IPS-Systemen ist ihr Normalzustand, dass sich nichts tut und sie keine Arbeit macht. Auch haben es die Tester als angenehm empfunden, dass die Honeypots keine Policy und kein Tuning erfordern. In der Praxis ist das eine wertvolle Eigenschaft.

Zum Test hat der Autor die Honeybox einige Tage ungeschützt ins Internet gestellt, um Logeinträge und Screenshots zu erhalten. Als Ergebnis meldete das System pro Tag rund sechs Angreifer, von denen sich zwei längere Zeit mit dem Honypot beschäftigt haben. Die Appliance überwacht alle konfigurierten virtuellen Honeypots und loggt jede versuchte Kontaktaufnahme, sei es mittels ICMP, ARP oder durch den Zugriff auf emulierte Daemons und Services.

Ihre Alarme verschickt die Honeybox zusätzlich auf Wunsch per E-Mail, sendet sie an einen Syslog-Server oder zeigt sie über das Webfrontend auf dem OOB-Interface an (siehe Abbildung  3). Der Hersteller hat in die Oberfläche die BASE-Engine integriert [6] , mit der Systemverwalter die Zugriffsversuche auswerten (siehe Abbildungen 4 und 5 ). Secxtreme hat die BASE-Engine erweitert und angepasst, denn sie verarbeitet normalerweise nur Snort-Alarme. Die Version auf der Appliance geht jedoch auch mit den Alarmen des Honeyd um.

Abbildung 3: Vom Dashboard der Honeybox aus überblickt der Systemverantwortliche den technischen Status der Honeybox und hat so den Überblick der verwendeten Bandbreiten oder der CPU-Last.
Abbildung 4: Das Dashboard der BASE-Engine zeigt eine Übersicht aller bisherigen Logeinträge und Alarme an. Die Web-basierte Software ermöglicht vielfältige Auswertungen und Statistiken.
Abbildung 5: Die Aktionen eines Angreifers betrachtet der Systemverantwortliche in einer Detailansicht.

Im Testverlauf hat die konfigurierte Appliance mit ihren virtuellen Honeypots zuverlässig funktioniert. Lediglich bei der Neukonfiguration oder beim Ändern von bestehenden virtuellen Honeypots gab es gelegentlich Abstürze des Systems. Auf Nachfrage erklärte der Hersteller, dass es sich hier um einen bekannten Bug im Tool »whiptail« handelt, das in den Menüs den Fortschrittsbalken erzeugt. Er versicherte, bereits daran zu arbeiten, das Problem zu beheben.

Die getestete Honeybox besitzt vier Sensorinterfaces, die ihr Betreiber dazu konfigurieren kann, zum Beispiel drei verschiedene DMZs oder zwei DMZs und das interne Netz mit Honeypots auszustatten. Die Möglichkeiten, mit dem Honeypot zu kommunizieren, sind bei Low-Interaction-Honeypots beschränkt: Ein Angreifer kann sich zum Beispiel nicht über einen emulierten Telnetd einloggen.

Dennoch ist es für den Admin ratsam, einige Überlegungen zur Sicherheit anzustellen, bevor er sich dazu entscheidet, mehrere DMZs gleichzeitig zu überwachen. Eine Verwundbarkeit der Honeybox oder des Honeyd selbst würde nämlich ungewollt die Segmentierungsfunktion der Firewall aushebeln: Wer mit der Honeybox mehrere DMZs gleichzeitig überwacht (siehe Abbildung  6), baut so durch den Honeyd eine Brücke zwischen den einzelnen DMZs. Die Segmentierung ist dann von der Sicherheit des Honeyd selbst abhängig. In der Theorie kann auch der Honeyd Schwachstellen aufweisen, die ein Angreifer womöglich dazu nutzt, sich zuerst Zutritt zur Appliance und danach zu anderen DMZs zu verschaffen.

Abbildung 6: Eine Honeybox mit zwei Sensor- und einem OOB-Interface überwacht zwei unabhängige demilitarisierte Zonen. Der Aufbau beeinträchtigt schlimmstenfalls die Segmentierung der Zonen und öffnet Angreifern möglicherweise eine Hintertür.

Stolperdrähte spannen

Obwohl der Hersteller Secxtreme in die Appliance Tripwire integriert, um ihre mögliche Kompromittierung frühzeitig zu entdecken [7] , erscheint es nicht ratsam, mit einer physikalischen Honeybox verschiedene Sicherheitszonen zu überwachen. Empfehlenswert ist hingegen, mehrere Subnetze des gleichen Sicherheitsniveaus im Auge zu behalten (siehe Abbildung  7). Mit virtuellen Honeypots sind auch ungewöhnliche Topologien abbildbar: So wäre ein Admin in der Lage, in einem internen Subnetz einige Hundert unterschiedliche Honeypots zu konfigurieren und darunter einen einzigen Produktionsserver zu verstecken.

Abbildung 7: Mehrere Honeyboxen untersuchen die unterschiedlichen Sicherheitszonen (blau, grün). Jedes Sensorinterface überwacht jeweils ein anderes Subnetz mit gleichem Sicherheitsniveau.

Der Hersteller gibt zusätzlich an, die Honeybox-Appliance erkenne im internen LAN Würmer oder Viren: Solche Schadsoftware würde vermutlich versuchen die Systeme in ihrer Umgebung zu infizieren, also auch die Honeypots. Was die aber als Alarm melden würden, und zwar auch dann, wenn der Virus völlig neu ist und es dafür noch keine Antivirus-Patterns bei den Herstellern gibt, also wenn es sich um einen im Kasten "Zero Day Attacks" beschriebenen Angriff handelt. Da die Honeyboxen ja keinerlei produktive Aufgaben haben, ist definitionsgemäß jeder Kontaktversuch mindestens als Fehler, wenn nicht als Angriff zu werten.

comments powered by Disqus
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 /2023