Datensicherung im Unternehmen - Netzwerksicherheit mit Firewalltechnologie


Diplomarbeit, 2003

65 Seiten, Note: 1,4


Leseprobe


Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1. Einleitung

2. Netzwerke
2.1 Entstehung von TCP/IP
2.2 ISO/OSI-Referenzmodell
2.3 TCP/IP-Protokoll
2.3.1 Internet Protocol
2.3.2 Internet Control Message Protocol
2.3.3 Transport Control Protocol
2.3.4 User Datagram Protocol

3. Sicherheitsprobleme
3.1 Sicherheitsprobleme IP-Protokoll
3.1.1 Spoofing-Angriff
3.1.2 Denial-of-Service Attacke
3.1.3 Routing Angriffe
3.2 Sicherheitsprobleme ICMP-Protokoll
3.2.1 Angriffe zum Verbindungsabbruch
3.2.2 Gezielte Umleitung von Paketen
3.2.3 Dedizierte Denial-of-Service Attacken
3.3 Sicherheitsprobleme des TCP- und UDP-Protokoll
3.3.1 TCP Sequenznummerangriff
3.3.2 Session Hijacking
3.4 Sicherheitsprobleme des Domain Name Service
3.4.1 DNS-Spoofing
3.5 Sicherheitsprobleme des World Wide Web
3.5.1 Cookies
3.5.2 Common Gateway Interface
3.6 Electronic Mail
3.7 File Transfer Protokoll
3.8 Telnet Dienst

4. Gefahren für das Netzwerk
4.1 Angreifer
4.2 Angriffe
4.2.1 Externe Angriffe
4.2.2 Interne Angriffe
4.3 Gefahren durch Software und Programme
4.3.1 Viren
4.3.2 Würmer
4.3.3 Trojanische Pferde
4.4 Sicherheitsziele und -anforderungen
4.4.1 Vertraulichkeit
4.4.2 Verfügbarkeit
4.4.3 Integrität
4.4.4 Der „gute“ Ruf

5. Firewall
5.1 Allgemeine Grundlagen
5.2 Ziele einer Firewall
5.3 Funktion
5.3.1 Paketfilter
5.3.1.1 Vor- und Nachteile
5.3.2 Proxies
5.3.2.1 Vor- und Nachteile
5.3.3 Network Address Translation
5.3.3.1 Vor- und Nachteile

6. Firewallkonzepte
6.1 Zentrale Firewall
6.2 Kaskadierte Firewall
6.3 Perimeter Netzwerk
6.4 Screening Router
6.5 Dual-Homed Host
6.6 Bastion Host
6.7 Screened Host
6.8 Screened Subnet

7. Fazit

Anhang

A Abbildungen

B Firewall Hardware

C Firewall Software

D Quellenverzeichnis

Bestätigung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung Beschreibung

1 ISO/OSI-Referenzmodell

2 Gegenüberstellung von OSI und TCP/IP mit seinen Protokollen

3 Format eines IP-Pakets

4 ICMP-Protokoll-Fehlermeldungen

5 Beispiele für Port-Belegung

6 3-Phasen-Handshake

7 TCP-Sequenznummernangriff

8 DNS-Spoofing Angriff

9 CGI-Skript

10 Grundprinzip einer Firewall

11 Funktion eines Proxy

12 Network Address Translation

13 Zentrale Firewall (Choke Point)

14 Perimeter Netzwerk mit einer Firewall

15 Perimeter Netzwerk mit mehreren Firewalls

16 Dual-Homed Host

17 Bastion Host

18 Screened Subnet

1. Einleitung

„Industriespionage mal anders: Kein Einbruch in der Nacht, keine bestochenen Mitarbeiter, die geheime Daten an die Konkurrenz verkaufen, sondern ein modifizierter Wurm, der Festplatten automatisch nach sensiblen Daten durchforscht und diese an seinen Absender schickt.“[1]

Im Februar 2003 berichtete die PC WELT, dass gezielte Industriespionage mit Hilfe von Wurm-Programmen durchgeführt wurde. Ebenso zeigt das Bundeskriminalamt in der Polizeilichen Kriminalstatistik der Bundesrepublik Deutschland für das Jahr 2002[2], dass im Jahr 202 im Bereich Computerkriminalität 57.488 Straften erfasst wurden. Ausdrücklich wir genannt, das der Bereich Datenveränderung/Computersabotage stark zugenommen hat (über 50 % im Vergleich zu 2001).

Diese Tatsachen müssen Firmen bzw. deren Verantwortlichen den Anstoß geben um sich um die Sicherheit ihres eigenen Netzwerkes Gedanken zu machen. Kein Unternehmen kann es sich erlauben ihre wichtigsten Daten und/oder ihre IT-basierende Produktionsumgebung zu verlieren. Ein Verlust der Kontrolle über die eigenen Systeme können unternehmen in den Ruin treiben, sie wären den Angreifern bis aufs letzte ausgeliefert.

Aus diesen Gründen gibt es zum Schutz der Netzwerke sogenannte Firewalls, die in dieser Arbeit behandelt werden.

2. Netzwerke

In diesem Kapitel beschreibe ich die Entstehung von Netzwerken und das Internet, der Quelle der meisten Gefahren und Angriffe auf eine lokales Netzwerk. Ebenso beschreibe ich die Funktion der gängigsten Protokolle, die zum Verständnis der auf ein Netzwerk ausgehenden Gefahren dienen. Diese Beschreibungen dienen auch dazu die Funktionen und Maßnahmen der Firewall zu verstehen.

