Firewalls, schon fast eine Unwort der heutigen zeit, mittlerweile ranken sich Gerüchte um die Fähigkeiten und Möglichkeiten einer Firewall als ob sie ein Mythos wäre oder eine Berühmtheit.

Die erste Erkenntnis sollte sein:

Firelwall!= Sicherheit

Dieses Dokument soll einen Möglichkeiten und Fähigkeiten einer Firewall beschreiben, auch werden hier die verschiedenen Ansätze in denen eine Firewall gestalltet werden kann gezeigt werden. Zu den wichtigsten Punkten dieser Arbeit sollen aber die Angriffszenarien gehören und natürlich nicht minder wichtig soll ein konkretes Beispiel angeführt werden.

Eine Firewall soll dazu dienen, dass der Verkehr zwischen zwei Netzwerken überprüft werden kann und natürlich auch Begrenzungen ermöglicht. Als Beispiel aus der realen Welt kann eine Firewall mit einem Tormann verglichen werden des Tor als das zu schützende Netzwerk anzusehen ist. Nun soll dieser Tormann einzelne Verbindungen durchlassen, andere aber abwehren und verhindern. Und somit definiert sich auch das Ziel eines Angreifers, er möchte unerkannt an diesen Tormann vorbeikommen.

Abbildung 1 - Firewall Konzept

Dennoch ist es auch wichtig das es Teilnehmern aus den Netzwerken möglich ist gewünschte Verbindungen aufzubauen und Übertragungen durchzuführen und hierbei befindet man sich bei der Definition einer Firewall immer auf einem schmalen Grad.

Abbildung 2 - Angriffszenario

Um nun diese Voraussetzungen erfüllen zu können gibt es drei weit verbreitete Ansätze: „raditional packed filter“, „stateful packet filter“ und „proxy based firewalls“. Auf den folgenden Seiten wollen wir die einzelnen Technologien kurz erklären und deren Vor und Nachteile aufzeigen

2 Typen von Firewalls

2.1 Traditional Packet Filters

Wie der Name schon sagt, liegt hier der Focus auf den einzelnen Datenpaketen. Wobei sich die entscheidung auf die Header Information und die Richtung jedes Datenpaktes beschränkt. Anhand dieser Informationen entscheiden einzelne Regeln darüber ob ein Packet passieren darf oder auch nicht. Dabei werden explizit folgende Informationen Bewertet:

Source-IP Adresse: Diese Information über die Herkunfts-IP ermöglich die Unterscheidung ob es diesem Absender überhaupt erlaubt werden soll, ein Paket in das geschützte Netzwerk zu schicken.
Source TCP/UDP port: Von welchem Port des Absenders wurde das Paket abgeschickt, beschreibt dieser Port einen bestimmten Service.
Destination-IP Adresse: Diese Feld des Headers beschreibt den gewünschten Empfänger im Netzwerk. Dadurch ist es dem Filter möglich zu entscheiden, ob der Empfänger überhaupt dieses Paket erwartet.
Destination TCP/UDP: An welchen Port des Empfängers soll das Paket gehen. In der RFC 1700 sind die Well kown Ports beschrieben, dadurch lässt sich spezifiziern ob dieses Paket überhaupt dem Service entspricht der einem bestimmten Port zugeordnet ist.
TCP code bit: Wird im Header in diesem Bereich ein SYN bit gesetzt handelt es sich um eine Initialisierung ein Verbindung, besteht es hingegen aus einem ACK bit, so kann von einer bestehenden Verbindung ausgegangen werden. Diese Information ist sehr wichtig für eine Paket basierte Firewall, da diese viel Erkenntnis darüber zulässt ob ein Paket angenommen oder verweigert wird. Im Gegensatz zu TCP unterstütz das UDP Protokoll diese Information leider nicht, da dieses bei der Verbindungserstellung und Aufrechterhaltung weniger restriktiv ist.
Protokol in use: Soll ein bestimmtes Protokoll im Netzwerk erlaubt sein und ein anderes hingen nicht erlaubt ist. Als Beispiel, es kann möglich sein, dass das TCP Protokoll den Filter passieren darf, hingegen das UDP Protokoll abgelehnt wird.
Dicection: In welche Richtung wird ein Paket gesendet. Verlässt es das Netzwerk oder will es in das Netzwerk gelangen. Auch auf diese Weise kann entschieden werden ob ein Paket passieren darf oder auch nicht.
Interface: Stammt das Packet aus einem sicheren Netzwerk oder auch einem unsicheren. Anhand des Interfaces kann entschieden werden ob ein Paket zugelassen wird oder abgewiesen.

Bei diesen Paket basierenden Filter, welche in Router oder Firewalls implementiert sind, werden diese Vorgaben in einzelnen Regeln festgelegt. Für jede Regel eine einzelne Zeile, wobei diese gesammelten Regel auch als access control lists (ACL) bezeichnet werden.

Dabei setzt jeder Entwickler auf seinen eigenen Syntax um diese Regeln zu spezifizieren. Teilweise werden auch grafische Interfaces zur Verfügung gestellt um diese einzelnen Regeln zu verifizieren.

Um einen Überblick zu erhalten haben wir in einer abstrakteren Art eine solche ACL beschrieben, welche natürlich sehr einfach gehalten ist und keineswegs ausreichend Möglichkeiten und Schutz bietet.

Action	Source Adress	Destination Adress	Protocol	Source Port	Destination Port	Code Bit
Allow	Inside Network Adress	Outside Network Adress	TCP	Any	80	Any
Allow	Outside Network Adress	Inside Network Adress	TCP	80	>1023	ACK
Deny	All	All	All	All	All	All

Abbildung 3 - Regel für Standard Packet Filter

