Firewalls:

Packet Filtering und Proxy Systeme





- Schriftliche Ausarbeitung -





Proseminar Rechnerkommunikation

WS 2000/2001

Referent: Daniel Nofftz







Inhalt:



1: Einleitung: Firewalls

2: Packet Filtering:
2.1 Einleitung: Gründe, Vor-/Nachteile
2.2 Grundliegende Protokollinformationen: IP,TCP,UDP
2.3 Filtern nach IP-Adressen / Port-Adressen: Grundliegende Filterkonzepte
2.3.1 Filtern nach IP-Adressen
2.3.2 Filtern nach Portadressen
2.3.3 Sonstiges Relevantes
2.4 Beispiel
2.5 Letzte Anmerkungen zum Packet-Filtering

3: Proxys:
3.1 Einleitung: Gründe, Vor-/Nachteile
3.2 Ansätze für die Verbindungsweiterleitung durch eine Proxy
3.3 Unterschiedliche Realisierungsebenen von Proxys
3.4 Anmerkungen
3.5 Beispiele

4: Quellen

1.Einleitung: Firewalls


Was sind Firewalls ?

Firewalls dienen als Schutzmechanismus zwischen zwei Netzen. So wie in manchen Gebäuden Feuerschutzwände und Feuerschutztüren verwendet werden, um das Übergreifen eines Feuers von einem Teil des Gebäudes auf einen anderen zu vermeiden, werden sie zwischen zwei Netzen (z.b. dem Internet und einem internen Netz) eingesetzt, um ungewollte Zugriffe und Übergriffe auf das interne Netz zu verhindern. Idealerweise stellt dabei die Firewall den einzigen Berührungs- und Datenaustauschpunkt zwischen den beiden Netzen dar. Um diesen Zweck zu erfüllen, werden meistens zwei verschiedene Systeme innerhalb einer Firewall eingesetzt: Paketfiltersysteme und Proxysysteme, auf die ich im Laufe dieses Textes näher eingehe.


Was bringen nun Firewalls für die Sicherheit eines Netzes ?

Durch eine Firewall lassen sich drei Wichtige Punkte realisieren:

Sicherheit, Kontrolle und Wachsamkeit.

Man kann Dienste sperren oder sie gewissen Kontrollen und Restriktionen unterziehen, die internen Daten vor Diebstahl und Verlust schützen, Angriffe auf Computersysteme unterbinden, die Nutzung von Diensten mitprotokollieren (hier vor allem: vermeintlich Angriffe, Fehler oder vermeintlich unerlaubte Datentransfers) und vieles mehr.


Da heutige Firewalltechnologien meist nur auf TCP/IP ausgerichtet sind, wird sich meine Abhandlung auf diese Protokollsuite beschränken. Es gibt zwar auch Firewalls die mit anderen Protokollen umgehen können, aber das würde den Rahmen des Referats sprengen.



2. Packet Filtering


2.1 Einleitung:


Was ist ein Paketfilter?

In einfache Worte gefasst, entscheidet ein Paketfilter aufgrund von grundliegenden Informationen über ein Paket (Headerinformationen der einzelnen Protokolle, Netzwerkinterface, ...) und einprogrammierten Regeln, ob ein Paket weitergeleitet wird, oder nicht.


Was bringt das?

Man kann einen Paketfilter an einem zentralen Punkt, nämlich an dem Punkt, wo ein zu schützendes Netz (z.B. das Firmennetz) auf ein Netz trifft, dem man nicht trauen kann (z.B. Internet), einrichten und garantiert damit bereits eine gewissen Schutz aller Rechner im zu schützenden Netz.

Die Vorteile des Ganzen liegen neben der bereits genannten Schutzwirkung für ein gesamtes Netz darin, dass das ganze ohne jegliche Kooperation der User funktioniert; im Endeffekt müssen diese nicht einmal davon wissen. Desweiteren sind die grundliegenden Funktionen für das Bewerkstelligen von Paketfilterung bereits in den meisten anspruchsvollen Routern (z.B. Cisco), wie sie gerade in den Netzen großer Firmen und Institutionen benutzt werden, schon vorhanden und es bietet sich damit an, diese sowieso schon vorhandene Schutzressource auch zu nutzen.


Natürlich bringt das ganze auch Nachteile mit sich. So werden die Daten an sich nicht untersucht, was es unmöglich macht zum Beispiel zwischen harmlosen Daten (wie einer Mail mit Geburtstagsgrüßen) und gefährlichen Daten (wie hochgeheime Konstruktionszeichnungen) zu unterscheiden. Auch kann man über den Paketfiltermechanismus keine Beschränkung der Dienste auf einzelne User erreichen (wie z.B. Herr Mayer darf telnet benutzen, Herr Weber nicht). Dazu kommt noch, dass die Konfiguration der Regeln für die Paketfiltermechanismen meist sehr komplex und unübersichtlich sind, und so oft eine Sicherheitslücke übersehen wird. Die verschiedenen Realisierungen von Paketfiltern bringen zusätzlich meist noch einen unterschiedlichen Syntax der Regeln mit, was das Ganze noch zusätzlich erschweren kann. Zusätzlich ergibt sich daraus das Problem, dass manche Anwendungsprotokolle sich nur sehr schlecht bis gar nicht zur Sicherung durch Paketfiltermechanismen eignen. Hier können dann manchmal zwischengeschaltete Proxysysteme helfen, auf die ich später noch eingehe.