„Unter einem Rechnernetz (engl.: computer network) verstehen wir ein räumlich verteiltes System von Rechner(n), Steuereinheit(en) und peripheren Geräten, die durch Datenübertragungseinrichtungen und -wege miteinander verbunden sind. Die Begriffe Rechnernetz, Netz und Netzwerk sind nicht klar voneinander abgrenzbar und werden synonym verwendet.“[3]

In der Anfangszeit der Netzwerke, welche damals hauptsächlich von großen Bildungseinrichtungen und dem Militär genutzt wurden, bestanden diese meist aus einem zentralen Großrechner und einer Anzahl von Peripheriegeräten, die sternförmig angeschlossen waren. Alle Transaktionen wurden auf dem Großrechner durchgeführt. Aber als die Anforderungen an diese Systeme immer weiter angestiegen sind, wurden in den 70er Jahren, die heute am häufigsten verbreitete Form der Computernetzwerke, die Client-Server-Architektur erschaffen. Die Entwicklung wurde durch einen extremen Preisverfall auf dem Computermarkt beschleunigt und so der Netzwerksektor auch für den privaten Haushalt geöffnet.[4]

2.1 Entstehung von TCP/IP

Die in der Praxis am häufigsten vorkommenden Netzwerke, die Client-Server-Netzwerke sind meist Netzwerke mit TCP/IP-Architektur. Ebenso ist das größte öffentliche Netzwerk, das Internet, auch auf TCP/IP-Architektur basierend.

Im Jahr 1969 wurde ein Projekt der DARPA (Defense Advanced Projects Research Agency) unter dem Namen ARPANET (Advanced Research Project Agency Network) ins Leben gerufen, was der Vorgänger des heutigen Internet ist. In erster Linie stellte das ARPANET Hochgeschwindigkeitsverbindungen zwischen wichtigen Rechnern der öffentlichen Einrichtungen und Bildungs- und Forschungseinrichtungen zur Verfügung. In diesem Netzwerk konnten seine Benutzer Daten von Rechner zu Rechner übertragen und Mails versenden. Während des Projekts stelle sich heraus, dass es die Möglichkeit gibt beliebige Netzwerke miteinander zu verbinden. In den 70er Jahren mündete dieses Projekt in der Schaffung des TCP/IP-Standards. Damit TCP/IP in das BSD-Unix-System implementiert und dafür entwickelt werden konnte, subventionierte die DARPA die Gründung der Firma Bolt Beranek and Newman Inc. (BNN), Ab Januar 1983 arbeiteten dann alle an das ARPANET angeschlossenen Rechner mit TCP/IP.[5]

2.2 ISO/OSI-Referenzmodell

Um Nachrichten miteinander austauschen zu können müssen Sender und Empfänger nach einen festgelegtem Protokoll Daten transformieren können.

Hierfür wird das ISO/OSI-Referenzmodell (siehe Abbildung 1) verwendet. Es besteht aus sieben Schichten, jede dieser Schichten hat zur Aufgabe nachrichten der darüber liegenden Schicht entgegenzunehmen und mit Hilfe der Dienste der darunter liegenden Schicht weiter zu leiten. Jede Schicht fügt in Form eines Headers ihre Steuerinformation an die Nachricht an. Ist über ein physikalisches Medium übertragen worden, empfängt die Bitübertragungsschicht des Empfängers die Daten und entfernt vor der Weitergabe in die nächst höhere Schicht die Steuerdaten ihrer Partnerschicht des Senders. Werden Daten zwischen zwei nicht benachbarten Endsystemen weitervermittelt, werden nur die Protokolle der Schichten 1 – 3 benötigt. Der Datenaustausch nicht direkt verbundener Endsysteme werden über Vermittlungsrechner, beispielweise mit Routern oder Gateways durchgeführt.[6] Die sieben Schichten des ISO/OSI-Referenzmodell:[7] Die ersten vier Schichten werden dem Transportsystem, die nächsten drei Schichten dem Anwendungssystem zugeordnet.

- Bitübertragungssicht (physical layer): es werden alle physikalisch-technischen Eigenschaften der Übertragungsmedien zwischen den verschiedenen End- bzw. Transitsystemen festgelegt.
- Sicherungssicht (data link layer): sichert die Bitübertragungssicht gegen Übertragungsfehler auf Übertragungsteilstrecken ab. Es wird aus einen potentiell fehlerbehafteten Kommunikationskanal einen für die Anwendungsinstanzen fehlerfreier Übertragungsweg erzeugt.
- Vermittlungssicht (network layer): hier werden die Zielsysteme über mehrer Transitsysteme hinweg adressiert, ebenso die Wegsteuerung der Nachrichten durch das Netz, ebenso wird die Flusskontrolle zwischen End- und Transitsystemen geregelt, was eine Überlastung der Übertragungswege und Rechner verhindert und eine gerechte Verteilung der Bandbreite ermöglicht.
- Transportschicht (transport layer): stellt den Anwendungsinstanzen die mit Hilfe der unteren drei Schichten hergestellten Endsystemverbinden bereit.
- Kommunikationssteuerungsschicht (session layer): es werden Sprachmittel zur Steuerung von Kommunikationsbeziehungen, d.h. Sitzungen bzw. Sessions, die aufgebaut, nach einer durch das Transportsystem verursachten Unterbrechung wieder aufgenommen und geordnet abgebaut werden können, zur Verfügung gestellt.
- Datendarstellungssicht (presentation layer): hier haben Anwendungsinstanzen die Möglichkeit Vereinbarungen über die Datenstruktur für den Datentransfer auszuhandeln.
- Anwendungsschicht (application layer): es werden die anwendungsspezifischen Funktionen einer Kommunikation vereinbart, es wird der inhaltsbezogene Aspekt berücksichtigt.