Um nun diese Regel zu verstehen bedarf es einer kurzen Erklärung. Die Regeln werden jeweils von oben nach unten abgearbeitet. Um nun über ein Paket zu entscheiden wird es mit den erstellten Regeln verglichen und je nach Action damit verfahren.

Die erste Regel erlaubt es zum Beispiel den Usern innerhalb des Netzwerkes auf alle IP’s außerhalb zuzugreifen, wenn dies über das TCP Protokoll geschied und der Empfänger die Nachricht auf Port 80 akzeptiert: In diesem Fall sind das externe Webserver laut (RFC 1700).

Die zweite Regel wiederum erlaubt es allen außenstehenden Webservern ein Paket in das Netzwerk zu schicken. Wobei es sich um eine bereits bestehende Verbindung handeln muss, welche ein ACK bit enthält und der Absender auf Port 80 und der Empfänger auf Port größer 1023 liegen muss. In diesem Fall kann es nur eine Antwort auf eine vorige Anfrage eines Users im internen Netzwerk sein.

Die dritte und letzte Regel ist auch die einfachste: verbietet alles was nicht obern explizit erlaubt ist. Diese Regel ist somit eigentlich selbsterklärend.

Nun kann man aber auch einige schwächen des Paket basierten Filterns erkennen, zum Beispiel ist in Regel zwei die einzige Einschränkung die verhindert das ein beliebiges Paket in das geschützte Netzwerk eindringe kann diese ACK bit welches bestätigt, dass es sich um die Antwort auf eine im Netzwerk gestellte Anfrage handelt. Dieses ACK bit kann aber sehr leicht vom Absender gefälscht werden, und schon hat er Zugang über alle Ports größer 1023. Ein weiteres Problem ist der Umgang mit dem UDP Protokoll, dieses ist zwar explizit bei diesem Beispiel verboten, aber in der Praxis ist das nicht immer möglich. Und wie wir weiter oben schon festgehalten haben, bietet das UDP Protokoll keine Alternative zum ACK bit.

Natürlich hat diese Art der Unterscheidung auch einen wesentlichen Vorteil. Durch die einfache Umsetzung des Filterns ist es einfach eine Entscheidung über ein Paket zu treffen. Es muss nur jedes einzelne Paket nach den einzelnen Regeln bewertet werden, was sehr ressourcensparend ist und somit auch sehr schnell ist.

2.2 Stateful Packet Filters

Die Stateful Packet Filtering Technologie kann als eine Art Erweiterung des traditionellen Packet filtern gesehen werden. Hier werden die bekannten schwächen aufgegriffen und versucht zu beseitigen. Dazu ist die Idee, dass bei einer Stateful nicht nur das Augenblickliche Paket betrachtet wird sonder vorangegangene Entscheidungen und somit der Entstandene Verkehr abgespeichert ist, natürlich im eingeschränkten Maße. Das heißt, es wird versucht das Hauptaugenmerk eher weg vom einzelnen Paket zu bekommen hin zu einer Sicht die eine ganze Verbindung mit einbezieht. Um dies umzusetzen werden einige Daten über verschiedene Verbindungen abgespeichert.

Source

Adresse

Destination

Adresse

Source

Port

Destination

Port

Timeout

(sek.)

10.1.1.20

10.34.12.11

2341

10.1.1.34

10.22.11.45

32141

Abbildung 4 -Aktive Verbindung Statefule Packet Filter

Diese Tabelle zeigt nun von allen aktiven Verbindungen die nötigen Informationen an.

Durch diese Daten über aktive Verbindungen ist es möglich über eine Paket zu entscheiden und man ist nicht mehr auf das TCP code bit angewiesen. Diese Daten zeigen nun an, dass ein Absender im Netzwerk ein Paket an ein Empfänger geschickt hat, sendet nun dieser die Antwort kann unabhängig von ACK bit entschieden werden, das dies eine autorisierte Antwort ist und Zugang zum gewünschten Empfänger erhält. Dabei beschreibt die Spaltet Timeout innerhalb welcher Zeitspanne eine Antwort erfolgen muss, wobei dieser Wert standardmäßig zwischen 10 und 90 Sekunden liegt.

Durch diese Erweiterung ergeben sich nun verschiedenste positive Möglichkeiten. Wenn ein Angreifer nun versuchen würde ein Paket mit einem gefälschten ACK bit in das Netzwerk zu schleusen würde dies hier auffallen, da keine Daten über eine Initialisierte Verbindung vorhanden sind und somit keine Notwendigkeit für dieses Paket besteht. Ein weiterer positiver Punkt ist die Überwachung von Datenübertragungen über das UDP Protokoll. In diesem Protokoll gibt es keine Möglichkeit zu überprüfen, ob dieses Paket die Antwort auf eine Anfrage aus dem gesicherten Netzwerk ist. Durch die Methode des stateful filtern kann aber auch im UDP diese Unsicherheit geklärt werden. Den auch jedes eingehende UDP Verbindung hat eine vorangegangene Anforderung abgesetzt, welche in der Tabelle der aktuellen Verbindungen aufscheint.

Natürlich hat diese Art der Umsetzung auch einen Nachteil. Da es nötig ist Daten abzuspeichern und jedes Paket mit diesen zusätzlichen Angaben verglichen werden muss, kommt es zu einigem verringerten Datendurchsatz oder es müssen mehr Ressourcen auf diesen Bereich verwendet werden.

Abschließend kann dieser Art des Filterns aber eindeutig der Vorzug gegeben werden, da der Verlust an Geschwindigkeit im Vergleich zu dem zusätzlichen Maß an Sicherheit bei weitem überwiegt. Dementsprechend ist diese Technik auch weit verbreitet und wird häufiger eingesetzt.

2.3 Proxy-Based Firewalls

