2 Pakete und Protokolle

15
2
Pakete und Protokolle
In diesem Kapitel werden die unteren Schichten der IP-Familie im Detail betrachtet.
NFS
NIS
Application
TFTP
SNMP
DNS
Presentation
portmapper
FTP
LPD
SMTP
TELNET
RPC
Session
XDR
UDP
Transport
Network
ICMP
IP
Data Link
TCP
ARP RARP
IEEE 802.3 Ethernet
andere
Physical
2.1 Ethernet und IEEE 802.3
0
1
2
3
preamble
8
receiver
sender
20
protocol (ip 0x800)
data, 46 to 1500 bytes
CRC, all but preamble and CRC
Ethernet-Pakete haben 64 bis 1518 Bytes (ohne preamble). Am protocol wird der Inhalt
unterschieden. Die Adresse ff:ff:ff:ff:ff:ff dient als Broadcast, wird also von allen
Netzkarten erkannt.
IEEE 802.3 enthält die Länge an Stelle der Protokoll-Nummer und muß daher noch ein logical
link control-Paket enthalten. Gebräuchliche Protokoll-Nummern sind groß, damit man sie nicht
mit Längen verwechseln kann.
16
2.2 ARP
0
1
2
3
hardware type (ethernet 1)
hardware bytes
4
protocol (ip 0x800)
protocol bytes
8
operation (1/2 ARP, 3/4 RARP)
sender hardware, sender protocol
receiver hardware, receiver protocol
ARP (RFC 826) setzt Ethernet Protocol 0x8086, Broadcast ff:ff:ff:ff:ff:ff und die
gesuchte IP-Adresse. Wenn ein Rechner seine IP-Adresse erkennt, füllt er seine HardwareAdresse aus. Es gibt Probleme, wenn zwei Rechner die gleiche IP-Adresse haben, weil sie
sich im Lauf der Zeit immer wieder widersprechen.
2.3 RARP
RARP (RFC 903) setzt Ethernet Protocol 0x8035, Broadcast und die gesuchte HardwareAdresse. Wenn ein Server(!) die Hardware-Adresse kennt, füllt er die IP-Adresse aus.
2.4 IP
0
1
version
hd words
priority
2
packet/fragment
unique id, to rejoin fragments
4
time to live
8
3
D T R C
N M
protocol
length in bytes
fragmentoffset
in bytes/8
header checksum
12
sender
16
receiver
options, filled to complete word
...
IP (RFC 791) verwendet einige type of service Bits, die die Priorität von Nachrichten festle-
gen, sowie Hinweise an die Router:
D
T
R
C
low delay
high throughput
high reliablity
low cost
IP kann Pakete fragmentieren, um sie durch Netze mit geringen MTU-Werten (maximum trans-
fer units) zu bringen. Sie müssen dann auch wieder rekombiniert werden:
N
M
don't fragment
more to come
Wenn N gesetzt ist und ein Paket nicht in ein Netz paßt, wird es verworfen. Die Fragmente
werden anhand ihrer id erkannt und anhand von offset zusammengesetzt, bis M nicht mehr
gesetzt ist.
time to live wird in jedem Router um 1 reduziert, bis ein Paket verworfen wird — dann
erfolgt eine ICMP-Meldung.
options sind Bytes, die zur Diagnose dienen.
17
2.5 ICMP
ICMP (RFC 792) sind Meldungen, die in IP-Paketen als Daten mit protocol 1 verschickt wer-
den. Sie bestehen mindestens aus 4 Bytes: Typ, Code und 2 Bytes mit einer Prüfsumme.
ping schickt als Typ 8, als Code 0, und fügt zwei Bytes mit einer id, zwei Bytes mit einer
Sequenznummer und einige Datenbytes hinzu. Die Antwort erhält den Typ 0.
Mit ICMP-Fehlermeldungen, zum Beispiel Typ 3 (destination unreachable), Typ 4 (source
quench) oder Typ 11 (ttl exceeded) kann man Netzprobleme untersuchen.
traceroute sendet Pakete mit fortschreitend größerer time to live und bestimmt aus den ICMPMeldungen die wahrscheinliche Route zum Ziel.
2.6 UDP
0
1
4
2
3
sender port
receiver port
length, UDP header and data
checksum
UDP (RFC 768) ist ein verbindungsloses, unsicheres Datagram-Protokoll auf Benutzer(Prozeß-) Ebene. Zum IP-Paket kommen Port-Nummern für Sender und Empfänger sowie
eine Daten-Prüfsumme hinzu, die allerdings die IP-Adressen auch berücksichtigt:
0
1
2
3
sender
receiver
0
protocol (udp 0x11)
length, UDP header and data
0
sender port
receiver port
4
length, UDP header and data
checksum
UDP hat verschiedene, wichtige Anwendungen:
TFTP
DNS
SNMP
RPC
NFS
RFC
RFC
RFC
RFC
RFC
1350
1034
1157
1831
1813
trivial file transfer protocol
domain name service
simple network management protocol
remote procedure call
network file system
Start von Rechnern ohne Platte
IP-Adressen für Namen
Rechnerbetrieb via Datenbank
auch über TCP
wesentlichste RPC-Anwendung
18
2.7 TCP
0
1
2
3
sender port
4
8
12
receiver port
sequence number
acknowledgment
hd words
number
U A P R S F
16
window
checksum
urgent pointer
options, filled to complete word
...
data
...
TCP (RFC 793) ist ein verbindungsorientiertes, sicheres Byte-Strom-Protokoll auf Benutzer(Prozeß-) Ebene. Zum IP-Paket kommen Port-Nummern für Sender und Empfänger, Informa-
tionen zur Absicherung der Übertragung und für vorrangige Daten sowie eine Daten-Prüfsumme hinzu, die allerdings die IP-Adressen auch berücksichtigt:
0
1
2
3
sender
receiver
0
protocol (tcp 0x6 )
length, TCP header and data
sender port
4
sequence number
acknowledgment
8
12
16
receiver port
hd words
number
U A P R S F
checksum
window
urgent pointer
options, filled to complete word
...
data
...
Man bezeichnet ein TCP-Paket als Segment.
Vorrangige Informationen liegen vor, wenn URG gesetzt ist. Sie befinden sich dann am Anfang
der Datenfläche und urgent pointer ist die Anzahl der vorrangigen Bytes.
sequence number ist ein vom Sender über Verbindungen hinweg fortlaufender Byte-Zähler,
der die Position des ersten, nicht-vorrangigen Bytes im Datenstrom bezeichnet.
acknowledgment number ist gültig, wenn ACK gesetzt ist, und ist dann die nächste sequence
number, die vom Sender erwartet wird, bezeichnet also die Position des ersten Bytes im
Strom, das noch nicht empfangen wurde.
PUSH wird gesetzt, damit der Empfänger die Daten nicht puffert, sondern sofort der Applikation
liefert. RESET wird im Notfall gesetzt, um eine Verbindung brutal abzubrechen. SYN wird in
Segmenten gesetzt, die zur Verbindungsaufnahme dienen. FIN wird in Segmenten gesetzt,
die zum Abbau der Verbindung dienen.
window teilt mit, wieviel Bytes maximal zwischen sequence und acknowledgment liegen
können. Diese Größe wird zur Flußkontrolle variiert.
Es gibt eine einzige option, mit der die maximale Größe für ein Segment mitgeteilt wird.
19
Verbindungen
Das Quadrupel aus Sender- und Empfänger-Adresse und -Port-Nummer ist per Verbindung
eindeutig (und deshalb Teil der Prüfsumme). Das heißt, zwei verschiedene Verbindungen
können auf einem Rechner durchaus die gleiche Port-Nummer verwenden.
TCP- und UDP-Port-Nummern bilden voneinander verschiedene Adreßräume.
Aufbau und Abbau einer Verbindung werden durch das folgende (bezüglich Fehlern und
Abbrüchen nicht vollständige) Zustandsdiagramm beschrieben:
closed
bind
connect
close
close
SYN
listen
SYN
SYN+ACK
send
syn received
SYN
ACK
ACK
SYN
syn sent
SYN+ACK
ACK
close
FIN
close
established
FIN
fin wait 1
ACK
fin wait 2
FIN
ACK
FIN
ACK
close wait
FIN
ACK
close
FIN
closing
last ack
ACK
ACK
time wait
closed
timeout 2MSL
Die Pfeile sind Zustandsänderungen, die durch Anforderungen an die Transportschicht (fett)
oder durch Empfang von ACK-, SYN- oder FIN-Segmenten (rot) ausgelöst werden. In der Regel
werden dann entsprechende Segmente (blau) verschickt.
ACK wird anhand der acknowledgment number zugeordnet. ACK darf nur sequentiell verschickt
werden — ein fehlendes Segment unterbindet weitere ACK. Gehen ACK verloren, können
deshalb Löcher akzeptiert werden.
20
Verbindungsaufbau
Beim Aufbau einer Verbindung müssen Sender und Empfänger ihre nächste sequence number bekanntgeben. Dies geschieht mit insgesamt zwei SYN- und einem ACK-Segment:
syn 123
syn 456 ack 124
ack 457
Bleiben Antworten mit ACK-Segmenten zu lange aus, muß erneut übertragen werden. Der
three way handshake dient dazu, vielfaches Hin und Her zu vermeiden:
syn 123
syn 123
syn 456 ack 124
syn 456 ack 124
ack 457
syn 456 ack 124
ack 457
Ein einfaches SYN/ACK könnte sehr leicht zu unendlich vielen Wiederholungen führen. Dies
wird unter anderem durch die Nummern vermieden.
21
Übertragung
Im Zustand established werden dann (bei Bedarf in beiden Richtungen!) Daten und ACK
übertragen:
123 data abcd
127 data xyz
456 ack 127
456 ack 130
ACK muß innerhalb einer Zeitschranke empfangen werden. Zu deren dynamischer, variabler
Bestimmung gibt es komplizierte Algorithmen, unter anderem von Phil Karn (KA9Q).
Bis zu window Bytes können ohne Empfang von ACK geschickt werden. Jedes ACK schiebt
dann dieses Fenster weiter (sliding window), wobei innere ACK nicht gesendet werden
brauchen.
Der Empfänger teilt bei ACK das verbleibende Fenster mit, damit der Sender entsprechend
weniger schickt — dies gilt allerdings nur, wenn gültige Daten übertragen wurden. Hat der
Empfänger wieder Platz, schickt er ein ACK mit einer neuen Fenstergröße — allerdings erst,
wenn der Puffer zu 25% leer ist oder wenigstens ein maximales Segment empfangen kann
(silly window algorithm).
Beim Start einer Verbindung wird das Fenster langsam vergrößert (slow start algorithm) und
später wird das Fenster bei zu vielen Wiederholungen verkleinert, um Netzüberlastung zu vermeiden (congestion avoidance).
Kleine Datenpakete werden nach Möglichkeit beim Sender gepuffert, um die weiteren Schichten weniger zu belasten (Nagle algorithm).
Echo
Eine wichtige Anwendung ist das Netz-Terminal-Protokoll TELNET. Dabei muß inbesondere
ein zeichenweises Echo möglichst effizient verschickt werden:
123 push data c
123 push data c
456 ack 124 data c
456 ack 124
124 ack 457
456 ack 124 data c
124 ack 457
Je nach Geschwindigkeit des Servers (rechts) benötigt man für ein Echo drei oder vier Segmente.
22
Verbindungsabbau
Zum ordentlichen Abbau der Verbindung muß jede Seite ein FIN-Segment verschicken und
ein ACK dafür empfangen. Je nach Zustand wird dann noch die doppelte maximale SegmentLebensdauer (MSL) abgewartet.
123 fin
456 fin ack 124
124 ack 457
Mit netstat kann man relativ häufig unvermittelt abgebrochene Verbindungen im Zustand time
wait entdecken.
Fazit
TCP hat sehr viele wichtige Anwendungen:
FTP
HTTP
SMTP
TELNET
X11
RFC
RFC
RFC
RFC
RFC
959
2616
821
854
1013
file transfer protocol
hypertext transfer protocol
simple mail transfer protocol
network terminal
X Window System protocol
Datei-Übertragung
World Wide Web
elektronische Post
remote login
Fenster-System
Die einzige Fehlerkorrektur erfolgt end to end, ist aber wegen relativ verläßlicher Übertragungen trotzdem recht effizient — insbesondere wegen der dynamisch änderbaren Fenster.
23
2.8 tcpdump
tcpdump erlaubt der Netzkarte, alle Pakete einzulesen, und läßt sich vom Kern ausgewählte
Pakete liefern, die dann dargestellt werden. Aus Sicherheitsgründen ist tcpdump nur für den
Super-User verfügbar.
tcpdump optionen filter-expression
Wesentliche Optionen kontrollieren die Art der Ausgabe:
-dd
-e
-s len
-t
-v
-x
filter-expression darstellen; sonst nichts
Ethernet- (statt IP-) bezogen
Paketlänge
kein Zeitstempel
mehr Information
Hex-Dump der Paketdaten
Ohne filter-expression wird alles berichtet. Eine filter-expression wird als PseudoCode in den Kern geladen und dort bezüglich eines Pakets interpretiert:
$ tcpdump -dtxv host molly and udp port domain
(000) ldh
[12]
12: ethernet type code
(001) jeq
#0x800
jt 2
jf 160x800: IP
(002) ld
[26]
26: ip sender
(003) jeq
#0x83ad0dd1
jt 6
jf 4131.173.13.209 molly
(004) ld
[30]
30: ip destination
(005) jeq
#0x83ad0dd1
jt 6
jf 16
(006) ldb
[23]
23: ip protocol
(007) jeq
#0x11
jt 8
jf 160x11: udp
(008) ldh
[20]
20: ip flags (fragmenting)
(009) jset
#0x1fff
jt 16
jf 10fragmented?
(010) ldxb
4*([14]&0xf)14: ip header length (wds)
(011) ldh
[x + 14]
udp 0: sender port
(012) jeq
#0x35
jt 15
jf 130x35: DNS
(013) ldh
[x + 16]
udp 2: receiver port
(014) jeq
#0x35
jt 15
jf 16
(015) ret
#68
(016) ret
#0
filter-expression kann sich also auf die Felder der verschiedenen Header beziehen und
diese und/oder/nicht verknüpfen und auch arithmetisch prüfen. Dies ist hinter einer Vielzahl
von symbolischen Namen und relativ verwirrenden Abkürzungen versteckt:
term:
C-constant
PROTOCOL [ offset : size ]
len
product:
term * term ...
term / term ...
sum:
product + product ...
product - product ...
bit-and:
sum & sum ...
bit-or:
bit-and | bit-and ...
primitive: bit-or RELOP bit-or
Literal
ether ip icmp arp rarp udp tcp
1, 2, oder 4 Bytes
Paketlänge
< <= > >= != =
Bis hierher kann man mit einer C-ähnlichen Syntax Bytes in den Protokoll-Schichten bit-weise
untersuchen.
24
Als Abkürzungen, die syntaktisch ebenfalls als primitive gelten, kann man die interessanten
Felder symbolisch abfragen, zum Beispiel:
primitive: ether proto NAME
\ip \arp \rarp
ip proto NAME
\icmp \tcp \udp
ether src NAME
Ethernet-Host
ether dst NAME
ether host NAME
ether broadcast
Ethernet Broadcast
src host NAME
IP-Host
dst host NAME
host NAME
ip broadcast
IP Broadcast (0 oder 1)
PROTOCOL dst port NUMMBER \udp \tcp Port-Nummer
PROTOCOL src port NUMMBER
PROTOCOL port NUMMBER
Man kann viel weglassen, denn Angaben werden auch von primitive zu primitive kopiert.
Es gibt auch Tests für Pakete, die das lokale Netz verlassen.
primitive schließlich werden verknüpft, wobei fehlende Angaben zu Feldern immer als Wildcard interpretiert werden:
negation:
not primitive
primitive
( union )
intersection: negation and negation ...
union:
intersection or intersection ...
Beispiele
clark
molly
penny
venus
0:a:27:e2:ef:46
0:30:65:b0:15:da
0:a0:cc:20:bb:2f
0:60:8:26:17:79
131.173.13.200
131.173.13.209
131.173.13.205
131.173.13.210
Assigned Numbers findet man zum Beispiel im RFC 1700.
ARP: Beim Start von venus versucht penny, venus zu finden; venus antwortet selbst. Außerdem versucht venus, den (nicht-existenten) Router zu finden:
$ tcpdump -tev host 131.173.13.210 and arp
tcpdump: listening on en0
0:a0:cc:20:bb:2f Broadcast arp 64: arp who-has venus tell 131.173.13.205
0:60:8:26:17:79 0:a0:cc:20:bb:2f arp 64: arp reply venus is-at 0:60:8:26:17:79
0:60:8:26:17:79 Broadcast arp 64: arp who-has 131.173.13.254 tell venus
25
Führt man auf venus
$ ping clark
aus, muß venus clark finden:
$ tcpdump -texv host 131.173.13.210 and arp
tcpdump: listening on en0
0:60:8:26:17:79 Broadcast arp 64: arp who-has 131.173.13.200 tell venus
0001 0800 0604 0001 0060 0826 1779 83ad
0dd2 0000 0000 0000 83ad 0dc8 c8c8 c8c8
c8c8 c8c8 c8c8 c8c8 c8c8 c8c8 c8c8 44d4
0d39
0:a:27:e2:ef:46 0:60:8:26:17:79 arp 68: arp reply 131.173.13.200 is-at
0:a:27:e2:ef:46
0001 0800 0604 0002 000a 27e2 ef46 83ad
0dc8 0060 0826 1779 83ad 0dd2 c8c8 c8c8
c8c8 c8c8 c8c8 c8c8 c8c8 c8c8 c8c8 44d4
0d39 3457 5e14
ping selbst findet in IP-Paketen statt (ist aber ICMP):
$ tcpdump -txv host 131.173.13.210
tcpdump: listening on en0
venus > 131.173.13.200: icmp: echo
4500 003c
83ad 0dc8
6566 6768
7576 7761
131.173.13.200 > venus: icmp: echo
4500 003c
83ad 0dd2
6566 6768
7576 7761
and icmp
request (ttl 32, id 37376)
9200 0000 2001 e5cc 83ad 0dd2
0800 415c 0300 0900 6162 6364
696a 6b6c 6d6e 6f70 7172 7374
6263
reply (ttl 255, id 14654)
393e 0000 ff01 5f8e 83ad 0dc8
0000 495c 0300 0900 6162 6364
696a 6b6c 6d6e 6f70 7172 7374
6263
Auf molly kann man mit nslookup direkt DNS-Anfragen bearbeiten. Der DNS-Server muß
erreichbar sein, sonst finden ARP-Anfragen zwecks Routing statt:
$ tcpdump -txv host molly and
tcpdump: listening on en0
molly.1055 > venus.53: 15645+
4500
83ad
0001
01
udp port domain
A? foo. (21) (ttl 64, id
0031 09e8 0000 4011 4dd7
0dd2 041f 0035 001d 256f
0000 0000 0000 0366 6f6f
2536)
83ad 0dd1
3d1d 0100
0000 0100
Macht man das auf venus, muß man völlig anders filtern:
$ tcpdump -txv host 131.173.13.210 and ip broadcast
tcpdump: listening on en0
venus.137 > 131.173.13.255.137: udp 50 (ttl 128, id 60160)
4500 004e eb00 0000 8011 2c73 83ad 0dd2
83ad 0dff 0089 0089 003a 8110 00c2 0110
0001 0000 0000 0000 2045 4745 5045 5043
4143 4143 4143
Hier wird UDP auf Port 137 verwendet -- das ist Windows' Netbios.
26
SYN- und FIN-Pakete beim TCP-Verbindungsauf- und -abbau kann man beobachten, indem
man die relevanten Flaggen filtert und zum Beispiel einen TELNET-Anruf (rot) tätigt:
$ tcpdump -t 'host venus and tcp[13:1] & 3 != 0' &
tcpdump: listening on en0
$ telnet venus
molly.1143 > venus.telnet: S 3305751711:3305751711(0) win 32768
<mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF) [tos 0x10]
venus.telnet > molly.1143: S 3550809343:3550809343(0) ack 3305751712 win 32120
<mss 1460,nop,nop,timestamp 7325201[|tcp]> (DF)
venus.1032 > molly.auth: S 3548526334:3548526334(0) win 32120
<mss 1460,sackOK,timestamp 7325203[|tcp]> (DF)
telnet> q
molly.1143 > venus.telnet: F 75:75(0) ack 122 win 33304
<nop,nop,timestamp 124467 7325216> (DF) [tos 0x10]
venus.telnet > molly.1143: F 122:122(0) ack 76 win 32120
<nop,nop,timestamp 7329858 124467> (DF)
Man sieht, daß eine Reihe von Optionen übermittelt werden und daß der TELNET-Server ohne
Erfolg versucht, eine Verbindung zurück zu einem Authentication-Server (RFC 931) aufzubauen, der ihm die Benutzer-Identität mitteilen soll.
Das abschließende ACK des three way handshake wird durch die Filterung unterdrückt.
27
2.9 ethereal
ethereal ist ein grafisches Frontend für tcpdump, das zum Beispiel unter Linux verfügbar ist:
Unter Capture kann man in einem Panel einen Filterausdruck eintragen und dann Pakete
sammeln:
Im Hauptfenster wählt man oben ein Paket. In der Mitte kann man mehr Informationen zu den
einzelnen Schichten aufklappen und unten sieht man die Rohdaten.
28