2.3 TCP/IP-Protokoll

TCP/IP ist kein eigenständiges Protokoll (siehe Abbildung 2), sondern es besteht aus eine Menge von Protokollen. Von jedem Protokoll wird ein bestimmter Dienst ausgeführt.[8] Im TCP/IP-Protokoll wirken das Internet Protocol (IP), das Internet Control Message Protocol (ICMP), das Transmission Control Protocol (TCP) und das User Datagram Protocol (UDP) zur Kommunikation mit.

2.3.1 Internet Protocol

Das Internet Protocol (IP) übernimmt die Aufgaben der Netzwerkschicht. Der bereitgestellte, unzuverlässige Dienst ist paketvermittelt und verbindungslos. Die Datenpakete werden zum Zielsystem geroutet, dabei können mehrere Vermittlungsrechner durchlaufen werden. Die größte mögliche IP-Paketlänge beträgt 65.535 Bytes, aber je nach Netzwerkinfrastruktur können diese IP-Pakete in kleinere Fragmente aufgeteilt werden, so ist beispielsweise im Ethernet die Paketgröße auf 1.500 Bytes beschränkt. Jedes der IP-Pakete besitzt seinen eigenen IP-Header und eine Teildatenmenge. Vom IP-Protokoll wird nicht gewährleistet, dass gesendete Pakete bzw. Fragmente vollständig, in der gesendeten Reihenfolge oder überhaupt beim Empfänger ankommen. Jedes IP-Paket muss für eine richtige Vermittlung über Sender und Empfänger inne haben, hierbei handelt es sich auf IP-Ebene um Rechner, welche mittels einer IP-Adresse identifiziert werden. Das IP-Paket besteht aus unterschiedlichen Feldern (siehe Abbildung 3), die grob zwischen Header und Nutzdaten unterschieden werden können. Die bei einem Angriff am häufigsten betroffenen Felder im IP-Header sind Fragment-Offset, Flags, Identifikation, Sende-Adresse, Empfangs-Adresse und IP-Optionen.

- In Identifikation, Flags und Fragment-Offset werden bei zerlegten IP-Paketen die Informationen zum zusammensetzen gespeichert.
- Sende-Adresse und Empfangsadresse enthalten die IP-Adressen der kommunizierenden Rechner.
- IP-Optionen können zusätzliche Funktionen erfüllen, die relevantesten Optionen sind Loose Source Routing und Strict Source Routing. Mit ihnen wird der Weg des IP-Paketes zum Empfänger bestimmt.[9]

2.3.2 Internet Control Message Protocol

Das Internet Control Message Protokoll (ICMP) ist neben dem IP-Protokoll auf der Vermittlungsschicht (network layer) als Hilfsprotokoll zur Steuerung und Überwachung angesiedelt. Das ICMP-Protokoll tauscht Fehlermeldungen zwischen Rechnern im Netzwerk aus. Die mit Hilfe des IP-Protokolls verschickten Daten können nicht immer an ihrem Ziel ankommen, da auf dem Weg beispielsweise falsch konfigurierte, überlastete und ausgefallenen Rechner und Router stehen könnten. Um diese entstandenen Fehler, die nicht hardwarebasierend gemeldet werden können, wurde das ICMP-Protokoll standardisiert. Ursprünglich sollte das ICMP-Protokoll nur Informationen und Fehlermeldungen zwischen Routern austauschen, so ist es aber heute auf jedem Rechner, der das TCP/IP-Protokoll installiert hat, vorhanden. Die Kommunikation von IP-Software zweier Rechner wird durch das ICMP-Protokoll ermöglicht. Das ICMP-Protokoll ist kein Protokoll zur Fehlerbeseitigung, sondern nur zur Fehlermeldung.[10] Da das ICMP-Protokoll auf dem IP-Protokoll aufbaut, wird es von diesem als Protokoll einer höheren Schicht behandelt. Die Nachrichten des ICMP-Protokoll haben immer einen vollständigen IP-Header, die eigentlichen ICMP-Protokoll Meldungen sind aber im IP-Datenteil untergebracht. ICMP-Meldungen haben unterschiedliche Formate, aber immer drei gemeinsame Felder, welche Typ, Code und 16-Bit Kopf-Prüfsumme sind. Wenn von einem ICMP-Paket eine Fehlerbedingung angezeigt wird, beinhaltet es immer den Kopf und die ersten 64 Bit Nutzdaten des Paketes welches die Ursache des Fehlers war, um die Anwendung feststellen zu können. Der am häufigsten verwandte Dienst des ICMP-Protokoll ist das testen der Erreichbarkeit und Statusabfragen im Netzwerk. Wenn ein System ein Echo-Paket empfängt, muss es eine Echo-Antwort mit allen enthaltenen Nutzdaten senden. Dieses Vorgehen wird mit dem ping-Befehl ausgelöst. Wenn ein Paket nicht weitergeleitet werden kann, werden folgende Fehlehrmeldungen ausgegeben (siehe Abbildung 4):[11]

2.3.3 Transport Control Protocol

