Internetbasierte Datennetzwerke

Internetbasierte Datennetzwerke
Literatur:
Internetbasierte Datennetzwerke, M.Ziegler, Schlembach Fachverlag,
ISBN: 3-935340-20-6
Computernetzwerke, Andrew.S. Tanenbaum, Prentice Hall
www.rfc-editor.org (Internetnormen)
www.protocols.com (IP-Netzwerkprotokolle)
Themen der Vorlesung:
- Übertragung analoger/digitaler Daten
- OSI-Modell der Netzwerkkommunikation
- Weltweite Normierung als Grundlage für Rechnerkopplungen
- Strukturierte Verkabelung mit hoher Flexibilität
- Datenverpackung: Protokolle, Schnittstellen, Rahmen
- Datenaustausch in 7 Schichten:
o Physical Layer: Media Access Control, Ethernet, CSMA/CD
o Logical Link Layer: Fehlerkorrektur, CSMA/CD
o Routing Layer: Wie finden Datenpakete ihren Weg? , IP
o Transport Layer: Datenströme mit TCP
o Session Layer: Anfang/Ende einer Kommunikation/Session
o Presentation Layer: Umlaute und andere Sonderfunktionen
o Applikation Layer: Sichtweise der AnwenderInnen
- weltweites Internet als lebendes Beispiel
- Verzeichnisdienst als Rückrat jedes Netzwerks
- Anwendungen im Internet
o ICMP : Management
o SNMP : Steuerung/Überwachung
o SMPT : elektronische Post
o ftp : Dateien und deren Übertragung
o www : Wissensnetzwerke auf einheitlicher Basis
- Sicherheit in strukturverstärkenden Elementen
o Firewalls, Gateways
Übertragungsnetze für digitale Daten
Analoge Daten
Messung kontinuierlicher Größen; begrenzte Genauigkeit bei Messung
und Übertragung
Digitale Daten
synchrone Messung des zeitlichen Ablaufs; Übertragung als einer von
zwei Spannungspegel
Analog-Digital-Wandlung
Informationsverlust; dieser ist abhängig von der
Abtastfrequenz
Shannon-Theorem
Die obere Grenzfrequenz der Übertragungsmedien muss
doppelt so groß (mindestens) wie die maximale Frequenz
der Impulsform sein.
Netzwerkanforderungen
- Nutzung gemeinsamer Ressourcen (z.B. Drucker, Plattenspeicher=
- Hohe Flexibilität
- Hohe Zuverlässigkeit
- Unabhängiger Austausch einzelner Systeme möglich
- Wertschöpfung im Arbeitsprozess unabhängig vom Standort des Rechners
Topologien von Netzwerken
Stern :
„single point of failure“
Ring:
nur Beziehungen zwischen Nachbarn; Nachrichten werden
„druchgereicht“
Komplett:
jeder Knoten ist mit jedem verbunden; Vermaschung; sehr aufwändig
bei größeren Netzwerken
Baum:
hierarchische Struktur
Bussystem:
Kabel mit Stichleitungen zu den Knoten; leicht zu realisieren
Logische Verbindungen in digitalen Übertragungsnetzen
Kopplung von mehr als zwei Endgeräten erfordert Strategie der Wegefindung (routing):
- Schaltung eigener Verbindungskabel zwischen den Kommunikationspartnern
(Datennetzwerkbereich Modem)
- Leitungsvermittlung wie im Telefonnetz (POTS = Plain Old Telephone System)
- Paketvermittlung wie bei der Briefpost
Kopplung von Endgeräten unterschiedlicher Hersteller erfordert weltweite Normierungen.
Netzwerkdesign Abstimmung physikalische Leitungen
Verbindungen
~ findet selten auf der „grünen Wiese“ statt.
mögliche logische
Veränderungen in der Schaltung logischer Verbindungen sollten abwärtskompatibel sein.
Weltweite Normierungen von Rechnerkopplungen
- Instanzen: ISO, ITU, DIN
- Protokollhierarchien
- Entwicklung eines RFC (Request-for-comment)
Wie werden Netze normiert?
- Definition exakter Schnittstellen
- Abwärtskompatibilität
- Begriffswelt vereinheitlichen ( Englisch!)
2 Ansätze zur Normierung:
1. erst normieren, dann implementieren (Umsetzbarkeit nicht sofort gegeben;
zeitaufwändig)
2. erst implementieren, dann normieren
Den Normen äquivalent sind dann die RFC
Aktivitäten von einer Idee zur Anwendung (
die zwei Elefanten)
1. Forschung, Diskussion, Besprechungen, Entwurfpapiere
2. Realisierung des Projekts und damit Investitionen
Es bleibt wenig Zeit für Investitionen
ISO
ITU
RFC
IETF
OSI
International Standards Organisation
International Telecommunications Union (ehemals CCITT)
Request for Comments
International Engineering Task Force
Open System Interconnect
ISO-Norm
OSI-Modell
7 Schichten, keine „schrägen“ Linien
2 Systeme kommunizieren über Subnetze hinweg (nicht unbedingt direkt)
„Double Headed Monster“
Schnittstellen:
SAP = Service Access Point
Exakte Definition von Schnittstellen zwischen zwei Schichten in der Software eines Knotens
möglichst wenig Schnittstellen
für jeden SAP eine ISO-Norm
Protokolle:
Protokoll: festgelegte Regeln für die Kommunikation
Exakte Definition von Protokollen zwischen gleichen Schichten in der Software zweier
Knoten. Kommunikation läuft immer zwischen gleichen Schichten.
Aufbau der Schichten (generell)
- Nachrichten werden mit einem Header versehen (ICI)
- Kapselung
- Nachfolgende Schichten betrachten Nachricht + Header als die neue Nachricht und
stellt den eigenen Header voran, usw…
Physikalischer Aufbau lokaler Netzwerke
Übertragungsmedien (strukturierte Verkabelung)
weggebundene Netze:
ohne Wegbindung:
magnetische Medien
Koaxialkabel (Basisband)
UTP Unshielded Twisted Pair
Glasfaserkabel
Laserstrahlen
Funk
Radar
Satellitenübertragung
strukturierte Verkabelung: EIA/TIA 568, ISO 11801
1 Hauptverteiler (HVT) Main Distribution Facility (MDF)
und x Unterverteiler (UVT) Intermediate Distribution Facility (IDF)
werden sternförmig mit dem Hauptverteiler verbunden (Backbone)
Physical Layer
- Media Access Control (MAC)
- Verbindung zwischen genau 2 Punkten
Kollisionsfreie MAC
-
externe Taktgeber
Token Ring (IEEE 802.5)
Konkurrierende MAC
-
CSMA/CD
Ethernet (IEEE 802.3)
CSMA/CD
Carrier Sense Multiple Access / Collision Detection
Station prüft, ob das Trägermedium belegt ist, bevor sie sendet. Während des Sendens wird
weiter geprüft, ob es zu einer Kollision kommt. Ist dies der Fall wird der Sendevorgang
abgebrochen und wiederholt.
Ist der Sendevorgang beendet und es kommt zu einer Kollision (late collision), kann diese
nicht erkannt werden.
Ethernet Rahmenformat (10 MBit/sec)
- Präambel
- Rahmenbegrenzungsoktet
- Adressierung (6 Oktets, weltweit eindeutig)
- Längenfeld (Länge des Datenfelds)
- Typfeld (anstatt Längenfeld möglich)
- Padding-Feld (erfüllt Forderung nach Mindestlänge von 64 Oktets)
- 32 Bit CRC
Vermittlungsschicht
- Kopplung von Netzwerken (auch unterschiedlicher Techniken!)
- Design-Aspekte der Vermittlungsschicht
- Internet-Protokoll (IP)
o IPv4 Header
o IPv4 Adressierung
o IPv4 Fragmentierung
- Weiterentwicklung zu IPv6
Wegfindung zwischen Teilnetzen
Zieladresse
Jedes Datenpaket enthältvollständige Quell- und
IP: Wegfindung in Datennetzen
- Erhöhung der Ausfallsicherheit der Kommunikation durch Nutzung alternativer
Wege zwischen den beteiligten Knoten, ohne dass der Anwender diese Wegewahl
bewusst steuern muss oder kann.
- Erhöhung des Durchsatzes der Kommunikationsbezeichnung durch Bündelung
verschiedener Wege mit unterschiedlichen Leistungsparametern.
- Aufteilung in logische Einheiten zwischen Netzwerken, die den übergreifenden
Datentransport nur an genau definierten Stellen zulassen. Dies ist u.a. auch bei
Firmennetzwerken häufig gefordert, da an den Grenzen der organisatorischen
Kostenstellen auch Verantwortungslinien existieren, die in den Netzwerken
abgebildet werden soll.
Koppelelemente zwischen den Netzen nötig, die über Weiterleitung der
Datenpakete entscheiden können. (Tabelle mit Einträgen für den bestmöglichen
Weg)
IP-Header
Bei der Erstellung des IP-Headers kann nicht „linear“ vorgegangen werden, z.B. muss das
Längenfeld zunächst freigehalten werden und kann erst gefüllt werden, wenn der Rest des
Headers erstellt wurde und die Länge dadurch ermittelt wurde ( problematisch)
Adressierung
Bitfolge
Klassenbezeichnung Anzahl Netze
0XX
Class A
126
10X
Class B
216-2
224-2
11X
Class C
Subnetzmaske
- identisch im LAN
- gekoppelte LANs nicht unbedingt identische NW-Masken
- „tolerante“ Routen erlauben leider Fehlerkonfiguration
Anzahl Knoten
224
216
256
Fragmentierung von IP-Paketen
wird erforderlich, wenn in Teilstrecken eines Netzwerks maximale Paketlängen im Layer 2
implementiert sind.
Herstellerabhängige Fragmentierung oft ohne aufwendige Header. Solche Geräte sind
unflexibel und werden daher selten eingesetzt.
Wenn ein absendender Knoten eine Fragmentierung nicht erlaubt, wird er das „Don’t
Fragment Bit“ setzen.
IPv6: Weiterentwicklung des IP-Protokolls
vollständige Adresse: 128 Bit/16 Oktets/32 Hex-Zeichen
Beispiel: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
oder 1080:0:0:0:8:800:200C:417A
Die ersten drei Bit werden als Format Prefix bezeichnet, die nächsten 13 sind der Top-LevelAggregator.
ICMP
Internet Control Message Protocol
Störungen werden zuerst von den Routern bemerkt. Der aufwändigste Teil des
Netzwerkdesigns besteht im Aufbau sauberer Layer 3 Strukturen. Die Fehlersuche hier sollte
möglichst unbeeinflusst von Eigenschaften der Knoten selbst möglich sein.
ICMP definiert (in RFC 792) zur Störungssuche (IP-Port: 01):
- Destination unreachable: absendender Router kennt keinen Weg
- Time exeeded: Time-to-Live-Feld wird 0 keine Weiterleitung
- Source Quench: Strecke überlastet (heute in Layer 4 implementiert)
- Redirect: *
- Echo Request/Reply: „Hallo, ist da wer?“ (als Ping implementiert)
* Ein Router kennt einen besseren Weg zum Ziel und versucht dies dem Sender mitzuteilen,
der dies in seine Routing-Tabellen eintragen kann (wenn er will).
Mapping mit ICMP – traceroute
Aufbau von Tabellen mit Routinginformationen in den Routern
Tabellen enthalten: - Zieladressen der erreichbaren Knoten, evtl. gruppiert
- Angabe des nächsten Routers (next hop)
- „Entfernung“ bis zur Zieladresse
- Kosten der Leitung (meist virtuelle Kosten, nicht Euro)
- Anzahl der noch zu passierenden Knoten bis zum Ziel
optimale Wegfindung
Pflege der Routing Tabellen
- Distance Vector Algorithmus
- Link State Algorithmus
- OSPF )Open Shortest Path First)
RIP
Routing Information Protokoll
Designaspekte der Transportschicht – Layer 4
Quality of Service (QoS)
Ziel: - Verbesserung der Dienstqualität
- Bereitstellung zuverlässiger verbindungsorientierter Dienste für Benutzerprozesse
in einem unzuverlässigen Netzverbund
- Kapselung der betriebssystemspezifischen Eigenarten der Implementierung des IPProtokollstapels (Pufferung der Daten)
- Kapselung der Teilnetze eines IP-Providers
- Definition von einheitlichen Schnittstellen für Netzwerkdienste unabhängig vom
Betriebssystem: „Berkeley Sockets“
- Überwachung der Dienstqualität während einer Verbindung
o Flusskontrolle
o Anpassung der Datenrate an die Leistungsfähigkeit des Rechners
o Option Negation zur bestmöglichen Ausnutzung der Übertragungsmedien
- Keine Kontrolle über die Anwendung auf der „anderen Seite“
Status Diagramm einer Transport-Layer-Verbindung
RFC 793: TCP-Implementierung eines Layer 4
Zustände
Übergänge
- Wartezeiten
- Anwendungen
Auslöser (Pfeillegende)
- Anwendungen
- Datagramm
- Timer
TCP-Header:
- definiert in RFC 793, RFC 1122, RFC 1323
- Signalisierung des Zustands der Verbindung durch Statusbits
- Lastabhängige Flusskontrolle über „sliding window“
- Kennzeichnung dringender Daten möglich (urgend Flag)
- Länge: 20 Oktets + Optionen
- Die IP-Adresse des Knotens zusammen mit dieser Port-Nummer bilden den TSAP,
bzw. den socket-identifier (48 Bit: 192.168.1.2.21) und ist damit in jedem Knoten
eindeutig
- Port-Nummern können international festgelegt werden (IANA)
- Ports kleiner 256 sind die „well-known-ports“ für Standarddienste
- Ports kleiner 1024 sind „privilegierte ports“, die in der Regel nur von einem
Systemprozess geöffnet werden dürfen
- Ports größer 1024 können von Knoten frei vergeben werden
- In der Regel sind mit den Port-Nummern auch Anwendungen verknüpft
- Jeder TCP-Layer nutzt eine Textdatei in der die Port-Nummern beschrieben
werden
TCP-Fenstermanagement (windowing)
- Vermeidung von Totzeiten
-
Anpassung der Netzbelastung
Ausnutzung unterschiedlich leistungsfähiger Rechner
Beispiel eines TCP-Datenstroms
Statusbits im TCP-Header
SYN synchronize Signal zum Verbindungsaufbau
ACK acknoledge „Acknoledgement Number“ gültig; gehört zu genau einer Verbindung
RST reset
Signalisierung von Problemen
URG urgent
Datensegmente, die bevorzugt behandelt werden sollen
PSH push
Daten sofort weitergeben, nicht auf vollen Puffer warten
FIN
Sender hat keine weiteren Daten und will Verbindung abbauen
3-Way-Handshake zum Verbindungsaufbau
-
-
Viele TCP-Implementierungen stellen einen schnell reagierenden Masterprozess
zur Verfügung, der eine Verbindungsanfrage beantwortet, indem ein Subprozess
generiert wird.
Der auf TCP-Port 111 hörende Process SUNRPC dient der dynamischen
Zuweisung von TCP-Ports zu registrierten Programmen.
Belegung der TCP-Puffer wird in Recv-Q bzw. Send-Q angezeigt.
UDP – RFC 768 – verbindungslose Layer 4 Kommunikation
In einigen Fällen reicht die Möglichkeit aus, Datenpakete abzusenden, über deren Verbleib
der Absender nicht informiert werden muss, und damit auf einen nennenswerten Overhead
verzichtet werden kann.
- kein Kontext (Seq # oder Ack #)
- keine Verbindungen (Statusbits und Übergänge)
- kein Lastmanagement (Window Size)
- Layer-4-Adressen (Ports) entsprechen TCP
- schnell
UDP
User Datagramm Protocoll
Weg eines IP-Pakets bis zur Anwendung
- Netzwerkkarte erkennt die korrekte (eigene) MAC-Adresse
- Netzwerkkarte prüft die Frame Check Sequence
- Interrupt der Netzwerkkarte an den Masterprozess inetd
- inetd erkennt die korrekte (eigene) Ziel-IP-Adresse und CRC
- inetd erkennt die Status-Bits im TCP/UDP Header
-
-
o Aufbau neuer Pufferbereiche, oder (SYN=1)
o Nutzung bereits vorhandener Empfangspuffer (SYN=0)
inetd erkennt die Ziel-TCP-Port-Nummer (SocketID)
inetd erkennt die Quell-TCP-Port-Nummer und Quell-IP-Adresse
o Nutzung etablierter Verbindung (identifiziert mit dem Socket Paar)
inetd entscheidet anhand der inetd.conf, welches Programm die weitere
Behandlung des Datenpakets durchführt
o Start einer neuen Instanz eines Programms (evtl. auch rpc-deamon)
inetd legt sich wieder schlafen und wartet auf den nächsten Interrupt
Meldung an den Anwender: „connection established“
TCP-Erweiterung – Optionen
TCP-Management der Wiederholungszähler RTO
Programmierung mit TCP-Sockets
- Implementierung schon zu Zeiten des RFC 791/793 verfügbar (1980)
- Lizenz der University of Berkeley kostenfrei
- modular programmiert
- Grundlage für nahezu alle Netzwerk-SW, erst Java schafft ein neues API
Verbindungsorientierte Kommunikation über Berkeley (Abb 4.12)
Verbindungslose Kommunikation mit UDP-Sockets (Abb. 4.13)
File Transfer Protocol – FTP
- Dateien und deren Übertragung
- Implementierung und Beispiel nach RFC 959
- Anwendung
o anonymous FTP
o FTP-Protocol im Browser (FTP-URL)
Eigenschaften einer Datei
Pfadname
- logisch zusammengehörige Dateien in einem Verzeichnis
Zeichensatz
- Inhalte von lokalen Anwendungen bearbeiten
- Benutzerschnittstelle zum Menschen
- Inhalte in 8/16/32 Bit Zeichensätzen möglich
Zeichenstruktur
- Zeilenende je nach Anwendung unterschiedlich (Interpunktion)
- Betriebssystemabhängigkeiten beim Zeilenendezeichen
Struktur auf dem Massenspeicher
- File Allocation Table (FAT)
- Größe der Datenblöcke auf magnetischen Speichern
- Begrenzung der Dateigröße
Architektur des FTP
RFC 959:
Textdateien
Binärdateien
Transfer ohne Veränderung umkehrbar
PI = Protokoll Interpreter
DTP = Daten Transfer Prozess
-
Kontrollverbindung zwischen Protokoll-Interpretern (PI)
Eine oder mehrere Datenverbindungen zwischen den DTP
Benutzerinterface über Zeichensatz des Virtual Terminal
Steuerung aller Operationen durch ein textbasiertes Benutzerinterface
ftp-Befehle
sind einzelne Worte
haben meist ein Argument
werden im Zeichensatz USASCII übertragen
ftp-Meldungen
bestehen aus 3 Ziffern und erklärendem Text
werden incl. Text vom entfernten System erzeugt (in dessen Sprache)
Beispiel für einen Dateitransfer mit ftp (Abb. 5.3 / S.141)
How to use anonymous ftp (RFC 1635)
- Bereitstellung von Informationen für die „Öffentlichkeit“ ohne
Benutzerauthentication
- Etablierte Regeln für solche Server (Netiquette)
o username: anonymous
o password: E-Mail-Adresse des Benutzers (ohne Prüfung auf Serverseite)
Browser nutzen hier gerne den direkten Zugriff auf integrierte Mail-Clients
o Verzeichnis / incoming off write-only, Verwaltung durch menschliche
Moderatoren des Serverbetreibers
o Maximale Anzahl von gleichzeitigen Downloads zur Begrenzung der
Auslastung des Servers
o Prüfung der Auflösbarkeit des anfragenden Client im DNS und Ablehnung
des Transfers, falls diese fehlschlägt
- Zugriff über ftp auf Port 80 aus einer URL herausoft möglich
o ftp://(user):(password)@hostname/path; TYPE={All}
Synchronisation im ftp-Protokoll: Wiederaufsetzen
Session-Layer in ftp nach RFC 959:
-
Aushandeln eines Marker-Codes zwischen den PI
Einbau des Marker-Codes in den Datenstrom in regelmäßigen Abständen
empfangender DTP speichert den Marker-Code außerhalb der empfangenen Datei
Nach Verbindungsabbruch und Neuaufbau erneuter Start desselben ftp-Befehls
Vorhandener Marker-Code wird bei der Get/Put-Anforderung übertragen und vom
Server-DTP ausgewertet
Server-DTP sendet nur die Daten nach dem letzten Marker-Code
Viele ftp-Implementierungen verzichten auf diesen Komfort: Ob mehrere Marker-Codes und
damit Sessions verwaltet werden können ist implementationsabhängig.
Presentation Layer
- Designaspekte des Presentation Layer
- Zeichensätze
o Normierungen ASCII, ISO 8559
o Herstellerspezifisch
o weltweit ein Zeichensatz UNICODE (ISO 10646)
- Virtual Terminal Protocol
o Beispiel: Telnet
Aufgabe des Presentation Layer (Darstellungsschicht)
- Anwendungen tauschen keine beliebigen Binärbitketten aus, es werden i.d.R.
Namen von Menschen, Datumsangaben, Ganzzahlen, etc. ausgetauscht
- Unterschiedliche Darstellungscodierung verschiedener Systeme:
o Nationale Umlaute
o Datumsschreibweise
o Ganzzahlen (Einer-/Zweierkomplement)
o Gleitkommazahlen (Exponent, Mantisse)
-
ASCII
ANSI
EBCDIC
UNICODE
Virtual Terminal
- Umsetzung aller Zeichen jeder Anwendung in einen virtuellen Zeichenvorrat
- RFC 854 Network Virtual Terminal für Anwendung telnet
Interaktive Sitzung über telnet-Protokoll
telnet - ist definiert in RFC 854 vom Mai 1983
- implementiert ein virtuelles Terminal auf Basis von TCP/IP
- arbeitet mit Aushandlung von Optionen zur Anpassung an unterschiedliche
Implementierungen
- bietet eine symmetrische Sicht auf Charakter Cell Terminals und Host-Prozesse
Kommandos zur Aushandlung von Optionen
- WILL X
Angebot einer Seite, die Option X sofort zu benutzen
- DO X
Antwort auf WILL X, die Option X wird sofort benutzt
- DONT X
Antwort auf WILL X, die Option X wird nicht benutzt
- WONT X Antwort auf WILL oder DO X, die Option X wird später benutzt werden
Nicht alle Implementierungen realisieren alle Optionen. Default: WONT X
Ablauf einer telnet-Sitzung mit Aushandlung von 2 Optionen:
Modell eines Network Virtual Terminal (NVT)
DNS – Domain Name Service
- Umsetzung von Namen in IP-Adressen
- Namenshierarchien
- dns im www
IP-Adressen für Rechner – Namen für Menschen
- Namensumsetzung ist eine typische Operation für Layer 6
- IP benötigt auf Layer 3 eine eindeutige 32 Bit Quell- und Zieladresse
- Anwender auf Layer 7 benötigen einen merkbaren Namen
- Umsetzung ist prinzipiell statisch möglich (/etc/hosts oder
c:\winnt\system32\drivers\etc\hosts o.ä.)
- 127.0.0.1 localhost
steht für eine Pseudo-IP-Adresse
- Pflegeaufwand für einige hundert Knoten noch erträglich
- Besser ist ein Client-Server-Modell mit hierarchischen Namensbäumen
NameResolver
RFC 1034 und 1035
dns
NameServer
dns Namenshierarchien
- Pflege der Namen soll weltweit verteilt erfolgen aber zusammen passen
- Abbildung „natürlicher“ (d.h. dem Anwender bekannter) Struktur
o geographische Einteilung (Länder, Staaten, Regionen)
o organisatorische Einteilung (Firmen, Abteilungen, Gruppen)
FQDN
Fully Qualified Domain Name
Struktur und Hierarchie des DNS
- gilt seit ca. 1980 (RFC 1034/1035)
- eingeführt aus technischen Gründen
- wird zunehmend zweckentfremdet (Markenschutz, Wettbewerbsrecht)
1997 Diskussion (jahrelang) und Einführung neuer Top-Level Domänen
Tabelle 5.7 / S. 159
Namensauflösung – dns Resolver
- in der Konfiguration aller Clients (in Unix-Systemen /etc/resolv.conf) werden die
IP-Adressen der erreichbaren dns-Server der eigenen Domain eingetragen
- Resolver senden UDP-Pakete auf UDP-Port 53 des ersten dns-Servers, falls keine
Antwort (timeout meist ca. 20 Sekunden) werden die anderen dns-Server gefragt
Anwender auf dem Knoten pc88.Kunde.de sucht shop.firma.com
8 Schritte bis zum Ergebnis
4 dns-Server in der Hierarchie beteiligt
Übertragung der Anfragen über UDP
Caching; Antworten werden zwischengespeichert
Suchstrategien von dns-Namen
- Angabe eines fully qualified dns-Namen als Ziel nicht zwingend erforderlich, alle
dns-resolver versuchen geeignet zu ergänzen
- Ablauf der Suche nach einem simple hostname
Knoten www.debis.de sucht (existierenden) Knoten ftp:
Anfrage
Antwort des/der dns-Server
ftp
ftp.de
ftp.debis.de
„name not found, authoritative“
„name not found“
INA 10
Knoten www.debis.de sucht (nicht existierenden) Knoten joe.firma.com
Antwort des/der dns-Server
Anfrage
joe.firma.com
joe.firma.com.de
joe.firma.com.debis.de
joe.debis.de
„name not found“
„name not found“
„name not found“
„name not found“
Client „Server failed“
beendet: Server kennt die Antwort nicht
Spezialfall dns-Auflösung im WorldWideWeb
Jede Ressource im www wird über eine URL angesprochen
{protokoll}://{user}:{password}@{host}/{path}/{document}?{query_string}
-
Der {host} ist ein dns-Name, der allerdings nicht unbedingt durch den Browser
selbst aufgelöst werden muss.
Proxy (stellvertreter) Hierarchien
o Vereinfachung des Datendtransports durch Caching
o Festlegung der Wege im Internet, Provider-eigene Leitungen bevorzugen
o Filterung von Inhalten
o Verlagerung aller dns-Aktivitäten
o zur Vereinfachung der client-Software (Browser)
Konfiguration eines dns-Servers
- Die dns-Daten werden im dns-Server in Textdateien verwaltet
- Format der Datensätze:
<Domain-Name><Time-to-Live><Type><Class><Value>
- Zur Syntaxvereinfachung werden wiederholte Felder in den Folgezeilen
leergelassen und aus den Vorgängerzeilen ersetzt
- Reihenfolge der Zeilen wegen der „defaults“ signifikant
- Praktisch nur Class IN (Internet Protokoll) implementiert
Konfigurationszeilen und Datentyp der Antwortpakete
SOA – Start of Authority
- Timestamp (String) signalisiert Aktualisierung der dns-Hierarchie
- Angaben zum Verwalter dieser dns-Domain (Mail-Adresse)
- default-Werte nicht ausgefüllter Elemente
o TTL eines cached Eintrags (oft 2419200sec = 1 Woche)
- Wiederholungszeiten und Replikationsintervalle
o secondary-timer (7200 sec. oft)
TXT – Informationen zur gesamten dns-Domain
- nur einmal pro Datei
- werden zusammen in der dns-Antwort ausgeliefert
MX – Mail Exchanger
- Liste von Mailservern, die unter der angegebenen Domain agieren
(bspw.: <username>@firma.com statt <username>@mail123.firma.com)
Absender benötigen keine Kenntnisse der internen Hostnamen
HINFO – Host Information
- zwei Worte („ „) zur Beschreibung (z.B. Anwendung, Betriebssystem)
- pro A Eintrag nur ein HINFO Eintrag
A – Adressinformation IPv4
- eigentlichen Zweck des dns, Angabe der IP-Adresse
- entweder FQDN (inkl. abschließendem Punkt) oder hostname, der um die aktuelle
(letzte SOA) Domain ergänzt wird
AAAA – Adressinformationen IPv6
- die einzige „echte“ Chance die 128 Bit-Adresse zu verwalten
NS – Name Server
- Hierarchie aus dns-Servern
- Verweis für einzelne Domains auf andere Server
o Pflege der Informationen nicht an einer einzigen Stelle erforderlich
o Verteilung der Verantwortung (Zonenkonzept) auf andere Personen
o Verteilung der Last auf die zentralen Server
… und weitere Direktiven (abhängig von der Server-SW-Version)
FORWARD oft wird jede lokale Funktion damit unterdrückt
INCLUDE
Einbeziehung weiterer Dateien
Verwaltung der Dateien über webmin oder Windows-GUI
- erleichtert die Aufrechterhaltung der Konsistenz
- verkürzt Restart-Zeiten, in denen keine Anfragen beantwortet werden
- dynDNS – dns-Informationen bei Anmeldung am Active Directory Service
Fehler im dns verbreitet sich schnell und bleibt lange erhalten (TTL)!!!
DNS und Sicherheit
dns-Server sind unverzichtbar für den Netzwerkbetrieb
- Hohe Ausfallsicherheit durch Aufbau mehrerer Secondary-Replikate
- eingeschränkter Administrationszugriff
o Verwaltung möglichst durch Werkzeuge mit Syntaxprüfung
o klare organisatorische Regelungen, wer wann die Einträge vornimmt
- die Maschine, die dns-Dienste anbietet, tut sonst nichts, um das Risiko durch
andere Software zu reduzieren
o hohe Last durch dns-Anfragen zu Spitzenzeiten
- Zugriffskontrolle auf die dns-Dienste
o Einzelhost-Abfragen von allen Clients im eigenen Verantwortungsbereich
o Zone-Transfer nur von eingetragenen Servern (secondary)
o Analyse der Logfiles auf verdächtige Muster
o Auswirkungen von dns-Fehlern oft erst nach Tagen sichtbar (TTL)
- Regelmäßige Aktualisierung der eingesetzten dns-Server-SW
dns-Server bieten viele Informationen
- Angreifer suchen gezielt diese Server. I.d.R. werden die Server nicht zerstört
sondern „nur“ genutzt
- Erkennen von übernommenen dns-Servern oftmals schwierig
o Einbau von falschen dns-Namen bzw. falschen IP-Adressen und
Überwachung der Logfiles bzw. Intrusion Detection Systeme auf deren
Verwendung
o statistische Auswertungen der Logfiles: Mustererkennung: wird z.B. eine
Versammlung aller Mitarbeiter im Aktivitätsmuster sichtbar
- Grundstruktur der dns-Daten ändert sich sehr selten, Ablage der Dateien auf einer
CD-ROM schützt gegen Änderungen
- Aufbau von split-dns an den Verwaltungsgrenzen eines Netzwerks
o internal nodes fragen FORWARDer, der einen external Server fragt
o external nodes sehen nur den external-Server, der keine (nur wenig)
Informationen über den intern benutzten Namensraum hat
o interner/externer Namensraum kann verschiedene domains nutzen
Rückwärtsauflösung – IN-ADDR.ARPA (RFC 1035)
- Umsetzung von IP-Adressen in Namen erforderlich für
o Prüfung der Konsistenz vermaschter dns-Server
o Einfachster Schutz gegen IP-Spoofing; IP-Adressen, die sich identisch
rückwärts und wieder vorwärts in einem dns auflösen lassen, sind korrekt
-
-
o Namensausgabe von als IP-Adressen ausgegebenen Parametern (z.B. muss
die Ausgabe eines „default-Gateway“ immer als IP-Adresse erfolgen)
Nutzung der Spezial-Domain IN-ADDR.ARPA in der alle IP-Adressen verwaltet
werden
o In IN-ADDR.ARPA sind nur Verweise auf die domain eingetragen, in der
die eigentliche Ressource-Information (RR) zu finden ist.
10.IN-ADDR.ARPA
PTR MILNET-GW.IST.EDU.
22.0.2.10.IN-ADDR.ARPA
PTR MILNET-GW.IST.EDU.
Wichtig ist die Aufgabe von fully-qualified names in den PTR-records
Struktur der dns-Nachrichten
dns-Protokoll Header (RFC 1035): 12 Oktets
- 16 Bit ID: willkürlich von Anfrager gewählt und vom Antwortenden wiederholt,
Matching offener Anfragen zu eingehenden Antworten
- Query/Response Bit
- OpCode (4 Bit)
- Authoritative Bit in answer (evtl. Verweis auf SOA im Response-Part einer
Nachricht)
- 3 Statusbits zur Rekursion
- 4 Reserve Bits
- 4 Bit Response Code (0 = no error)
- 4 Counter mit je 16 Bit zur Struktur der Antwort (Anzahl der Einträge)
Alles in UDP Port 53 verpackt
SNMP – Simple Network Management Protocol
- Manager-Agent Modell
- Management Information Base (MIB)
- SNMP-Protokoll
- Monitoring-RMON
SNMP – Manager-Agent Modell
- Netzwerkverwaltung mit sehr vielen Knoten und Routern nicht mehr nur mit ping
und Messung der Reaktionszeiten machbar
- Zentralisierung der Verwaltung notwendig
- Implementierung von Agenten in allen zu überwachenden Systemen
- Agenten nicht nur für „Netzwerk“-Komponenten verfügbar
SNMP-Agenten sind häufig als eigene Anwendung implementiert (SNMP-deamon, snmpd)
ASN.1 Abstract Syntax Notation 1
- ASN.1 beschreibt Objekte und fasst einfache Objekte in komplexere Objekte
zusammen (Baumstrukturen)
- ASN.1 ist in ISO-8824 definiert
- SNMP verwendet eine Untermenge der in ASN.1 erlaubten Konstrukte
- Beispiele: count INTEGER:: :: 100 Definition d. Variablen count mit Wert 100
status::INTEGER{up(1), down(2), unknown(3)}
Tabelle 5.11
MIB – Einheitliche Sichtweise von Manager und Agent
- Software für Managementstationen und Agent werden zu unterschiedlichen Zeiten
von unterschiedlichen Herstellern implementiert
- Strukturierung der verwaltbaren Objekte in einem einheitlichen Baum
- Namen der numerischen Objekte im Objektbaum in der ASN.1-Syntax
Abb. 5.10 Teil des SNMP-Objektbaums
MIB-2 vorgeschriebene Objekte
RFC 1213 schreibt 175 Objekte (10 Gruppen) für alle SNMP-Agenten vor
Gruppe
Anzahl Objekte
Beschreibung
system
interfaces
at
ip
icmp
tcp
udp
transmission
snmp
7
23
3
42
26
19
6
x
29
Name, Standort, Betreuer
Schnittstellen auf Layer 1-2
Inhalt d. amp-Tabelle d. Zielsystems
IP-Statistik u. Eigenschaften d. Layer 3
num. Wert
Beispiel eines MIB-Zweigs (MIB-2): interfaces
Beispiel eines privaten MIB-Zweigs: enterprises
Beispiel für eine MIB-Datei: TOASTER.MIB (S. 170)
SNMP-Protokoll
- SNMP arbeitet nur mit UDP-Paketen auf UDP-Port 161
- Abfragen und Ändern von Variablen
- Kontext d. Abfragen und Veränderungen wird in Manager und Agent getrennt
ermittelt:
o Tabellen zusammengehöriger Variablen in der MIB definierbar
o Gültigkeit von Teilbäumen mit Flag-Variablen gekennzeichnet
- SNMP stellt im Protokoll (Version 1) 6 Nachrichtentypen zur Verfügung
- Return-Codes:
- value
- no such variable
- end of MIB tree
- Viele verschiedene Implementierungen
Nachrichten
- get
-
set
trap
- get next
- get bulk (V2)
- inform
(sollte nicht von jedem beliebigen ausgeführt werden
Sicherheit)
abgeleitete Abfragetools
- snmptable
- snmpdf
- snmpnetstat
- etc.
Beispiel einer SNMP-Anfrage:
$snmpget –d Router.firma.com <xxxxx> System.sysName.0
Beispiel einer SNMP-Antwort
Monitoring mit SNMP – RMON (RFC 2819)
- Belastung durch zyklische Abfragen
-
- Netzwerk
- Agent/Manager
Auswertung i.d.R. nur in größeren Zeitabständen erforderlich
Funktionsgruppen:
ethernet statistics
ethernet history/control
alarm
host statistics
host TopN
host Matrix
filter/package capture
event
Die Netzwerküberwachung mit RMON setzt spezielle Geräte, RMON-Probes, ein, in denen
nur ein SNMP-Agent und einige Zähler implementiert sind. Diese Zähler sind definierten
Variablen im MIB-Baum zugeordnet und überwachen deren Werte, die in festgelegten
Zeitabständen in lokalen Speichern in diesen Probes abgelegt werden.
Überwachung eines Switch – „kleine“ RMON-Probes-snmptable
hostAddress; hostInPkts; hostOutOkts; hostInOktets; hostOutOktets; hostOutBroadcastPkts;
hostOutMulticastPkts;
Beispiel für eine SNMP-Anwendung: Toast herstellen
Realisierung eines SNMP-Agenten
- SNMP-Weiterentwicklungen – Version V1, V2
- SNMPV1 – RFC 1157
o klassisches SNMP
- SNMPV2 – RFC 1905
o Manager-Agent-Modell
o MIB wie in V1 über vereinfachte ASN.1 Syntax definiert
o Ergänzung um „Sub-Manager“ (Deligieren v. Teilbäumen)
informRequests zum Austausch d. Informationen zwischen
Managern
o Operation „getbulkwalk“ zur Verringerung der Netzlast
große MIB-Bäume werden schneller abfragbar
…
SNMP – Weiterentwicklungen – Version V3
- RFC 2570 – Introduction to SNMPV3; RFC 2571 - Architektur
- Klare Trennung zwischen
o Beschreibungssprache der verwaltbaren entities (ASN.1)
o Struktur d. verwaltbaren entities (MIB’s und MIB-Tabellen)
o Protokoll (UDP-161)
o Sicherheit und Verwaltung
- grundlegende Aspekte in allen SNMP-Versionen identisch
RFC 2574 – message level security
- Verschlüsselung (DES)
- Echtheitsprüfung (Bildung eines Digest/Hash mit MD5, SHA)
- Vorsorge gegen Replay, Delay und Redirection
o Synchronisation d. Uhren in Manager und Agent
o Öffnen eines Zeitfensters für „legale“ Antworten
RFC 2575 – view based access control
- nicht alle Manager fürfen alle MIB-Zweige sehen/bearbeiten
Struktur möglicher SNMP-Agenten und Manager
Ablage der Management Informationen (MIB):
- als eine große Textdatei konsistent auf Manager und Agent
- kompliziert zur Verbesserung d. Zugriffsgeschwindigkeit für Manager
- als viele Textdateien mit IMPORT-Funktionen
o Start der Abfrageanwendungen deutlich verzögert bei vielen Zweigen
o Agent bearbeitet die MIB’s meist nur einmalig
Struktur des Agent:
- monatlich
- MasterAgent/SubAgent (extensible Agent)
o MasterAgent reagiert auf UDP-161 und erkennt den MIB-Zweig
o SubAgent erhält die Anfrage vom MasterAgent für den eigenen Zweig
o SubAgents arbeiten als eigene Prozesse; sie registrieren „ihren“ Zweig
beim Start des Prozesses beim konfigurierten MasterAgent
Implementierung von SNMP-Agenten
Microsoft Windows
- Windows 2000 extensible agent (Master/SubAgent) von Microsoft
- SubAgents für MIB2 von Microsoft Serverprodukte (IIS, SQL-Server)
- enterprises-MIB unterhalb des Microsoft-Zweigs
- UCD (freeware) ucd-snmp:
o Monolith mit wesentlichen Funktionen (auch unter Windows 9x)
o sehr gute Abfrage-Werkzeuge für alle SNMP-Versionen
Linux
-
UCD-SNMP
o extensible Agent, Erweiterung auch mit Shell-Scripten möglich
o SNMP-Trap-Fänger als Deamon
andere OS
- viele Hersteller bringen eigene Agenten mit
- Vielfalt der SNMP-RFC’s zwingt zum genauen Vergleich der…. (unvollständig)
Beispiel eines SNMP-Agenten – UCD – SNMP
eMail – elektronische Post im Internet
- Architektur und Dienste
- UserAgents, Mailprogramme
- Header und Nachrichten …
- SMTP
eMail Architektur und Dienste
Anforderungen an eMail
- Kommunikation zwischen Personen, die zu unterschiedlichen Zeiten arbeiten
- Speicherung der ausgetauschten Informationen
- Unabhängigkeit von allen technischen Eigenschaften der benutzten Systeme:
o Betriebssystem des eingesetzten Rechners
o Anwendung mit der die eMail erstellt/gelesen wird
o Nationale Lokalisierung des Anwenderrechners
o Zeitzone der beteiligten Systeme
- Schutz gegen zeitweise Unterbrechung des Übertragungswegs
- Nachvollziehbarkeit der Kommunikation
- Telekommunikationsbehörden empfehlen ITU X.400
- Rechner- und Netzwerkhersteller empfehlen SMTP
Architektur der Internet eMail nach RFC 822
- Prinzip elektronischer Post
- Kommunikation zwischen Agenten
o User Agent
o Message Transfer Agent (MTA)
o Kommunikation über TCP-Port 25 (SMTP) und TCP-Port 110 (POP3)
- Anwender sehen eine Programmoberfläche, in die der UA integriert ist
- Speicherung in Mailboxen
-
Alle Kontrollinformationen für die Übertragung wird den Agenten hinzugefügt
Funktion eines eMail User Agent (Mailprogramm)
Grundfunktionen:
- Abholen von Mail bei einem Mailserver (poll)
- Anzeige aller Subject-Zeilen (header-lines)
- Anzeige einer einzelnen Mail mit korrekt dargestellten (Sonter-)Zeichen (read)
- Erkennen von Dateianhängen zur korrekten Ablage (attachments)
- Ablage von gelesenen Mails in Ordnern (move)
- Löschen von gelesenen Mails (delete)
- Start eines Editors zur Erstellung einer neuen Mail (new)
- Start eines Editors mit dem Text einer empfangenen Mail (forward)
- Zwischenspeichern einer Mail bis der Server erreichbar ist (queuing)
Erweiterte Funktionen:
- Automatische Aktionen beim Eintreffen spezieller Mails
- Start von Anwendungsprogrammen zur Darstellung von Dateianhängen
- Integration in andere Anwendungsprogramme
Nachrichtenformate in RFC 821
- Analogie zur real post
- Umschlag (envelope):
o enthält alle für die Weiterleitung der eMail erforderliche Information
(Zieladresse, Priorität, Sicherheitsstufe)
- Kopfzeilen (header):
o enthält die Steuerinformationen für den UA
- Nachricht (body):
o Text der Nachricht, in Abhängigkeit von den header-Zeilen durch den UA
interpretiert und dargestellt
alle Felder nur 7 Bit ASCII !
Headerzeilen nach RFC 822/2822
MIME – Multipurpose Internet Mail Extension
Limitierung der eMail nach RFC 822/2822
- Nachrichten in Sprachen mit Umlauten
- Nachrichten in Sprachen mit nicht-lateinischen Schriftzeichen
- Nachrichten ohne Text, z.B. Audio, Video
MIME – Standard (RFC 1521)
- Verpackung der binären Informationen in 7 Bit ASCII Nachrichten
- Beibehaltung der RFC 822-Struktur aus Envelope, Header und Body
- Kann von reinen RFC 822-Mailsystemen weitergeleitet werden
- Nur Austausch der Anwendungsprogramme erforderlich für die „neuen“
Funktionen: Anhänge sind Mailbody im RFC-Sinn
- Mailclients können das „richtige“ Programm starten
MIME-Header
- MIME-Version
- ContentDescription
- … (unvollständig)
MIME – RFC 1521 – Content-Transfer-Encoding
Schema für die Codierung der Nachrichtenströme
- ASCII-Text: 7 Bit, max. 1000 Zeichen pro Zeile: englischer Text
- extended ASCII-Text: 8 Bit, max. 1000 Zeichen pro Zeile
o toleriert von manchen Mailsystemen
o Zerstörung der binären Inhalte beim Transport möglich
- Quoted Printable Encoding
o Codierung aller Zeichen über ASCII = 127 durch NN (NN: hex-Wert des
Zeichens)
- base64-encoding: 24 Bit werden in 4 Einheiten
- … (unvollständig)
- Datenmenge um 4/3 vergrößert
- Operation sehr schnell
- keine Verschlüsselung der Daten, nur Verschleierung
Content Type type/subtype
- Darstellung des Inhalts durch die Möglichkeit des empfangenen Systems bestimmt
- Viele ContentTypes sind schon definiert (text/plain)
Auswertung im Client
Implementierung in internet-konformen (RFC 1521) Systemen
- Zuordnung der möglichen Werde zu lokalen Anwendungen je Anwendung
gepflegt
- Bisher nicht bekannte MIME-Typen werden jedem User individuell zur Auswahl
angeboten
Implementierung Microsoft
SMTP – Simple Mail Transfer Protocoll
- Bei Verbindungsanfragen auf TCP-Port 25 wird eine Serveranwendung gestartet
(z.B. sendmail)
- Einfaches ASCII-Protokoll mit Befehlen aus 4 Buchstaben
o HELO/EHLO
o MAIL FROM
o RCPT TO
o DATA
o QUIT
- Überprüfung der Gültigkeit der eingegebenen Parameter
o Syntax des Behfehls
o Auflösbarkeit der benutzten Domains mit dem dns-resolver des Mailservers
o keine Begrenzung
o …
Beispiel für Senden einer Mail
UA
MTA
Zustellung der eMail an den Empfänger
- Bereitstellung von Mailboxen für lokale Benutzer durch den letzten MTA
- Speicherung von eingehender eMail bis zur Anmeldung des Benutzers
- POP3 Post Office Protokoll Nr.3 TCP 100 (RFC 1225)
o Abholen und explizites löschen der eMail auf dem Server (polling)
o Ablage der abgeholten Mails auf dem Client, von dem der Benutzer sich
angemeldet hat
o Möglichkeit des offline-Arbeitens
o zentrale Datensicherung
www – World Wide Web
- Grundlagen
- HTML – Die Sprache zur Darstellung im Web
- http – Übertragungsprotokoll
- Anwendungen
o Standardbrowser
o Proxy-Architektur, automanic proxy configuration
o Aktive Inhalte
o Zugriffsschutz in http
Grundlagen und Historie des www
- Grundlagenforschung am CERN mit geographisch weit verstreuten
Wissenschaftlern erfordert ein Netz aus verknüpften Dokumenten
- 1989 realisiert Tim-Berners-Lee den ersten www-Prototypen
- 1995 gründet der Autor des Mosaic-Browser, Marc Andreessen, die Fa. Netscape
Communications Corp.
- Wegen der Einfachheit der Client-Server-Architektur des www entstand eine
Vielzahl von unterschiedlich implementierten Programmen weltweit
- Die Idee der Dokumentenverknüpfung unabhängig vom eingesetzten Programm
wird seid 1994 durch das W3C fortgeführt
- Die Kommerzialisierung führte inzwischen zu sehr starker Abhängigkeit von den
eingesetzten Programmen
Verwechslung zwischen Inhalt und Darstellung/Layout
Uniform Ressource Locator – URL
Voraussetzung: Syntaktisch einheitliche Darstellung aller Dokumente
Ziel: Verknüpfungen von Teildokumenten im Kontext des Lesens
{protokoll}://{user}:{password}@{host}:{port}/{path}/{document}?{query_string}
user, password, port und query_string sind optionale Elemente
Protokolle im URL-Feld:
- http
Hypertext Transfer Protocol (TCP-Verbindung auf Port 80)
- ftp
File Transfer Protocol (TCP-Verbindung uaf Port 21)
- telnet
Remote Login (TCP-Verbindung auf Port 23)
- news
Lesen eines USENET-Artikels (TCP-Port 119)
-
file
mailto
Zugriff auf lokale Dateien
Aufruf eines lokalen Mailprogramms
Architektur des www – RFC 1630
- Client-Server Architektur
- stateless (jede Operation ist ohne Zusammenhang mit der vorherigen)
- http – Hypertext Transfer Protocol, i.d.R. über TCP-Port 80
- URL – Uniform Ressource Locator
- Verknüpfungen der Dokumente (hyperlinks) durch den Autor festgelegt
- die Server kennen sich nicht
- Browser stellen die Informationen nur dar
- Inhaltsbeschreibung durch MIME-Header nach RFC 1521
(Abb. 5.15, S. 191)
http – Hypertext Transfer Protokoll (RFC 1945, 2616, 2817)
Prinzipieller Ablauf nach Auswahl eines Hyperlinks:
- Browser zerlegt URL und fragt den dns-Resolver nach dem hostname
- dns liefert eine IP-Adresse
- Browser baut eine TCP-Verbindung zum entsprechenden Socket auf dem Server
auf
- Browser sendet den GET-Befehl für das gewünschte Dokument
- Server sendet die Datei
- Browser baut die TCP-Verbindung ab
- Browser analysiert die Seite und stellt den Text dar
- Für alle Bilder in dieser Seite wird danach eine eigene TCP-Verbindung aufgebaut,
jedes Bild einzeln übertragen und an der vorgesehenen Stelle dargestellt
HTTP 1.1 (RFC 2616/2817) erlaubt persistente Verbindungen, die meisten Browser spielen
nicht mit
RFC 1945/2616 – http – Layer 7: Browser fragt Server
Anfragen vom Browser (Beispiele einiger http-Methoden):
- Reines ASCII-Protokoll, alle Methoden nur in Großbuchstaben
- GET
- HEAD
- POST
{Methode} {URL}
{Protokollversion}
GET
/index.html HTTP/1.0
<weitere Headerzeilen>
<Leerzeile>
Anfrage zum Lesen einer vollständigen Seite
Anfrage zum Lesen nur des Headers einer Seite
Übertragen von Informationen vom Browser zum Server
- TRACE
Anfrage wird, ergänzt um Serverinformationen, reflektiert, ohne dass der
Server ein Dokument ausliefert und dies im Logfile vermerkt wird
http – Layer 7: Status
Antworten des Servers in derselben TCP-Verbindung (meist auf Port 80)
Headerzeilen, Beispiele einiger Status-Codes
200 OK
204 No Content
206 Partial Content
301 Moved permanently (URL-redirection)
305 Use Proxy
400 Bad request (meist falsches Zeichen (z.B. Umlaut) im Request)
403 authorization required
404 not found
500 Server Error
Den Meldungen folgen:
- MIME Header
o content type
o content-transfer-encoding
- Status-Header
- und das Dokument (entsprechend dem content-type)
http – Layer 7: Header
Spezifische MIME-Header im http-Protokoll:
- Accept encoding:
compress, gzip
- Referer:
http://some.host/page-with-source-link.html (Woher?)
- Location:
http://www.w3.org/pub/www/people.html (Umleitung!)
- Last Modified:
TUE, 15 Nov 1994 12:45:26 GMT
- User-Agent:
CERN-LineMode/2.15 libwww/2.17b3
- Retry-After:
120 (Anzahl von „Wartesekunden“)
- Via:
alle beteiligten Personen verm???en sich hier
- www-Authenticate:
{challenge}
- Authorization:
{credentials}
und viele mehr, wird aber oft nicht ausgewertet
HTML – Hypertext Markup Language
- HTML beschreibt die Formatierung eines Dokuments
- HTML-Dokumente bestehen aus ASCII-Text
- HTML definiert spezielle Markup-Tags aus ASCII-Zeichen, die vom Autor in die
Dokumente eingebaut werden
<HTML> … </HTML>
<HEAD> … </HEAD>
<TITLE> … </TITLE>
<BODY> … </BODY>
<Hn> … </Hn>
<UL> … </UL>
<LI> … </LI>
<OL> … </OL>
<P>
Dokument ist mit HTML markiert
Begrenzt den Header des Dokuments
Begrenzt den Titel des Dokuments
Begrenzt den Textkörper des Dokuments
n=1-6: Begrenzt eine Überschriftenzeile
umrahmt eine unnummerierte Liste
begrenzt ein Listenelement
begrenzt eine Liste mit Positionsnummern
beginnt einen neuen Abschnitt (Paragraph)
<A HREF=“…“>…</A>
markiert einen Hyperlink (Anker)
Beispiel einer HTML-Seite
Dynamische Generierung von HTML-Seiten
- Der http-Server an TCP-Port 80 kann Programme benutzen, um die Informationen
dynamisch zusammenzustellen
- CGI : Common Gateway Interface
o erlaubt die Parameterübergabe an solche Programme
o ermöglicht dynamische Seitenerstellung ohne die Software des http-Servers zu
verändern
- Typische Programmiersprachen für dynamische Seiten sind:
o PERL - Practical Extraction and Reportgeneration Language
o PHP – Personal Homepage Processor
o jede andere Programmiersprache für das Betriebssystems des Servers
- Java
o erstellt die HTML-Seite lokal in einer virtual machine im Browser
o oder mit JSP (Java Server Pages) in der VM des Servers
- JavaScript/Active X
o können einige (wenige) Funktionen innerhalb der großen Browser (Netscape
und Microsoft IE) ausführen
(Abb. 5.17, S. 200)
RFC 2617 – Zugriffsschutz im http
Schutz aller http-Zugriffe (alle http-Methoden)
- Zugriff auf zusammengehörige URLs begrenzt: Realm (Gebiet)
- Realm ist meist ein Verzeichnisbaum oder eine Anwendung
Ablauf einer geschützten Anfrage:
- Browser versucht Zugriff ohne Credentials
o Status Code 401
o www-Authenticate:{challenge}, die Challenge ist oft nicht die Realm
- Browser sucht passende Credentials zu dieser Challenge
o im eigenen Cache (i.d.R. aus dieser Session)
o in einer Passwort-Datei (Internet Explorer: „Passwort speichern“)
o durch eine Frage beim User
- Credentials werden base64 codiert im Authorization:Header geschickt
- Verfahren läuft bei jeder Seite genauso ab, viele Browser schicken allerdings
bereits „vorsorglich“ den Authorization:Header mit
Session Authentication sicherer, nur Session-ID mit jeder Seite geschickt
Strukturierung der Any-to-Any – Proxy Architektur
(Abb. 5.16, S. 197)
Any-to-Any
Pro:
Jeder Browser erreicht alle potentiellen Server weltweit
Contra:
Adressknappheit
Netzgrenzen
Sicherheit
Automatic proxy configuration
isPlainHostName(url)
dnsDomainls(host, domain)
isResolvable(host)
isInNet(host, pattern, mash)
dateRange(day)
timeRange(hour)
(Tab. 5.22, S.198)
NETSCAPE
vorteilhafte Sicherheitsaspekte (z.B. timeRange/dataRange)
MIME-Header: contenttype: application/x-ns-proxy-autoconfig
Sicherheit in internetbasierenden Datennetzwerken
- Grundlagen
- Angriffsszenarien
- Abwehrstrategien
o organisatorische Regelungen
o Firewallbetrieb
Menschen mit guten und bösen Absichten
guter Hacker:
- detailverliebt, neugierig kreativ
- programmiert gerne hochspezialisierte Systeme, die „keiner“ versteht
- findet neue Wege außerhalb eingefahrener Wege
- keineswegs auf Computer angewiesen
böser Hacker:
- dringt unauthorisiert in fremde Systeme (Gebäude, Netzwerke, Rechner) ein
- verschafft sich „Achtung“ in der Szene durch high-score-Listen
- hat wenig oder kein Wissen über das, was er anrichtet (script-kiddies)
- verdient den Lebensunterhalt i.d.R. nicht durch die Erstellung von Software
- sind anfällig gegen kommerzielle Versuchungen, gekoppelt mit social engineering
Bedrohungen für Netzwerke und Systeme
Vertraulichkeit
- Abhören der (unverschlüsselten) Informationen
- Diebstahl von Informationen
o komplette Dokumente, eigentlicher Empfänger erhält gar nichts
o Wissensdiebstahl (durchaus auch nur teilweise, Subject-Zeilen)
o Hintertüren/Trojaner installieren
Ehrlichkeit
- ist der angegebene Absender tatsächlich die Person, die ich kenne?
- Prüfung gegen dritte Instanz (Public-Key-Infrastucture, Web-of-Trust)
Integrität
- ist der angekommene Inhalt identisch mit dem abgesendeten
Nicht-Abstreitbarkeit
- „Die Rechnung habe ich nie bekommen, also zahle ich nicht!“
- Prüfung gegen dritte Instanz
Prüfung der Sicherheit-Auditierung
- Warum?
o IT-Systeme von Unternehmen müssen laut KonTraG (Gesetz zur Transparenz
von Konzernen) auditiert werden.
o Finanzdienstleister benötigen Sicherheitspläne (Basel II)
- BackBox-Text
o nur öffentliche Quellen und social engenieering
o Lahmlegen des Systems wahrscheinlich
o bei Firmenüberpfüfungen ehr ungewöhnlich
- ChrystalBox-Test
o Netzwerkverwalter und „Angreifer“ arbeiten zusammen
o komplette Dokumentation (auch Passworte) liegt dem Prüfer vor
o Überwinden der ersten Sicherheitswälle durch Prüfungen im LAN
o Lahmlegen (denial-of-service) wird vermieden
- GreyBox-Test
o Teilwissen, Netzwerkverwalter „misst“ die Zeit, bis der Rest der Informationen
bekannt ist
Authentication – Authorization
- Warum?
o Nutzergerechte Kostenverteilung
o Angebot zeit-/anzahlabhängiger Leistungen (Digital Rights Management)
o Kopplung verschiedener Anwendungen (online-Banking, offline-Banking)
o Rollenkonzepte entsprechend organisatorischer Festlegungen
o Verarbeitung personalbezogener Daten (BDSG, TKDG)
- Authentication eines Menschen
o Prüfung eines/mehrerer Merkmale
- shared secret (Passwort)
-
- Wissen und Besitz (PIN und SmartCard)
- Biometrie
Authentication eines Rechners
o Ethernet-Adresse / IP-Adresse
o CPU-ID
o TCPA (Trusted ComPuting Alliance) – Fritz-Chip
IP-Spoofing = Vortäuschen einer Absenderadresse
IPv4 benötigt Absender-Adresse gar nicht, erst TCP benutzt den Rückweg
Angriffszenarien auf unsichere TCP/IP-Implementierungen
- technikgetriebene RFC’s
- nur good guys in der Entwicklung beteiligt
- Übernahmeungeprüften Quellcodes in
eigene Programme
Struckturierung des Netzwerkübergangs
Grundsätze der Absicherung von Netzwerken
- Jeglicher Datenverkehr zwischen zwei Netzen muss die Firewall passieren
- ‚default-deny’ Policy
o erlaubte Dienste werden explizit freigeschaltet
o was nicht explizit erlaubt ist, ist verboten
- nur die benötigten Dienste sind erlaubt
o Festgelegt in Sicherheits-Politik des Unternehmens
- Firewall Logs müssen ständig beobachtet/ausgewertet werden
o nur so können Angriffe rechtzeitig erkannt werden
o permanente Ausbildung der beteiligten Personen erforderlich
- Sicherheitsmaßnahmen folgen dem Grundsatz der Verhältnismäßigkeit
o Potentieller Schaden und Aufwand für dessen Verhinderung abwägen
o Bedrohungs- / Risikoanalyse relativ zum Geschäftszweck
- Wirksamkeit der Sicherheitsmaßnahmen muss regelmäßig überprüft werden
o alle 6 Monate externes Audit
o jeden Monat internes Audit
Begriffsdefinition Firewall
- Chapman/Zwichy: Eine Firewall ist eine Komponente, die den Zugriff zwischen
einem geschützten Netz und dem Internet oder zwischen sonstigen Netzen
beschränkt
- Cheswich/Bellowin: Eine Ansammlung von Komponenten zwischen 2 Netzen
wird Firewall genannt, wenn folgende Bedingungen erfüllt werden:
o Jeglicher Verkehr zwischen den Netzen muss die Firewall passieren
o Nur der im Sicherheitskonzept vorgesehene Verkehr wird durchgeschleust
- Manche Anbieter: Eine Firewall ist gut, wenn sie viel kostet und keine Arbeit
macht
Eine Firewall ist ein Konzept, kein Gerät!
Firewall – Statischer Paket-Filter
-
-
-
-
Beispiel:
o permit tcp host 1.2.3.4 gt 1023 any eq www
o permit tcp any eq www host 1.2.3.4 gt 1023
Schützt gegen
o Zugriffe/Angriffe auf interne Dienste
o Adressfälschung (Spoofing)
Schwächen
o nur elementare Filtermöglichkeiten
o keine Filterung der Applikationsdaten
Stärken
o hohe Durchsatzraten
o günstige Realisierung
Funktionsprinzip: Filterung aufgrund von TCP/IP Header-Informationen
Firewall – Dynamischer Paketfilter – stateful inspektion
-
-
-
Beispiel
o permit tcp host 1.2.3.4 gt 1023 any eq www
o permit tcp any eq www host 1.2.3.4 gt 1023 established
Schützt zusätzlich gegen
o Denial-of-service Angriffen gegen ext. Dienste
o FIN-Scans
Schwächen
o keine Filterung von Applikationsdaten
Stärken
o hohe Durchsatzraten
o verbesserte Filtermöglichkeiten
Funktionsprinzip: Filterung aufgrund von TCP/IP Header-Informationen und internen
Zustandstabellen
Firewall – Application-Gateway – Proxy
-
-
-
Beispiel
o permit http command get from any to http-server
o deny ftp command put from internal to any
Schützt zusätzlich gegen
o unerwünschte Nutzung von externen Diensten
Schwächen
o relative geringe Durchsatzraten
o für jeden Netzwerkdienst eigene Anwendung (Proxy) erforderlich
Stärken
o hohe Sicherheit
o Analyse von Applikationsdaten (kann z.B. „tunnelung“ verhindern)
Funktionsprinzip: Analyse des Applikationsdatenstroms; Lesen des entsprechenden RFC;
Kontext einer Anwendung entnehmen
Firewall-Architektur – 1stufige Systeme
- eine Komponente mit Filterfunktion
- geringe Sicherheit durch fehlende Redundanz in den Sicherheitskomponenten
- Einsatzgebiet: Kopplung von Netzen mit leichtem Gefälle der
Vertrauenswürdigkeit
- Beispiel: Zwei verschiedene Abteilungen einer Unternehmenseinheit
Firewall-Architektur – 2stufige Systeme
- zwei Komponenten mit Filter- und Loggingfunktion
- Sicherheit durch Herstellerwechsel
- Einsatzgebiet: Kopplung von Netzen mit mittlerem Gefälle der
Vertrauenswürdigkeit
- Beispiel: Zwei verschiedene Einheiten eines Unternehmens
Firewall-Architektur – 3stufige Systeme
- drei Komponenten mit Filter- und Loggingfunktion
- Sicherheit durch Herstellerwechsel
- Einsatzgebiet: Kopplungen von Netzen mit hohem Gefälle der
Vertrauenswürdigkeit
- Beispiel: Unternehmen / Internet
Internet
Paketfilter
Applikation
Gateway
Paketfilter
Internes
Netz
Firewall - DeMilitarisierte Zone (DMZ)
- Ausgangsfrage: Wie können A und B Mails austauschen, ohne dem jeweils
anderen Zugang zum internen Netz zu gewähren?
- Antwort
o Mailserver in extra Netzsegment (DMZ)
o (Paket-)Filter akzeptieren (SMTP/POP) Verbindungsaufbau nur von innen
nach außen
Sichere Anbindung eines Webservers
- Paketfilter erlaubt (www) Verbindungsaufbau nur von außen in die DMZ – schützt
Gateway
- Gateway
- (unvollständig)
Fill-Blown-Up/Realität
Schlussfolgerung – Was kann eine Firewall?
- Eine Firewall
o steht im Blickpunkt von Sicherheitsentscheidungen
o ist einziger Verbindungspunkt zwischen Netzen
- Eine Firewall erzwingt
o eine Sicherheitspolitik
o eine Entscheidung über zulässige und nicht-zulässige Dienste sowie
Nutzungsbeschränkungen
- Eine Firewall ermöglicht
o eine genaue Überwachung der Dienstnutzung
o als einziger Verbindungspunkt ist jeder Datenverkehr an der Firewall sichtbar
- Eine Firewall verhindert Freigabe interner Informationen
Schlussfolgerung – Was kann eine Firewall nicht?
- vor internen Angreifern schützen
o kann zu Nachlässigkeit bei Absicherung interner Systeme führen
- vor Verbindungen schützen, die an der Firewall vorbei gehen
o organisatorische Regeln erforderlich
- vor Inhaltsmanipulation schützen
o Verschlüsselung mit starker Kryptographie schützen
- vor neuen und noch nicht adressierten Angriffen schützen
o Angreifer sind kreative Menschen
- vor Konfigurationsfehlern schützen
o Abwehrer sind auch nur Menschen
- vor Angriffen auf öffentlich zugängliche Systeme schützen
o solche Systeme müssen extra gehärtet werden
- vor Viren, Trojanern, etc. schützen
o Hierfür sind 3rd Party Produkte notwendig
o organisatorische Regelungen helfen
o gesunder Menschenverstand („I love you“)