Schließlich bleibt noch zu erwähnen, dass nichts und niemand eine absolute Sicherheit garantieren kann. Nur weil man einen Paketfilter hat, der vermeintlich unerwünschte Pakete aus dem internen Netzwerk heraushält, heißt das nicht, dass man dafür die Sicherheit der einzelnen Rechner im Netzwerk vernachlässigen darf.



2.2 Grundliegende Protokollinformationen: IP,TCP,UDP


Schauen wir uns als erstes den Header eines IP Paketes an (wichtige Felder sind rot hervorgehoben):




-> Anhand des „Protocol“-Feldes wird unterschieden, zu welchem über der IP Schicht liegenden Protokoll das Paket gehört. Wie wir später sehen werden ist es sinnvoll, die Filterregeln nach verschiedenen Protokollen wie TCP,UDP und ICMP zu trennen.


-> Die Source- und Destinationadress erlaubt es, die hereinkommenden Pakete nach Herkunfts- und Zielrechner (bzw. Herkunfts- und Ziel-IP-Adresse) zu filtern, was eine grundliegende Technik ist, auf die ich später noch eingehen werde. (siehe 2.3)


-> Im Options-Feld interessiert eigentlich nur eine einzige Option, und zwar die „source routing“ Option. Normalerweise folgt ein Paket beim Weg durch das Internet den Routingentscheidungen der Router, d.h. jeder Router versucht anhand von Tabellen und/oder Algorithmen den effektivsten Weg für das Paket zu finden. Bei der „source routing“ Option geschieht dies nicht. Hier wird dem Paket vom Absender eine Liste von Wegpunkten mitgegeben, d.h. der Absender entscheidet, welchen Weg das Paket nimmt.

Nehmen wir mal an, ein internes Netz ist über 2 Leitungen mit dem Internet verbunden: eine 2Mbit Standleitung und einer ISDN Standleitung, die aber nur als Backup dient. Der Router vom Provider weiß, dass er alle Pakete die für das Netz des Kunden gedacht sind, über die „dicke“ Leitung schicken soll. Da dies so konfiguriert ist, ist bei dem Kunden auch nur an dem Router, an dem die „dicke“ Leitung ankommt eine Firewall aufgesetzt. Wenn ein Angreifer nun von diesem Umstand weiß, gibt er dem Paket einfach einen Wegplan mit, der das Paket über die ISDN-Leitung zum Ziel bringt. Damit hat er dann das ganze Sicherheitskonzept untertunnelt.


Ansonsten ist noch zu beachten, dass durch den Umstand, das Pakete höherer Protokollebenen im IP-Protokoll fragmentiert (in mehrere IP-Pakete geteilt) werden können, „Datenschnipsel“ nach außen gelangen können. Wird z.B. nur das erste IP-Pakete einer TCP Verbindung abgeblockt (enthält den TCP Header) so kann es sein, dass die restlichen Fragmente ihr Ziel erreichen. Normalerweise sollten dies keine verwendbaren Daten mehr sein, aber wenn jemand genau weiß nach was er sucht, könnten diese Fragmente durchaus wichtige Informationen für ihn enthalten.



Als nächstes schauen wir uns nun den Header eines TCP-Paketes an:




-> Der Source- und der Destinationport sind die Voraussetzung, um bei TCP Verbindungen nach Portnummern zu filtern; was neben dem Filtern nach IP-Adressen die zweite grundliegende Filtermethode ist. Auch hierauf wird später noch genauer eingegangen (siehe 2.3).


-> in dem Flags-Feld ist das ACK-Bit von besonderem Interesse (und eigentlich auch das einzigste für das Packetfiltering interessante Flag). Das ACK-Bit wird bei einer TCP Verbindung (siehe hierzu auch den Vortrag TCP-IP aus dem Proseminar) in Verbindung mit der Acknowledgment Number dazu benutzt, innerhalb einer Verbindung den Erhalt eines vorhergehenden Paketes vom Kommunikationspartner zu bestätigen (Mechanismus um sicherzustellen, dass auch alle Pakete innerhalb einer TCP Verbindung ankommen). Das ACK-Bit gibt dabei an, dass man den Erhalt eines Paketes bestätigt, während die ACK-Number angibt bis zu welchem Paket, innerhalb einer Reihe von gesendeten Paketen, man den Erhalt bestätigt. Dies hat den Nebeneffekt, dass jedes Paket, außer das, welches die TCP-Verbindung einleitet (da es ja die Verbindung einleitet und deshalb kein vorhergehendes Paket existiert, dessen Übertragung man bestätigen kann), das ACK-Bit gesetzt hat.