Das Transport Control Protocol (TCP) setzt auf dem IP-Protokoll auf und ist ein zuverlässiges, verbindungsorientiertes Protokoll der Transportschicht (transport layer). Aus der Sicht der aufsetzenden Anwendungsprogramme arbeitet es Datenstrom orientiert, den, von den Anwendungen erhaltenen kontinuierlichen Datenstrom wandelt es in Datenpakete um. Wird das TCP-Protokoll von einer Anwendung zum Aufbau einer logischen Verbindung zwischen zwei Endsystemen veranlasst, übergibt die Anwendung die Daten Datenstrom orientiert an die TCP-Ebene. Der Datenstrom wird in TCP-Pakete umgewandelt, und das TCP-Protokoll fügt seinen Header hinzu und leitet diese an die IP-Schicht weiter. Es wird nach dem Datentransport zum Zielrechner überprüft, ob die Datenpakete in richtiger Reihenfolge angekommen sind, diese Kontrolle erfolgt über die Vergabe von Sequenznummern. Das Eintreffen von Paketen wird durch bestätigen von Acknowledgements beim Absender durch den Empfänger durchgeführt. Bei Fehlerfällen werden die Pakete erneut übertragen. Ende zu Ende-Verbindungen können durch das TCP-Protokoll zwischen zwei Endsystemen, einzelnen Prozessen und Diensten hergestellt werden. Um die Endpunkte der unterschiedlichen Dienste zu identifizieren wird das Port-Konzept (siehe Abbildung 5) verwendet. Ein Port ist eine 16-Bit Adresse. Dienste, zu welchen eine Verbindung aufgebaut werden soll, werden an einen Port gebunden. Der, an einen Dienst gebundene Dienstprozess hat die Aufgabe an dem verbundenen Port auf eingehende Nachrichten zu lauschen und diese zu bearbeiten. Portmapper stehen auf der Anwendungsebene zur Verfügung, welche die Realisierung der Zuteilung von Port-Adressen durchführen. Allgemein bekannte Netzdienste besitzen eine eindeutige Portnummer. Portadressen £ 256 bezeichnet man als well-known-Ports. Unix bezeichnet die Ports 0 bis 1023 als trusted ports. Von diesen Ports dürfen nur mit Supervisor-Rechten ausgeführte Programme Nachrichten empfangen und Dienste an binden, so soll ein Zugriff von beliebigen Usern auf privilegierte Informationen verhindert werden.[12] Der Aufbau von logischen Verbindungen zwischen Ports auf den beteiligten Endsystemen wird von der TCP-Schicht unterstützt. Daher enthält jedes TCP-Paket die 16-Bit Portadresse des Sende- und Empfangsport. Jedes Paket erhält außerdem eine 32-Bit Sequenznummer, die nach TCP-Spezifikationen bei Verbindungsaufbau mit einem zufälligen Wert initialisiert und dann fortlaufend inkrementiert wird, um die richtige Reihenfolge und zuverlässige Übertragung zu kontrollieren. Durch zurücksenden eines eigenen Paketes, welches eine Acknowledgenummer, die um 1 erhöhte Sequenznummer des Bytes ist, welches der Empfänger als letztes erfolgreich empfangen hat, wird der Eingang eines Paketes bestätigt. Mit dem 3-Phasen Handshake Protokoll (siehe Abbildung 6) wird ein TCP-Verbindungsaufbau zwischen zwei Maschinen durchgeführt.[13]

- Phase 1: es erfolgt ein Connection Request von einem Prozess von Rechner A, er sendet ein Paket mit Empfänger-IP und -Port, ebenso wird eine Sequenznummer Seq C erstellt und das Acknowledge-Bit gelöscht. Lauscht die Zielmaschine an diesem Port wird das TCP-Paket zugestellt.
- Phase 2: der Empfang des Paketes wird durch das Setzen des Acknowledge-Bits quittiert, das Antwortpaket wird von Rechner B mit einer neu generierten Sequenznummer Seq S versehen.
- Phase 3: von Rechner A wird die Sequenznummer Seq S bestätigt.

2.3.4 User Datagram Protocol

Das verbindungslose User Datagram Protocol (UDP) nutzt die Fähigkeiten des IP-Protokolls erweitert mit der Möglichkeit zur Abwicklung von Kommunikation zwischen Ports oder den verbundenen Prozessen. Beim UDP-Protokoll werden die eintreffenden Pakete nicht quittiert, Paketverluste werden nicht erkannt, ebenso kann die korrekte Reihenfolge der Pakete nicht überprüft werden. Nur mit Maßnahmen aus der Anwendungsebene kann diesem verhalten entgegen gewirkt werden.[14] Die Übertragung von Programmen ist für das UDP-Protokoll nicht sinnvoll, da keine sichere und kontrollierte Übertragung stattfindet, es wird aber meist für Übertragungen mit dem Real-Time-Protokoll oder bei Übertragungen im lokalen Netzwerk genutzt, da hier Übertragungsfehler keine Rolle spielen oder aufgrund kurze Wege im LAN keine fehler entstehen. Hier kann das UDP-Protokoll seinen Geschwindigkeitsvorteil gegenüber dem TCP-Protokoll ausnutzen.[15]

3. Sicherheitsprobleme

Netzwerkprotokolle und Dienste sind Bedrohungen bezüglich ihrer Integrität, Vertraulichkeit, Verbindlichkeit, Verfügbarkeit und Authentizität ausgesetzt. Im folgenden Kapitel möchte ich diverse Sicherheitsprobleme unterschiedlicher Protokolle und Dienste beschreiben. Allerdings auf Grund der hohen Anzahl der Protokolle und Dienste werde ich nicht alle, sondern nur eine Auswahl bearbeiten. Die beschriebenen Sicherheitsprobleme geben einen Einblick mit welchen, zum Teil einfachen, Mitteln die Möglichkeit geboten wird in fremde Netze und Rechner einzudringen oder diese zu missbrauchen. Gegen diese Sicherheitsprobleme soll eine Firewall schützen.

3.1 Sicherheitsprobleme IP-Protokoll

