Das World Wide Web (WWW) ist als Hypermedia-System konzipiert; es stellt textuelle, graphische und auditive Informationen sowie Interaktionsmöglichkeiten auf WWW-Seiten zur Verfügung, auf die über graphische Benutzeroberflächen, sogenannte WWW-Browser, zugegriffen wird. Die Bereitstellung der Hypermedia- und Interaktionsfunktionalitäten im Browser erfolgt mit Hilfe der Auszeichnungssprache HTML (Hypertext Markup Language).

HTML wurde auf Grundlage von SGML (Standard Generalized Markup Language) durch eine Initiative von Tim Berners-Lee, dem Begründer des WWW, entwickelt. Aus dieser Initiative ging 1994 das „W3-Consortium" (W3C) hervor; alle bedeutenden Unternehmen der IT-Branche von Adobe, Apple über IBM, Intel und Microsoft bis Oracle, Xerox u.v.m. sind darin vertreten. Seit seiner Gründung zeichnet dieses Industriekonsortium für die weltweite Normung von HTML verantwortlich. Im Mai 1996 wurde die aktuelle Version HTML 3.2 vom W3C verabschiedet.

HTML kennzeichnet die Struktureigenschaften eines WWW-Dokumentes und darin enthaltene Verweise (Links) auf andere Dokumente im WWW. Die Struktureigenschaften betreffen z.B. Absätze, Titel, Listen und Überschriften, nicht jedoch exakte Schriftarten, -größen oder Einrückungen der Bildschirmdarstellung. Das letztlich für den Betrachter sichtbare Layout eines Dokumentes ist von den graphischen Darstellungsmöglichkeiten des Browsers abhängig. Für die Übertragungsgeschwindigkeit im WWW ist es entscheidend, daß der Umfang „roher" HTML-Dokumente mit eingebetteten Formatierungsanweisungen deutlich geringer ist als der Umfang komplett formatierter und im Layout fertiger Dokumente.

HTML-Dokumente enthalten den Text des Dokumentes selbst und die HTML-Auszeichnungen, welche die Struktur, die Formatierung des Dokumentes und die Verweise auf andere Dokumente oder eingefügte Medien kennzeichnen. HTML-Auszeichnungen (Tags) haben in der Regel eine Anfangs- und eine Ende-Kennung, die den zu beeinflussenden Darstellungsinhalt umrahmen.

Eine HTML-Datei besteht aus zwei Teilen: der Kopfteil wird vom Head-Tag, der Rumpfteil vom Body-Tag umfaßt (vgl. Abb. 1). Der Kopfteil enthält allgemeine Informationen über das Dokument, wie bspw. dessen Titel. Im Rumpfteil befindet sich der gesamte Dokumentinhalt mit seinen Auszeichnungen für Struktur und Verweise.

Abb. 1 HTML-Code-Beispiel

Tags für die Einbindung von Verweisen (Links) auf andere WWW-Seiten sind bezeichnend für den Hyperlink-Charakter des WWW. Ein Tag vom Typ <A HREF = „URL"> kann auf eine beliebige Seite im gesamten WWW verweisen, die über einen URL (Unique Resource Locator) erreichbar ist. Wählt der Anwender auf seiner Browser-Oberfläche einen solchen Link an, wird die adressierte WWW-Seite abgerufen und angezeigt. Auf gleiche Weise lassen sich mit dem Img-Src-Tag einzelne Graphiken adressieren und anzeigen (Abb. 2 zeigt das Ergebnis des HTML-Code-Beispiels aus Abb. 1).

Abb. 2 Ergebnis des HTML-Code-Beispiels

Die wichtigsten Strukturierungsanweisungen für Text sind Tags für Absätze, Überschriften mehrerer Untergliederungsstufen, Listen, Textausrichtung und Zeichenformatierung. Die Kennzeichnung einer Zeichenkette als Block gewährleistet die durchgehend einheitliche Darstellung des betreffenden Abschnittes. Da HTML im ASCII-Format geschrieben wird, müssen für die Darstellung von deutschen Umlauten spezielle Codes in ein kaufmännisches Und (&) und ein Semikolon (;) gefaßt werden (z.B.„ü" für ein „ü" und „Ü" für ein „Ü").