Nun hat TCP eine nette Eigenart, die vom Packetfiltering-Standpunkt aus sehr praktisch ist: Um eine TCP-Verbindung fehlschlagen zu lassen (abzuweisen), genügt es eben, genau dieses eine erste Paket abzublocken, da es dadurch nicht zu einem Verbindungsaufbau kommen kann; d.h. man hat mit dem nicht gesetzten ACK-Bit eine eindeutige Identifikationsmöglichkeit dieses ersten Paketes und kann dieses damit besonders einfach herausfiltern. Zusätzlich kann man damit auch feststellen von welcher Seite aus eine Verbindung aufgebaut wird, denn nur aus dieser Richtung kommt ein Paket ohne ACK-Bit -> Wenn man kein Paket ohne ACK-Bit von außen nach innen läßt, kann keiner von außen eine Verbindung nach innen aufbauen. Es bringt auch nichts, wenn ein Angreifer das verbindungsaufnehmende Paket mit einem ACK-Bit ausstatten will, da dieses den Erhalt eines nie gesendeten Paketes quittieren würde, und so vom Zielrechner direkt verworfen werden würde.


Nun kommen wir zu den UDP Paketen:




-> Hier stehen wieder der Source- und Destination Port zur Verfügung um ein Filtern nach Portnummern zu realisieren.


-> Bei UDP liegt das Problem besonders darin, dass es ein verbindungsloses Protokoll ist. Das führt dazu, dass sich ein UDP „Datenaustausch“ (also eine Kommunikation mit hin- und hergeschickten Paketen) nicht so einfach wie eine TCP Verbindung erkennen und abblocken lässt. Es muss für jedes Paket einzeln entschieden werden, ob es weitergeleitet wird oder nicht. (Im Gegensatz zu TCP, wo es ja meist reicht, nur das erste Paket abzublocken, um eine komplette Verbindung fehlschlagen zu lassen.) Daneben lässt sich ebenfalls nicht sicher sagen, ob ein Datenaustausch von außerhalb oder von innerhalb eingeleitet wurde. Das einzige Kriterium hierfür wären die verwendeten Portadressen (siehe Punkt 2.3), und die lassen sich ohne großen Aufwand fälschen.

Dies alles zusammen führt dazu, dass UDP schwieriger und nur mit mehr Aufwand zu filtern ist. Im Allgemeinen muss UDP deswegen auch als weit unsicherer eingestuft werden als TCP. Ein grundliegender Ansatz um UDP so sicher wie möglich zu gestalten, wird weiter unten bei der Diskussion der RPC-Services genannt.


-> Für UDP gibt es noch den Ansatz des sogenannten „dynamic packet filtering“. Hierbei merkt sich der Paketfilter ein und ausgehende UDP Pakete und speichert sie zwischen, um dann neu eintreffende UDP Pakete mit den bereits gesendeten vergleichen zu können. So ergibt sich in bestimmten Grenzen die Möglichkeit zu entscheiden, ob z.B. eingehende Pakete Antworten auf vorher herausgegangene Pakete sind. Zusätzlich lässt sich über solch einen Mechanismus auch ansatzweise klären, ob ein Datenaustausch von innen oder von außen begonnen wurde. Leider besitzen diese Fähigkeit nur wenige Paketfilter.



Viele Paketfiltersysteme bieten desweiteren die Möglichkeit ICMP Pakete zu filtern. Hierbei wird im Gegensatz zu den anderen Protokollen durchaus nach dem Inhalt des Paketes gefiltert, nämlich nach der Art der übermittelten ICMP-Nachricht. Dies ist aber ein sehr zweischneidiges Schwert. Einerseits kann man mit dem Herausfiltern bestimmter ICMP Nachrichten verhindern, dass ein vermeidlicher Gegner z.B. die Struktur des internen Netzes ausspionieren kann, andererseits verhindert man damit auch sinnvolle Anwendungen des ICMP Protokolls.

Ein weiterer Punkt rund ums ICMP Protokoll ist, ob man dem Paketfiler erlauben soll, ICMP-Error Meldungen zurückzusenden, falls eine Verbindung unterbunden wird. Dies hat einerseits den Vorteil, dass klar ist, dass und warum keine Verbindung zustandekommt, andererseits bietet das Ganze womöglich schon wieder mehr Informationen, als man weitergeben will.



2.3 Filtern nach IP-Adressen / Port-Adressen: Grundliegende Filterkonzepte


Im Folgenden werden die Grundliegenden Konzepte zum Paketfiltern besprochen. Dies sind insbesondere das Filtern nach IP-Adressen und das Filtern nach Portnummern.


2.3.1 Filtern nach IP-Adressen:


Das Filtern nach IP-Adressen stellt so ziemlich das einfachste Filterkonzept dar. Hierbei wird die Entscheidung darüber, ob ein Paket weitergeleitet wird oder geblockt wird anhand der im IP-Header enthaltenen Ziel- und Herkunftsadresse gefällt. So kann man für ganze Netze oder für einzelne Rechner explizit Zugriffe erlauben oder verbieten.

Beispiele für Filterregeln nach IP-Adressen wären z.B.:

Alle Pakete die von außen kommen, aber eine interne IP-Adresse vorgeben, sollen abgeblockt werden.

(Eine sehr wichtige Regel, da es sich hierbei entweder um ein vollkommen fehlgeleitetes Paket oder um einen Angriffsversuch handeln muss. Diese Regel sollte man nach Möglichkeit immer in die Paketfilterregeln aufnehmen.)

oder:

Alle Pakete werden verworfen, es sei denn, sie kommen von einem bestimmten Rechner (z.B. einem Proxy-Server).