Auf alle Kommunikationsverbindungen werden keinerlei Daten eines IP-Paketes, also weder Nutzdaten, noch der IP-Header verschlüsselt, sie liegen im Klartext vor. Die Pakete haben dadurch keinen Schutz vor unbefugtem Lesen und ermöglichen Verkehrsflussanalysen, wobei anhand von Sende- und Empfangsadressen Zugriffs- und Kommunikationsprofile erstellt werden können. Dem Empfänger eines IP-Paketes ist es nicht möglich durch Überprüfungsmaßnahmen unautorisierte Modifikationen und folglich Angriffe abzuwehren. Durch nicht fälschungssichere IP-Adressen der kommunizierenden können Prozesse und transferierte Daten nicht eindeutig zugeordnet werden, was zur Folge hat, dass IP-basierende Aktionen unverbindlich sind.[16]

3.1.1 Spoofing-Angriff

Ein Unix-Rechner hat in der Datei /etc/host.equiv vom Administrator eine Liste von Rechnern eingetragen, welchen er vertraut, d.h. diese vertrauenswürdigen Rechner können sich ohne Eingabe eines Passwortes, bei gleicher Benutzerkennung, auf dem Rechner einloggen. Ebenso können in der Datei .rhosts vom jeweiligen Benutzer vertrauenswürdige Rechner und Benutzer eingetragen werden. Dieses Verfahren wird in der Unix-Welt Trusted Host Konzept genannt. In der Datei /etc/host.equiv des Rechners „PC01“ ist der Rechnername „PC02“ eingetragen. Bei einem rlogin oder rsh-Aufruf werden die Dateien /etc/host.equiv und .rhosts nach passenden Einträgen durchsucht. Schafft es ein Angreifer dem Zielrechner die Identität eines vertrauenswürdigen Rechners vorzutäuschen, erhält er einen authentifizierungslosen Zugang zum Zielrechner. Der Aufrufer eines Netzdienstes wird über seine IP-Adresse identifiziert und dir r-Dienste vertrauen auf die Richtigkeit der Adressen, so kann der Angreifer nun versuchen die IP-Adresse des „PC02“ in seine IP-Pakete zu platzieren.[17]

3.1.2 Denial-of-Service Attacke

Für die schon seit langen bekannten Denial-of-Service (DoS) Attacken geht meist Adress-Spoofing voraus. Die wahrscheinlich bekanntesten Angriffe waren im Februar 2000 auf Yahoo, Amazon.com und eBay. Durch diese Beispiele wird die Gefährlichkeit von DoS Attacken dargestellt. Bei Dos Angriffen werden Zombierechner, welche beliebige Rechner im Internet sein können verwendet. Diese Rechner werden von Angreifern durch Sicherheitslücken, wie falsche Konfiguration, offene Ports, die nicht von einer Firewall blockiert werden oder durch unsichere Dienste als Administrator kontrolliert. RPC ist ein unsicherer Dienst, mit welchem Befehle in einer RPC-Nachricht vom Befehlsinterpreter des Zielsystems ausgeführt werden, so können Dämonenprozesse installiert werden und auf befehl des Angreifers den DoS Angriff starten. Ist der Angriff erfolgreich, ist die einzige Möglichkeit der Abwehr den Verkehr von Zombie IP-Adressen abzublocken.[18]

- UDP-flood Angriff: basierend auf UDP-Diensten, hier wird vom Angreifer ein mit gefälschter Rücksendeadresse UDP-Paket gesendet, das den Dienst zur Erzeugung von Zeichen „chargen“ mit dem Echo-Dienst des Zombierechners verbindet, dessen Adresse gefälscht ist. Die vom Opfer erzeugten Zeichen werden vom Echo-Dienst wieder zurückgesandt, so entsteht dauerhafter Traffic, welche beide Rechner lähmt.[19]
- SYN-flood Angriff: TCP basierend, durch die Nutzung der Protokollschritte einer TCP-Verbindung wird ein DoS Angriff durchgeführt. Es wird eine große Anzahl von SYN-Paketen mit gefälschter Absenderadresse, welche von nicht existenten Rechnern stammt, an das Opfer gesandt. Das Opfer beendet seine SYNC-ACK Pakete an die falschen Absenderadresse und wartet auf die Bestätigung, dadurch das diese nicht beantwortet werden, füllt sich das Eingangsfenster und so wird das Opfer am weiteren arbeiten gehindert und kann keine Anfragen mehr bearbeiten.[20]
- Smurf-Angriff: hier wird vom Angreifer eine ICMP-Echo-Anfrage an eine Vielzahl von Rechnern gesandt, die eine gefälschte Sendeadresse enthält. Das Opfer erhält nun die Antwort von den antwortenden Rechnern gleichzeitig und das System wird lahmgelegt.[21]

3.1.3 Routing Angriffe

Für Routing Angriffe wird das Routing-Protokoll benutzt, welches die Wege der IP-Pakete im Netz festlegt. Diese Wege lassen sich im Optionsfeld des IP-Paketes[22] ändern. Gewöhnlich ist der Weg eines IP-Paketes aber symmetrisch, d.h. die Antworten nehmen den gleichen Weg zurück vom Zielrechner zum Anfragerechner.

