Schutz eines Rechenzentrums gegen externe Angriffe durch den Einsatz virtueller IDS-Sensoren und Honeypots

Schutz eines Rechenzentrums gegen externe Angriffe durch den Einsatz virtueller IDS-Sensoren und Honeypots Diplomarbeit im Studiengang Informatik angefertigt am Lehr- und Forschungsgebiet Informatik 4 der RWTH Aachen in Kooperation mit LeanoMedia Informationslogistik GmbH, Köln von Tobias Hülsdau Matrikelnummer 214 371 Aachen, im März 2006 Betreuer: Prof. Dr.-Ing. Felix Freiling Zweitgutachter: Prof. Dr. Bischof Externe Betreuung: Dipl.-Ing. Claus Wickinghoff

Hiermit versichere ich, daß ich die Arbeit selbständig verfaßt und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt, sowie Zitate kenntlich gemacht habe. Aachen, 01.03.2006 (Tobias Hülsdau) 1

Inhaltsverzeichnis 1 Einführung 4 1.1 Problemstellung und Ziel der Arbeit............... 4 1.2 Virtualisierung.......................... 5 1.3 IDS................................. 7 1.4 Honeypots............................. 7 2 Auswahl einer Virtualisierungslösung 8 2.1 Einführung und Anforderungen................. 8 2.2 Linux-VServer........................... 10 2.3 User-Mode Linux......................... 12 2.4 XEN................................ 14 2.5 Auswahl einer Lösung: XEN................... 17 3 Konzeption und Analyse 19 3.1 Einleitung............................. 19 3.2 Anforderungen.......................... 19 2

3.3 Konzept zur Verbesserung der Sicherheit............ 20 3.4 Analyse eines Einbruchs..................... 23 3.5 Zwischenbewertung des Konzeptes................ 28 3.6 Modifikation des Konzeptes................... 30 3.7 Fazit................................ 31 4 Implementierung 33 4.1 Einleitung............................. 33 4.2 Samhain.............................. 36 4.3 auditables............................. 40 4.4 auditwrapper........................... 42 4.5 auditdb.............................. 46 4.6 auditfyd.............................. 48 5 Evaluierung 55 5.1 Einleitung............................. 55 5.2 Ausführung eines simulierten Angriffs.............. 55 5.3 Auswertung............................ 58 5.4 Fazit................................ 61 6 Ausblick 63 7 Zusammenfassung 65 A Konfigurationsdateien von Samhain 69 B Sourcecode 72 3

Kapitel 1 Einführung 1.1 Problemstellung und Ziel der Arbeit Ein Internet-Provider betreibt mehrere Server in einem Rechenzentrum. Darunter befinden sich sowohl Server für die eigene Infrastruktur (Firewall, Mailserver), komplett an Kunden vermietete Server sowie Server auf denen Domains und Webseiten verschiedener Kunden gemeinsam gehostet werden. Besonders letztere bereiten zunehmend Sicherheitsprobleme, da die Kunden mitunter fehlerhafte dynamische Webseiten online stellen. Ein erfolgreicher Angriff über eine bekannte Forensoftware hatte bereits mehrere Stunden Dienstausfall zur Folge und verursachte einen erheblichen Aufwand an Arbeitszeit. Eine ständige Überwachung aller von Kunden installierten dynamischen Webseiten ist nicht mit vertretbarem Aufwand durchführbar. Daher soll ein Konzept entwickelt und implementiert werden, dass bei zukünftigen Angriffen eine Minimierung von Reaktionszeit und Schadenswirkung bietet. Dies soll in Teilen durch die Virtualisierung von Servern erreicht werden. Der Einsatz von dedizierten Intrusion Detection Systemen und Honeypots auf virtuellen Servern erscheint als geeigneter Ansatz. Die gesamte Entwicklung soll unter Debian GNU/Linux erfolgen. 4