Die Gefahren dieses Ansatzes liegen hauptsächlich darin begründet, dass eine IP-Adresse ohne Probleme gefälscht werden kann, und man deshalb einer IP-Adresse im schlimmsten Fall nicht mehr trauen kann, als dem Besitzer des Rechners, von dem das Paket (wirklich) kommt. Desweiteren kommt dazu, dass das Filtern nach IP-Adressen eine „ alles oder nicht“ – Lösung ist. Entweder man hat vollen Zugriff auf das interne Netz, oder man hat überhaupt keinen. Es wäre sinnvoll neben der Möglichkeit manchen Rechnern komplett den Zugriff auf das interne Netz zu verbieten, auch den Zugriff für Rechner auf manche Dienste zu blockieren, welche nach diesen Kriterien Zugriff aufs interne Netz hätten. Genau dafür eignet sich nun das Filtern nach Portnummern ...


2.3.1 Filtern nach Portnummern:


Das Filtern nach Portnummern erlaubt es bestimmte Dienste herauszufiltern, indem Verbindungen zu bestimmten Ports/Portnummern unterbunden werden. Viele Dienste die auf einem Rechner verfügbar sind, lassen sich einer bestimmten Portnummer zuordnen. So sind z.B. den meisten Diensten auf einer Unix-Workstation feste Portnummern zugeordnet, welche unter Linux z.B. in /etc/services aufgelistet sind.


Schauen wir nun kurz auf den Vorgang, wie eine Verbindung aufgebaut wird: Die verbindungsaufnehmende Aplikation nimmt eine Portnummer >1023 und sendet von diesem Port aus ein Paket an die Portnummer des Zieldienstes (meist <1023 , da die meisten traditionellen Dienste eine festzugeordnete Portnummer kleiner 1023 haben).

Dies ist unter anderem ein Kriterium, von welcher Seite aus eine Verbindung geöffnet wurde.

Leider ist es kein zuverlässiges Kriterium. Generell gilt, das sich Portadressen, genauso wie IP-Adressen, fälschen lassen! Der Besitzer eines Rechners kann seinen Rechner so manipulieren, dass er zum Aufbau einer Verbindung einen anderen Port z.B. nicht >1023, sondern =23 (telnet) nutzt. Dies kann, wie unten in dem Beispiel zu sehen ist, durchaus eine Filterregel aushebeln.

Andersherum laufen aber auch oft Zieldienste auf einem Port oberhalb von 1023 (wie z.B. X-Windows, oder die RPC-Dienste, auf die wir gleich noch zu sprechen kommen).


-> All dies führt dazu, dass man die Filterregeln in Bezug auf Port Adressen so eng wie möglich halten sollte.


UDP ist besonders problematisch, da es keine Möglichkeit gibt, auf das ACK-Bit zu filtern, und es damit sehr schwierig ist, genau zu unterscheiden, von welcher Seite eine Datenaustausch angefangen wurde.


Ein besonderes Problem bilden beim Filtern nach Portadressen die RPC-Dienste.

Die RPC-Dienste sind kein Protokoll an sich, das separat gefiltert wird, sondern es handelt sich dabei um eine Gruppe von Applikationen, die auf TCP und UDP aufsetzen und den RPC Mechanismus nutzen. Diese Gruppe von Applikationen hat einige Eigenarten, die sie besonders kritisch in Bezug auf Paketfilterung machen. Zuerst einmal haben RPC-Services keine Portnummer fest zugeordnet. Wenn ein Client Programm einen Server über das RPC-Protokoll kontaktieren will, spricht er zuerst den RPC-Portmapper auf dem Zielrechner an, welcher dem Client dann mitteilt, auf welchem Port der von ihm verlangte Dienst läuft. Der Client baut dann genau mit diesem Port einen Datenaustausch auf. Das Problem liegt nun darin, dass diese RPC-Services variable Portnummern benutzen, und sich damit nicht einfach durch das Sperren einer einzigen Portnummer oder eines bestimmten Portnummernbereiches filtern lassen. Man kann zwar den Port auf dem der Portmapper angesprochen wird herausfiltern (der Portmapper hat einen fest zugewiesenen Port <1023), aber durch ein einfaches „scannen“ aller Portnummern >1023 lassen sich eventuell trotzdem laufende RPC-Services finden.

Um das Ganze besonders schlimm zu machen, benutzen einige besonders sicherheitsrelevante Dienste den RPC-Mechanismus (NFS und YP/NIS), die dazu noch das UDP Protokoll benutzen, welches ja ebenfalls nicht besonders gut zu filtern ist.

Der beste Lösungsansatz zum Sichern der RPC-Dienste und UDP im Allgemeinen ist, UDP ganz zu sperren und nur für ein paar, wohldefinierte Dienste zu öffnen.



2.3.3 Sonstiges Relevantes


Ein weiteres wichtiges Kriterium, welches eigentlich bei jedem Paketfilter zur Anwendung kommt, ist, die Pakete nach dem Netzwerkinterface zu unterscheiden, auf welchem sie hereinkommen oder herausgehen. Die Frage hierbei ist: Kommt das Paket auf der Netzwerkkarte an, die den Paketfilter mit dem Internet verbindet, oder kommt es auf der internen Netzwerkkarte/-interface an? So macht es, wie beim Filtern nach IP-Adressen schon erwähnt, sehr viel Sinn, alle von außerhalb ankommenden Pakete (also Pakete die über das externe Netzwerkinterface ankommen) herauszufiltern, die vorgeben eine interne Adresse zu haben.