- Script Source Routing: hier müssen die IP-Adressen in der richtigen Reihenfolge in das IP-Paket eingetragen sein, um effektiv angreifen zu können muss der Angreifer die genaue Netzwerkinfrastruktur kennen.[23]
- Loose Source Routing: hier wird ein explizierter Pfad zum Ziel angegeben. So kann der Angreifer seinen Rechner in den Vermittlungspfad aufnehmen und kann beim zurücksenden der Antwort-Pakete beispielsweise Klartext-Passwörter auslesen.[24]
- Routing Information Protocol (RIP): es wird zur Bekanntgabe von Routing Informationen, also von vorgegeben Wegstrecken im Netzwerk eingesetzt, die die Empfänger nicht überprüfen. Der Angreifer wird durch versenden von manipulierten RIP-Paketen eine Station dieser Route. Jetzt kann er die gesendeten Pakete mitlesen und analysieren, bei zusätzlich aktivierter Source Routing kann er auch die Antwortpakete mitlesen.[25]

3.2 Sicherheitsprobleme ICMP-Protokoll

Die Nichterreichbarkeit von Empfängern oder die Aufforderung zum Fragmentieren von zu großen Paketen werden von ICMP-Fehlermeldungen[26] durchgeführt. Die Verfügbarkeit von Verbindungen oder Geräten werden ICMP-Statusmeldungen abgewickelt. Wird von der Netzwerkschicht eines Routers ein Stau in einem Teil des Netzwerkes erkannt, so werden mit dem Teilnetz verbundene Router durch ein ICMP-redirect aufgefordert die in der Nachricht angegebenen Wege zu verfolgen. Die Verursacher eines Staus werden von einer ICMP-source quench Nachricht angeleitet ihren Nachrichtenversand zu senken.[27]

3.2.1 Angriffe zum Verbindungsabbruch

Erhält ein Absender die ICMP-Nachricht destination unreachable, wurde das Datenpaket nicht an die gewünschte Adresse gesendet. Im Paket-Header des ICMP-Paketes sind der Sender- und Empfängerport des nichtvermittelten Paketes enthalten, hieraus erkennt der Sender mittels des angezeigten Fehlers, welche Verbindung abgebrochen werden muss. Existente ältere ICMP-Implementationen sind nicht fähig Portinformationen zu analysieren. Der Absender beendet alle seine Verbindungen, wenn er einen entsprechenden Fehler gemeldet bekommt. So können von Angreifern gefälschte ICMP-Nachrichten den Abbau einer Vielzahl von Internetverbindungen verursachen. Des weiteren kann ein Opfer isoliert werden und vom Angreifer werden dessen Verbindungen zum Spoofing missbraucht.[28]

3.2.2 Gezielte Umleitung von Paketen

Wenn ein Router ein günstigere Route erkannt hat, sendet er eine ICMP-Nachricht redirect heraus. Wenn nicht ausschließlich nach Routing-Tabellen vermittelt wird, kann ein Angreifer mit ICMP-redirect die Vermittlungswege über seinen Rechner leiten und im Gegensatz zu Source Routing, das nur ein Datenpaket betrifft, eine Vielzahl von Paketen seiner Opfer filtern und analysieren. Abhilfe ist nur möglich, wenn Router nur nach ihren festen Routing-Tabellen vermitteln, die nur durch kontrollierte Bedingungen werden können.[29]

3.2.3 Dedizierte Denial-of-Service Attacken

Mit source quench Nachrichten drosselt der Empfänger seine Übertragungsgeschwindigkeit bis er keine dieser Nachrichten mehr erhält. Durch den Versand von synthetischen ICMP-Nachrichten kann so der Datenfluss sogar zum Stillstand gebracht werden. Durch Beobachtung von vermehrt auftretender Nachrichten dieser Art können Gegenmaßnahmen eingeleitet werden. Eine andere dedizierte DoS-Attacke ist die ping-to-death-Attacke. Der Angreifer sendet ein ICMP-Ping Paket mit einer Nutzdatengröße von mindestens 65.510 Byte. Hier wird die maximale IP-Paketgröße überschritten und das Paket wird fragmentiert zum Zielrechner gesandt. Nach dem Zusammensetzten der Fragmente kommt es zu einem Überlauf, der von manchen Netzwerktreibern nicht abgefangen werden kann. Der Überlauf entsteht, weil zusätzlich zu den Nutzdaten auch noch der Ping-Header hinzu kommt und es entsteht eine Paketlänge von mehr als 65.510 Bytes. Durch diesen Überlauf entstehen dann Systemabstürze.[30]

3.3 Sicherheitsprobleme des TCP- und UDP-Protokoll

Das verbindungslose UDP-Protokoll ist oft ein Ziel von Angreifern, das den Empfang von Datenpaketen nicht quittiert und die korrekte Reihenfolge nicht überprüft. So kann der Angreifer Datenpakete unerkannt entfernen oder zusätzlich einschleusen. Die Kommunikationspartner identifizieren und authentifizieren sich beim UDP-Protokoll mit fälschbaren IP-Adressen. Bei dem TCP-Protokoll hat sich der Kommunikationspartner auch noch über das Acknowledgement und die richtige Sequenznummer zu identifizieren. Daher sind UDP-Dienste in größerer Gefahr zum Angriff missbraucht zu werden als FTP-Dienste. Im Gegensatz zu TCP kann bei UDP nicht zwischen dem Verbindungsaufbau und der Kommunikation unterschieden werden, was aber für Paketfilter einer Firewall notwendig ist, um zulässige Verbindungen gewähren zu lassen.[31]

3.3.1 TCP Sequenznummerangriff