Standardisierte Tags für Farb-, Schriftart- und Hintergrundgestaltungen, das Umfließen von Bildern mit Text, die transparente Überlappung von Anzeigeelementen sowie die Darstellung von Text und Graphiken in Tabellen geben HTML-Autoren einen breiten Gestaltungsspielraum für das Layout ihrer Dokumente. Die Browser von Netscape und Microsoft erkennen und handhaben jedoch auch herstellerspezifische HTML-Tags, die (noch) nicht vom W3-Consortium als Standard verabschiedet sind. Mit der Frame-Technik von Netscape und Microsoft lassen sich z.B. WWW-Seiten in mehrere Fenster unterteilen. Die verwendeten Frame-Tags gehören nicht zum aktuellen HTML-Standard, werden in der Praxis jedoch häufig zur Grobstrukturierung von WWW-Seiten genutzt.

Eigenentwickelte HTML-Dokumente sollten grundsätzlich offline in verschiedenen Browsern getestet werden, bevor sie online im WWW zur Verfügung gestellt werden. Für die Entwicklung von HTML-Dokumenten bieten sich Web-Publishing-Pakete an, die einen Browser zum Testen, einen HTML-Editor zum Handcoding und hochproduktive WYSIWYG-Werkzeuge enthalten. Die führenden Produkte sind als zeitlich begrenzte Testversionen, Shareware oder Freeware bei den Herstellern downloadbar (Microsoft Frontpage, Adobe Pagemill, Softquad Hot Metal, Corel Web Designer, Asymetrix Web Publisher, Netscape Navigator Gold, Claris Homepage, Netobjects Fusion, Golive Cyberstudio). Mit den WYSIWYG-Werkzeugen lassen sich relativ schnell WWW-Seiten produzieren: Assistenten unterstützen ein konsistentes Seiten-Design, Formatvorlagen strukturieren Seiteninhalte, Graphiken werden per Drag und Drop plaziert. Der HTML-Code solcher Aktionen wird automatisch generiert. Über die Gegenprüfung dieses Codes im HTML-Editor kann sich auch der Einsteiger an das Handcoding von HTML für Feinarbeiten herantasten.

HTML ab der Version 2 ermöglicht die Interaktion zwischen dem Anbieter der WWW-Seite und dem Anwender über Formulare, die der lokale Browser auf Anweisung des Form-Tags am Bildschirm aufbaut. Für den Input des Anwenders stehen Eingabe- und Auswahlfelder sowie Schaltflächen zur Verfügung. Mit dem an den Form-Tag gebundenen Verknüpfungsmechanismus CGI (Common Gateway Interface) werden Formulareingaben im lokalen Browser als Argumente an ein Programm des entfernten Servers übergeben, das Programm dort ausgeführt und dessen Output an den lokalen Browser zur Darstellung zurückgegeben. Das Server-Programm kann die Formulareingaben für eine Datenbankabfrage verwenden und das Abfrageergebnis in HTML codiert an den Browser zur Anzeige senden (Search Engines, Börsenkurse). Server-Programme schreiben auch Formulareingaben von Online-Bestellungen in eine Datenbank des Produktanbieters, veranlassen eine bestätigende email an den Besteller sowie den Versand der bestellten Produkte. Grundsätzlich können auf dem entfernten Server beliebige Programme gestartet werden, die dort für den Zugriff per CGI vorgehalten werden. Für WWW-Interaktionen wie Gästebücher, Zugriffzähler, email-Versand etc. kursieren frei erhältliche CGI-Programme im WWW. CGI-Software mit speziellen Funktionen muß selbst programmiert oder gekauft werden. CGI-Programme können mit jeder auf dem Server lauffähigen Programmiersprache erstellt werden; häufig verwendete Sprachen sind PERL, C und C++.

Ab der HTML-Version 2 lassen sich mit dem Img-Src-Tag auch Image Maps in HTML-Dokumente einbetten. Eine Image Map ist eine sensitive Graphik, die in verschiedenen Bereichen des Bildes mit unterschiedlichen Aktionen (meist Links) hinterlegt ist. In einem als Image Map realisierten Stadtplan können per Mauszeiger einzelne Stadtteile angewählt werden, zu denen jeweils eine eigene Graphikdatei mit einer Ausschnittsvergrößerung angezeigt wird. Serverseitige Image Maps funktionieren strukturell wie CGI-Anwendungen: der Server liefert die Image Map an den Browser, die Koordinaten des Mauszeigers (Benutzer-Input) werden als Argumente an die Image-Map-Anwendung des Servers zurückgegeben, der Server veranlaßt die entsprechende Aktion im Browser (Server-Output). Bei Clientseitigen Image Maps liefert der Server zur sensitiven Graphik direkt auch die Aktionsanweisungen (plus evtl. zugehörige Darstellungselemente) zu den einzelnen Koordinatenbereichen der Graphik mit.

