% (c) Andreas Hofmeier % http://www.lgut.uni-bremen.de/an-h/ % http://an-h.de/ oder http://an-h.de.vu/ (ohne Werbung) \documentclass[11pt]{article} \usepackage{a4,german} \usepackage[T1]{fontenc} \usepackage[latin1]{inputenc} \usepackage{ngerman} \usepackage[dvips]{graphics} \usepackage{latexsym} \usepackage{exscale} \usepackage{amssymb,amsmath} %\documentclass[11pt]{report} %\usepackage{isolatin1} %\usepackage{german} \usepackage{epsf} \usepackage[dvips]{rotating} \usepackage{longtable} \usepackage{dcolumn} \usepackage{listings} %\usepackage{eurosym} %\EUR{300} \usepackage{multicol} %\usepackage[dvips]{rotating} %ENDHEAD \parindent=0pt \parskip=\baselineskip %\setcounter{tocdepth}{4} %\setcounter{secnumdepth}{4} \pagestyle{plain} \pagestyle{myheadings} \markright{\mbox{\bf A. Hofmeier, RDUe Laborversuch Firewalling und Attacken}} %\markboth{\mbox{\bf A. Hofmeier, EMT Laborversuch FS}}{\mbox{\bf A. Hofmeier, EMT Laborversuch FM}} \begin{titlepage} \title{-- RDUe Labor --\\Rechnernetze und Datenübertragung\\Laborbericht über Versuch:\\Firewalling und Attacken} \author{Andreas Hofmeier} %\date{12. Mai 2003} \date{} \end{titlepage} \begin{document} %%PDF \section*[Deckblatt] \maketitle \begin{center} \begin{tabular}{rl} Auftraggeber: & Prof. Dr.-Ing. Kai-Oliver Detken,\\ & Fachhochschule Bremen \\ Durchführung am: & 04.06.2004, 08.06.2004 und 16.06.2004\\ Ort der Durchführung: & FH Bremen, Flughafenalle 10,\\ & Raum: I222 \\ Abgabe am: & 28.07.2004\\ \\ \end{tabular} Versuchsgruppe \\ \begin{tabular}{rcll} \\ Andreas Hofmeier & & & \\ Clemens Nau & & & \\ Marco Bensch & & & \\ \end{tabular} \end{center} \begin{abstract} . \\In diesem Versuch sollte die Leistung und die Sicherheit einer unter SuSE GNU Linux laufenden Firewall untersucht werden. Mit Hilfe eines speziellen Computers (Navtel InterEmulator) wurden der HTTP-Server, die HTTP-Klienten sowie die Angriffe Simuliert. \\\\ Für den Versuch vorgesehen waren zusätzlich Versuche mit einem unter Linux laufenden HTTP-Server und einer FTP-Übertragung vom InterEmulator zum InterEmulator. Diese Versuche konnten aufgrund technischer Probleme nicht durchgeführt werden. \\\\ Der Ping (DoS) Angriff legte die Firewall wie erwartet lahm. Erwartungsgemäß reagierte die Firewall garnicht auf Ping-of-Death-Attacken. Die Versuche mit der Smurf sowie der SYN-Attacke wurden nicht korrekt durchgeführt. \end{abstract} \newpage \tableofcontents \newpage \section{Versuchsziele} Ziele dieses Versuches war es ein Grundverständnis für Netzwerksicherheit zu erlangen. Es sollte ausprobiert werden, welche Formen von Attacken eine Firewall abwehren kann und welche nicht. Zusätzlich sollte die Performance der Firewall bestimmt werden, denn keine Sicherheit ohne Preis (hier die Zugriffszeit). \section{Vorbetrachtungen} \subsection{Firewall - Was ist das?} Bei einer Firewall handelt es sich um einen Computer welcher ein sicheres Netzwerk (z.B. ein firmeninternes Netzwerk) von einem unsicheren Netzwerk (z.B. dem Internet) abschottet. \centerline{ \epsfxsize=13.5cm\epsffile{StandortFirewall.eps} } (Im Internet gibt es natürlich unzählige Klienten und Server, dass ich habe hier vorausgesetzt. Größenverhältnisse nicht ganz realistisch...) Wollte man hundertprozentige Sicherheit erreichen, so müsste man ``nur'' die Verbindung der beiden Netzwerke trennen. Hat dann allerdings auch nur 0\% Zugriff auf Dienste außerhalb des internen Netzwerkes. Möchte man unbeschränkten Zugriff auf diese externen Dienste haben, ist es ein leichtes die beiden Netzwerke über zum Beispiel einen Router miteinander zu verbinden. Nun hat man allerdings keinen Schutz mehr vor der ``bösen Welt''. Schnell wird klar, dass keines der beiden extreme wirklich sinnvoll ist. Aber es sollte genauso klar sein, dass alles seinen Preis hat. Es ist nahezu unmöglich hundertprozentige Sicherheit und vollen Zugriff unter ein Dach zu bringen. Möchten Sie zum Beispiel ein Firmengelände einer sicherheitsbewussten Firma betreten, so werden sie um Eingangskontrollen kaum herumkommen. Die Kontrollen sind der Preis für die Sicherheit. Nicht nur das sie eine gewisse Zeit warten müssen, auch das Sicherheitspersonal und die Ausweise, etc kosten Geld. Genauso ist es bei einer Firewall. Eine Firewall ist sozusagen die Eingangskontrollstelle zu ihrem Netzwerk. Auch wenn die eine Firewall ein Paket meist schneller abfertigt als ein Wachmann eine Person, kann die Verzögerung schon zu Problemen führen. Ein gutes Beispiel hierfür sind Echtzeitanwendungen wie Videokonferenzen. \subsection{Angriffe auf Firewalls I: Denial-of-Service (DoS) Attacke} Ein weiteres Problem einer Eingangskontrolle ist deren Dimensionierung. Aus Kostengründen wird man natürlich versuchen eine auf seinen Bedarf zugeschnittene Eingangskontrolle aufzubauen. Aber was passiert, wenn sich alle Bewohner einer Stadt entschließen zu der Eingangskontrolle zu gehen? Gut, sie würden nicht reingelassen -- aber, da die Zufahrtsstraßen verstopft wären, würde auch niemand anders mehr reinkommen. Da Computer ``normalerweise'' einfacher zu programmieren sind als Menschen, ist es in Netzwerken relativ einfach genügend viele Zugriffe zu produzieren um die normale Funktion eines System untergehen zu lassen. So etwas würden man dann eine Denial-of-Service Attacke nennen. \subsection{Paketfilter} Wie der Name vermuten lässt, filtert diese einfache Form der Firewall Pakete nach gewissen Kriterien. So können zum Beispiel alle Pakete ausgefiltert (nicht zugelassen) werden, die zu groß sind, einen ungültigen oder unerwünschten Absender haben oder an einem bestimmten Port/Service (der nicht erwünscht ist) gerichtet sind. %Es gibt statische und dynamische Paketfilter. Die Statischen werden %vom Benutzer (Administrator) eingestellt und bleiben eine längere Zeit %erhalten. Während die Dynamischen automatisch (z.B. durch ein Programm) %aktualisiert und an die aktuellen Bedürfnissen angepasst werden. Paketfilter eignen sich gut um zum Beispiel eine bestimmten Service zu unterbinden sind aber nutzlos gegen Angriffe auf Applikationsebene. So könnten unerwünschte FTP-Zugriffe durch sperren des Ports 21 unterbunden werden. Dies ist zum Beispiel sinnvoll, wenn der FTP-Server nur intern verwendet werden soll. FTP-Anfragen werden schon vor erreichen des Servers abgefangen und können diesen nicht mehr beeinträchtigen. Würden die Anfragen bis zum FTP-Server durchgelassen, könnte dieser zum Beispiel durch Überflutung mit Zugriffen (Denial-of-Service Attacke) beeinträchtigt werden. Des weiteren wäre es möglich Schwachstellen des Servers selber auszunutzen. Hier sind insbesondere Buffer-Overflows zu nennen. Vor diesen beiden Angriffen bietet ein Paketfilter also nur dann Schutz, wenn der entsprechende Service verboten wurde. Dies auch nur begrenzt, da die Firewall selber so damit beschäftigt sein kann die Angriffe abzuweisen, dass nichts anderes mehr durchkommt. Einige Beispiele: Ping-Flooding (DoS auf Paketebene) gegen FTP-Server (über Firewall; egal, ob FTP zugelassen): Die die Internetverbindung wäre lahmgelegt aber der FTP-Server könnte intern weiter verwendet werden; Überflutung mit FTP-Zugriffen: Ist der Service erlaubt, also von außen sichtbar, ist eine Firewall machtlos. Ansonsten würde die Firewall den Angriff total abwehren. Die Internetverbindung wäre nur wenig darurch belastet. Weiterhin kann ein Paketfilter manipulierte Paket filtern. So zum Beispiel Ping-of-Death-Attacken, welche mit Hilfe von manipulierten (z.B. übergroßen) Paketen versuchen den Zielrechner zum Absturz zu bringen. Das meint aber nicht, dass die Firewall in der Lage wäre manipulierte Daten innerhalb eines korrekten Datenstroms (z.B. Ausnutzungen eines Buffer-Overflows) erkennen und abzuweisen. Hierfür ist der jeweilige Server selber zuständig. Um diesem Problemen vorzubeugen können Applikationsfilter eingesetzt werden. \subsection{Applikationsfilter} Bei Applikationsfiltern handelt es sich um einen Filter auf Applikationsebene. Ganz im gegensatz zu Paketfiltern können hier Angriffe auf der Applikationsebene (z.B. Ausnutzung von Buffer-Overflows) abgewehrt werden. Applikationsfilter müssen daher auf die jeweilige Applikation zugeschnitten sein, anders als Paketfilter, denen die Applikation egal ist. Proxys sind zum Beispiel eine Form von Applikationsfiltern. Ein weiteren interessanter Aspekt neben dem Filtern von sicherheitsrelevanten Daten wie Viren und Trojanern, ist das Filtern von unerwünschten Inhalten, wie zum Beispiel Werbung, Spam, Pornos, etc... \subsection{Proxys} Proxys sind eine Erweiterung von Applikationsfiltern. Sie filtern nicht nur den Datenstrom sondern speichern ihn auch zwischen (cachen). Das hat den großen Vorteil, dass häufig gebrauchte Daten nicht immer wieder durch einen Flaschenhals (z.B. langsame Internetverbindung) neu geladen werden müssen. Das macht den Zugriff schneller. In der heutigen Zeit, in der nach Traffic-Volumen abgerechnet wird, macht es sich ebenfalls in den Onlinekosten bemerkbar. Da häufig gebrauchte Daten eben nur einmal, statt ``häufig'' geladen werden. Für die häufigen HTTP (WWW/WEB) Zugriffe stehen unter GNU Linux unter anderem diese beiden Proxys zur Verfügung: Apache (kann neben WEB-Server auch als Proxy arbeiten) und Squid. \subsection{Angriffe auf Firewalls II} Angreifen kann man nur, was man auch erkennen kann. Also sollte die Firewall von außen nicht sichtbar sein. Dies kann dadurch erreicht werden, dass die Firewall nicht auf ICMP-Anfragen (z.B. Pings) reagiert. So bleibt die Firewall für Traceroute unsichtbar. Das setzt natürlich voraus, dass die IP der Firewall für nichts anderes als für Firewall verwendet wird. Läuft zum Beispiel der WEB-Server auf dem selben Rechner wie die Firewall, ist die IP der Firewall schon bekannt und angreifbar. Ganz davon zu schweigen, dass der zusätzliche Dienst ebenfalls Sicherheitslücken enthalten kann und somit die Firewall ``angreifbarer'' macht. Hier gilt: Jeder Service erhöht die Angriffsfläche. Gelingt ein Einbruch auf einer Firewall (zum Beispiel über ein WEB-Server auf dem selben Rechner), kann diese zum Router umfunktioniert werden und alle Zugriffe von außen sind möglich. Bricht jemand allerdings auf einem ``nur Webserver''-Rechner ein, so sind die Zugriffe von außen werterhin durch die Firewall beschränkt. Ein von einem Trojaner geöffneter Port kann zum Beispiel nicht von außen erreicht werden. Natürlich sollte der Admin bei einem Login auf einer Firewall (genauso wie bei jedem anderen Login auch) alle Sicherheitsvorschriften beachten. Einloggen wenn möglich nur von ``sicheren Rechnern'' (keine Fremdrechner mit Keyboardloggern im Hintergrund) aus. Ebenfalls sollte ein anerkanntes Verschlüsselungsverfahren wie z.B. SSL/SSH verwendet werden. \subsection{Paketfilter unter Linux} Der Linux-Kernel hat einen Paketfilter integriert. Auf Grund der hohen Zuverlässigkeit und Sicherheit eignet sich GNU Linux ganz besonders gut für den Einsatz als Firewall. \subsubsection{Bedingungsketten} \centerline{ \epsfxsize=13.5cm\epsffile{Chain.eps} } Bei jedem Paket geht der Linux-Kernel die entsprechende Bedingungskette durch. Eine Bedingungskette besteht aus einer Reihe von Tests und bedingten Operationen die nacheinander abgearbeitet werden. Jede Kette endet mit einer Policy. Sozusagen einer ``wenn nichts anderes zutrifft, dann tue dies''-Operation. Unter Tests können zum Beispiel Paketgröße, Quell- und Zieladresse sowie Port, Pakettyp (UDP/TCP/ICMP), Zuordnung (bereits offene Verbindung, Verbindungsanfrage), etc getestet werden. Die Operation ist jeweils einem Test zugeordnet und wird durchgeführt wenn dieser zutrifft. Operationen können sein: Paket durchlassen (akzeptieren, keine weiteren Tests), Paket Verwerfen (Löschen, keine weiteren Tests) oder Protokollieren (Eintrag an Systemlogdeamon/Logfile senden, die Kette wird weiter durchlaufen) Um die Tests und die daraus resultierenden Operationen so exakt wie möglich festlegen zu können, existieren mehrere Ketten die bei verschiedenen Ereignissen durchlaufen werden: INPUT (wird bei jedem an dem Firewallrechner eintreffenden Paket abgearbeitet), OUTPUT (wird bei jedem Paket durchlaufen, welches den Firewallrechner verlässt) und FORWARD (mit welcher jedes Paket überprüft wird, welches von der Firewall weitergegeben, bzw geroutet wird). Zusätzlich zu diesen Ketten gibt es noch weitere Ketten die zum Beispiel bei einem durch NAT bearbeiteten Paket zum Einsatz kommen. Des weiteren kann der Benutzer auch eigene Ketten definieren, die er mittels einer Operation aufrufen kann. Es ist zu beachten, dass die Ketten ``von links nach rechts bzw von oben nach unten'' abgearbeitet werden. Wenn also die erste Anweisung ein ACCEPT ALL (also: Test immer Richtig und Operation ACCEPT) ist, werden alle Pakete angenommen, egal, was für Anweisungen noch folgen. Ein Sicherheitsbewusster Admin definiert grundsätzlich alle ACCAPTS und schmeißt mit Hilfe der Policy alles was übrigbleibt weg. Auf keinen Fall sollte es umgekehrt gehandhabt werden, weil in diesem Fall etwas Sicherheitsrelevantes übersehen werden könnte. Wird im anderen Fall etwas übersehen, zeigt sich dies daran, dass ein bestimmte Zugriff nicht mehr funktioniert (z.B. HTTP). Dies ist einfach zu erkennen und schnell zu beheben. Jedenfalls einfacher als die Tatsache, dass ein Zugriff durchgelassen wird, der nicht durchgelassen werden sollte. Wenn dieser Zugriff vergessen wurde, ist davon auszugehen, dass dieser auch beim obligatorischen Test der Firewall vergessen wird. \subsubsection{iptables: Setzen der Bedingungsketten} Die Ketten liegen im Hauptspeicher und können mittels dem Programm {\tt iptables} ausgelesen und geändert werden. Es handelt sich hierbei um ein kleines Konsole-Programm, welches vorwiegend in Skripten Verwendung findet oder von höheren, meist graphischen, Konfigurationsprogrammen aufgerufen wird. Es ist zu bedenken, dass der Hauptspeicher flüchtig ist. Alle Ketten also verloren gehen, wenn der Computer ausgeschaltet wird. Um die Ketten auf Festplatte zu sichern existieren vorgefertigte Skripte. \newpage \section{Versuchsaufbau und Durchführung} \subsection{Das Netzwerk} \begin{multicols}{2}[][1cm] Der Versuch wurde im großen und ganzen so wie in der Anleitung beschrieben aufgebaut: Der InterEmulator-Client wurde über das Netzwerk 192.168.2.0/255.255.255.0 mit der Firewall verbunden. Die Firewall reichte die Anfragen dann über das Netzwerk 192.168.1.0/255.255.255.0 an den InterEmulator-Server weiter. Die Beiden Netzwerke waren völlig unabhängig zu einander. Bei beiden Netzwerken sowie allen anderen beteiligten Netzwerkequipment handelte es sich um 100MBps Geräte. \\\\\\ \centerline{ \includegraphics[width=6.5cm]{Netzwerk.eps} } \end{multicols} Im ersten Schritt des Versuches, nachdem die Hubs aufgestellt und entsprechend verkabelt waren, folgte die Konfiguration der einzelnen Rechner. Dies erfolgte in Gruppenarbeit weitgehend parallel. Es ist zu erwähnen, dass es nicht so einfach war, den Versuch zum laufen zu bekommen, als dies erwartet worden war. \subsection{Firewall} Konfiguration der GNU Linux Firewall: \subsubsection{Netzwerkkonfiguration} \begin{tabular}{|l||l|l|} \hline Einstellung & eth0 (TP) & eth1 (LWL) \\ \hline \hline MAC-Adresse & 00:30:84:6C:3A:BE & 00:04:76:DA:F6:BA \\ \hline IP-Adresse & 192.168.1.4 & 192.168.2.100 \\ \hline Netmask & 255.255.255.0 & 255.255.255.0 \\ \hline Default Gateway & -- & -- \\ \hline \end{tabular} Das Kernel-Modul für den Paketfilter war bereits ordnungsgemäß geladen. Ein Problem, welches uns einige Zeit gekostet hat, bestand darin, dass wir erst rausfinden mussten, wieso die Firewall keine Pakete weiterleitet. Des Rätsels Lösung war, dass das Forwarding erst eingeschaltet werden musste: {\tt\small \begin{lstlisting} echo "1" > /proc/sys/net/ipv4/ip_forward \end{lstlisting} } \subsubsection{Konfiguration des Paketfilter über iptables} Die Konfiguration des Paketfilter erfolgte über iptables: {\tt\small \begin{lstlisting} # Policy fuer alle drei verwendeten Ketten auf Paket verwerfen iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP # Alle zu einer bereits bestehenden Verbindung (Stream) # gehoerenden Pakete zulassen iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Vom Firewallrechner gesendete ICMP-Pakete zulassen, # damit das Anpingen und testen der Server und Klienten # moeglich ist iptables -A OUTPUT -p icmp -j ACCEPT # Das Aufbauen einer HTTP-Verbindung im Protokoll vermerken iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j LOG \ --log-prefix "New HTTP Connection " # Das Aufbauen einer HTTP-Verbindung erlauben iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -j ACCEPT # Das Aufbauen einer FTP-Verbindung im Protokoll vermerken iptables -A FORWARD -p tcp --dport 21 -m state --state NEW -j LOG \ --log-prefix "New FTP Connection " # Das Aufbauen einer FTP-Verbindung erlauben iptables -A FORWARD -p tcp --dport 21 -m state --state NEW -j ACCEPT # Alle weiter zu leitenden DNS-Anfragen verwerfen iptables -A FORWARD -p udp --dport 53 -j DROP # letzte Anweisung, bevor uebrig gebliebene Pakete durch die # Policy verworfen werden: Dies im Protokoll vermerken iptables -A FORWARD -j LOG --log-prefix "DEFAULT DROP FORWARD " iptables -A INPUT -j LOG --log-prefix "DEFAULT DROP INPUT " iptables -A OUTPUT -j LOG --log-prefix "DEFAULT DROP OUTPUT " \end{lstlisting} } \subsection{Konfiguration des Navtel InterEmulator} Der folgende Abschnitt beschreibt die Konfiguration des Navtel InterEmulators. Der Navtel InterEmulator ist ein PC in einem Spezialgehäuse. Durch spezielle Karten ist es dem Gerät möglich große Netzlasten in Form von Zugriffen oder Angriffen zu erzeugen. Es ist an dieser Stelle zu erwähnen, dass wir bei der Konfiguration auf erhebliche Probleme stießen. Der Versuch, welcher für eine Labor-Sitzung angesetzt war, musste auf 3 Laborsitzungen zu je meist mehr als 5 Stunden ausgedehnt werden. Der InterEmulator Reagierte teilweise unlogisch und nicht nachvollziehbar auf gewisse Einstellungen. So mussten wir zum Beispiel feststellen, dass die Ports (Netzwerkanschlüsse) des InterEmulators nicht beliebig beschaltet (mit Servern, Klienten oder Angriffen belegt) werden konnten. Die Anordnung musste zu Teil ausprobiert werden. Versuche den HTTP-Versuch über den InterEmulator zu fahren funktionierten einmal und ein anderes mal wieder nicht -- ohne erkennbaren Unterschied in der Konfiguration. Erschwerend kam hinzu, dass keine ausreichende Dokumentation zur Verfügung stand. \subsubsection{HTTP-Server} Der HTTP-Server des InterEmulators wurde mit folgenden Werten betrieben: \centerline{ \includegraphics[width=360pt,height=265pt]{bilder/http-server.bmp.eps} } %\begin{tabular}{|r|l|} %\hline %Parameter & Einstellung \\ %\hline %\hline %HTTP-Version & 1.1 \\ %Server MAC-Adresse & 00 04 55 04 40 00 \\ %Server IP Adresse & 192.168.1.5 \\ %Subnet Mask & 255.255.255.0 \\ %Gateway & 192.168.1.4 \\ %Server Port & 80 \\ %\hline %\end{tabular} \newpage \subsubsection[HTTP-Klienten]{Konfiguration der HTTP-Klienten} Es wurden 50 HTTP-Klienten durch den InterEmulators emuliert. Da das Fenster mit den Einstellungen nicht auf eine Bildschirmseite passte, musste es in zwei Teilen dargestellt werden. Das ist auch der Grund für die abgeschnittene Titelleiste: \centerline{ \includegraphics[width=360pt,height=265pt]{bilder/http-client-oben.bmp.eps} } \centerline{ \includegraphics[width=360pt,height=265pt]{bilder/http-client-unten.bmp.eps} } \subsubsection[Ping Attack]{Konfiguration der Ping Attacken} %Hier die Konfiguration der Ping-Attacken: \centerline{ \includegraphics[width=360pt,height=265pt]{bilder/attack01.bmp.eps} } \subsubsection[Ping-of-Death Attack]{Konfiguration der Ping-of-Death Attacken} %Hier die eingestellten Werte für die Ping-of-Death-Attacken: \centerline{ \includegraphics[width=360pt,height=265pt]{bilder/attack02.bmp.eps} } %PDF \vspace{3cm} \subsubsection[Smurf Attack]{Konfiguration der Smurf Attacken} %Parametrierung der Smurf-Attacken: \centerline{ \includegraphics[width=360pt,height=265pt]{bilder/attack03.bmp.eps} } \subsubsection[SYN Attack]{Konfiguration der SYN Attacken} %Konfiguration der SYN-Attacken: \centerline{ \includegraphics[width=360pt,height=265pt]{bilder/attack04.bmp.eps} } %PDF \vspace{4cm} \section{Versuchsauswertung} \subsection{Übersicht Transfer zu Attacken} Die folgende Tabelle zweigt die vom Navtel InterEmulator ``abgelesenen'' Werte. Es werden hier die gesendeten und empfangenden Frames gegenübergestellt. \begin{tabular}{|r||r|r|r|r|r|r|} \hline & & \multicolumn{3}{c|}{Client} & \multicolumn{2}{c|}{Server} \\ Attack & FW & Rx & Tx & Time & Rx & Tx \\ \hline \hline Ping & 1758 & 6938 & 8940 & 77 & 8597 & 6838 \\ Ping-of-Death & 3203 & 13277 & 15950 & 67 & 15804 & 12604 \\ Smurf & 4161 & 311001 & 16500 & 69 & 16303 & 13003 \\ SYN (Ref) & 3602 & 14404 & 18000 & 74 & 17806 & 14205 \\ \hline \end{tabular} Die Angaben zur Laufzeit wurden an Hand des Protokollfiles der Firewall überprüft. Die vom InterEmulator gemessenen Laufzeiten waren immer 4 Sekunden größer. Alle Laufzeitangaben in Sekunden. Der Server wurde immer zuerst gestartet und zuletzt beendet. Daten wurden nur übertragen, wenn Server und Klient gleichzeitig liefen. Daher ist die Zeit, die der Server lief, nicht von Interesse. Die Counter wurden für jeden Versuch durch einen Neustart des Server, Klienten oder Attacke auf Null zurückgesetzt. Tx und Rx wurden bei dem Server und Klienten jeweils in ``Frames'' gemessen. Leider ist nicht genau bekannt, was ein Frame ist. Es ist anzunehmen, dass es sich hierbei um ein Ethernet-Frame handelt. Also ein Paket darstellt. Die Größe ist leider nicht bekannt. Die unter FW angegebenen Werte stellen die Anzahl der Erstellungen von Verbindungen dar, die vom Paketfilter der Firewall festgestellt wurden. Also, wann hat ein Client eine Socket-Stream-Verbindung zu einem Server aufgebaut. Dieser Wert entspricht der Anzahl der ``New HTTP Connection'' - Zeilen im Protokollfile. Da nicht bekannt ist, wieviele Frames pro Stream übertragen wurden, oder ob es da überhaupt einen Zusammenhang gab, sind dieser Werte leider nicht mit den Rx und Tx-Werten vergleichbar. An dieser Stelle hätten wohl die übertragenen Pakete statt die Streams gezählt werden sollen. Dazu hätte die iptable anders Eingestellt werden müssen. Um eine bessere Übersicht zu erhalten wurden diese Zahlen auf die Laufzeit des jeweiligen Versuches bezogen. Also der jeweilige Wert durch die entsprechende Laufzeit dividiert. \begin{tabular}{|r||r|r|r|r|r|} \hline & & \multicolumn{2}{c|}{Client} & \multicolumn{2}{c|}{Server} \\ Attack & FW/s & Rx/s & Tx/s & Rx/s & Tx/s \\ \hline \hline Ping & 22.8 & 90.1 & 116.1 & 111.6 & 88.8 \\ Ping-of-Death & 47.8 & 198.2 & 238.1 & 235.9 & 188.1 \\ Smurf & 60.3 & 4507.3 & 239.1 & 236.3 & 188.4 \\ SYN (Ref) & 48.7 & 194.6 & 243.2 & 240.6 & 192.0 \\ \hline \end{tabular} Da bei der SYN-Attacke keine Attacken gesendet wurden, kann diese Zeile mit Werten hier als Referenz verwendet werden. Die vorgesehene Referenzmessung wurde zwar durchgeführt, es wurde aber versäumt, die Werte zu notieren. Es ist zu erkennen, dass die Ping-Attacke den Datentransfer am meisten heruntergezogen hat. Während die Ping-Attacke lief, kamen am wenigsten Pakete durch. Die Ping-of-Death Attacken haben den Transfer nicht sonderlich beeinflusst. Dies kann darauf zurückgeführt werden, dass nur wenige Attacken gesendet wurden, welche von der Firewall abgefangen wurden. Sieht man von dem Ausreißer bei Rx/Client mal ab (dazu gleich mehr), so hat der Smurf-Attacke den Datentransfer noch etwas weniger beeinflusst als die Ping-of-Death Attacke. \subsection{Übersicht Transfer Client/Server} Diese Tabelle stellt eine Übersicht über das Verhältnis von gesendeten und Empfangenen Frames dar. Es wurden jeweils die Anzahl der Empfangenden Pakete durch die Anzahl der Gesendeten geteilt. Dieser Wert wurde dann mit 100 multipliziert um auf Prozent zu kommen. \begin{tabular}{|r||r|r|} \hline & \multicolumn{2}{c|}{Daten (Frames) Angekommen (in Prozent)} \\ Attack & Server $\rightarrow$ Client & Client $\rightarrow$ Server \\ \hline \hline Ping & 101.5 & 96.2 \\ Ping-of-Death & 105.3 & 99.1 \\ Smurf & 2391.8 & 98.8 \\ SYN & 101.4 & 98.9 \\ \hline \end{tabular} Dieser Gegenüberstellung Zeigt, dass fast alle oder sogar mehr der gesendeten Frames angekommen sind. Dies ist meiner Ansicht nach nicht möglich. Während der Ping-Attacke zum Beispiel, war die Firewall tot. Das Netz war überlastet. Wie können in diese Fall 96\% der Pakete durchkommen? Geschweige denn 101\%? Da die Attacken fast 50\% der Zeit liefen, erwarte ich, dass um die 60\% der Pakete durchkommen. Das bei der Smurf-Attacke ca. 24 mal so viele Frames angekommen sind, wie abgeschickt wurden, kann damit erklärt werden, dass die Smurf-Attacken die Firewall passiert haben und vom InterEmulator als Zugriffe gewertet wurden. Diese These wird auch von der Tatsachen unterstützt, dass die Firewall erheblich mehr Streams registriert hat, als bei der Referenzübertragung. \subsection{Anzahl der Attacken} In dieser Tabelle ist die Anzahl der jeweils durchgeführten, empfangenen (Werte vom InterEmulator) und von der Firewall registrierten Attacken dargestellt. Die Anzahl der von der Firewall registrierten Angriffe wurde durch Auszählung der entsprechenden Zeilen im Protokollfile ermittelt. Dazu im Abschnitt Wirkung der Angriffe auf die Firewall mehr. \begin{tabular}{|r||r|r|r|r|} \hline & \multicolumn{4}{c|}{Attack} \\ Attack & FW & Rx & Tx & Time \\ \hline \hline Ping & 668 & 1 & 4671789 & 32 \\ Ping-of-Death & 118 & 1 & 9070 & 21 \\ Smurf & 279323 & 16974 & 3111350 & 20\\ SYN & 0 & 0 & 0 & 29\\ \hline \end{tabular} Übersicht Angriffe pro Sekunde. \begin{tabular}{|r||r|r|r|} \hline & \multicolumn{3}{c|}{Attack} \\ Attack & FW/s & Rx/s & Tx/s \\ \hline \hline Ping & 20.9 & 0.0 & 145993.4 \\ Ping-of-Death & 5.6 & 0.0 & 431.9 \\ Smurf & 13966.2 & 848.7 & 155567.5 \\ SYN & 0.0 & 0.0 & 0.0 \\ \hline \end{tabular} \subsection{Wirkung der HTTP-Zugriffe auf die Firewall} Die Firewall registrierte, wie mittels iptables eingestellt, nur das Aufbauen einer neuen Socket-Stream-Verbindung. Jede neue Verbindung, bzw. jedes Paket, welches eine Verbindung aufbaut, wurde in der Logdatei mittels einer Zeile festgehalten. Hier ein Beispiel: {\tt\small \begin{lstlisting} Jun 16 15:28:55 INRN05 kernel: New HTTP Connection IN=eth1 \ OUT=eth0 SRC=192.168.2.200 DST=192.168.1.5 LEN=44 TOS=0x00 \ PREC=0x00 TTL=59 ID=0 DF PROTO=TCP SPT=4096 DPT=80 WINDOW=8\ 192 RES=0x00 SYN URGP=0 \end{lstlisting} } (Die Zeile aus der Logdatei war zu lang um auf eine Seite zu passen, daher wurde sie umgebrochen, was durch einen Backslash am Ende der Zeile gekennzeichnet wird.) Der erste Teil dieser Zeile gibt das Datum, die Uhrzeit, den Namen des Computers und das verursachende Programm (hier der Paketfilter, welcher in den Kernel eingebettet ist) an: {\tt Jun 16 15:28:55 INRN05 kernel} Nun folgt das ``log-prefix'': {\tt New HTTP Connection}. Das Interface, an welchem dass Paket ankommt bzw die Firewall wieder verlässt sowie die Quell- und Zielrechner dürfen natürlich auch nicht fehlen: {\tt IN=eth1 OUT=eth0 SRC=192.168.2.$\backslash$ 200 DST=192.168.1.5} Hiernach folgen noch einige Paketinformationen, wie die Time-To-Live, Paketgröße, Protokoll, Windowgröße oder Typ. Das jede Verbindung eine eigene Zeile hervorgerufen hat und nicht mit {\tt last message repeated n times} abgekürzt wurde, ist darauf zurück zu führen, dass der InterEmulator für die nächste Verbindung die nächste IP verwendet hat. Also 192.168.2.200, 192.168.2.201, ... 192.168.2.249 und dann wieder von vorne. Alle aufeinanderfolgende Zeilen also unterschiedlich waren. Pro Sekunde wurden 50 Verbindungen aufgebaut, woraus man schließen kann, dass jeder der 50 Klienten einmal pro Sekunde seine Verbindung neu aufgebaut hat. \subsection{Wirkung der Angriffe auf die Firewall} \subsubsection{Ping Attack} Während der Ping Attacken liefen, reagierte der GNU Linux Rechner, welcher als Firewall herhalten musste, überhaupt nicht. Es kam also zu dem erwarteten Ergebnis, das die Firewall zwar die Pings abschottet, währenddessen aber auch nichts anderes durchkommt. Der Computer reagierte noch nicht einmal auf Eingaben über die Text-Konsole. Das steht allerdings im Wiederspruch zu dem weiter oben abgeleiteten Ergebnis, dass die meisten Frames durchkamen. Ich hätte erwartet, dass viel mehr Frames gesendet wurden (in beiden Richtungen) als Empfangen wurden. Dieser Wiederspruch kann aufgelöst werden, indem man davon ausgeht, dass nur Frames übertragen werden, wenn eine Socket-Stream-Verbindung besteht. Während der Angriffe wurden laut Protokollfile tatsächlich keine Verbindungen aufgebaut. Erwähnenswert ist noch, dass es eine Lücke von 14 Sekunden im Protokollfile zwischen der letzten neuen Verbindung und dem ersten eingetragendem Angriff gibt. Einige der Zeilen im Protokollfile sind durcheinander geraten. Das meint, dass eine neue Zeile begonnen wurde, bevor die alte abgeschlossen war. Dies alles sind Indizien für die Tatsache, dass der Kernel (bzw. der Paketfilter) völlig überlastet war und seinen Dienst nicht mehr richtig verrichtete. Beispiel für eine durch den Angriff verursachten Zeile im Logfile. Da diese Zeilen alle gleich sind oder besser gesagt gleich sein sollten, wurde hier mittels {\tt last message repeated 34 times} abgekürzt. Diese Form der Abkürzung wurde natürlich beim auszählen der Einträger für die weiter oben liegenden Tabellen berücksichtigt. {\tt\small \begin{lstlisting} Jun 16 15:29:37 INRN05 kernel: DEFAULT DROP FORWARD IN=eth1\ OUT=eth0 SRC=192.168.2.99 DST=192.168.1.5 LEN=46 TOS=0x00 \ PREC=0x00 TTL=127 ID=60929 PROTO=ICMP TYPE=8 CODE=0 ID=1 SE\ Q=1 Jun 16 15:29:37 INRN05 last message repeated 34 times \end{lstlisting} } Da wir mittels iptables keine Regel definiert hatten, die Pakete wie dieses ausschließt, wurd es durch die DORP-Anweisung in der Policy gekillt. Den Eintrag haben wir mit Hilfe der letzten Anweisung in der FORWARD-Chain erzwungen. Dieser letzte Eintrag sorgt nur für eine Ausgabe im Logfile, er schmeißt das Paket nicht weg, dies ist Aufgabe der Policy. Hier ein Beispiel für {\bf eine} vermanschte Zeile im Logfile: {\tt\small \begin{lstlisting} Jun 16 15:29:37 INRN05 kernel: DEFAULT DROP FORWARD IN=eT=e\ th0 SRC=192.168.2.99 DST=192.168.1.5 LEN=46 TOS=0x00 PREC=0\ x00 TTL=127T=eth0 SRC=192.168.2.99 DST=192.168.1.5 LEN=46 T\ OS=0x00 PREC=0x00 TTL=127 ID=60929 PT=eth0 SRC=192.168.2.99\ DST=192.168.1.5 LEN=46 TOS=0x00 PREC=0x00 TTL=127 ID=60929\ PROTO=ICMP TYPE=8 CODE=0 ID=T=eth0 SRC=192.168.2.99 DST=19\ 2.168.1.5 LEN=46 TOS=0x00 PREC=0x00 TTL=127 ID=60929 PROTO=\ ICMP TYT=eth0 SRCT=eth0 SRC=192.168.2.99 DST=192.168.1.5 LE\ N=46 TOS=0x00 PREC=0x0T=eth0 SRC=192.168.2.99 DST=192.168.T\ =eth0 SRC=192.168.2.99 DST=192.168.1.5 LEN=46 TOS=0x00 PREC\ =0x00 TTLT=eth0 SRC=192.T=eth0 SRC=192.168.2.99 DST=192.168\ .1.5 LEN=46 TOST=eth0 SRC=192.168.2.99 DST=192.168.1.5 LEN=\ 46 TOS=0x00 PREC=0x00 TTL=127 ID=6T=eth0 SRC=192.168.2.99 D\ STT=eth0 T=eth0 SRC=192.16T=eth0 SRC=192.168.2.T=eth0 SRC=1\ 92.168.2.99 DST=192.168.1.5 LEN=46 TOS=0x00 PREC=0x00 TTL=1\ 27T=eth0 SRC=192.168T=eth0 SRC=19T=eth0 SRC=192.168.T=eth0 \ SRC=192.168.2.99 DST=192.168.1.5 LEN=46 TOS=0x00 PREC=0x00 \ TTL=127 ID=60929 PROT=e \end{lstlisting} } Gut zu wissen, dass Computer sich auch mal Fehler machen. An diesen Stellen (so sieht fast das ganze Protokollfile aus) wurde immer nur eine Zeile gezählt. \subsubsection{Ping-of-Death Attack} Die Ping-of-Death-Attacke versucht durch ein übergroßes Paket einen Fehler im Netzwerkstack des Zielrechner auszunutzen und diesen so zum Absturz zu bringen. Die Spuren dieser Angriffe waren schon schwieriger zu finden. Das öffnen neuer Verbindungen lief nebenbei ungestört weiter, genauso wie der Kommandointerpreter auf der Konsole. Es gab auch keine Aussetzer oder ``Vermanschungen'' im Logfile. Die obere Zeile fand sich in ähnlicher Form nur vier und untere 14 mal im Log. {\tt\small \begin{lstlisting} Jun 16 15:37:52 INRN05 kernel: NET: 24 messages suppressed. Jun 16 15:37:52 INRN05 kernel: Oversized IP packet from 192\ .168.2.99. \end{lstlisting} } \subsubsection{Smurf Attack} Laut {\tt http://www.computec.ch/software/denial\_of\_service/smurf/index\-.html} sendet die Smurf-Attacke ein Ping mit gefälschte Absenderadresse (hier versehentlich die Falsche angegeben: 192.168.2.99) an eine Broadcastadresse (hier 192.168.2.255). Laut RFC haben alle Computer in diesem Netzwerk dieses Ping zu erwidern. Wird nun die Absenderadresse auf das Angriffsziel gesetzt, so erhält dieser Rechner mal viele Pings. In unserem Fall waren allerdings nur zwei (Mit Ping-Rechner drei) Rechner im Netzwerk, was die Attacke ins leere laufen lassen hat. Zudem war die Source-Adresse mit 192.168.2.99 (192.168.2.100, die Firewall bzw. 192.168.1.4, der HTTP-Server wäre richtig gewesen) falsch angegeben. Mit dieser Einstellung griff sich der InterEmulator sozusagen selbst an. %Des %weiteren Funktioniert dieser Angriff nur, wenn der Angreifer im %gleichen Subnetz wie das Opfer sitzt. Der InterEmulator hätte also nur %die Firewall, nicht aber den HTTP-Server angreifen können. ???????? Die Attacken beantwortet und so den eigentlichen Angriff hat in diesem Fall wohl der Ping-Rechner durchgeführt. Diesen hatten wir Zeitweise in das Netzwerk geschaltet um es mittels Pings den Fehler im Netzwerk zu suchen. Die Firewall filterte alle Pings aus und konnte diese daher nicht mehr beantworten: \newpage {\tt\small \begin{lstlisting} Jun 16 15:43:01 INRN05 kernel: DEFAULT DROP INPUT IN=eth1 O\ UT= MAC=ff:ff:ff:ff:ff:ff:00:04:55:04:40:00:08:00 SRC=192.1\ 68.2.99 DST=192.168.2.255 LEN=46 TOS=0x00 PREC=0x00 TTL=128\ ID=60929 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=1 Jun 16 15:43:01 INRN05 last message repeated 182 times \end{lstlisting} } Die Attacke hatte also nur eine indirekte Wirkung auf den Transfer: Durch die Belastung des Netzwerkes durch den Angriff auf sich selbst ist der HTTP-Transfer etwas nach unten gegangen. \subsubsection{SYN Attack} Laut InterEmulator wurden keine Angriffe gesendet. Im Protokollfile waren ebenfalls keine Spuren eines Angriffs zu finden. \section{Anhang: Verwendete Geräte} \subsection{Navtel InterEmulator} {\tt Navtel Comnunications Inc. IP InterEmulator Serial 000001394} Betriebsystem: Microsoft Windows NT \subsection{Firewall} \begin{itemize} \item[-] CPU Typ: AMD Athlon XP, 1544 MHz (5.75 x 269) 1800+ \item[-] Motherboard: Asus A7V266-EX (5 PCI, 1 AGP Pro, 1 ACR, 3 DIMM) \item[-] Motherboard Chipsatz: VIA VT8366A Apollo KT266A \item[-] Systembus: PCI-32 mit 33MHz \item[-] Arbeitsspeicher: 128 MB (DDR SDRAM) \item[-] BIOS Typ: Award Medallion (01/23/02) \item[-] Grafikkarte: 3D Prophet 4000XT TV Out (32 MB) \item[-] 3D-Beschleuniger: ST PowerVR Kyro \item[-] Soundkarte: C-Media CMI8738 Audio Chip \item[-] Diskettenlaufwerk \item[-] Festplatte (40 GB, 7200 RPM, Ultra-ATA/100) \item[-] ATAPI CD-R/RW 24X10 (24x/10x/40x CD-RW) \item[-] PIONEER DVD-ROM DVD-116 (16x/40x DVD-ROM) \end{itemize} \subsubsection{Netzwerkkarte (eth0) TP} \begin{itemize} \item[-] Hersteller: 3Com \item[-] Typ: 3Com Etherlink XL 3C905C-TX-M \item[-] Geschwindigkeit: 10/100 MBps \item[-] Bus: PCI \item[-] Funktionallität: IEEE 802.1p (Prioritätsvergabe für Datenübertragung) \item[-] Sonstiges: Passive (d.h. kein Prozessor auf der Netzwekkarte) \item[-] IP: 192.168.1.4 \item[-] MAC: 00:30:84:6C:3A:BE \end{itemize} \subsubsection{Netzwerkkarte (eth1) LWL} \begin{itemize} \item[-] Hersteller: Allied Telesyn \item[-] Typ: Allied Telesyn AT-2700FX-PCI-100MB-Ethernetadapter \item[-] Geschwindigkeit: 10/100 MBps \item[-] Bus: PCI \item[-] Funktionallität: IEEE 802.1p (Prioritätsvergabe für Datenübertragung) \item[-] Sonstiges: Passive (d.h. kein Prozessor auf der Netzwekkarte) \item[-] IP: 192.168.2.100 \item[-] MAC: 00:04:76:DA:F6:BA \end{itemize} \subsubsection{Betriebsystem} \begin{itemize} \item[-] Distribution: SuSE 9.0 \item[-] Kernel: {\tt Linux 2.4.21-199-athlon \#1 Fri Mar 12 08:24:04 UTC 2004 i686 athlon i386} \item[-] Socks-Implementation: BSD Sockets \end{itemize} %\centerline{ %\includegraphics[width=225pt,height=225pt]{bilder/16_06_2004/http_ohne_attack.bmp.eps} %} %\centerline{ %\includegraphics[width=225pt,height=225pt]{bilder/16_06_2004/http_ohne_attack_20_sek.bmp.eps} %} %\centerline{ %\includegraphics[width=512pt,height=372pt]{bilder/16_06_2004/http_pingofdeath_attack_20_sek.bmp.eps} %} %\centerline{ %\includegraphics[width=512pt,height=372pt]{bilder/16_06_2004/http_pingofdeath_attack_20_sek_b.bmp.eps} %} %\centerline{ %\includegraphics[width=512pt,height=372pt]{bilder/16_06_2004/http_ping_attack_20_sek.bmp.eps} %} %\centerline{ %\includegraphics[width=512pt,height=372pt]{bilder/16_06_2004/http_ping_attack_20_sek_b.bmp.eps} %} %\centerline{ %\includegraphics[width=512pt,height=372pt]{bilder/16_06_2004/http_smurf_attack_20_sek_.bmp.eps} %} %\centerline{ %\includegraphics[width=512pt,height=372pt]{bilder/16_06_2004/http_smurf_attack_20_sek_b.bmp.eps} %} %\centerline{ %\includegraphics[width=512pt,height=372pt]{bilder/16_06_2004/http_syn_attack_20_sek.bmp.eps} %} %\centerline{ %\includegraphics[width=512pt,height=372pt]{bilder/16_06_2004/http_syn_attack_20_sek_b.bmp.eps} %} % %\centerline{ %\includegraphics[width=360pt,height=265pt]{bilder/attack01.bmp.eps} %} %\centerline{ %\includegraphics[width=360pt,height=265pt]{bilder/attack02.bmp.eps} %} %\centerline{ %\includegraphics[width=360pt,height=265pt]{bilder/attack03.bmp.eps} %} %\centerline{ %\includegraphics[width=360pt,height=265pt]{bilder/attack04.bmp.eps} %} %\centerline{ %\includegraphics[width=373pt,height=382pt]{bilder/ftp-client.bmp.eps} %} %\centerline{ %\includegraphics[width=360pt,height=265pt]{bilder/ftp-server.bmp.eps} %} %\centerline{ %\includegraphics[width=362pt,height=382pt]{bilder/http-client-oben.bmp.eps} %} %\centerline{ %\includegraphics[width=362pt,height=382pt]{bilder/http-client-unten.bmp.eps} %} %\centerline{ %\includegraphics[width=360pt,height=265pt]{bilder/http-server.bmp.eps} %} %\centerline{ %\includegraphics[width=360pt,height=265pt]{bilder/ports01.bmp.eps} %} \end{document} \section{Versuchsdurchführung} Was ist ein überwachter Applikationsfilter (Screened Subnet)? Warum hat das Firewall-System mindestens zwei Netzwerkkarten? .Was sind iptables? .Wie lassen sich iptables konfigurieren? Firewall-Graphik Packetfiltergraphik: S4 Verarbeitung eines Paketes: S5 Diese Tabelle gibt uns eine Übersicht über die Werte, welche vom InterEmulator gezählt wurden. \begin{tabular}{|r||r|r|r|} \hline & Server & Client & Angriffe \\ \hline \hline Anzahl der empfangen Frames & 6938 & 8597 & 1 \\ Anzahl der gesendeten Frames & 8940 & 6838 & 4671789 \\ \hline \end{tabular} Erstaunlich ist, dass nur ca. 4\% (Server $\rightarrow$ Client) bzw. 1.4\% (Client $\rightarrow$ Server) der Frames (was immer das auch ist) verlohrengegengen sind. Hier das Originaldiagramm, welches vom InterEmulator erzeugt wurde. Die beiden ersten Diagramme (links) stellen die vom Klienten und Server dar. Was der Server sendet, muss der Klient empfangen. Das erklährt, wieso die Diagramme invers zueinander sind. Es ist gut zu erkennen (rechtes Diagramm), dass keine von den Atacken durchgekommen ist. Die eine in der Tabelle aufgeführte Atacke entstammt wahrscheinlich aus eine anderen Quelle. Das nur genau eine Ping-Atacke durchkommt ist unrealistisch. \centerline{ \includegraphics[width=445pt,height=112pt]{bilder/16_06_2004/http_ping_attack_20_sek_b2.bmp.eps} } 1758 668 Atacken