Trotz zusätzlicher Überprüfungsmaßnahmen der Identität der Kommunikationspartner sind auch hier Angriffe möglich, dies rührt von Implementierungsschwäche von TCP aus Unix. Die Quittierung eines TCP-Paketes wird durch die Rücksendung des Acknowledgements mit einer inkrementierten Sequenznummer durchgeführt. Um erfolgreich anzugreifen, muss die richtige Sequenznummer bekannt oder richtig erraten worden sein. Hier ist das Problem, dass die Generierung der Sequenznummern nicht, wie in der Spezifikation des TCP-Protokolls gefordert, zufällig, sondern mit einem 32-Bit Zähler erhöht werden, d.h. bei einer neuen Verbindung wird der Zählerstand um 64 erhöht. Hat man Kenntnisse über den aktuellen Zählerstand kann man mit sehr hoher Wahrscheinlichkeit die nächste Sequenznummer bestimmen. Ein Maskierungsangriff funktioniert dann folgendermaßen (siehe Abbildung 7):[32] Der Angreifer X versucht auf dem Server Z eine Verbindung auf einem kritischen Port herzustellen, beispielsweise Port 25 für den Maildienst. Der Server Z antwortet mit einer neu generierten Sequenznummer. Der Angreifer täuscht die Identität seines Opfers C vor und sendet an X an einen sicherheitskritischen Port eine Nachricht zur Etablierung der Verbindung, z. B. mit rlogin an Port 513. Jetzt antwortet Angreifer X wieder, aber an Opfer C. Aus der Vorbereitung erhaltenen Sequenznummer SeqZ kann er nun die Sequenznummer SeqZ’ berechnen und wiederum als C maskiert die Sequenznummer an Z quittieren. So wird dem Rechner Z eine etablierte rlogin-Verbindung zu C vorgetäuscht und der Angreifer kann sich als C auf dem Server Z einloggen. Allerdings muss der Angreifer verhindern, dass Opfer C kein Reset-Paket an Server Z schickt, da von C keine Verbindung zu Z aufgebaut wurde. Dies wird umgangen, da ankommende Nachrichten an Ports in einer Warteschlange puffern und bei Überschreitung der Kapazität weitere ankommende Nachrichten ignoriert werden, so wird kein Reset-Paket versendet. Folglich muss der Angreifer einen Port von Opfer O überfluten und kann dann seinen maskierten Angriff mit Angabe des überfluteten Ports als Empfängerreply von Z starten.

3.3.2 Session Hijacking

Ein Angreifer versucht beim Session Hijacking eine bestehende Verbindung zu übernehmen. Er versucht durch desynchronisieren der Kommunikationspartner unbemerkt an die Stelle eines Partners zu treten und eigene Datenpakete einzuschleusen. Auch hier ist wiedereinmal die geringe Authentifikation der Kommunikationspartner mit korrekten Acknowledgements der Grund der Angriffsmöglichkeit. Um einen Angriff durchführen zu können, werden mit Monitoring-Tools alle übertragenen Datenpakete beobachtet. Die benötige Sequenznummer, die zum Einschleusen eines Paketes erforderlich ist, lässt sich so einfach herausfinden. Die Kommunikationspartner werden durch einfügen von Datenpaketen desynchronisiertem sie verwenden dann eine veraltete Sequenznummer. Der Empfänger der veralteten Information schickt ein Acknowledgement, das sich auf die Sequenznummer des Angriffpaketes bezieht. Der Original-Kommunikationspartner schickt als Antwort auf dieses nicht gültige Pakete eine Fehlerinformation an den Server. In dieser Zeit, in der die Kommunikationspartner desynchron sind, werden laufend Acknowledgementnachrichten ausgelöst, was erhöhte Netzwerklast und Verbindungsunfähigkeit zur Folge hat. Durch Beobachtung des Netzwerkverkehrs kann dieser Situation entgegengewirkt werden. Der Abwehr der Verbindungsübernahme bedarf es weiterer Protokolle wie beispielsweise Secure Socket Layer (SSL). Auf die Funktion von SSL[33] wird im weiteren der Arbeit nicht eingegangen.[34]

3.4 Sicherheitsprobleme des Domain Name Service

Die Aufgabe des verteilten Namendienstes Domain Name Service (DNS) ist es, Namen auf IP-Adressen abzubilden und umgekehrt. Das aus Teilnetzen bestehende Internet ist hierarchisch in Domänen strukturiert. Zweistellige Ländercodes und mehrstellige Kürzel sind Domänen der obersten Ebene, beispielsweise .de für Deutschland, .at für Österreich und .com für Commercial oder .gov für Gouvernement. Allerdings kann man nicht von der logischen Struktur der Domänen auf die physikalische Struktur schließen, d.h. das eine Rechner mit dem Namen server.ricosta.de nicht unbedingt in Donaueschingen platziert sein muss. Für einen Knoten können durch die Flexibilität des DNS mehrere dienstspezifische Namen vergeben werden, für WWW-Seiten www.ricosta.de oder für Datei-Transfer ftp.ricosta.de. Jeder DNS-Server verwaltet einmal die Datenbank der Reverse-Zone, welche die Zuordnung von IP-Adresse zu Domänenname enthält und die Datenbank der Forward-Zone, die Zuordnung von Domänenname zu IP-Adresse. Ein Reverse-Lookup ist die Anfrage eines Domänennamens zu einer IP-Adresse. Beim Design von DNS kommt aber eine Problematik zu tragen, die keine Maßnahmen zur Überprüfung der Konsistenz beider Datenbanken realisiert und fordert. Die Verfügbarkeit wird durch Replikation von unterschiedlichen dezentral verwalteten DNS-Servern erhöht, dennoch hat jede Hierarchiestufe einen primären DNS-Server. Eine am Port 53 des DNS-Server ankommende DNS-Anfrage beantwortet der Server selbst oder sendet sie an einen Server weiter. Eine Antwort erhält der Anfrager vom für den DNS-Namen verantwortlichen DNS-Server. Der Anfrager legt diese Antwort in seinem Cache ab, um bei einer erneuten Anfrage die Antwort direkt liefern zu können. Aus gründen der Effizienz basiert DNS auf dem unzuverlässigem UDP-Protokoll, folglich werden unbeantwortete Anfragen wiederholt. Antworten auf Anfragen für die bereits ein Antwortpaket entgegengenommen wurde, werden ignoriert. Angriffsziele sind DNS-Server daher, da sie stets versuchen die Anfragen aus der lokalen Datenbank und dem Cache zu beantworten.[35]