Ziel der Arbeit ist die Auswahl einer Virtualisierungslösung sowie die Erstellung und Implementierung eines Konzeptes zur Verbesserung der Sicherheit. Es wird aus drei Kandidaten eine Virtualisierungslösung ausgewählt, um auf einem physikalischen Server mehrere Gastsysteme parallel betreiben zu können. Ein im Verlauf dieser Arbeit erfolgter weiterer Angriff wird analysiert und mit den gewonnen Erkenntnissen eine Überarbeitung des Konzepts vorgenommen. Dieses wird implementiert und anschliessend mit einem simulierten Angriff, der sich an den erfolgten echten Einbruch anlehnt, geprüft. 1.2 Virtualisierung In [Sin04] definiert Amit Singh Virtualisierung wie folgt: Virtualization is a framework or methodology of dividing the resources of a computer into multiple execution environments, by applying one or more concepts or technologies such as hardware and software partitioning, timesharing, partial or complete machine simulation, emulation, quality of service, and many others. Obwohl, oder gerade weil, diese Definition sehr lose ist, was der Autor in seiner Veröffentlichung selber anmerkt, verdeutlicht sie das Verständnis des Begriffs im Rahmen der Arbeit. Im Rahmen der Arbeit ist Virtualisierung das Mittel zum Zweck, um einen physikalischen Computer bzw. Server in mehrere getrennte Einheiten zu unterteilen, so dass diese wiederum wie ein eigenständiger Computer behandelt werden können. Konkret sollen auf einem Server mehrere Betriebssysteminstanzen parallel laufen. Im folgenden werden die Begriffe Hostsystem und Gastsystem benutzt. Der Begriff Hostsystem bezeichnet einen Computer mit darauf laufender Virtualisierungslösung. Der Begriff Gastsystem bezeichnet ein Betriebssystem bzw. 5

im konkreten Fall eine Linux Distribution, die parallel mit anderen Gastsystemen auf einem Hostsystem läuft. Es gibt verschiedene Techniken zur Virtualisierung von Computern. Mittels Software kann eine andere Architektur inklusive Prozessorbefehlssatz als die des Hostsystems emuliert werden. Dieser Ansatz ist allerdings nicht sehr performant. Durch das Abfangen und Umschreiben priviligierter Instruktionen kann mehreren parallel laufenden Betriebssystemen vorgetäuscht werden, sie würden auf nativer Hardware laufen. Dabei werden meistens andere als die wirklich vorhandenen Geräte wie Festplattencontroller oder Netzwerkkarte emuliert. Dieser Ansatz ist auf Architekturen, die keine besondere Unterstützung bieten, sehr aufwendig (siehe[law99]). Bei der Paravirtualisierung bildet ein spezieller Kernel (Hypervisor oder Virtual Machine Monitor) die unterste Schicht. Alle darauf laufenden Gastsysteme müssen an den Hypervisor angepasst werden und wissen von dessen Existenz. Dieser Ansatz erfordert die Portierung der Gastsysteme auf die Architektur des Hypervisors. Bei der Partitionierung stellt der Kernel auf dem Hostsystem die Möglichkeit bereit, Prozesse in Kontexten ablaufen zu lassen. Prozesse aus einem Kontext können mit Prozessen aus einem anderen Kontext nicht ungewollt interagieren. Damit einher geht eine Einschränkung des Zugriffs der Prozesse auf Ressourcen wie Festplatte oder Netzwerk, so dass einem Kontext gezielt Teile der Ressourcen zur Verfügung gestellt werden können. Unter diesem Ansatz ist es nicht möglich, verschiedenartige Gastsysteme parallel laufen zu lassen. 6

1.3 IDS Der Begriff IDS steht in dieser Arbeit für Intrusion Detection System. In [Cou03] wird der Begriff wie folgt definiert: Software/hardware that detects and logs inappropriate, incorrect, or anomalous activity. IDS are typically characterized based on the source of the data they monitor: host or network. A host-based IDS uses system log files and other electronic audit data to identify suspicious activity. A network-based IDS uses a sensor to monitor packets on the network to which it is attached. Ein bekanntes Network-Based IDS ist snort. Es überwacht den Netzwerkverkehr an zentraler Stelle und prüft alle Pakete gegen seine Signaturdatenbank. Ein Beispiel für ein Host-Based IDS ist tripwire, dass in periodischen Abständen alle Dateien auf einem Computer auf Veränderungen hin überprüft. 1.4 Honeypots Ein Honeypot ist ein System, Computer oder Netzwerk, ohne produktiven Wert, dessen einzige Aufgabe darin besteht, unauthorisierte Zugriffe auf sich zu ziehen, indem es sich für einen potentiellen Angreifer als wertvoll darstellt. Honeypots werden eingesetzt, um durch gezielte Beobachtung Angriffsmuster verstehen zu lernen ([Hol06]), um einen Einbruch in ein Netzwerk zu erkennen oder um Angreifer zu bremsen oder entmutigen ([Pro04], [Spi03]). Ein Problem mit der Benutzung von Honeypots zum Erkennen von Einbrüchen ist, dass der Angreifer auch gezielt den Honeypot angreifen muss. 7