Plug-ins als Clientseitige Zusatzprogramme zum Browser dienen der Präsentation von in WWW-Seiten eingebetteten Multimedia-Elementen, deren Formate nicht mit Browsereigenen Funktionen handhabbar sind (Video, Audio, spezielle graphische Formate). Über die Anbieter von speziellen Multimedia-Elementen sind die notwendigen Plug-ins meist frei erhältlich. Bei der Installation tragen sich die Plug-ins selbst in eine Liste ein, die dem Browser signalisiert, welches Zusatzprogramm bei welchem Multimediaformat aufgerufen werden soll.

JavaScript wurde von Netscape als unmittelbare Ergänzung zu HTML entwickelt, wird jedoch als proprietäre Script-Sprache nicht vom HTML-Standard erfaßt. JavaScript-Code wird über den Script-Tag in HTML eingebunden, vom Server vollständig zum Browser übertragen und dort von einem speziellen Browserintegrierten JavaScript-Interpreter ausgeführt. JavaScript ist klar von der objektorientierten Programmiersprache Java zu unterscheiden. Java-Applets sind vorkompilierte Java-Programme, die mit dem Applet-Tag in HTML-Dokumente eingebunden werden. Beim Zugriff wird das Applet vom Server des Anbieters in den lokalen Browser übertragen und dort völlig eigenständig von einer Browserintegrierten Java Virtual Machine (z.B. HotJava von Sun, Netscape ab Ver. 2.0, MS Internet Explorer 3.0) ausgeführt.

Die Möglichkeiten, allein mit HTML die kommunikativen und wirtschaftlichen Potentiale des WWW auszuschöpfen, sind begrenzt. CGI, JavaScript und Java knüpfen an den Grenzen von HTML an und stellen erweiterte Möglichkeiten zur Dynamisierung von WWW-Inhalten, Interaktion und Animation bereit. Aufgrund ihrer Fähigkeiten, diese Erweiterungen und Hypermediafunktionalität zu integrieren, werden HTML-Umgebungen zukünftig verstärkt als Organisationszentren für WWW-Projekte fungieren, die auch öffentlich nicht zugängliche Netzbereiche von Unternehmen (Intranet) umfassen. Führende Workgroup-ComputingProdukte wie Lotus Notes oder Novell Intranetware verwenden bereits die HTML-Technik.

Artikelanfang Seitenanfang

Literatur

December, J.; Ginsburg, M.: HTML & CGI Unleashed – Professional Reference Edition, Macmillan Computer Publishing 1996
Nefzger, W.; Münz, S.: HTML-Referenz 3.2, 2., völlig neubearb. Aufl., Franzis-Verlag 1996
Ragget, D.; Lam, J.; Alexander, I.: HTML 3.2 – Neue Möglichkeiten für das Web-Publishing, Addison-Wesley 1996

Artikelanfang Seitenanfang

Autor & Copyright
Axel C. Schwicker
Johannes Gutenberg-Universität Mainz,
Fachbereich 03,
Saarstrasse 21,
D-55099 Mainz
acs@bong.bwl.unimainz.de

Artikelanfang Seitenanfang

Honeypots und Honeynets

Kurzinfo
Erläuterung
Bewertung
Literatur
Autor & Copyright

Kurzinfo Honeypots sind Server mit nur scheinbar wertvollen Daten wie Adressen und Dokumenten zur Täuschung von Angreifern [14].Mit ihnen soll von Systemen abgelenkt werden, die tatsächlich wertvolle Daten verarbeiten.

Erläuterung

Zusätzlich werden die Angriffe auf diese Honeypots beobachtet und analysiert, um neuartige Angriffe kennen zu lernen; dazu werden sie protokolliert und ggf. auch rückverfolgt. Angriffe auf Honeypots sind also erwünscht.

Unter einem Honeynet wird eine Menge vernetzter Honeypots mit denselben Aufgaben und Zielen verstanden. Der Vorteil eines Honeynets gegenüber einem Honeypot liegt in der Überwachungs-und Verwaltungsmöglichkeit der einzelnen Honeypots von einem anderen System aus. Damit lassen Honeynets auch die Beobachtung erfolgreich angegriffener Systeme zu, auf denen sich der Angreifer volle Administrationsrechte verschafft hat: Die schützende und überwachende Infrastruktur liegt nicht auf dem einzigen Honeypot selbst, sondern außerhalb der Zugriffsmöglichkeiten des Angreifers. Dies verursacht allerdings einen höheren Aufwand für Konzeption, Implementierung und Betrieb.

Honeypots und Honeynets wurden bisher überwiegend für Forschungszwecke eingesetzt. Der höhere Aufwand, die größere Komplexität und die Möglichkeit, Angriffsverfahren zu erkennen, scheinen den Einsatz von Honeynets in Unternehmen nicht zu rechtfertigen.

Neuere Untersuchungen [17] zeigen allerdings, dass ein längerfristiger Einsatz von Honeynets in Unternehmen auch Informationen liefern kann, die die Sicherheit des Unternehmensnetzwerks direkt – zumindest aber indirekt – verbessern können. Ein erkannter und beobachteter Angriff ermöglicht sofortige Reaktion und liefert daher einen direkten Nutzen. Die statistische Auswertung der Zugriffe auf das Honeynet kann indirekt genutzt werden, um andere Sicherheitsmechanismen anzupassen und liefert damit indirekten Nutzen. Ein Honeynet bietet zudem eine kontrollierte Testumgebung, in der neue Systeme vorab oder parallel zur Einführung betrieben und genau beobachtet werden können.

Derzeitige Angriffe sind wie folgt in mehreren Stufen aufgebaut [6]: Bevor überhaupt ein Angriff erfolgt, wird das Ziel aufgeklärt (Footprinting) und ermittelt, welche Netzsegmente und Maschinen zum Angriffsziel gehören sollen.

Dann folgt ein Scannen, um herauszufinden, über welche Ports Kommunikationsverbindungen aufgebaut werden können. Danach wird geprüft, welches Betriebssystem auf den Zielrechnern eingesetzt wird und ob – und gegebenenfalls sogar welche – Firewalls die Systeme schützen. In der letzten Stufe der Vorbereitung ermittelt der Angreifer die Versionen der für ihn sichtbaren Serverdienste (Bannergrabbing). Nachdem das Angriffsziel analysiert wurde, erfolgt der Angriff z.B. durch Ausnutzen bekannter Sicherheitslücken in einem der erkannten Dienste.

Honeypots

Honeypots sollen angegriffen werden, damit die Angriffe analysiert werden können; Honeypots übernehmen keine produktiven Aufgaben. Daraus resultiert, dass ein in einem Netzwerk platzierter Honeypot, im Vergleich zu produktiven Systemen (fast) keine berechtigten Zugriffe aufweist. Jeder Zugriff wird als verdächtig angesehen und untersucht.

Die vergleichsweise geringe Menge gespeicherter (scheinbarer) Nutzdaten erlaubt leichter eine vollständigere Protokollierung, weil die Zugriffe im Gegensatz zu produktiven Systemen nicht in der Masse der berechtigten Zugriffe untergehen.

Bei Verdacht auf einen Angriff wird vom Honeypot Alarm ausgelöst und eine gezielte Beobachtung des Angreifers und des Angriffsverfahrens vorgenommen – noch bevor der Angriff erfolgreich ist – mindestens aber während des Angriffs.

Eine Analyse neuer – durch einen Honeypot erkannter – Angriffe kann zur Erstellung von Regeln für ein Intrusion Detection oder Intrusion Protection System genutzt werden.

Auf Produktionssystemen müssten verdächtige Zugriffe dagegen aus der Vielzahl der berechtigten Zugriffe – z.B. mit Intrusion-Detection-Systemen – erst herausgefiltert werden. Intrusion-Detection-Systeme untersuchen die Datenströme im Netzwerk und vergleichen sie mit den Signaturen ihnen bekannter Angriffe. Wird eine Übereinstimmung festgestellt, generiert das System einen Alarm. Dieses Verfahren birgt einige konzeptbedingte Probleme wie die ausschließliche Erkennung nur bekannter Angriffsmuster und Fehlalarme bei Angriffsmustern ähnelnden berechtigten Zugriffen.

Klassifikation nach Zielen

Mit dem Einsatz von Honeypots können zwei Ziele verfolgt werden [15]: Produktiver Einsatz zum Schutz der IT oder Forschungszwecke wie Kennnenlernen von Angriffsmethoden, -werkzeugen und -taktiken.

Honeypots sollen für Angreifer möglichst interessant erscheinen (nur scheinbar wertvolle Nutzdaten: Täuschung) und den Angreifer vom Angriff auf tatsächlich wertvolle Daten verarbeitende Systeme ablenken.

Produktionshoneypots (Production Honeypots)

Produktionshoneypots melden (unberechtigte) Zugriffe. Die Zugriffe können entweder auf Fehler oder auf Angreifer zurückgeführt werden; jedenfalls werden diese Zugriffe als Angriffe behandelt und es wird ein Alarm ausgelöst. In der Folge des Alarms lassen sich die tatsächlichen Produktionssysteme gegen den geführten Angriff absichern.

Forschungshoneypots (Research Honeypots)

Forschungshoneypots sollen möglichst viel über Angriffsmethoden und die eingesetzten Werkzeuge in Erfahrung bringen. Die detaillierte Ausprägung dieser Systeme ist abhängig von den Zielen.

Sollen z.B. neue Würmer analysiert werden, werden entsprechende Sicherheitslücken offen gelassenen.

Nach einer Infektion des Systems kann der Wurm und seine Funktionsweise analysiert werden.

Eine weiteres im Forschungsbereich angesiedeltes Einsatzfeld ist die Trenderkennung: An verschiedenen Stellen im Internet platzierte Honeypots können Daten über die Zugriffsversuche auf verschiedene Ports liefern. Die Zugriffshäufigkeiten können Hinweise auf neue Angriffswerkzeuge liefern.

Die Ergebnisse werden unter Betreibern im Rahmen von Vereinigungen ausgetauscht [4, 16].

Klassifikation nach Interaktionsgrad

Honeypots können auch nach Interaktionsmöglichkeiten klassifiziert werden, die sie Angreifern bieten. Drei Klassen werden unterschieden [15].

Honeypots mit niedrigem Interaktionsgrad („low interaction")

Einfache Programme simulieren Dienste, ohne dass sie nutzbar oder überhaupt vorhanden sind. Ein simulierter Telnet-Dienst könnte z.B. einen Login-Prompt gefolgt von einem Passwort-Prompt anbieten – jedoch bei Anmeldeversuchen immer eine Fehlermeldung zurückliefern. Die Klasse der sicherstellen Honeypots mit geringem Interaktionsgrad eignet sich zur Angriffserkennung und Trenderkennung. Es können jedoch keine Informationen gesammelt werden, die über Verbindungsversuche und deren Häufigkeit hinausgehen.

Produktbeispiele für Honeypots mit niedrigem Interaktionsgrad sind Specter [12] und Honeyd [13]. Die von Specter angebotenen Dienste können über Checkboxen ausgewählt und aktiviert werden.

Dadurch kann ein Specter-Honeypot mit wenig Aufwand implementiert werden. Honeyd kann eher als ein Werkzeugkasten für Honeypots betrachtet werden. Dienste werden über Skripte simuliert, die bei Zugriff auf die konfigurierten Netzwerk-Ports durch den Honeyd gestartet werden. Diese Eigenschaft verursacht im Vergleich zu Specter etwas mehr Aufwand, erhöht jedoch auch die Flexibilität.

Honeypots mit mittlerem Interaktionsgrad („medium interaction")

Diese simulieren angebotene Dienste. Sie sind besonders für das Beobachten programmgesteuerter Angriffswerkzeuge nützlich, da diese im Gegensatz zu menschlichen Angreifern nur die einprogrammierten Eigenschaften der Dienste prüfen und dann eine Schadensfunktion ausführen.

Ein Beispiel für einen Honeypot mit mittlerem Interaktionsgrad ist ein System, dass eine bekannte Sicherheitslücke eines Webservers nachbildet; Würmer, die diese Lücke ausnutzen, sind zwar in der Lage, ihre Schadensroutine zu installieren, können sie aber nicht aktivieren. Das System kann einen Alarm auslösen, wenn eine bisher nicht bekannte Schadensroutine abgeliefert wird. Diese kann dann analysiert werden. Honeypots mittleren Interaktionsgrads müssen speziell auf ihren Einsatzzweck hin entwickelt werden.

Zur Implementierung von Honeypots mit mittlerem Interaktionsgrad kann auch Honeyd eingesetzt werden, da über entsprechend umfangreichere Skripte auch komplexere Dienste simuliert werden können.

Honeypots mit hohem Interaktionsgrad („high interaction")

Diese Honeypots stellen einem Angreifer den vollen Funktionsumfang eines Betriebssystems zur Verfügung. Meist handelt es sich um Standard-Betriebssysteminstallationen, die entsprechend modifiziert wurden: Auf UNIX-artigen Systemen wird häufig ein Keylogger installiert, der sämtliche Ein- und Ausgaben aller Terminals protokolliert. Darüber hinaus werden so viele Protokollinformationen wie möglich an entfernte Rechner verschickt; damit ist die Protokollinformation auch dann noch verfügbar, wenn ein Angreifer sie auf dem Zielrechner gelöscht hat – z.B. um seine Spuren zu verwischen. Es sollen möglichst viele Informationen protokolliert werden, ohne dass ein Angreifer davon etwas merkt oder sogar die protokollierten Informationen zerstören könnte.

Da Betriebssysteme mit vollwertigen Diensten eingesetzt werden, bieten diese Honeypots eine größere Angriffsfläche. Über bewusst offengelassene oder bisher unbekannte Sicherheitslücken in der Dienstesoftware oder der Konfiguration des Systems können Angreifer daher auf diesen Honeypots Zugriffsrechte oder sogar Administrationsrechte erlangen. Zwar ist einerseits eine genauere Beobachtung der Angriffe möglich, andererseits bietet ein vollständiges Betriebssystem dem Angreifer mehr Missbrauchsmöglichkeiten.

Auf nicht besonders geschützten Systemen könnte ein Angreifer mit Administrationsrechten die Überwachungsmechanismen erkennen, deaktivieren und damit den Nutzen des Honeypots einschränken. Ein Angreifer mit Administrationsrechten ist auf den meisten heute üblichen Betriebssystemen nur schwer kontrollierbar. Ausnahmen bilden gehärtete Systeme [8, 9, 10], die die Rechte der Prozesse und Benutzer durch Mandatory Access Control reduzieren können. SELinux [11] ist z.B. eine Erweiterung für Linuxsysteme, die Einschränkungen möglich macht.

Honeynets

Um auch bei nicht besonders abgesicherten Systemen Kontrolle und Schutz der Protokolldaten gewährleisten zu können, wurden Honeynets entwickelt. Durch die Honeynet-Infrastruktur können auch Systeme kontrolliert werden, auf denen ein Angreifer Administrationsrechte hat (Abb. 1).

Abb. 1 Honeynet-Konfiguration

Im Honeynet Project [15] werden drei Ziele definiert, die bei der Konzeption eines Honeynets berücksichtigt werden sollen.

Die Kontrolle (Data Control) stellt sicher, dass ein erfolgreicher Angreifer das Zielsystem nicht für weitere Angriffe nutzen kann.
Die Datenerfassung (Data Capture) soll eine möglichst vollständige Überwachung des Angreifers sicherstellen (Protokollierung). Kontrolle und Datenerfassung sollen von Angreifern nicht bemerkt werden.
Alle gesammelten Daten sollen archiviert (Data Collection) und an einer zentralen Stelle zur Auswertung bereit gestellt werden – z.B. um zukünftig Daten verschiedener Honeynets an dieser zentralen Stelle zu sammeln und die Ergebnisse (besser) korrelieren zu können. Die Entwicklung von Konzepten und Werkzeugen für eine zentrale (gemeinsame) Datenhaltung und -auswertung ist eins der noch offenen Forschungsprojekte des Honeynet Projects.

Honeypots mit hohem Interaktionsgrad und Honeynets lassen sich durch Virtualisierung auch auf einem einzigen Rechner implementieren. Dabei kommen virtuelle Maschinen wie VMware Workstation oder GSX-Server [19] oder User-Mode Linux [18] zum Einsatz. In den virtuellen Maschinen lassen sich Betriebssysteme als Prozess eines Hostsystems starten. Hardwarezugriffe der Gastsysteme werden entweder an die Hardware des Gastsystems weitergereicht oder durch Software emuliert. Eine Platte in einem User-Mode-Linux-System besteht beispielsweise aus einer Datei im Hostsystem. Auf dem Hostsystem können mehrere User-Mode-Linux-Instanzen gestartet werden und über virtuelle Hubs ein Netzwerk bilden.

Die Virtualisierung ermöglicht eine umfangreichere Protokollierung. Die Anpassung der in virtuellen Maschinen laufenden Betriebssysteme mit Keyloggern kann entfallen, da die virtuelle Maschine, anders als reale Hardware, die Zugriffe auf virtuelle Hardware protokollieren kann. Im CoVirt Projekt [2] wird eine auf User-Mode Linux basierende virtuelle Maschine, ein aus Performancegründen angepasstes Linux und ein Abspielservice entwickelt, mit denen sich Aktivitäten innerhalb der virtuellen Maschine so vollständig protokollieren lassen, dass sie zur Analyse Instruktion für Instruktion wieder abspielen können.

Die aktuelle Honeynet-Generation des Honeynet Projects erreicht die geforderten Ziele durch mehrere Komponenten. Die Kontrolle wird durch eine, dem Honeynet vorgeschaltete, Firewall realisiert, die als Bridge zum Internet fungiert. Bei Bedarf kann dieser Bridge-Firewall noch ein Router mit gleichem Regelwerk vorgeschaltet werden, um Redundanz zu erreichen. Die Firewall lässt alle eingehenden Verbindungen zu, um einen uneingeschränkten Zugriff auf die Zielsysteme zu erreichen.

Ausgehende Verbindungen sind besonders verdächtig, da sie auf einen erfolgreich angegriffenen Honeypot schließen lassen. Die Firewall ist so konfiguriert, dass sie jegliche ein- und ausgehende Verbindungen protokolliert. Alle ausgehenden Verbindungen lösen einen Alarm aus und werden darüber hinaus in ihrer Anzahl beschränkt, um eine Nutzung erfolgreich angegriffener Systeme für Massenscans oder Denial of Service-Attacken zu verhindern. Weiterhin wird der ausgehende Datenstrom durch Snort-Inline [7] gegen das Regelwerk des Snort Intrusion Detection Systems [1] geprüft: Damit können Pakete bekannter Attacken fallengelassen und in Zukunft auch modifiziert durchgelassen werden.

Die Datenerfassung wird durch einen im Honeynet platzierten Sniffer realisiert, der den Datenfluss im Honeynet vollständig erfasst und zu Auswertungszwecken speichert. Im Honeynet Project kommt das Intrusion-Detection-System Snort zum Einsatz. Der Snort-Sensor ist so konfiguriert, dass er neben den Alarmen auch ein vollständiges Binärlog und Sitzungen unverschlüsselter textbasierter Protokolle erstellt. Durch die Sitzungsprotokolle lassen sich beispielsweise eingegebene Befehle und resultierende Antworten von FTP- oder Telnetsitzungen überwachen.

Sniffer und Firewall können über ein separates Netzsegment mit einem Wartungssystem verbunden werden, das einen Zugriff auf die Infrastruktur über das Internet erlaubt. Mit Hilfe der Sitzungsprotokolle und auf den Zielsystemen installierten Keyloggern lassen sich die Aktivitäten eines Angreifers in Echtzeit beobachten.

Bewertung

Honeypots weisen (fast) keine berechtigten Zugriffe auf; personenbezogene Daten werden daher in Honeypot- oder Honeynet-Systemen im Rahmen der technischen Überwachung der Kommunikation nicht protokolliert, gespeichert und ausgewertet; erst recht nicht solche von Mitarbeitern. Vielmehr fallen nur Angriffsdaten an: Mit welchen Verfahren und auf welche Daten wurde wann und wie zugegriffen. Im Allgemeinen wird auch auf eine Rückverfolgung der Angreifer wegen des entstehenden Aufwands verzichtet; weniger aufwändig aber wirkungsvoller ist nämlich die Absicherung der eigenen Systeme gegen diese neuen Angriffe [vgl. 5].

Honeypots und Honeynets erfordern einen hohen Analyseaufwand der Protokolldaten. Es kann erwartet werden, dass diese Analyse zukünftig programmgesteuert vorgenommen wird und die Ergebnisse – ebenfalls programmgesteuert – unmittelbar in das Regelwerk von Sicherheitstools wie Firewalls, Intrusion Detection und Intrusion Protection Systemen eingespeist werden. Erste Ansätze dazu lassen sich bei einem System erkennen [3], das – als ein der Firewall vorgeschaltetes System – bei Anfragen auf nichtexistente Dienste mit „Ködern" antwortet. Werden diese „Köderinformationen" daraufhin benutzt, wird das Regelwerk der Firewall so angepasst, dass der Nutzer der „Köder" keinen Zugriff mehr auf die vorhandenen Dienste erlangen kann und es wird zusätzlich ein Alarm ausgelöst.

Artikelanfang Seitenanfang

Literatur

Caswell, B.; Roesch, M.: Snort. The open source network intrusion detection system. o. O. 2004 http://www.snort.org
Chen, P. M., Noble, B. et al.: CoVirt/ReVirt Ann Arbor 2004
http://www.eecs.umich.edu/CoVirt/
ForeScout (ed.): ActiveScout. San Mateo 2004
http://www.forescout.com
La Bella, R.: Florida Honeynet Project. o. O. 2004
http://www.floridahoneynet.org
Landesbeauftragter für den Datenschutz Niedersachen: Protokollierung.
Orientierungshilfe und Checkliste. Hannover 2000
http://www.lfd.niedersachsen.de/ master/0,,C27924_N13192_L20_D0_I560,00.html
McClure, S.; Scambray, J.; Kurz, G.:Hacking exposed. Berkeley 2003
N. N. (ed.): Project: snort_inline. o. O. 2004
http://sourceforge.net/projects/snort-inline
Microsoft Corp. (ed.):Microsoft Windows 2000 Security Hardening Guide. Redmond/WA 2003 http://www.microsoft.com/technet/treeview/ default.asp?url=/technet/security/prodtech/windows/win2khg.asp
National Security Agency (NSA) (ed.): Guide to Securing Microsoft Windows XP. Fort Meade 2002
http://www.nsa.gov/snac/os/winxp/winxp.pdf http://www.nsa.gov/snac/os/winxp/winxp.pdf
National Security Agency (NSA) (ed.): Security Recommendation Guides. Fort Meade 2003a
http://www.nsa.gov/snac/
National Security Agency (NSA) (ed.): SELinux. Fort Meade 2003b
http://www.nsa.gov/selinux
NETSEC, Network Security Software (ed.): Specter. Bern 2003
http://www.specter.com/default50.htm
Provos, N. et al.: Honeyd. Ann Arbor 2004 http://www.honeyd.org
Shirey, R.: Internet Security Glossary. Request for Comments 2828 informal. 2000
Spitzner, L.: Honeypots, Tracking Hackers. Boston 2003
Spitzner, L. et al.:The Honeynet Project. o. O. 2003
http://www.honeynet.org
Stevens, R.: Kosten-,Nutzen- und Risikoanalyse für den Einsatz von Honeynets in einer Unternehmensumgebung am Beispiel des Einsatzes bei einem Internet Service Provider. Diplomarbeit Sankt Augustin 2003
User-Mode Linux Projekt (ed.):User-Mode Linux Kernel. o. O. 2004
http://user-mode-linux.sourceforge.net
vmware Inc. (ed.):VMware Workstation/GSX Server. Palo Alto 2004

Hinweis: Die URLs entsprechen dem Stand bei der Veröffentlichung des Artikels und werden nicht aktualisiert.

Artikelanfang Seitenanfang

Autor & Copyright
R. Stevens
Accenture GmbH,
Post & Public Services,
Düsseldorf
mail@RichardStevens.de

Prof. Dr. H. Pohl
Fachbereich Informatik,
Fachhochschule Bonn-Rhein-Sieg,
ISIS InStitut für InformationsSicherheit,
Max-Pechstein-Str. 4,
50858 Köln
Hartmut. Pohl@sang.net

Artikelanfang Seitenanfang