Die beiden vorangegangen Techniken waren ausschließlich auf die einzelnen Pakete einer Verbindung beschränkt und bezogen ihre Informationen aus dem TCP und IP Layer. Im Vergleich dazu ist die Proxy basierte Anwendung wesentlich höher gelagert. Hier wird die Entscheidung auf Ebene des Application Layers getroffen.

Um dieses Schema der Proxy Firewall und die Kontrolle auf Applikationsebene zu verdeutlichen verwenden wir wieder ein Beispiel aus dem realen Leben. Spät am Abend läutet das Telefon, und meine Freundin hebt ab. Es ist meine Mutter die mit mir sprechen möchte. Da ich aber schon sehr müde bin, habe ich keine Lust mit ihr zu sprechen. Dementsprechend teile ich dies meiner Freundin mit, diese wiederum die Auskunft an meine Mutter weitergibt und ihr sagt, sie solle doch Morgen wieder anrufen. Weiters kann es passieren das ein Telefonverkäufer anruft um etwas zu verkaufen, aber darauf antwortet mein Freundin, dass er sich verwählt habe.

Beide Situationen beschreiben den Umgang mit einem Proxy. In diesem Beispiel ist meine Freundin mein Proxy, ich gebe Informationen an sie weiter und sie wiederum gibt sie nach außen weiter und entscheidet auch für mich ob diese Anfrage erwünscht ist. In diesem Fall werden die Entscheidungen auch auf Applikationsebene entschieden.

Eine Proxy Firewall arbeitet nach genau dem selben Prinzip.

Abbildung 5 - Schema Proxy-based

Der Proxy überprüft dabei nicht jedes einzelne Paket sondern setzt auf der höheren Ebene an. Er erlaubt zum Beispiel eine Interaktion per ftp, wobei er natürlich eine Authentifikation von den Usern anfordert und falls diese fehlt die Verbindung nicht zulässt. Er kann zum einem entscheiden welche User welche Connection öffnen dürfen über diese Authentfikation, er ist aber auch möglich generell einzelne Applikation zu verbieten. Es kann zum Beispiel möglich sein ein Interaktion mittel Telnet zu erlauben aber ein per ftp zu verbieten. Natürlich muss die verwendete Applikation auch die Übertragung mittels eines Proxys unterstützen.

Zusätzlich zu überprüfen ob eine Übertragung erlaubt ist, kann der Proxy auch entscheiden ob die Übertragung dem geforderten Protokoll entspricht und falls nicht diese auch ablehnen. Als Beispiel kann angeführt werden, das ein Web-proxy überprüft ob die Übertragung auf Port 80 den Anforderungen der http Spezifikation auch entspricht.

Weiter Einsatzgebiet für den Proxy sind Performancesteigerungen, dies kann umgesetzt werden durch das cachen von Informationen, welche öfters angefordert werden. Bei einem Proxy, der für Sicherheitskritische Bereiche sollte aber davon Abgesehen werden, da dies zu einem verstärkten Risiko beiträgt.

Die Vor und Nachteile bei einer Proxy-basierten Firewall lassen sich sehr einfach spezifizieren, durch den höheren Level kann eine verstärkte Sicherheit in verschiedenen Bereichen gewährt werden, aber dem gegenüber steht ein verstärkter Einsatz von Rechnerleistung.

2.4 NAT und VPN

NAT (Network Adress Translation) und VPN (Virtual Privat Network) sollen hier nur am Rande Erwähnung finden da sie im engeren Sinne nicht als Firewall angesehen werden können.

2.4.1 Network Adress Translation

Das Grundprinzip das sich dahinter versteckt ist, dass ausgehende Pakete „maskiert“ werden. Normalerweise haben Rechner eine interne IP die einmalig im Netzwerk ist, zusätzlich hat der Server der die Verbindung nach außen herstellt eine IP die im gesamten Netzwerk (Internet) einmalig ist. Will nun ein Rechner, der sich im geschützten Netzwerk befindet ein Paket abschicken wird durch die NAT seine Private IP Adresse mit der des Servers der die Verbindung herstellt überdeckt. Dadurch ist es für Außenstehende nicht möglich direkt an diesem Rechner eine Antwort zu schicken sondern nur über den Server der diese NAT implementiert. Durch diese Technik kann man das „private“ Netzwerk vom öffentlichen abtrennen.

2.4.2 Virtual Privat Netzwerk

Diese Technik wird hauptsächlich dazu eingesetzt um dauerhafte Verbindungen zwischen Rechner über ein unsicheres Netzwerk zu ermöglichen. Grundsätzlich kann man von einem Tunnel sprechen, an dessen beiden Seiten sich ein Rechner befindet, welcher nur Verbindungen von und zum Rechner auf der anderen Seite zulässt. Einsatzgebiete hierfür sind hauptsächlich Firmennetzwerke, deren Ausdehnung so groß ist, dass es sich nicht lohnt eigene Leitungen zu erhalten. Daher wird der gesamte Verkehr zwischen den beiden Bereichen des Firmennetzwerkes über eine VPN realisiert. Somit ist es möglich über eine „sichere“ Leitung durch ein unsicheres Medium hindurch (Internet) beide Teile des Firmennetzwerkes zu verbinden.

2.5 Welche Technik für welche Anforderung

Diese Frage ist nicht immer eindeutig zu beantworten, es soll aber versucht werden zumindest die grundsätzliche Fragestellung zu beantworten.

Als das häufigste Ziel für einen Angriff kann meist der Webserver gesehen werden, diese hat die meiste Verbindung zur Außenwelt. Auch ist deren Adresse für viele bekannt.

Würde man nun den Webserver in das interne Netzwerk einbetet und durch eine Firewall diesen und das gesamte Netzwerk vor Angriffen von außen absichern, für dies zu einen einfachen Problem. Ist der Angreifer erst einmal bis zum Webserver vorgedrungen, steht im sofort das gesamte interne Netzwerk zur Verfügung.