Auch ist es wichtig zu unterscheiden, auf welchem Netzwerkinterface die Filterregeln aufgesetzt werden. Werden die Filterregeln auf dem externen Interface aufgesetzt, wird der Paketfilter durch die Filterregeln auch selber geschützt. Wird z.B. der Port 23 für telnet auf dem internen Interface gesperrt, kann von außen immernoch ein telnet auf den Paketfilter selber gemacht werden. Setzt man dagegen diese Regel auf dem externen Interface auf, wird der Paketfilter selber auch dadurch geschützt.


Ein weiterer wichtiger Punkt ist, dass bei der Erstellung von Filterregeln versucht werden sollte, zwischen hereingehenden und herausgehenden Verbindungen zu unterscheiden. Gerade TCP bietet über das ACK-Bit eine gute Möglichkeit nach diesem Kriterium zu filtern, und es ist sicherlich oft von Vorteil manche Verbindungen heraus- aber nicht hereinzulassen (wie z.B. telnet oder auch http).

Außerdem sollte man daran denken, das viele Datenaustausche bidirektional sind, d.h. auf herausgehende Pakete kommen auch hereinkommende Antworten, welche ebenfalls durch den Filter durchgelassen werden sollten.


Beim Filtern nach Diensten und IP-Adressen geht man grundsätzlich am besten nach dem „Default-Deny-Ansatz“ vor. -> alle Verbindungen ,die nicht explizit erlaubt wurden, werden abgeblockt. Dies ist bei Weitem sicherer als der umgekehrte Fall!


==> ein gutes Set von Filterregeln berücksichtigt das Filtern nach IP-Adressen, nach Portnummern und nach allen sich anbietenden Zusatzinformationen (wie Netzwerkinterface und ACK-Bit)



2.4 Beispiel


Im Folgenden ein kleines Beispiel, um zu zeigen wie eine kleines Set von Filterregeln nun aussieht. Das Set wird in mehreren Schritten weiterentwickelt, um am Prozess der Weiterentwicklung die Funktion der einzelnen Regeln zu verdeutlichen.

Das Beispiel wird in Form einer einfachen Tabelle gezeigt, wohingegen natürlich die Syntax einer echten Firewallkonfiguration anders aussieht. Da aber nahezu jedes Packet-Filtering System eine eigene Syntax hat, verwende ich diese vereinfachte Form da sie wesentlich überschaubarer und lesbarer ist.


Aufgabe für das Regelset:

Erlaube herausgehende Mails (SMTP-Protokoll, Portnummer 25, nutzt das TCP-Protokoll) und hereinkommende Mails, aber nichts anderes.
















Erstes Beispielset:




Was genau bewirkt nun das Set?

Gehen wir dafür durch die einzelnen Zeilen:

Die erste Zeile erlaubt hereinkommende Verbindungen, die den Port 25 ansprechen, während die zweite Zeile die Antworten zurück an den Sender erlauben. Zur Erinnerung: Der sendende Computer wird für die Verbindung einen willkürlichen Port oberhalb 1023 nehmen und auf den Zielport 25 zugreifen. Die Rückantworten werden dann vom Port 25 des mailempfangenden Rechners an den vom Sender mitgeteilten Port zurückgesendet. Damit erlauben die Regeln 1 und 2 hereinkommende Mails von außerhalb. Die Regeln 3 und 4 realisieren jetzt den gleichen Mechanismus für den Fall, dass ein interner Rechner Mails an einen externen Rechner schicken will.

Die Regel 5 realisiert jetzt wiederum den „Default-Deny“-Ansatz. Sie verbietet alle Verbindungen außer diejenigen, die durch die vorhergehenden Regeln explizit erlaubt wurden.


Leider erfüllen diese Regeln zwar den ersten Teil der Anforderung, denn Mails kommen nun auf jeden Fall durch die Firewall, aber leider erlaubt dieser erste Entwurf weitaus mehr als wir eigentlich wollten, denn durch die Regeln 2 und 4 ist auch jede Verbindung von einem Port >1023 auf einen Port >1023 möglich. Damit währe z.B. durchaus eine Verbindung zum X-Server möglich, der seinerseits als feste Portnummer den Port 6000 zugewiesen bekommen hat.

Also müssen wir unsere Filterregeln soweit erweitern, dass solche Verbindungen abgefangen werden.











Zweites Beispielset:




Da wir nun in den Regeln 1-4 auch die Nummer des Source-Ports berücksichtigen, ist nun solch eine Unterwanderung der Sicherheit wie oben beschrieben nicht mehr möglich. Bei der Regel 2 darf nun auch wirklich nur der SMTP-Dienst Antworten nach außen schicken und bei Regel 4 dürfen jetzt auch nur Antworten von außen, die vom SMTP Dienst gesendet wurden herein.


Das sieht doch nun wirklich sicher aus ... aber nicht sicher genug ...