Kapitel 2 Auswahl einer Virtualisierungslösung 2.1 Einführung und Anforderungen Die Evaluierung und Auswahl einer Virtualisierungslösung ist ein zentraler Bestandteil dieser Arbeit. Dies ist durch mehrere Anforderungen begründet: Dienste wie Web- und Mailserver, die bislang zusammen auf einem Server liefen, sollten aus Sicherheitsgründen voneinander separiert werden. Die Webauftritte verschiedener Kunden sollten voneinander getrennt werden, um die Schadenswirkung bei Einbrüchen durch Fehler (z.b. Webanwendungen) zu begrenzen. Da die Server in einem kommerziellen Rechenzentrum untergebracht sind, sollte die Separierung der Dienste und Webauftritte nicht mit einer Vergrösserung des Hardwareaufwandes einhergehen, um die Anmietung zusätzlicher Höheneinheiten zu vermeiden. 8

Die Möglichkeit, virtuelle Server unkompliziert von einem physikalischen Server auf einen anderen zu migrieren erscheint sinnvoll, um flexibel auf erhöhte Ressourcennachfrage reagieren zu können und die Ausfallzeit bei Hardwaredefekten zu minimieren. Zusätzliche virtuelle Server können bei Bedarf remote eingerichtet werden, ohne dass ein Einsatz vor Ort notwendig ist. Besonders der zweite Punkt ist hervorzuheben und wäre für sich alleine schon Grund genug eine Virtualisierungslösung einzusetzen. Für die Auswahl der Virtualisierungslösung gab es folgende grundsätzliche Vorgaben: Sie muss unter und mit Linux lauffähig sein. Sie soll unter einer Open Source Lizenz stehen, um nicht an einen Hersteller gebunden zu sein, sie bei Bedarf selber anpassen zu können und um sie ohne den Einsatz finanzieller Mittel ausführlich testen zu können. Es werden drei Virtualisierungslösungen, die die genannten Vorgaben erfüllen, in die engere Wahl genommen: Linux-VServer, User-Mode-Linux (UML) und XEN. Aus den drei Lösungen soll diejenige ausgewählt werden, die die folgenden Anforderungen am besten erfüllt: Hohe Geschwindigkeit: Die Virtualisierungslösung darf für den Benutzer der Dienste keinem merkbaren Geschwindigkeitsverlust erkennen lassen im Vergleich zu einem nicht virtualisierten System. Vollständige Netzwerkunterstützung: Die Gastsysteme sollen die Möglichkeit haben, auch spezielle Netzwerkfunktionen wie Raw Sockets und Firewalling nutzen zu können. 9

Stabilität im Produktivbetrieb: Die Gastsysteme müssen stabil laufen, um die Anforderungen der Kunden an hohe Dienstverfügbarkeit zu erfüllen. 2.2 Linux-VServer Beim Linux-VServer Projekt ([Pöt04]) handelt es sich um Erweiterungen des Standard Linux Kernels, deren Ziel es ist, Ressourcen zu partitionieren, um verschiedene Prozesse möglichst effizient aber komplett isoliert voneinander parallel laufen zu lassen. Dies wird mit der Bereitstellung von so genannten Kontexten erreicht. Prozesse die in einem Kontext ausgeführt werden, haben nur Zugriff auf die diesem Kontext zugeteilten Ressourcen, wie z.b. Teilbereiche des Dateisystems oder IP-Adressen, dürfen aber nicht ungewollt mit Prozessen in anderen Kontexten interagieren. Das Konzept lässt sich am einfachsten mit einem stark erweiterten chroot() Systemcall vergleichen. Im Gegensatz zu anderen Virtualisierungslösungen wird für eine virtuelle Instanz bzw. einen Kontext kein eigener Kernel gestartet. Da alle Prozesse in allen Kontexten unter demselben Kernel laufen, müssen alle Systemaufrufe, die den Zugriff auf Ressourcen ermöglichen, entsprechend erweitert werden, um die Existenz von Kontexten zu beachten. Diese Erweiterungen sind mittlerweile so weit fortgeschritten, dass es möglich ist, in einem Kontext eine eigene komplette Linux-Distribution zu booten. Damit können auf einem physikalischem System mehrere eigenständige virtuelle Server bereit gestellt werden. Die Vorgehensweise von Linux-VServer hat zwei grosse Vorteile: Hohe Geschwindigkeit: Da es keine zusätzliche Abstraktionsschicht gibt und auch keine virtuelle Hardware emuliert wird, laufen Prozesse unter Linux-VServer mit derselben Geschwindigkeit wie unter einem unmodifizierten Linux-Kernel. 10

Prozess Prozess Prozess Prozess Prozess Prozess Kontext 1 Prozess Kontext 2 Linux VServer Kernel Hardware Abbildung 2.1: Linux VServer Schema Gute Ressourcenausnutzung: Jeder Kontext verbraucht nur genau soviel Hauptspeicher, wie die in ihm laufenden Prozesse benötigen. Von mehreren Kontexten genutzte Shared Libraries müssen nur einmal geladen werden. Alle Kontexte teilen sich ein Dateisystem und können sogar statische Dateien wie Programme und Bibliotheken gemeinsam nutzen. Es gibt nur einen globalen Disk Cache. Es gibt jedoch mehrere Nachteile: Linux-VServer ist nicht in den Standard Linux-Kernel integriert, es muss ein speziell gepatchter Kernel verwendet werden. Dies erhöht die Zeitspanne, bis sicherheitskritische Fehler behoben werden und neue Hardwaretreiber oder Features genutzt werden können. Die Erweiterung aller Systemaufrufe um die Beachtung von Kontexten 11

ist sehr aufwendig und dementsprechend potentiell fehleranfällig. Ein Bug im Kernel betrifft direkt alle virtuellen Server. Einige spezielle Netzwerkfunktionen sind innerhalb von Kontexten nicht verfügbar, z.b. Routing oder Firewalling. Programme wie traceroute funktionieren nicht, da keine Raw-Sockets zur Verfügung stehen. 2.3 User-Mode Linux User-Mode Linux (UML) ([Dik00]) ist eine Portierung des Linux Kernels auf sein eigenes Systemcall-Interface. Ein UML Kernel läuft als normaler User-Space Prozess unter einem Linux Host Kernel. Alle Prozesse, die unter dem UML Kernel gestartet werden, laufen ebenfalls direkt unter dem Host Kernel. Der UML Kernel fängt alle ihre Systemcalls ab und bedient diese. Um seinerseits Zugriff auf die Ressourcen des Host Systems zu bekommen, bedient sich der UML Kernel wiederum normaler Systemcalls. Das Konzept, alle Prozesse als Host Prozesse laufen zu lassen, hat allerdings den Nachteil, dass der UML Kernel aus technischen Gründen in ihrem Adressraum vorhanden sein muss. Dies stellt ein grosses Sicherheitsproblem dar und ist im Allgemeinen nicht erwünscht. Die Erweiterung,,skas mode (Separate Kernel Address Space) für den Host Kernel eliminiert das Problem, indem alle Prozesse unterhalb des UML Kernels in nur einem einzigen Thread laufen, aber trotzdem einen eigenen Adressraum besitzen, der jeweils umgeschaltet wird. Als zusätzlichen Vorteil bietet der skas mode einen Geschwindigkeitsvorteil gegenüber dem alten Modell. Als Dateisystem dient dem UML Kernel eine Datei auf dem Hostsystem, die mit einem Dateisystem formatiert ist und als Blockdevice angesprochen wird. Um bei mehreren parallel laufenden UML Systemen Speicherplatz zu sparen, beherrscht der Blockdevice-Treiber im UML Kernel Copy-on-write 12

postfix postfix apache UML Kernel apache Linux Kernel Abbildung 2.2: UML Schema alle Instanzen teilen sich ein gemeinsames, schreibgeschütztes Image und schreiben nur lokale Änderungen in eine eigene Datei. UML hat mehrere Vorteile: Die vom UML Kernel benötigten Funktionen sind im Standard Linux Kernel integriert. Jedes aktuelle Linux System kann ohne weitere Modifikationen als UML Hostsystem fungieren. Die UML Architektur ist in den Standard Kernel integriert. Vollständige Netzwerkfunktionalität: Die Gastsysteme verfügen über vollständige Netzwerkfunktionalität wie Raw-Sockets und Firewalling. 13

Der Hauptnachteil von UML ist die deutlich geringere Performance bei I/O intensiven Programmen im Vergleich zu einem nativen Linux System. 2.4 XEN Der Virtual Machine Monitor, oder auch Hypervisor, XEN ([BDF + 03]) benutzt Paravirtualization um mehrere Gastsysteme parallel auf x86 Hardware laufen zu lassen. Paravirtualization heisst, dass den Gastsystemen keine native Hardware vorgetäuscht wird, sondern sie auf eine spezielle XEN- Architektur portiert werden müssen. Wichtig bei der Entwicklung von XEN war, dass das ABI (Application Binary Interface) stabil bleibt, Programme also weiterhin unmodifiziert auf den Gastsystemen laufen. Um eine Isolierung der einzelnen Gastsysteme voneinander zu gewährleisten, läuft der XEN Kernel mit höheren Privilegien als die Gastsysteme. Auf der x86 Architektur befinden sich normalerweise das Betriebssystem im privilegierten Ring 0 und alle Programme in Ring 3. Unter XEN laufen der XEN- Kernel in Ring 0, die Gastsysteme in Ring 1 und die Programe wie gewohnt in Ring 3. XEN ist eines der wenigen Systeme, welches überhaupt Gebrauch von Ring 1 macht. Für die Ansteuerung von I/O Geräten wie Festplatten und Netzwerkadaptern bedient sich XEN der Hilfe eines seiner Gastsysteme. Das erste Gastsystem welches von XEN beim Booten gestartet wird, wird als Domain0 (Dom0) bezeichnet und bekommt spezielle Rechte. Das Domain0 System darf auf die Hardware zugreifen und muss dafür die entsprechenden Gerätetreiber mitbringen. Allen weiteren Gastsystemen, die als DomainU (Unpriviliged, DomU) bezeichnet werden, stellt es über Backend-Treiber Blockdevices und Netzwerkschnittstellen zur Verfügung. Die DomU Systeme benötigen nur spezielle Frontend-Treiber, welche von der physikalischen Hardware unabhängig sind. Des Weiteren wird Dom0 zur Verwaltung der Gastsysteme benutzt. Diese Vorgehensweise ermöglicht es dem XEN Kernel leichtgewichtig zu bleiben 14

BLK Dom0 VIF DomU DomU eth0 hda eth0 hda eth0 hda XEN Kernel NET HDD Hardware CPU RAM Abbildung 2.3: XEN Schema und gleichzeitig auf jeder Hardware lauffähig zu sein, die durch den Dom0 Kernel unterstützt wird. Als Dom0 Kernel kommt Linux zum Einsatz, als DomU Kernel sind bisher Linux, FreeBSD, NetBSD und Plan9 auf die XEN Architektur portiert worden. In der aktuellen Version 3.0 unterstützt XEN die CPU Erweiterungen Intel VT-x. Damit ist es möglich, auch nicht auf die XEN Architektur portierte Betriebssystemkerne als DomU laufen zu lassen. Von dieser Möglichkeit wird im Rahmen der Diplomarbeit wegen fehlender spezieller Hardware allerdings kein Gebrauch gemacht. Der von XEN benutzte Ansatz bietet mehrere Vorteile: Hohe Geschwindigkeit: Gegenüber einem nativen Linux System be- 15

trägt der Geschwindigkeitsverlust von Linux unter XEN etwa 2 bis 8% ([BDF + 03]). Verglichen mit Linux-VServer ist XEN also weniger performant, aber immer noch deutlich schneller als andere Lösungen wie UML oder VMWare. Sicherheit: Die Gastsysteme unter XEN sind komplett voneinander isoliert. Selbst bei einem Fehler im Kernel eines Gastsystems kann ein Angreifer nicht die restlichen Systeme kompromittieren (gilt natürlich nicht, wenn auf den anderen Gastsystemen derselbe Angriffsvektor angewandt werden kann). Da XEN selber leichtgewichtig ist und auf eigene Hardwaretreiber verzichtet, ist die Wahrscheinlichkeit eines sicherheitsrelevanten Fehlers im XEN Kernel geringer als bei einem kompletten Betriebssystem. Vollständige Netzwerkfunktionalität: Die Gastsysteme verfügen über vollständige Netzwerkfunktionalität wie Raw-Sockets und Firewalling. Wenn die auf einem XEN System laufenden DomU Systeme über eine virtuelle Bridge (Linux als Dom0 bietet dies Funktionalität mit einem Bridge-Device) mit der Netzwerkkarte verbunden sind, lässt sich hinsichtlich der Handhabung kaum ein Unterschied zwischen einem DomU und einem Betriebssystem auf dedizierter Hardware feststellen. Als grosser Nachteil von XEN ist die im Vergleich mit Linux-VServer schlechtere Ausnutzung des Hauptspeichers zu nennen. Jedes Gastsystem bekommt beim Start eine festgelegte Menge RAM zugewiesen, so dass freier Speicher in einem Gastsystem nicht automatisch von einem anderen genutzt werden kann. Ausserdem führen alle Gastsysteme ihren eigenen Disk-Cache und können auch keine Shared-Libraries gemeinsam nutzen. 16