Abbildung 6 - einfache Firewallarchitektur

Im Vergleich dazu hat sich das anlegen einer so genannten DeMilitarized Zone (DMZ) in der Praxis sehr bewährt. Dabei werden Webserver, FTP-Server, DNS und weitere in einem Bereich angesiedelt an deren beiden Seiten sich eine Firewall befindet. Auf der Seite des Internets wird Packet-basiert gefiltert hingegen auf seiten des internen Netzwerkes wird auf eine Proxy basierte Firewall gesetzt

Abbildung 7 - Architektur mit DeMilitarized Zone

Durch diese Zusammenstellung ist es möglich die Vorteile beider Seiten zu nutzen. Und zusätzlich kann ein gelungener Angriff auf dem Webserver (oder anderen) am internen Proxy aufgefangen werden. Dies kann den nötigen Zeitraum bringen, um einen Angreifer zu erkennen und das interne Netzwerk vor Schaden bewaren.

3 Attack Scenarios

3.1 Buffer Overflow Angriffe

“Ulf HÃrnhammar discovered a buffer overflow bug in versions of lftp up to and including 2.6.9. An attacker could..[..]”

Solche oder ähnliche Meldungen bekommt man beinahe täglich zu lesen wenn man bei Security-Mailinglists oder Update-Agenten angemeldet ist. Dass ein Buffer Overflow eine gefährliche Sache ist wissen viele Computerbenutzer schon intuitiv, was aber genau dahinter steht ist aber vielen weiterhin unbekannt. Deshalb wollen wir in unserer Arbeit grob umreißen, wie ein solcher Angriff aussehen kann und dies in Kontext mit Firewalls stellen.

Eine der häufigsten Buffer Overflow Angriffe ist der sog. Stack based Buffer Overflow. Dazu eine Kurze Erklärung was ein Stack ist:

Ein Stack ist eine Art Notizblock für den Computer auf dem wichtige (zu erledigende) Dinge festgehalten werden. Wichtig ist dass dieser Stack nach dem Last in – First out Prinzip arbeitet Dieser Stack unterstützt einerseits die Koordination bei Funktionsaufrufen in Programmen. Ein sog. Buffer ist dann eine globale Variable für diese Funktionen (z.B. für ihre Variablen). Nach Ausführung der Funktion wird der Inhalt dieses Buffers aus Effizienzgründen nicht gelöscht, sondern nur der Zeiger auf diesen geändert. Dieser bekommt den Wert den er hatte bevor er für die eben ausgeführte Funktion herangezogen wurde. Ein Return Pointer der gleich nach diesen nun nicht gelöschten Daten steht sorgt dafür, dass der Rechner mit den Aufgaben mit denen er vor Aufruf der Funktion beschäftigt war fortfährt.

3.1.1 Funktionsweise eines Buffer Overflows

Im Wesentlichen versucht der Angreifer den im Buffer reservierten Speicherbereich für zu „sprengen“. Alles was über die vorgemerkte Speichergröße einer Funktion hinausgeht wird somit im Stack einfach in die folgende Region geschrieben wo eigentlich noch die Daten der zuvor ausgeführten Funktion stehen sollten. Der oben erwähnte Return Pointer fällt dieser Überfüllung ebenfalls zum Opfer und das Programm stürzt ab.

Besser ist es allerdings das Programm nicht einfach Abstürzen zu lassen sondern es dazu zu bringen „Fremdcode“ auszuführen. Der Angreifer wird in diesem Fall den Buffer mit „sinnvoller“ Information überfüllen anstelle des Return Pointers wird er einen neuen Pointer einfügen der wiederum auf einen Speicherbereich zeigt den auch der Angreifer eingefügt hat. In diesem Speicherbereich stehen dann im Idealfall bereits Befehle in Maschinensprache welche vom Prozessor auch gleich freudig interpretiert werden. So könnte dort beispielsweise der Befehl

rm -rf *

stehen was den Angegriffenen sicher weniger freuen sollte. Dies stellt natürlich einen reinen Sabotageakt dar und wird sicher nicht immer funktionieren, da ein Buffer Overflow dem Angreifer nicht automatisch Administratorprivilegien verschafft.

Fazit Buffer Overflows können durch Firewalls nicht ausdrücklich verhindert werden. Ihnen muss schon bei der Programmentwicklung entgegengetreten werden. Dies muss durch fehlerfreies Programmieren und genaue Parameterüberprüfung geschehen.

Firewalls können aber durchaus ihren Teil dazu beitragen die Wahrscheinlichkeit für einen Solchen Angriff gering zu halten. So kann verhindert werden, dass Programme die potentiell anfällig sind für solche Attacken nicht auf Anfragen aus dem Internet oder anderen gefährlichen Netzbereichen reagieren.

3.2 Web Application Attacks – Angriffe übers Web

Mit „Web Application Attacks“ bezeichnet man all jene Angriffe die auf jegliche Dienst abziehlen die übers World Wide Web ablaufen. Diese Art von Attacken wird in letzter Zeit immer häufiger, da die Anzahl der Webanwendungen immer größer wird und durch den steigenden Zeitdruck bei der Entwicklung kommt es vielfach zu leicht ausnutzbaren Schwächen im Sicherheitsbereich.

Anzumerken ist auch das die Verwendung von z.B.: SSL vor solchen Attacken nicht wirklich schützen kann. Wobei SSL an sich als sichere „Transportverschlüsselung“ nach wie vor seine Berechtigung hat.

Eine Firewall kann all die in diesem Kapitel beschriebenen Angriffe nicht abwehren, es kann aber durch die richtige Platzierung des Webservers (in der DMZ mit Firewall davor und danach) in der Netzinfrastruktur das Risiko für die restlichen Rechner im Netz deutlich verringert werden.

3.2.1 Account Harvesting – Zugangsdaten ermitteln

3.2.1.1 Angriffstechnik

Die Technik des „Account Harvesting“ ist eine Technik die durchaus auch schon bei regulären „Nicht-Web-Anwendungen“ verwendet werden konnte.

Das Prinzip von Account Harvesting zielt darauf ab, bei Seiten die eine UserID und ein Passwort zur Benutzerverifikation benötigen, durch durchprobieren von Usernamen und der anschließenden Analyse der Antwortseite der Webseite, herauszufinden welche UserIDs gültig sind und welche nicht.

Zum Beispiel :

Versuch 1:

Angreifer versucht sich mit UserID „aaa“ und Passwort „z“ einzuloggen. (UserID „aaa“ existiert)

Angreifer erhält die Fehlermeldung „wrong password“

Versuch 2:

Angreifer versucht sich mit UserID „aab“ und Passwort „z“ einzologgen. (UserID „aab“ existiert NICHT)

Angreifer erhölt die Fehlermeldung „unknown userID“

à durch die unterschiedlichen Fehlermeldungen kann der Angreifer sofort erkennen das die erste versuchte UserID gültig ist.

3.2.1.2 Verteidigung gegen „Account Harvesting“

Um solche Attacken abzuwehren muss nicht viel Aufwand getrieben werden, es muss nur darauf geachtet werden das sowohl bei ungültiger UserID als auch bei ungültigem Passwort die selbe Fehlermeldung ausgegeben wird. Dabei ist aber auch darauf zu achten das nicht nur die Webseite selbst exakt übereinstimmen sondern auch die eventuell im URL mitübergebenen Parameter übereinstimmen.

3.2.2 Angreifen von „Session tracking“ Mechanismen

Der Mechanismus des „Session tracking“ basiert darauf das jeder Nutzer einer Webanwendung nach der Authentifizierung eine eindeutige SessionID zugeordnet bekommt. Diese dem jeweiligen Nutzer zugeordnete ID wird ab diesem Zeitpunkt bei jeder Anfrage oder Antwort vom Webserver mitübertragen, was entweder durch codierung in den URL oder durch Ablegen von Cookies erfolgt. Eine weitere Möglichkeit wäre es auch die SessionID versteckt bei in der Seite selbst einzubetten, z. B.: in einem hidden Field bei HTML Formularen.

3.2.2.1 Angriffstechnik

Der Angreifer A authentifiziert sich mit den ihm zur Verfügung stehenden Logindaten und erhält vom Server eine SessionID zugewiesen. Wenn es dem Angreifer A jetzt gelingt eine SessionID zu finden die aktuell gerade einem anderen Benutzer B des Systems zugeordnet ist, und er seine Anfragen an den Server mit der SessionID des Benutzers B versieht, wird er für die Webanwendung zu Nutzer B und der Angreifer A kann auf alle Features der Anwendung zugreifen die eigentlich nur für B zugänglich wären.

Das Problem der Angreifers liegt lediglich darin das er eine gültige SessionID herausfinden muss. Dazu wird er sich zuerst unzählige male mit einem ihm bekannten Login anmelden und dabei die jeweils erhaltenen SessionIDs speichern um sie anschließend statistisch zu analysieren und aufgrund dieser Vorhersagen über künftige SessionIDs zu machen.

Das einfügen der SessionID in die Anfrage an den Server stellt dann ja keine Herausforderung mehr dar da Angreifer ja vollen Zugriff auf die lokal vorliegenden Daten hat.

3.2.2.2 Abwehren von „Session Tracking“ Angriffen

Hashen oder signieren der Session Tracking Informationen mittels eines sicheren kryptografischen Verfahrens
Verschlüsseln der in den URL/Cookie/Formular eingebetteten Informationen.
Lang genuge SessionIDs verwenden um zufälliges überlagern zu verhindern
dynamisches ändern der SessionID von Seite zu Seite
Zeitinformation zur SessionID hinzufügen und gemeinsam verschlüsseln

3.2.3 Code Injection – Einschleusen von Fremdcode

Das Prinzip von „Code Injection“ basiert darauf das der Angreifer versucht über spezielle Daten die er der Webanwendung übergibt diese dazu zu bewegen seinen, in den übergebenen Daten enthaltenen Code auszuführen.

3.2.3.1 Angriffstechnik

Der Angreifer versucht dazu überall wo Daten an die Webanwendung übergeben werden, spezielle Zeichen einzugeben um seinen Code einzuschleusen.

Ein Beispiel für so etwas wäre wenn bei einer Webanwendung ein Parameter direkt in das SQL Statement das an den Datenbankserver gesendet wird übernommen wird.

z.B.:

in der Webanwendung ist folgende SQL Abfrage programmiert, wobei die variable „userid_from_the_web direkt aus der vom User gesendeten Abfrage übernommen wird:

SELECT * FROM benutzerdaten WHERE userid=’userid_from_the_web’

Der Angreifer könnte jetzt in folgenen String als userid bei seine Abfrage übergeben:

333’ or userid=’1337’

und würde damit Daten abrufen können die er eigentlich gar nicht sehen dürfte.

Diese Technik ist überall dort anwendbar wo Benutzerdaten ungeprüft in die Anwendung übernommen werden.

3.2.3.2 Schutz gegen Code Injection Angriffe

Der Schutz gegen solche Attacken ist prinzipell relativ einfach, man muss nur beim Entwickeln der Anwendung darauf achten, niemals Daten vom Benutzer ungeprüft zu übernehmen. Bei der Überprüfung müssen alle speziellen Zeichen die in der jeweiligen Programmiersprache vorhanden sind entweder entfernt oder entsprechend auskommentiert werden.