Der schlaue Angreifer überlegt sich nun folgendes: „Der Paketfilter erkennt den SMTP-Dienst ja nur an seiner Portadresse! Also deaktiviere ich nun den SMTP-Dienst auf meinem Rechner und baue eine Verbindung vom Port 25 meines Rechners zum Port 6000 des Zielrechners auf.“

Dies sieht wiederum für unser jetziges Set von Filterregeln so aus, als käme eine Antwort auf eine herausgehende SMTP-Verbindung an (Regel 4). Die Rückantwort auf unsere „Angriffsverbindung“ dagegen werden nach Regel 2 als Antwort des Zielrechners auf hereinkommende Mails interpretiert.


Um diese Unterwanderung des Regelsets nun herauszufiltern müssen wir noch nach einem weiteren wichtigen Kriterium greifen: dem ACK-Bit (SMTP läuft ja über TCP)















Drittes Beispielset:




Beim zweiten Regelset war der Angriff möglich, weil ein Verbindungsaufbau als eine Antwort auf eine bereits aufgebaute Verbindung getarnt wurde. Das ACK-Bit liefert uns nun aber die Möglichkeit einen Verbindungsaufbau explizit herauszufiltern. In TCP ist nämlich nur das allererste Paket vom Sender zum Empfänger ohne das ACK-Bit. (siehe Erklärungen zum TCP-Header weiter oben) Und ... was das Ganze besonders einfach macht: Es reicht, wie oben bei der Besprechung des TCP-Headers bereits gesagt, zum Unterbinden einer TCP-Verbindung, bereits aus, dieses allererste Paket herauszufiltern.


In unserem Fall bringt das folgendes: Da der Angreifer eine Verbindung aufbaut, aber dabei eine Regel ausnutzt, die eigentlich nur Antwort-Pakete durchlassen soll, verlangen wir einfach, dass all diese Pakete das ACK-Bit gesetzt haben. Damit kann über diese Regeln kein verbindungsaufbauendes Paket mehr hereinkommen, und damit wird auch der Angriff unterbunden.


Nun sollte das Regelset die gestellten Anforderungen komplett erfüllen.



2.5 Letzte Anmerkungen zum Packet-Filtering


Grundsätzlich ist die Reihenfolge, in der die Regeln abgearbeitet werden wichtig. Normalerweise werden sie von oben nach unten abgearbeitet, bis eine Regel passt. Eine Veränderung der Reihenfolge kann komplett andere Ergebnisse nach sich ziehen.


Bsp:

1. vertraue allen Rechnern des CIP-Pools der Informatik an der Uni Trier

2. misstraue allen anderen Rechnern an der Uni Trier

Werden die Regeln nun in der Reihenfolge 1 - 2 interpretiert, passiert alles so wie es soll. Wird aber zuerst die Regel 2 interpretiert, verwirft diese bereits alle Pakete der Uni-Trier, und damit auch die Pakete des CIP-Pools.


Die falsche Reihenfolge von Regeln ist eine weit verbreitete Fehlerquelle, welche zu gravierenden Sicherheitslücken führen kann. Deshalb sollte man hierbei besonders vorsichtig sein und lieber alles nochmal Korrekturlesen.

ACHTUNG! Manche Paketfiltersysteme versuchen die Reihenfolge der Filterregeln zu optimieren, um eine Performancesteigerung zu erreichen. Dies funktioniert aber nicht immer und kann zu unerwünschten Ergebnissen führen.


Und als abschliessenden Tip zum Thema Paketfilterung: Gebrauch von der Protokollierungsfunktion der meisten Paketfiltersysteme machen.




3. Proxy Services


3.1 Einleitung:


Was ist ein Proxy ?

Proxysysteme realisieren einen Internetzugang für ein ganzes Netz oder eine ganze Gruppe von Rechnern über einen einzigen Rechner bzw. Proxy Server (obwohl dieser Begriff auch für die Software, die den Proxydienst realisiert, verwendet wird). Damit dies funktioniert, nimmt entweder der Client direkt Verbindung mit dem Proxy auf oder die Verbindung des Clients wird zum Proxy umgeleitet, welcher dann eine Verbindung zum eigentlichen Ziel aufbaut. (Welche unterschiedlichen Realisierungsstrategien es dafür gibt wird unter 3.2 besprochen.)

Nach außen hin sieht es dann so aus, als ob der Benutzer eine Verbindung vom Proxy aus aufbauen würde, während es nach innen hin im besten Fall so aussieht, als wäre man direkt mit dem Internet verbunden. Idealerweise (aus sicherheitsorientierter Sicht) ist der Weg über den Proxy die einzige Möglichkeit den entsprechenden Dienst zu nutzen.


Der Vorteil des Ganzen liegt primär darin begründet, dass der Internetzugang (oder zumindest der Zugang zu bestimmten Diensten) für ein ganzes Netz, in einem einzelnen Rechner gebündelt wird. Gleichzeitig ist es aber den Benutzern möglich, das Internet (oder den bestimmten Dienst) im idealen Falle genauso zu benutzen, als wären sie direkt damit verbunden.

Darüber hinaus bietet ein Proxy Kontrollfunktionen, die meist über die eines Paketfiltersystemes hinausgehen. So können Kriterien innerhalb des Application-Level-Protocols herangezogen werden, und nicht nur auf Basis von IP und Portnummern gefiltert werden, z.B. gibt es Proxyserver für den WWW Zugriff, welche unerwünschte Elemente wie Popup-Fenster oder Cookies herausfiltern können.

Ein weiterer wichtiger Punkt ist natürlich, dass mit der Kenntnis des Application-Level-Protokolls die Möglichkeiten Verbindungen mitzuprotokollieren erweitert werden.


Ein großes Problem ist, dass es nicht für jeden Dienst einen Proxy gibt. Das kann daran liegen, dass sich manche Dienste einfach durch ihr Kommunikationsprotokoll nicht im Geringsten für Proxys eignen, oder an sich einfach so unsicher sind, dass es gar nichts bringen würde einen Proxy für diesen Dienst zu entwickeln (zu nennen wäre hier z.B. das X11 Protokoll, welches an sich sehr unsicher ist, da es viele Manipulationen erlaubt. Würde man aber all die sicherheitsbedenklichen Protkollteile herausfiltern, würde das Ganze seinen Sinn verlieren, da praktisch keine Funktionalität mehr da wäre.)

Durch die verschiedenen Protokolle, die manche Anwendungen benutzen, ist es auch oft nötig, für verschiedene Anwendungsprotokolle verschiedene Proxys einzusetzen, was zu einem hohen Einrichtungaufwand führt. Desweiteren ist es manchmal nötig, Clientsoftware daran anzupassen, dass sie einen Proxy verwenden soll, bzw. schon angepasste Software zu verwenden.



3.2 Ansätze für die Verbindungsweiterleitung durch eine Proxy


Um eine Verbindung aufzubauen, die über einen Proxy weitervermittelt wird, muss zuerst einmal eine Verbindung zum Proxy aufgenommen werden, damit dieser die tatsächliche Verbindung aufbauen kann. Für diesen Schritt gibt es verschiedene Ansätze:

Zuerst einmal ist es möglich die gleiche Software zu verwenden, wie bei einer Verbindung ohne zwischengeschalteten Proxy. Dies führt in der Regel aber dazu, dass der Benutzer ein anderes Vorgehen benutzen muss, um die Verbindung aufzubauen. Um z.B. eine telnet-Verbindung durch einen Proxy aufzubauen, öffnet der Benutzer eine telnet-Verbindung zum Proxy und gibt an der nun kommenden Eingabeaufforderung die Adresse des tatsächlichen Zielcomputers ein.

Der Nachteil dieses Ansatzes ist klar: Die Benutzer müssen die geänderte Benutzungsweise lernen. Gerade bei größeren Netzen mit unerfahrenen Benutzern ein wahrer Horror für den Systemadministrator.


Ein anderer Ansatz ist es, dass man die verwendete Software anpasst,so dass sie automatisch entsprechende Proxyfunktionen nutzt. Die Bedienungsweise und das Vorgehen zum Aufbauen einer Verbindung bleibt dabei die gleiche wie beim Aufbau einer Verbindung ohne Proxy.

Der Vorteil liegt auf der Hand: Kein Lernaufwand beim Benutzer. Dafür muss allerdings die Software angepasst werden, sofern nicht bereits angepasste Software verfügbar ist, und es entsteht ein erhöhter Konfigurationsaufwand.

Heutzutage besitzen bereits viele Programme die Fähigkeit auf diese Weise mit bestimmten Proxys zusammenzuarbeiten. So kann z.B. der bekannte IRC-Client mIRC mit dem SOCKS-Proxy oder Netscape mit WWW-Proxys oder dem SOCKS-Proxy umgehen, wobei in der Regel oft nur die Eingabe weniger Konfigurationsdaten, wie IP-Adresse des Proxys und Portadresse des Proxys, reicht.


Der neuste Ansatz ist der sogenannte „transparent proxy“-Ansatz. Hierbei arbeitet der Proxy eng mit einem Packetfilter-System zusammen, welches die Fähigkeit besitzt Verbindungen „umzuleiten“. Der Paketfilter leitet Anfragen für bestimmte Dienste einfach zu dem Proxy-Server um, welcher dann entsprechend die Verbindung aufbaut.

Der Vorteil liegt hierbei darin, dass weder die Benutzungsweise, noch die Software an sich verändert werden muss. Also entsteht weder ein erhöhter Konfigurationsaufwand auf den Rechnern noch ein Lernaufwand bei den Benutzern. Dafür entsteht aber zusätzlicher Aufwand bei der Konfiguration des Paketfilters, wobei die Filterregeln noch unübersichtlicher werden. Außerdem besitzt nicht jeder Paketfilter die Möglichkeit Pakete umzuleiten, und nicht jede Proxysoftware kann als „transparent“-Proxy verwendet werden.



3.3 Unterschiedliche Realisierungsebenen von Proxys


Neben der Form wie auf Proxys zugegriffen wird, kann man auch noch zwei Realisierungsebenen von Proxys unterscheiden. Ein Proxy kann entweder auf Anwendungsebene arbeiten oder auf Verbindungsebene:


Ein Proxy auf Anwendungsebene kennt das Protokoll der Anwendungsebene und kann dieses, oder wenigstens Teile davon, interpretieren. Dadurch ist es möglich wesentlich sicherere Verbindungen zu erreichen, indem z.B. unsichere Protokollfunktionen herausgefiltert werden. Außerdem ist es möglich, wesentlich genauer bestimmte Aspekte der Verbindungen mitzuprotokollieren. Dafür sind solche Proxys meist nur auf einen bestimmten Dienst oder eine sehr kleine Gruppe von Diensten beschränkt, was dazu führt, dass man für nahezu jeden Dienst einen eigenen Proxy benötigt.

Wegen dieser Beschränkung nennt man diese Form von Proxys auch spezialisierte Proxys.


Ein Proxy auf Verbindungsebene versteht das Protokoll der Anwendungsebene in der Regel nicht und fungiert nur als „Vermittlungsstation“ (-> leitet die Pakete an den Zielserver und leitet die Antworten zurück zum Client). Der Vorteil dieses Ansatzes liegt darin, dass meist auf einen Schlag eine ganze Menge von Applikationen und Diensten unterstützt werden, allerdings auf Kosten der besseren Kontroll-, Filter- und Protokollierungsmöglichkeiten die ein Proxy auf Anwendungsebene bietet (diese liegen dann in etwa bei denen eines Paketfilters). Im Gegensatz zu den spezialisierten Proxys werden Proxys auf Verbindungsebene auch generische Proxys genannt.


Neben diesen beiden Hauptformen, existieren natürlich auch alle möglichen Mischformen der beiden Grundkonzepte, wie spezialisierte Proxys die versuchen mehrere Anwendungsprotkolle auf einmal zu verstehen oder generische Proxys die Teile des Anwendungsprotokolls verstehen.


Proxys die über diese Grundfunktionen hinaus noch weitere Funktionen anbieten, werden als intelligente Proxysysteme bezeichnet. Solche Zusatzfunktionen können z.B. die Fähigkeit zum Zwischenspeichern von Daten beim Zugriff auf das WWW sein (cashing) oder ähnliches. Solche Zusatzfunktionen findet man meistens nur bei spezialisierten Proxys.



3.4 Anmerkungen


Proxys und TCP/UDP:

Proxys für TCP Verbindungen erfordern, wegen der Verbindungsorientiertheit des Protokolls, in der Regel weniger Rechnerkapazität. Umgekehrt benötigen UDP Proxys wesentlich mehr Rechnerkapazität, da UDP verbindungslos ist. Dies liegt daran, dass oft für jede offene Verbindung über einen Proxy, eine separate Instanz des Proxyprogramms gestartet wird. Bei UDP gibt es aber keine Verbindungen, deshalb muss im schlimmsten Fall für jedes einzelne Pakete eine Proxyinstanz gestartet werden, während bei TCP eine Instanz für jede Verbindung gestartet wird, und diese dann für alle Pakete dieser Verbindung sorge trägt.


Proxydienste nach außen anbieten:

Es ist durchaus möglich einen Proxy aufzusetzen der als Vermittler von Verbindungen von außen nach innen dient. Dies kann viele Gründe haben: Restriktion des Zugriffs auf das interne Netz, Sicherung des internen Netzwerkes, Hochverfügbarkeit durch redundante Systeme mit dem Proxy als Umschalter zwischen verschiedenen Zielservern, usw ...



3.5 Beispiele


Zum Schluss noch kurz zwei Beispiele aus dem großen Angebot von Proxys:


Squid:

Squid ist ein sehr verbreiteter, spezialisierter Proxy für WWW-Verbindungen.

Er arbeitet auf Anwendungsebene und bietet z.B. als zusätzliche Funktion die Möglichkeit Webdokumente und Dateien zwischenzuspeichern, damit sie, falls sie in naher Zukunft nocheinmal aufgerufen werden, nicht erst aus dem Internet geladen werden müssen, sondern direkt vom Proxy zu Verfügung gestellt werden können.

Die Fähigkeit WWW-Proxys zu benutzen ist heutzutage nahezu in jedem Browser bereits vorhanden.


SOCKS:

SOCKS ist ein Proxy auf Verbindungsebene und bietet als generischer Proxy Unterstützung für eine Vielzahl von Programmen. Damit Programme mit SOCKS zusammenarbeiten können, müssen sie speziell modifiziert werden. Hierfür steht eine Programmbibliothek zur Verfügung, welche Programmen mit wenig Programmieraufwand die Fähigkeit verleiht, SOCKS als Proxy zu benutzen. SOCKS ist recht weit verbreitet und wird ebenfalls von vielen Programmen unterstützt. (wie z.B. Netscape oder mIRC).



4. Quellen


Die Hauptquelle meines Referates war das Buch:

„Building Internet Firewalls“

D. Brent Chapman, Elizabeth D. Zwicky

O`Reilly Verlag

erschienen: 1995

Das Hauptaugenmerk lag dabei auf den Kapiteln 6 und 7 (Seite 131 bis 206).

Das Buch ist gerade in einer neu überarbeiteten Fassung erschienen, welche mir aber nicht zur Verfügung stand.


Neben diesem Buch habe ich auch ein paar Informationen (alles rund um das Thema transparent-proxying) in dem Firewall-HOWTO von Mark Grennan (Stand: 26.2.2000) und dem IPCHAINS-HOWTO von Paul Russell (Stand 12.3.1999) gefunden. Beide finden sich auf den Seiten des Linux Documentation Projects www.linuxdoc.com .


13