Sicherheit in vernetzten Systemen - RRZ UniversitÃ¤t Hamburg

Weitere Magazine

Empfehlungen

Info

KAPITEL 1. GRUNDLAGEN: INTERNET-PROTOKOLLE 1.4.5 TCP-Verbindungsabbau Soll die Verbindung zwischen zwei Rechnern wieder abgebaut werden, so sendet der Rechner, der die Verbindung abbauen will, ein Datenpaket, in dem das FIN-Flag (FIN: Finish) gesetzt ist, wie in Abbildung 1.10 gezeigt. Der TCP-Zustandsautomat dieses Rechners befindet sich dann um Zustand FIN-WAIT-1 (siehe 1.6) Derandere Rechner nimmt dieses FIN-Flag zur Kenntnis (sein Zustandsautomat geht in den Zustand CLOSE-WAIT, vgl. 1.6) und sendet ein Datenpaket mit dem ACK-Flag zum Zeichen, daß das Paket mit dem FIN-Flag angekommen ist. Rechner A Rechner B shutdown(s,1) SEQ=x, FLAGS=FIN, ACK SEQ=y, ACK=x+1, FLAGS=ACK SEQ=y, ACK=x+1, FLAGS+ACK, DATA=5 write(...) read(...) SEQ=x+1, ACK=y+5, FLAGS+ACK SEQ=y+5, ACK=x+1, FLAGS=FIN, ACK SEQ=x+1, ACK=y+5, FLAGS=ACK shutdown(s,2) oder close(s) shutdown(s,0) Abbildung 1.10: Abbau einer TCP-Verbindung Das FIN-Flag signalisiert lediglich, daß eine Seite das Senden von Daten beendet hat. Die andere Seite kann weiterhin Daten senden, bis auch sie mit dem FIN-Flag das Ende ihres Datenstroms signalisiert. Erst nachdem beide Seiten jeweils ein Datenpaket mit FIN-Flag gesendet und den Empfang des FIN- Flags der Gegenseite bestätigt haben, ist die Verbindung vollständig abgebaut. Solange befindet sich der TCP-Automat in einem der Zustände FIN-WAIT-1, FIN-WAIT-2, CLOSING oder TIMED-WAIT (siehe Abbildung 1.6). Zum Abbau der Verbindung stehen der Programmiererin zwei Systemaufrufe zur Verfügung. Entweder kann die Verbindung mittels shutdown() einseitig geschlossen werden oder die Verbindung kann mit close() vollständig abgebaut werden. Im letzteren Fall nimmt das aufrufende Programm keine Daten mehr an, ihr Empfang wird jedoch vom Betriebssystem quittiert und die Daten werden verworfen, bis die Gegenseite ihrerseits die Verbindung abbaut. Dem Programm wird beim Aufruf signalisiert, ob sich noch ungelesene Daten in den Puffern des Betriebssystems befinden. Der Aufruf wird in diesem Falle ohne weitere Aktionen abgebrochen, es sei denn, die Programmiererin signalisiert explizit, daß die Daten verworfen werden sollen. 1.5 UDP Im Gegensatz zu TCP ist UDP ein sehr einfach aufgebautes Protokoll. UDP weist daher auch beträchtlich weniger Funktionalität auf als TCP. Der wichtigste Unterschied zu TCP ist, daß UDP ein 16 SS 99, Seminar 18.416: Sicherheit in vernetzten Systemen
1.5. UDP verbindungsloses Protokoll ist. Somit bietet UDP keinerlei Schutz gegen den Verlust von Datenpaketen, gegen Paketduplikate oder die Auslieferung von Paketen in einer anderen Reihenfolge. Der Vorteil liegt in der wesentlich einfacheren Implementierung von UDP, was besonders Systemen mit knappen Ressourcen zugute kommt. Der zweite Grund für die Existenz von UDP liegt darin, daß für Anwendungen, die die volle Funktionalität von TCP nicht benötigen, ein einfaches Protokoll bereitgestellt wird. So besteht die Möglichkeit, die notwendige Funktionalität nur im für die Anwendung benötigten Umfang anzufordern. Die folgende Abbildung 1.11 zeigt schematisch den Aufbau eines UDP-Paketes. 0 16 31 SENDER-PORTNUMMER EMPFÄNGER-PORTNUMMER LÄNGE PRÜFSUMME DATEN Abbildung 1.11: UDP Paketformat (aus [Santi 1998, S. 68]) Das Längenfeld gibt die Länge des UDP-Paketes in Bytes an und das Prüfsummenfeld wird wie bei IP und TCP nur dazu benutzt, die Integrität der Datenfelder im Protokollkopf sicherzustellen, nicht jedoch die der Nutzdaten. Im Gegensatz zu TCP bezieht UDP auch Felder des IP-Kopfes in die Prüfsummenberechnung mit ein, so daß hier von einer „Pseudoprüfsumme“ gesprochen wird. Hier zeigt sich ein weiterer Vorteil von UDP gegenüber TCP, nämlich der wesentlich geringere Overhead, ein UDP-Kopf ist nur acht Byte lang, gegenüber 20 (oder mehr bei Verwendung von Optionen) Byte bei TCP. Analog zu TCP benutzt UDP das Konzept der Portnummern, um die verschiedenen Anwendungen unter einer IP-Adresse anzusprechen. Wie unter TCP werden 16 Bit große Zahlen für die Portnummern des Absenders und Empfängers verwendet. TCP und UDP Portnummern sind nicht identisch, eine unter TCP bereits vergebene Portnummer kann unter UDP nochmals verwendet werden und u.U. eine völlig andere Anwendung identifizieren. 1.5.1 UDP-API Das 4-Tupel (SenderIP, SenderPort, EmpfängerIP, EmpfängerPort) abstrahiert unter UDP nicht eine Verbindung wie unter TCP, sondern eine Kommunikationsbeziehung. Der Unterschied wird aus Sicht der Programmiererin deutlicher, wenn das API der UDP-Sockets betrachtet wird. UDP-Sockets werden wie TCP-Sockets mit dem Aufruf socket() vom Betriebssystem bereitgestellt, lediglich die Parameter sind anders. Der connect() Aufruf kann entfallen, da UDP ein verbindungsloses Protokoll ist. Ebenso kann der accept() Aufruf für Sockets entfallen, die von Servern benutzt werden. Zwingend notwendig bleibt für Server jedoch der Aufruf von bind(), um dem Betriebssystem mitzuteilen, unter welcher IP-Adresse und Portnummer das Programm ansprechbar ist. Die Funktion sendto() kann dazu benutzt werden, auch an verschiedene Empfänger Daten zu versenden, allerdings müssen die Empfängeradressen beim Aufruf übergeben werden. Mit TCP-Sockets ist SS 99, Seminar 18.416: Sicherheit in vernetzten Systemen 17
Seite 1 und 2: Fachbereich Informatik der Universi
Seite 3 und 4: Zusammenfassung Der vorliegende Ban
Seite 5: Vorwort Die Motivation zur Durchfü
Seite 9 und 10: Inhaltsverzeichnis 1 Grundlagen: In
Seite 11 und 12: INHALTSVERZEICHNIS 4 Policy, Vorfal
Seite 13 und 14: INHALTSVERZEICHNIS 8 Hochgeschwindi
Seite 15: INHALTSVERZEICHNIS 11.6Portscanner-
Seite 18 und 19: KAPITEL 1. GRUNDLAGEN: INTERNET-PRO
Seite 36 und 37: LITERATURVERZEICHNIS 1.5 vorgestell
Seite 38 und 39: KAPITEL 2. SICHERHEITSPROBLEME 2.2
Seite 40 und 41: KAPITEL 2. SICHERHEITSPROBLEME daß
Seite 42 und 43: KAPITEL 2. SICHERHEITSPROBLEME Netz
Seite 44 und 45: KAPITEL 2. SICHERHEITSPROBLEME Eine
Seite 46 und 47: KAPITEL 2. SICHERHEITSPROBLEME PING
Seite 48 und 49: KAPITEL 2. SICHERHEITSPROBLEME ein
Seite 50 und 51: KAPITEL 2. SICHERHEITSPROBLEME Clie
Seite 52 und 53: KAPITEL 2. SICHERHEITSPROBLEME Date
Seite 55 und 56: Kapitel 3 Übersicht über Lösungs
Seite 57 und 58: 3.3. PERSONELLE SICHERHEIT Da auch
Seite 59 und 60: 3.4. HOSTSICHERHEIT Diese Schutzma
Seite 61 und 62: 3.4. HOSTSICHERHEIT 3.4.7 Verschlü
Seite 63 und 64: 3.5. NETZWERKSICHERHEIT Eine Firewa
Seite 65 und 66: 3.6. POLICY Proxy-Server können f
Seite 67 und 68: 3.7. ZUSAMMENFASSUNG 3.7 Zusammenfa
Seite 69 und 70: Kapitel 4 Policy, Vorfallsbearbeitu
Seite 71 und 72: 4.2. AUFBAU EINER POLICY Um nun die
Seite 73 und 74: 4.2. AUFBAU EINER POLICY „Herr Sc
Seite 75 und 76: 4.3. ZUSÄTZLICHE DOKUMENTE Eine m
Seite 77 und 78: 4.4. ERSTELLUNG UND UMSETZUNG Der e
Seite 79 und 80: 4.4. ERSTELLUNG UND UMSETZUNG Die M
Seite 81 und 82: 4.4. ERSTELLUNG UND UMSETZUNG Beson
Seite 83 und 84:
4.5. GESCHICHTE UND ENTWICKLUNG DER
Seite 85 und 86:
Kapitel 5 Kryptographische Verfahre
Seite 87 und 88:
5.2. GRUNDLEGENDE BEGRIFFE 5.2.3 De
Seite 89 und 90:
5.3. SYMMETRISCHE CHIFFREN man den
Seite 91 und 92:
5.3. SYMMETRISCHE CHIFFREN funktion
Seite 93 und 94:
5.3. SYMMETRISCHE CHIFFREN entweder
Seite 95 und 96:
5.4. ASYMMETRISCHE CHIFFREN OFB (Ou
Seite 97 und 98:
5.4. ASYMMETRISCHE CHIFFREN Sicherh
Seite 99 und 100:
5.6. WEITERE NOTWENDIGE ALGORITHMEN
Seite 101 und 102:
5.6. WEITERE NOTWENDIGE ALGORITHMEN
Seite 103 und 104:
5.7. SCHLUSSBEMERKUNG die Verschlü
Seite 105 und 106:
Kapitel 6 Keymanagement und Kommuni
Seite 107 und 108:
6.2. VERFAHREN ZUR ABSICHERUNG VON
Seite 109 und 110:
6.3. KEYMANAGEMENT-PROTOKOLLE Modif
Seite 111 und 112:
6.3. KEYMANAGEMENT-PROTOKOLLE Proto
Seite 113 und 114:
6.3. KEYMANAGEMENT-PROTOKOLLE Das T
Seite 115 und 116:
LITERATURVERZEICHNIS Nach erfolgrei
Seite 117 und 118:
Kapitel 7 „Klassische“ Firewall
Seite 119 und 120:
7.2. ELEMENTE EINES FIREWALLS 3. TC
Seite 121 und 122:
7.3. FIREWALL-ARCHITEKTUREN Clients
Seite 123 und 124:
7.3. FIREWALL-ARCHITEKTUREN Eine we
Seite 125 und 126:
7.3. FIREWALL-ARCHITEKTUREN Vor- un
Seite 127 und 128:
7.4. FIREWALL-ARCHITEKTUREN IN DER
Seite 129:
LITERATURVERZEICHNIS ¯ Firewalls b
Seite 132 und 133:
KAPITEL 8. HOCHGESCHWINDIGKEITS-FIR
Seite 134 und 135:
Seite 136 und 137:
Seite 138 und 139:
Seite 141 und 142:
Kapitel 9 „Active Content“ und
Seite 143 und 144:
9.2. ACTIVE CONTENT Im Gegensatz zu
Seite 145 und 146:
9.2. ACTIVE CONTENT JavaScript Bei
Seite 147 und 148:
9.2. ACTIVE CONTENT Im Rahmen diese
Seite 149 und 150:
9.2. ACTIVE CONTENT Andere Angriffe
Seite 151 und 152:
9.2. ACTIVE CONTENT Allerdings sind
Seite 153 und 154:
9.2. ACTIVE CONTENT On-Access-Viren
Seite 155 und 156:
9.2. ACTIVE CONTENT Erlaubt man die
Seite 157 und 158:
9.3. MOBILER CODE (AGENTEN) ihm nac
Seite 159 und 160:
9.4. FAZIT Die Autoren wenden das b
Seite 161 und 162:
Kapitel 10 Public-Key-Zertifizierun
Seite 163 und 164:
10.2. EINFÜHRUNG IN PUBLIC-KEY-VER
Seite 165 und 166:
10.3. PUBLIC-KEY-ZERTIFIZIERUNG 10.
Seite 167 und 168:
10.4. ZERTIFIZIERUNGSINSTANZEN 10.4
Seite 169 und 170:
10.5. PUBLIC-KEY-INFRASTRUKTUREN de
Seite 171 und 172:
10.5. PUBLIC-KEY-INFRASTRUKTUREN ei
Seite 173 und 174:
10.6. PKI-PRAXIS des ITU-Standards
Seite 175 und 176:
10.6. PKI-PRAXIS die Zertifikate f
Seite 177 und 178:
10.7. AUSBLICK 10.7.1 Entwicklungsr
Seite 179:
LITERATURVERZEICHNIS [TLS] Dierks,
Seite 182 und 183:
KAPITEL 11. CRACKER-TOOLS AM BEISPI
Seite 184 und 185:
Seite 186 und 187:
Seite 188 und 189:
Seite 190 und 191:
Seite 192 und 193:
Seite 194 und 195:
Seite 196 und 197:
Seite 198 und 199:
Seite 200 und 201:
Seite 202:
LITERATURVERZEICHNIS [Cert] http://
Alle anzeigen

Sicherheit in vernetzten Systemen - RRZ UniversitÃ¤t Hamburg

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?