Im Speziellen ist dabei auf folgenden Zeichen zu achten:

Anführungzeichen jeglicher Art (‚ ´, `, “)
Strichpunkte
* und % als Platzhalter
_ und teilweise auch .
Zeichen die auf der Unix-Shell Spezialfunktionen haben: (&\|*?~<>()[]{}$\n\r)

3.3 „Offline“ Attacken

3.3.1 Social Engineering

Hier gibt es einige gute Varianten an einen Benutzeraccount zu gelangen. Der Angreifer

könnte sich beispielsweise in einem Fake-Mail als Systemadministrator ausgeben und User,

die für ihre schlechten Computerkenntnisse bekannt sind, auffordern ihm zu irgendwelchen

Zwecken die Login Daten per Mail zu schicken, oder ihren Login nach seinen Vorgaben zu ändern. Auch könnte er sich als neuer Mitarbeiter oder externer Berater ausgeben der „schnell mal“ an einem Firmencomputer etwas erledigen muss, und deshalb einen Login benötigt. Hauptziel sollten hier Mitarbeiter sein, von denen bekannt ist, dass sie leicht beeinflussbar sind was Computer betrifft.

Nicht zu unterschätzen ist auch, dass „charmante Damen“ mitunter noch leichter an Passwörter u.ä. kommen können, so kann durch den altbewährten „Augenaufschlag“ schnell ein ganzes Sicherheitskonzept ausgehebelt werden.

3.3.2 Dictionary Attacks

Systematisches Durchprobieren von Logindaten führt mit ziemlicher Sicherheit zum Ziel, kann aber teilweise relativ lange dauern. Eine weitere, relativ effektive, Methode kann es sein, bei bekanntem Loginnamen die wahrscheinlichsten Passwörter diese Person betreffen durchzuprobieren, denn nicht wenige Leute haben nach wie vor triviale Passwörter. Geburtsdaten, zweite Vornamen, Loginname oder Namen aus der Familie sind die Varianten die gleich zu Beginn ausprobiert werden sollten.So könnte man für bestimmte User je ein maßgeschneidertes Dictionary erstellen welches unterschiedliche Wörter, diese Person betreffend, kombiniert um schnell ein breites Feld wahrscheinlicher Passwörter abzudecken. Es kann weiters sehr effektiv sein, bei Diensten für die ein User früher angemeldet war, dessen damaliges Passwort zu ermitteln, da viele Benutzer stets nur ihr „altes“ Passwort in neue Accounts übernehmen. Allerdings ergeben sich gerade durch aktuelle Entwicklungen im Sicherheitsbereich neue Probleme für die eingangs beschrieben systematischen Brute Force Attacken. Im Wesentlichen unterscheiden wir drei Hauptprobleme bei dieser Methode:

Automatisiertes Durchprobieren muss sehr schnell hintereinander erfolgen um in angemessener Zeit mit dem richtigen Login zu terminieren. Diese Versuche erzeugen nicht unerhebliche Mengen an Serverlast/Webtraffic was der Angegriffene bemerken könnte.

Bei manchen Anmeldesystemen wird der Login nach einer gewissen Zahl an Fehlversuchen automatisch deaktiviert.

In großen Unternehmen wird vermehrt dazu übergegangen, beim Anmeldeverfahren „Identifikation durch Wissen“(Passwort) um die Komponente „Identifikation durch Besitz“ zu ergänzen. Ein sogenanntes Security Token (siehe [3]) wird von Mitarbeitern mitgeführt und generiert in Abständen von z.B. 60 Sekunden mittels Hashfunktion einen Wert der bei der beim Login zusätzlich angegführt werden muss. Solche Verfahren führen konventionelle Brute Force Attacken ad absurdum. Nur ein Diebstahl des Geräts bzw. ein Ermitteln der Hashfunktion kann bei diesem Verfahren zum Ziel führen.

3.3.3 Dumpster Driving

Hier handelt es sich um das Durchwühlen des Mülls den die Mitarbeiter des Zielsystems produzieren. Dieser Begriff kann jedoch auch weiter gefasst werden, so könnten Pinwände im Zielunternehmen inspiziert werden oder der Arbeitsplatz eines Mitarbeiters nach Notizzetteln mit Logindaten untersucht werden. Vielfach sind Logindaten auch auf Unterseiten von Möbeln oder Geräten z.B. Laptops zu finden. Weiters könnte bei kurzer Abwesenheit eines Mitarbeiters dessen Email Postfach eingesehen bzw. der Inhalt kopiert werden. Auch der oben erwähnte Diebstahl eines Security Tokens bzw. das Beschaffen eines wegen kleiner Mängel ausgeschieden Tokens würde in diese Kategorie passen. Schlussendlich könnte die nähere Umgebung des Aktenvernichters nach Zetteln abgesucht werden die ihrem tödlichen Schicksal knapp entgangen sind, bzw. erst auf ihre Vernichtung warten.

4 Linux iptables Grundwissen

Iptables ist der bekannteste aktuelle Paktetfilter für Linux. Auch wenn die Einbindung in manche aktuelle Distributionen etwas anderes vermuten lässt ist Iptables ein Kernelmodul.

Wie funktioniert dieser Paktetfilter?

Dies möchten wir mit einer kleinen Grafik verdeutlichen:

Abbildung 8 - Iptables Routing im Linux Kernel

4.1 Wie wird Iptables angewendet?

Iptables ist ein Befehl und daher bei den meisten Distributionen unter

/sbin/iptables

zu finden. Wenn der Pfad entsprechend gesetzt ist muss natürlich das /sbin Verzeichnis davor nicht immer angegeben werden.

Dieser Befehl wird also dazu verwendet um das Verhalten der Firewall zu steuern. Natürlich benötigen wir dazu einige Parameter die wir nun kurz vorstellen wollen. Die Reihenfolge dieser Parameter haben wir so gewählt, dass sie grob mit der wie diese nach dem iptables Kommando eingegeben werden einhergeht.

Zunächst rufen wir also iptables auf und können danach aus folgenden Parametern wählen:

-A „Append“ eine neue Regel anhängen.

-D „Delete“ eine Regel entfernen.

-I „Insert“ eine neue Regel einfügen.

-R „Replace“ ersetzt eine Regel.

-X Löscht eine leere Regel

Nach Angabe dieses Parameters können wir nun drei Zustände unterscheiden

INPUT eingehende Pakete

OUTPUT abschickende Pakete

FORWARD Pakete nicht selbst annehmen sondern an eine best Adresse/Interface weiterleiten

PREROUTING

POSTROUTING

Danach können folgende Dinge mit folgenden Parametern spezifiziert werden:

-s „Source“ ermöglicht die Quelladresse der Pakete zu überprüfen/spezifizieren

-sport „Source Port“ selbiges für den Quellport

-d „Destination“ ermöglicht das Zieladresse der Pakete zu überprüfen/spezifizieren

-dport „Destination Port“ selbiges für den Zielport

-i „In-Interface“ Netzwerkkarte über die die Pakete hereinkommen definieren

-o „Out Interface“ detto

-p „Protocol“ ermöglich das Protokoll (z.B. UDP) zu überprüfen/spezifizieren

-m „match“ kann benutzt werden um genauer zu filtern z.B. stateful oder nach mac-Adresse

Nun kann unter Eingabe des Parameters

-j

natürlich noch bestimmt werden was mit Paketen auf die die eben definierten Regeln zutreffen passieren soll. Hier gibt es folgende Optionen nach der Eingabe von –j:

ACCEPT Nimm die Pakete an

DROP Pakete kommentarlos verwerfen

REJECT Wie DROP nur dass der Absender der Pakete ein Antwortpaket erhält

LOG Zeichne auf was mit den Paketen passiert ist

5 Beispielbefehle

Genug der Theorie, wir wollen nun an drei praktischen Beispielen vorführen wie solche Regeln aussehen können.

Aufgabenstellung: Alle TCP-Pakete die auf Port 4662 hereinkommen sollen die Firewall passieren können. Der Iptables-Befehl dafür sieht wie folgt aus.

Abbildung 9 - Beispiel 1

Aufgabenstellung: Alle UDP-Pakete die auf Port 666 hinauswollen sollen kommentarlos abgelehnt werden

Abbildung 10 - Beispiel 2

Aufgabenstellung: Alle Pakete die auf der Netzwerkkarte eth1 hereinkommen sollen sofern die Verbindung bereits steht oder sie von „innen“ angefordert wurde die Firewall passieren können.

Abbildung 11 - Beispiel 3

Bei den Beispielen muss natürlich klar sein, dass die Firewall generell für alles auf DENY geschaltet ist und erst durch Kommandos wie wir sie gerade behandelt haben stückweise nach Bedarf geöffnet wird. Der Befehl für das komplette „Zumachen“ würde übrigens

INPUT DROP

lauten. Nun jedoch zu unserem etwas ausführlicheren Firewall Script in dem wir die gerade kennengelernten Kommandos in vielfacher Ausprägung und Variation wieder finden werden.

6 Firewall Script Beispiel

der aktuelle firewall script die zeilen jeweils kommentiert...

#!/bin/sh

# Beispiel Firewall script für Linux 2.4 mit iptables

# This program is free software; you can redistribute it and/or modify

# it under the terms of the GNU General Public License as published by

# the Free Software Foundation; version 2 of the License.

# This program is distributed in the hope that it will be useful,

# but WITHOUT ANY WARRANTY; without even the implied warranty of

# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

# GNU General Public License for more details.

# You should have received a copy of the GNU General Public License

# along with this program or from the site that you downloaded it

# from; if not, write to the Free Software Foundation, Inc., 59 Temple

# Place, Suite 330, Boston, MA 02111-1307 USA

###########################################################################

# 1. Einstellungen.

###########################################################################

# LAN Konfiguration.

# Definieren der Internen IP der Firewall

# der IP-Addressenbereich für das interne Netz

# die Broadcast Addresse für das LAN

# das Interface zum lokalen LAN

LAN_IP="192.168.0.1"

LAN_IP_RANGE="192.168.0.0/16"

LAN_BCAST_ADRESS="192.168.255.255"

LAN_IFACE="eth1"

###########################################################################

# Localhost Konfiguration.

LO_IFACE="lo"

LO_IP="127.0.0.1"

###########################################################################

# Internet Konfiguration.

INET_IP="194.236.50.155"

INET_IFACE="eth0"

###########################################################################

# wo liegt IPTables?

IPTABLES="/usr/sbin/iptables"

###########################################################################

# die notwenigen Kernel Module laden

# die benötigten Kernel Module laden

/sbin/depmod -a

/sbin/modprobe ip_conntrack

/sbin/modprobe ip_tables

/sbin/modprobe iptable_filter

/sbin/modprobe iptable_mangle

/sbin/modprobe iptable_nat

/sbin/modprobe ipt_LOG

/sbin/modprobe ip_conntrack_irc ports=6661,6662,6663,6664,6665,6666,6667,6668

/sbin/modprobe ip_nat_irc ports=6661,6662,6663,6664,6665,6666,6667,6668

/sbin/modprobe ip_conntrack_ftp # Erlaubt active FTP; requires ip_conntrack

/sbin/modprobe iptable_nat # für NAT benötigt

/sbin/modprobe ip_nat_ftp # erlaubt active FTP via NAT

#/sbin/modprobe ipt_REJECT

#/sbin/modprobe ipt_MASQUERADE

###########################################################################

# alle Einstellungen zu /proc

# IP Forwarding aktivieren, ist unbedingt notwendig, weil standardmaessig

# deaktiviert ist.

echo "1" > /proc/sys/net/ipv4/ip_forward

###########################################################################

# Die eigentlichen Regeln für iptables

# default policies für INPUT, FORWARD and OUTPUT chains setzen

# sollte aus sicherheitsgründen immer auf DROP sein

$IPTABLES -P INPUT DROP

$IPTABLES -P OUTPUT DROP

$IPTABLES -P FORWARD DROP

# Eine eigenen chain für "bad_tcp_packets"

# Verwerfen von "schlechten" TCP Packeten

$IPTABLES -N bad_tcp_packets

$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \

--log-prefix "New not syn:"

$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

# verwerfen von offensichtlich gefälschten IPs

$IPTABLES -A bad_tcp_packets -i $INET_IFACE -s 192.168.0.0/16 -j DROP

$IPTABLES -A bad_tcp_packets -i $INET_IFACE -s 10.0.0.0/8 -j DROP

$IPTABLES -A bad_tcp_packets -i $INET_IFACE -s 172.16.0.0/12 -j DROP

# NAT aktivieren

$IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP

# Verwerfen von "schlechten" TCP Packeten

$IPTABLES -A FORWARD -p tcp -j bad_tcp_packets

# Annehmen der Packet die wir forwarden wollen

$IPTABLES -A FORWARD -i $LAN_IFACE -j ACCEPT

$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG \

--log-level DEBUG --log-prefix "IPT FORWARD packet died: "

# eigen chains für ICMP, TCP und UDP anlegen

$IPTABLES -N icmp_packets

$IPTABLES -N tcp_packets

$IPTABLES -N udpincoming_packets

# die allowed chain für TCP Verbindungen

$IPTABLES -N allowed

$IPTABLES -A allowed -p TCP --syn -j ACCEPT

$IPTABLES -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A allowed -p TCP -j DROP

# ICMP rules

# ICMP echo und Time Exceeded erlaufen (für ping und traceroute)

$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT

$IPTABLES -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT

# TCP rules

# Verbindungen auf SSH von überall aus zulassen event. auch Webserver

$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 22 -j allowed

#$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 80 -j allowed

# UDP ports

# eventuell hereinkommenden DNS traffic zulassen, ist aber wegen --state ESTABLISHED,RELATED nicht mehr notwendig

#$IPTABLES -A udpincoming_packets -p UDP -s 0/0 --source-port 53 -j ACCEPT

##########################

# INPUT chain

# ungültige TCP Packet werden verworfen.

$IPTABLES -A INPUT -p tcp -j bad_tcp_packets

# Regeln für die hereinkommenden Packete aus dem Internet.

# ICMP in die neue Chain icmp_packets .. usw.

$IPTABLES -A INPUT -p ICMP -i $INET_IFACE -j icmp_packets

$IPTABLES -A INPUT -p TCP -i $INET_IFACE -j tcp_packets

$IPTABLES -A INPUT -p UDP -i $INET_IFACE -j udpincoming_packets

# Regeln um den Zugriff vom lokalen Lan zu erlauben, bzw. stateful aus dem Internet

$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -d $LAN_BCAST_ADRESS -j ACCEPT

$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LO_IP -j ACCEPT

$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $LAN_IP -j ACCEPT

$IPTABLES -A INPUT -p ALL -i $LO_IFACE -s $INET_IP -j ACCEPT

$IPTABLES -A INPUT -p ALL -i $LAN_IFACE -s $LAN_IP_RANGE -j ACCEPT

$IPTABLES -A INPUT -p ALL -d $INET_IP -m state --state ESTABLISHED,RELATED \

-j ACCEPT

# alle verworfenen packete loggen, aber nur eingeschänkt um die log files nicht zu überfluten

$IPTABLES -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \

--log-level DEBUG --log-prefix "IPT INPUT packet died: "

###############################

# OUTPUT chain

# ungültige TCP Packet werden verworfen.

$IPTABLES -A OUTPUT -p tcp -j bad_tcp_packets

# OUTPUT rules welche Traffic aus dem LAN in das internet erlauben.

$IPTABLES -A OUTPUT -p ALL -s $LO_IP -j ACCEPT

$IPTABLES -A OUTPUT -p ALL -s $LAN_IP -j ACCEPT

$IPTABLES -A OUTPUT -p ALL -s $INET_IP -j ACCEPT

# so und noch alles loggen was nicht auf obiges zutrifft.

$IPTABLES -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \

--log-level DEBUG --log-prefix "IPT OUTPUT packet died: "

################################### END ##################################

7 Referenzen

[1] Skoudis, Ed: Counter Hack, Prentice Hall 2002

[2] Linux iptables HOWTO, http://www.linuxguruz.com/iptables/howto , (Zugriff 17.12.2003)

[3] Zwicky, Cooper & Chapman, Building Internet Firewalls Second Edition, O’Reilly 2000

8 Abbildungsverzeichnis

Abbildung 1 - Firewall Konzept 3

Abbildung 2 - Angriffszenario. 4

Abbildung 3 - Regel für Standard Packet Filter 5

Abbildung 4 -Aktive Verbindung Statefule Packet Filter 6

Abbildung 5 - Schema Proxy-based. 7

Abbildung 6 - einfache Firewallarchitektur 9

Abbildung 7 - Architektur mit DeMilitarized Zone. 9

Abbildung 8 - Iptables Routing im Linux Kernel 15

Abbildung 9 - Beispiel 1. 16

Abbildung 10 - Beispiel 2. 17

Abbildung 11 - Beispiel 3. 17