2.5 Auswahl einer Lösung: XEN Die Auswahl einer Virtualisierungslösung bildet die Grundlage für das weitere vorgehen im Rahmen der Arbeit. Die drei Lösungen, Linux-VServer, UML und XEN werden anhand der in Abschnitt 2.1 formulierten Anforderungen miteinander verglichen. Da Linux-VServer keine Abstraktionsschicht besitzt, ist die Geschwindigkeit vergleichbar mit der eines Standard Linux Kernels. In [BDF + 03] wurde die relative Geschwindigkeit von Linux, XEN, VMware und UML in verschiedenen Benchmarks verglichen (s. Abb. 2.4). Es zeigt sich, dass XEN nur rund 2 bis 8% langsamer ist als ein Standard Linux Kernel. Die Geschwindigkeit von UML bricht hingegen besonders bei I/O intensiven Programmen stark ein. Da die Ergebnisse der vorliegenden Benchmarks in [CDD + 04] bestätigt wurden, wurde auf eigene Performance Tests verzichtet. 1.1 1.0 567 567 554 550 263 271 172 158 1714 1633 418 400 518 514 0.9 Relative score to Linux 0.8 0.7 0.6 0.5 0.4 0.3 334 535 80 65 310 111 150 172 0.2 0.1 199 306 0.0 L X V U L X V U L X V U L X V U L X V U L X V U SPEC INT2000 (score) Linux build time (s) OSDB-IR (tup/s) OSDB-OLTP (tup/s) dbench (score) SPEC WEB99 (score) Figure 3: Relative performance of native Linux (L), XenoLinux (X), VMware workstation 3.2 (V) and User-Mode Linux (U). Abbildung 2.4: Performance von Linux (L), XEN (X), VMware workstation memory management. In the case of the VMMs, this system time is expanded to a greater or lesser degree: whereas Xen incurs a mere 3% overhead, the other VMMs experience a more significant slowdown. Two experiments were performed using the PostgreSQL 7.1.3 database, exercised by the Open Source Database Benchmark suite (OSDB) in its default configuration. We present results for the multi-user Information Retrieval (IR) and On-Line Transaction Processing (OLTP) workloads, both measured in tuples per second. A small modification to the suite s test harness was required to produce correct results, due to a UML bug which loses virtual-timer interrupts under high load. The benchmark drives the database via PostgreSQL s native API (callable SQL) over a Unix domain socket. PostgreSQL places considerable load on the operating system, and this is reflected in the substantial virtualization overheads experienced by VMware and UML. In particular, the OLTP benchmark requires many synchronous disk operations, resulting in many protection domain transitions. The dbench program is a file system benchmark derived from the industry-standard NetBench. It emulates the load placed on a file server by Windows 95 clients. Here, we examine the throughput experienced by a single client performing around 90,000 file system operations. SPEC WEB99 is a complex application-level benchmark for evaluating web servers and the systems that host them. The workload is a complex mix of page requests: 30% require dynamic content generation, 16% are HTTP POST operations and 0.5% execute a CGI script. As the server runs it generates access and POST logs, so the disk workload is not solely read-only. Measurements therefore reflect general OS performance, including file system and network, in addition to the web server itself. A number of client machines are used to generate load for the server under test, with each machine simulating a collection of users concurrently accessing the web site. The benchmark is run must receive an aggregate bandwidth in excess of 320Kb/s over a series of requests. A warm-up phase is allowed in which the number of simultaneous clients is slowly increased, allowing servers to preload their buffer caches. For our experimental setup we used the Apache HTTP server version 1.3.27, installing the modspecweb99 plug-in to perform most but not all of the dynamic content generation SPEC rules require 0.5% of requests to use full CGI, forking a separate process. Better absolute performance numbers can be achieved with the assistance of TUX, the Linux in-kernel static content web server, but we chose not to use this as we felt it was less likely to be representative of our real-world target applications. Furthermore, although Xen s performance improves when using TUX, VMware suffers badly due to the increased proportion of time spent emulating ring 0 while executing the guest OS kernel. SPEC WEB99 exercises the whole system. During the measurement period there is up to 180Mb/s of TCP network traffic and considerable disk read-write activity on a 2GB dataset. The benchmark is CPU-bound, and a significant proportion of the time is spent within the guest OS kernel, performing network stack processing, file system operations, and scheduling between the many httpd processes that Apache needs to handle the offered load. XenoLinux fares well, achieving within 1% of native Linux performance. VMware and UML both struggle, supporting less than a third of the number of clients of the native Linux system. 3.2(V) und UML (U) im relativen Vergleich (Quelle: [BDF + 03]) XEN und UML verfügen jeweils über RAW-Sockets und Firewalling. Sie erfüllen die Anforderung an vollständige Netzwerkunterstützung. In einem Gastsystem unter Linux-VServer können weder RAW-Sockets geöffnet werden, noch Firewalling benutzt werden. Linux-VServer erfüllt die Anforderung 17 4.2 Operating System Benchmarks To more precisely measure the areas of overhead within Xen and the other VMMs, we performed a number of smaller experiments targeting particular subsystems. We examined the overhead of virtualization as measured by McVoy s lmbench program [29]. We used version 3.0-a3 as this addresses many of the issues regarding the fidelity of the tool raised by Seltzer s hbench [6]. The OS performance subset of the lmbench suite consist of 37 microbench-

an eine vollständige Netzwerkunterstützung nicht. Damit ist es nicht möglich, in einem Gastsystem unter Linux-VServer ein IDS oder den honeyd laufen zu lassen. XEN erfüllt als einziges der drei betrachteten Lösungen die Anforderungen nach hoher Geschwindigkeit und vollständiger Netzwerkunterstützung. UML hat Probleme mit der Geschwindigkeit. Linux-VServer bietet keine vollständige Netzwerkunterstützung. XEN wird als Virtualisierungslösung für das weitere Vorgehen im Rahmen dieser Arbeit ausgewählt. 18

Kapitel 3 Konzeption und Analyse 3.1 Einleitung In diesem Kapitel wird ein Konzept zur Verbesserung der Sicherheit entwickelt und vorgestellt. Ein nach Erstellung des Konzeptes verübter Einbruch in einen der Server wird analysiert. Aufgrund der Analyse wird das Konzept einer Zwischenbewertung unterzogen und modifiziert. 3.2 Anforderungen An das Konzept zur Verbesserung der Sicherheit werden nachfolgende Anforderungen gestellt: Schnelle Erkennung von Einbrüchen: Da auf den Gastsystemen Webseiten von Kunden gehostet werden, die oftmals ihre eigenen Webapplikationen wie Shopsysteme oder Bulletinboards einrichten, sind Schwachstellen nicht dauerhaft zu unterbinden. Ein Einbruch kann jederzeit passieren. Umso wichtiger ist eine schnelle Erkennung, um Ausfallzeiten und Kosten so gering wie möglich zu halten. 19

Alarmierung des Administrators: Der Administrator muss benachrichtigt werden, sobald ein Einbruch vermutet wird. Das System soll nicht autonom Angriffe abwehren, da so die Gefahr besteht, dass es legitimen Datenverkehr in falscher Annahme unterbindet. Dies wäre kontraproduktiv, da der Zweck der Massnahmen eine Verbesserung der Verfügbarkeit ist. Minimierung von false positives: Wenn ein Mensch mit zu vielen Warnmeldungen konfrontiert wird, die zu einem sehr hohen Prozentsatz falsche Alarme sind, wird er sie irgendwann ignorieren. Deswegen sollen Warnmeldungen nur abgesetzt werden, wenn die Wahrscheinlichkeit für einen Angriff sehr hoch ist. Loggen von verdächtigen Ereignissen: Es sollen möglichst viele Ereignisse möglichst genau protokolliert werden, um den Verlauf eines Angriffs im Nachhinein besser analysieren zu können und um die Schwachstelle schneller lokalisieren zu können. Eindämmung der Schadenswirkung: Die potentielle Schadenswirkung durch einen Einbruch soll minimiert werden und möglichst auf den kompromittierten Dienst bzw. die Webanwendung beschränkt bleiben. Geringer Ressourcenverbrauch: Das System soll die vorhandenen Ressourcen möglichst wenig belasten, um den Kunden eine weiterhin hohe Dienstqualität bieten zu können. 3.3 Konzept zur Verbesserung der Sicherheit Das Konzept zur Verbesserung der Sicherheit stützt sich auf drei Ansätze, die im Zusammenspiel die vorgegebenen Anforderungen erfüllen: Virtualisierung der Server mit XEN und Einsatz jeweils eines Honeypots und eines IDS auf jedem Hostsystem (s. Abb. 3.1). 20

Gastsystem 1 Gastsystem 4 Gastsystem 2 IDS Gastsystem 3 Honeypot Hostsystem Abbildung 3.1: Konzept zur Verbesserung der Sicherheit Die Virtualisierung der Server mit XEN dient der Eindämmung der Schadenswirkung bei einem erfolgreichen Angriff. Bislang auf einem Server zusammen gehostete Dienste sowie Webseiten verschiedener Kunden werden auf mehrere Gastsysteme aufgeteilt. Ein kompromittiertes Gastsystem kann offline genommen und durch ein Backup ersetzt werden, ohne dass die Konnektivität der anderen Dienste und Kunden beeinträchtigt wird. Es kann außerdem zur genaueren Analyse gesichert und in einer sicheren Umgebung gestartet werden. Das Hostsystem (Domain0 unter XEN) dient nur der Verwaltung der Gastsysteme und stellt, ausser SSH zum entfernten Anmelden, keine Netzwerkdienste zur Verfügung. Die Dateisysteme der Gastsysteme werden in regelmässigen Abständen als Image auf einen dedizierten Backup-Server gesichert. Um ein konsistentes Backup zu gewährleisten, ohne die Gastsysteme offline nehmen zu müssen, wird die Snapshot-Funktion des Logical Volume Managers genutzt. Eine Snapshot-Partition bildet den Inhalt einer Ursprungs-Partition zu einem bestimmten Zeitpunkt ab, ohne dass sich 21

Änderungen an der Ursprungs-Partition auf die Snapshot-Partition auswirken. Auf den virtualisierten Servern läuft ein Gastsystem als Honeypot. Es dient zur Erkennung von Einbrüchen in die anderen Gastsysteme. Da der Honeypot keinen produktiven Wert hat, sind alle Verbindungen zum Honeypot verdächtig. Verbindungen von einem der produktiven Gastsysteme zum Honeypot sind ein starker Indikator für einen Einbruch, da der Honeypot keine Dienste bereit stellt, die die produktiven Gastsysteme im normalen Betrieb benötigen. Der Honeypot baut selbständig nie Verbindungen zu den anderen Gastsystemen oder nach aussen auf. Jede vom Honeypot ausgehende Verbindung weist auf einen Einbruch hin und muss untersucht werden. Zusätzlich zum Honeypot läuft auf den virtualisierten Servern ein IDS in einem eigenen Gastsystem. Das IDS überwacht den Netzwerkverkehr aller auf dem Hostsystem befindlichen Gastsysteme anhand vorgegebener Regeln. Das IDS alarmiert den Administrator bei Verstoss, eventuell leitet es auch selbstständig Gegenmassnahmen ein wie z.b. Härtung der Firewall oder Terminierung von TCP Verbindungen über RST Pakete. Die Regeln des IDS werden laufend angepasst unter Zuhilfenahme der vom Honeypot gewonnenen Erkenntnissen über Einbruchsversuche. Die Anpassung erfolgt manuell durch den Administrator, in einer späteren Ausbaustufe möglicherweise aber auch (halb-)automatisch. Für die Implementierung des Konzeptes wird eine iterative Herangehensweise benutzt. Im ersten Schritt wird ein Server, der später als Ersatz für einen weniger leistungsfähigen produktiven Server dienen soll, mit XEN installiert. Auf dem Server werden mehrere Gastsysteme installiert, die aber noch keine produktiven, oder aber unkritische Dienste übernehmen. Ein Gastsystem wird mit der freien Honeypotlösung honeyd installiert. In diesem Schritt wird die Verlässlichkeit von XEN im Rechenzentrumsbetrieb getestet und über den Honeypot werden erste Daten gesammelt. 22