3.4.1 DNS-Spoofing

Bei DNS-Spoofing (siehe Abbildung 8) wird die Zuordnung von IP-Adresse zu Domänennamen verfälscht. Angreifer X versucht dem Domänennamen ricosta.de mit der IP Adresse 125.125.125.125 seine eigene IP-Adresse 225.225.225.225 zuzuordnen, indem der entsprechende Eintrag in der Reverse-Zonen-Datenbank des DNS-Servers platziert wird. Voraussetzung ist das Rechner Z dem Rechner ricosta.de durch einen Eintrag in der /etc/hosts.equiv-Datei vertraut. Maskiert als ricosta.de kann der Angreifer durch rlogin- oder rsh-Aufruf Zugriff auf den Rechner Z erhalten. Bei diesem Aufruf wird durch den entsprechenden r-Dienst von Rechner Z der Domänenname seines Auftraggebers erfragt, d.h. er fragt nach der IP-Adresse 225.225.225.225 und erhält ricosta.de als Antwort, gibt sich der r-Dienst zufrieden, wird nachgeprüft, ob ricosta.de in der Trusted-Hosts-Datei eingetragen ist. Jetzt hat der Angreifer Zugriff auf den Rechner Z, da er als vertrauenswürdig eingestuft wurde. In neueren Versionen der DNS-Software wird zur Abwehr ein doppelter Reverse-Lookup durchgeführt, d.h. die erhaltene IP-Adresse wird zusätzlich in der Forward-Zonen-Datenbank abgefragt, so kann eine Fälschung erkannt werden. DNS-Software älteren Datums akzeptiert sogar nicht eigens angeforderte Daten und trägt diese in ihren Cache ein. So kann ein Angreifer DNS-Servern falsche Namen einschleusen. Beispielsweise wird die IP-Adresse eines Finanzangebotes verändert und die Anfrager landen auf der Seite des Angreifers, der dort falsche Informationen verbreitet.[36]

[...]


[1] http://www.pcwelt.de/news/viren_bugs/29049/ Stand: 02.06.2003

[2] http://www.bka.de/pks/pks2002/index2.html Stand: 02.06.2003

[3] siehe Hansen, HR (1998): Wirtschaftsinformatik I. Lucius & Lucius Verlag. S. 1029

[4] vgl. Hansen, HR (1998): Wirtschaftsinformatik I. Lucius & Lucius Verlag. S. 1029 ff.

[5] vgl. Siyan, K, Hare, C. (1995): Internet Firewalls & Netzwerksicherheit. SAMS. S. 26 – 27

[6] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 41

[7] vgl. Hansen, H.R. (1998): Wirtschaftsinformatik I. Lucius & Lucius Verlag. S. 1048 ff.

[8] vgl. Siyan, K, Hare, C. (1995): Internet Firewalls & Netzwerksicherheit. S. 27

[9] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 45 ff.

[10] vgl. http://goethe.ira.uka.de/seminare/grk/icmp/ Stand: 06.05.2003

[11] vgl. http://www.tik.ee.ethz.ch/tik/education/lectures/PPS/internet_praktikum/Unterlagen/Handouts_pdf/ICMP.pdf Stand: 06.05.2003

[12] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 48 ff.

[13] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 48 ff.

[14] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 50

[15] vgl. http://goethe.ira.uka.de/seminare/internet/tcp+udp/ Stand: 06.05.2003

[16] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 51 f.

[17] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 51 f.

[18] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 52

[19] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 53

[20] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 53

[21] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 53

[22] siehe Abbildung 3: Format eines IP-Pakets

[23] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 54

[24] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 54

[25] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 55

[26] siehe Abbildung 4: ICMP-Protokoll-Fehlermeldungen

[27] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 55

[28] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 56

[29] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 57

[30] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 56 f.

[31] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 58 f.

[32] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 59 ff.

[33] z.B. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 500

[34] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 61 f.

[35] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 63 ff.

[36] vgl. Eckert, C. (2001): IT-Sicherheit. Oldenbourg. S. 64 f

Ende der Leseprobe aus 65 Seiten

Details

Titel
Datensicherung im Unternehmen - Netzwerksicherheit mit Firewalltechnologie
Hochschule
Duale Hochschule Baden-Württemberg, Villingen-Schwenningen, früher: Berufsakademie Villingen-Schwenningen
Note
1,4
Autor
Jahr
2003
Seiten
65
Katalognummer
V18979
ISBN (eBook)
9783638232159
ISBN (Buch)
9783638700276
Dateigröße
1090 KB
Sprache
Deutsch
Schlagworte
Datensicherung, Unternehmen, Netzwerksicherheit, Firewalltechnologie, Internet, Security, Sicherheit, Firewall, Spoofing, Man in the middle
Arbeit zitieren
Thorsten Schäfer (Autor:in), 2003, Datensicherung im Unternehmen - Netzwerksicherheit mit Firewalltechnologie, München, GRIN Verlag, https://www.grin.com/document/18979

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Datensicherung im Unternehmen - Netzwerksicherheit mit Firewalltechnologie



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden