15.4 Netzwerkverbindungen
Das Tool netstat kennen Sie bereits. Es ist in der Lage – der Name lässt bereits darauf schließen – eine Übersicht über den »Status« des Netzwerks zu geben. Dies umfasst zum Beispiel eine Übersicht über bestehende IPv6-Verbindungen oder die Nutzung von Netzwerkschnittstellen. Letztere Information erhält man im Übrigen auch via ifconfig.
15.4.1 Datenaufkommen von Schnittstellen
Das Datenaufkommen kann entweder durch ifconfig oder via netstat abgefragt werden.
Listing 15.26 Informationen zur Ethernet-Schnittstelle
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:50:04:E9:AE:1B
inet addr:192.168.0.3 Bcast:192.168.0.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1207 errors:0 dropped:0 overruns:0 frame:0
TX packets:1086 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:126448 (123.4 Kb) TX bytes:171926 (167.8 Kb)
Interrupt:9 Base address:0xd400
Listing 15.27 netstat
$ netstat -i|egrep 'Iface|eth0'
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 1254 0 0 0 1121 0 0 0 BMRU
Gehen wir die wichtigsten Teile dieser beiden Ausgaben einmal durch. Zunächst füllt vielleicht der Parameter HWaddr 00:.... auf. Dabei handelt es sich um die sogenannte MAC-Adresse der Ethernet-Schnittstelle. [Fn. MAC steht für Medium Access Control.] Layer 1 des TCP/IP-Schichtenmodells verwendet diese MAC-Adresse zur Identifikation. Die Internet-Adresse sowie die Netzmaske sind Ihnen bereits bekannt; die Broadcast-Adresse (Bcast) hingegen ist Ihnen wahrscheinlich neu. Über sie lassen sich alle Hosts in diesem (Sub-)Netzwerk zugleich erreichen (sofern sie darauf konfiguriert sind, auf Broadcast-Nachrichten zu antworten).
Die Flags UP, BROADCAST, RUNNING und MULTICAST signalisieren, dass das Interface aktiv ist, Daten empfangen kann und Broadcasting sowie Multicasting unterstützt. [Fn. Multicasting ist eine spezielle Möglichkeit, um, ähnlich wie beim Broadcasting, mehrere Systeme auf einmal anzusprechen. Näheres erfahren Sie im RFC zum IGMP-Protokoll.]
Außerdem ist zu sehen, dass die maximale Datenmenge (Maximum Transmission Unit, MTU) 1500 Bytes beträgt – der Standardwert für Ethernet-Netzwerke. Die Routing-Metrik dieses Interfaces hat den Minimalwert »1«. Das bedeutet, dass Datenpakete auf direktem Wege zum Ziel gelangen. Weitere Informationen stellen unter anderem die bereits über das Interface übermittelte Datenmenge, die Anzahl der Kollisionen und die Anzahl der versendeten bzw. erhaltenen Frames dar.
Die Ausgabe von netstat -i ist der von ifconfig inhaltlich recht ähnlich. Die Spalten MTU und Met geben die bereits bekannte Maximum Transmission Unit sowie die Metrik der Schnittstelle an. Die RX- und TX-Spalten geben an, wie viele Pakete empfangen bzw. gesendet wurden. Dabei stehen die Abkürzungen »OK« jeweils für erfolgreich versandte bzw. empfangene Pakete, »ERR« für fehlerhafte Pakete, »DRP« für gedroppte (verworfene) Pakete und »OVR« für Overruns.
15.4.2 Protokollstatistiken
Allgemeine Protokollstatistiken kann netstat ebenfalls ausgeben. Dazu übergibt man einfach den Parameter -s. Von System zu System scheint einem die Datenmenge dabei entweder zu genügen oder überraschend groß zu sein. Zu sehen ist zunächst ein Aufruf des Kommandos unter Linux und später – allerdings stark verkürzt und nur, um Ihnen einen Einblick in die Statistikfähigkeit des BSD-Kernels zu geben – eine Ausgabe des gleichen Kommandos unter OpenBSD.
Listing 15.28 Protokollstatistiken
linux# netstat -s
Ip:
1339 total packets received
0 forwarded
0 incoming packets discarded
1309 incoming packets delivered
1309 requests sent out
Icmp:
29 ICMP messages received
2 input ICMP message failed.
ICMP input histogram:
destination unreachable: 15
echo requests: 14
29 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 15
echo replies: 14
Tcp:
1 active connections openings
2 passive connection openings
0 failed connection attempts
0 connection resets received
1 connections established
1310 segments received
1265 segments send out
0 segments retransmited
0 bad segments received.
1 resets sent
Udp:
0 packets received
0 packets to unknown port received.
0 packet receive errors
15 packets sent
TcpExt:
ArpFilter: 0
4 delayed acks sent
2 packets directly queued to recvmsg prequeue.
820 packets header predicted
TCPPureAcks: 191
TCPHPAcks: 888
TCPRenoRecovery: 0
TCPSackRecovery: 0
TCPSACKReneging: 0
TCPFACKReorder: 0
TCPSACKReorder: 0
TCPRenoReorder: 0
TCPTSReorder: 0
TCPFullUndo: 0
TCPPartialUndo: 0
TCPDSACKUndo: 0
TCPLossUndo: 0
TCPLoss: 0
TCPLostRetransmit: 0
TCPRenoFailures: 0
TCPSackFailures: 0
TCPLossFailures: 0
TCPFastRetrans: 0
...
...
openbsd$ netstat -s
ip:
10609 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
0 fragments received
0 fragments dropped (duplicates or out of...
0 malformed fragments dropped
0 fragments dropped after timeout
0 packets reassembled ok
10570 packets for this host
39 packets for unknown/unsupported protocol
0 packets forwarded
0 packets not forwardable
0 redirects sent
5819 packets sent from this host
5122 packets sent with fabricated ip header
0 output packets dropped due to no bufs, etc.
0 output packets discarded due to no route
0 output datagrams fragmented
0 fragments created
0 datagrams that can't be fragmented
0 fragment floods
0 packets with ip length > max ip packet size
0 tunneling packets that can't find gif
0 datagrams with bad address in header
0 input datagrams checksum-processed by h...
0 output datagrams checksum-processed by h...
icmp:
...
igmp:
...
ipencap:
...
tcp:
...
udp:
...
esp:
...
ah:
...
etherip:
...
ipcomp:
...
carp:
...
pfsync:
...
ip6:
...
icmp6:
...
rip6:
...
15.4.3 Aktive TCP-Verbindungen
Um uns eine Liste aktiver TCP-Verbindungen zu verschaffen, verwenden wir wieder einmal unser Lieblingstool netstat, denn TCP-Verbindungen aufzulisten zählt zu seinen Spezialitäten. Für jede aktive TCP-Verbindung gibt netstat -a das Flag ESTABLISHED aus. [Fn. Es gibt noch diverse andere TCP-Flags wie FIN_WAIT. Stevens beschreibt sie hervorragend in seinem leider etwas veralteten Buch »TCP/IP Illustrated Vol. 1«.]
Listing 15.29 Aktive TCP-Verbindungen
netstat -a | grep ESTABLISHED
tcp 0 48 faust.sun:ssh 192.168.0.1:40406 ESTABLISHED
Durch einen Doppelpunkt getrennt sind dabei zunächst der eigene Host und der lokale Port aufgelistet, anschließend der Remote-Host und dessen Port.
15.4.4 Listen-Ports
Auf fast jedem Rechner im Netzwerk laufen ein paar Dienste, etwa SSH oder ein Webserver. Diese Dienste benötigen in aller Regel (allerdings gibt es tatsächlich Ausnahmen) einen offenen Port, um Daten entgegenzunehmen. Geöffnete TCP-Ports werden in netstat mit dem Flag LISTEN versehen; unter UDP sieht man nur einen Eintrag ohne Flag. netstat zeigt Ihnen sogar aktive UNIX-Domain-Sockets an.
Listing 15.30 netstat -a
$ netstat -a|more
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Ad. (state)
tcp 0 0 eygo.40406 faust.ssh ESTABLISHED
tcp 0 0 eygo.nntp *.* LISTEN
tcp 0 0 localhost.nntp *.* LISTEN
tcp 0 0 *.ssh *.* LISTEN
tcp 0 0 *.www *.* LISTEN
tcp 0 0 localhost.submissi *.* LISTEN
tcp 0 0 localhost.smtp *.* LISTEN
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Ad. (state)
udp 0 0 *.* *.*
udp 0 0 *.syslog *.*
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Ad. (state)
tcp6 0 0 localhost.nntp *.* LISTEN
tcp6 0 0 *.ssh *.* LISTEN
tcp6 0 0 localhost.submissi *.* LISTEN
tcp6 0 0 localhost.smtp *.* LISTEN
Active UNIX domain sockets
...
Verwendet man bei netstat -a zusätzlich die Option -n, so unterdrückt man die Adressauflösung und sieht blanke IP-Adressen. Das Gleiche gilt für die Dienstbezeichnungen bei den einzelnen Ports. netstat bezieht die Port-Bezeichnungen aus der Datei /etc/services – in diese können gegebenenfalls auch eigene Dienste eingetragen werden. Diese Datei besteht aus Zeilen der Form »Name Portnummer/Protokoll«: [Fn. Analoge Informationen zu den einzelnen Protokollen finden Sie in der Datei /etc/protocols.]
Listing 15.31 Auszug aus /etc/services
tcpmux 1/tcp
echo 7/tcp
echo 7/udp
...
netstat 15/tcp
...
chargen 19/udp
ftp-data 20/tcp
ftp 21/tcp
ssh 22/tcp
ssh 22/udp
telnet 23/tcp
...
15.4.5 ARP-Cache
Die Hardwareadresse, also die MAC-Adresse, von Ethernet-Schnittstellen hatten wir bereits erwähnt. Über das (Reverse) Address Resolution Protocol (ARP) tauschen die einzelnen Hosts Informationen über MAC-Adressen und IP-Adressen aus. Diese werden im sogenannten ARP-Cache abgelegt, den man über das Programm arp abfragen und administrieren kann. In ihm werden Zuordnungen zwischen IP- und MAC-Adresse hergestellt, wodurch also von der MAC-Adresse auf die IP-Adresse geschlossen werden kann und umgekehrt.
Die Informationen sind (bis auf wenige explizit zu konfigurierende Ausnahmen) dynamisch, das heißt, sie werden nach einer bestimmten Zeit wieder gelöscht und müssen neu abgefragt werden, was netzwerkorganisatorische Gründe hat. Den aktuellen ARP-Cache kann man mit arp -a abfragen.
Listing 15.32 ARP-Cache abfragen
# arp -an
? (192.168.0.2) at <incomplete> on eth0
? (192.168.0.1) at 00:50:BF:11:35:A5 [ether] on eth0
Der Rechner im Listingbeispiel scheint also in letzter Zeit keine Kommunikation mit einem Host, der nicht im ARP-Cache steht, geführt zu haben. Um nun beispielsweise den Host 192.168.0.5 zu erreichen, müssen die Rechner zunächst untereinander ARP-Informationen austauschen. Diesen Austausch erzwingen wir, indem wir eine TCP/IP-Kommunikation (der Einfachheit halber über das Tool ping) mit dem Host starten.
Listing 15.33 Anpingen des Hosts 192.168.0.5
# ping 192.168.0.5
PING 192.168.0.5 (192.168.0.5) 56(84) bytes of data.
64 bytes from 192.168.0.5: icmp_seq=1 ttl=128
time=0.279 ms
^C
--- 192.168.0.5 ping statistics ---
1 packets transmitted, 1 received, 0 % packet loss,
time 0ms
rtt min/avg/max/mdev = 0.279/0.279/0.279/0.000 ms
Nun enthält der ARP-Cache auch die IP- und MAC-Adresse des Hosts 192.168.0.5:
Listing 15.34 Der aktuelle ARP-Cache
# arp -an
? (192.168.0.2) at <incomplete> on eth0
? (192.168.0.1) at 00:50:BF:11:35:A5 [ether] on eth0
? (192.168.0.5) at 00:00:CB:59:FD:BE [ether] on eth0
15.4.6 tcpdump
Sniffing
Hin und wieder (zum Beispiel bei der Entwicklung von Netzwerksoftware oder zur Fehlererkennung bei der Netzwerkadministration) ist es notwendig, sich die Netzwerkpakete anzusehen, die auf einer Schnittstelle ankommen und gesendet werden. Diese Tätigkeit bezeichnet man als Sniffing (Schnüffeln). Sniffing wird oft auch von Angreifern in Tools integriert, die dann Passwörter aus dem Datenstrom, der über eine Netzwerkschnittstelle läuft, herausfiltern oder Verbindungsinformationen filtern, die für ein erfolgreiches Hijacking benötigt werden. Da wir nun aber keine bösen Absichten verfolgen, werden wir Ihnen einfach das Standardtool vorstellen, mit dem Sie diese Funktionalität zur Fehlererkennung nutzen können.
Dieses Tool nennt sich tcpdump. Da es je nach Betriebssystem auf eine andere Art und Weise an die Daten der Netzwerkschnittstelle herankommt, verwendet tcpdump die Packet Capture Library (PCAP). Diese Library stammt von einigen Entwicklern der University of California (dort kommt auch BSD her) und kann systemunabhängig in jede mögliche Sniffing-Software integriert werden – sehr nützlich.
Startet man das Tool als normaler Nutzer, wird man feststellen, dass man keine Berechtigung zum Sniffen hat. Daher kann auch kein normaler Nutzer Netzwerkdaten auf diese Art und Weise ausspähen, was sicherheitstechnisch eindeutig von Vorteil ist.
Startet man tcpdump als Superuser, gibt man entweder eine gewünschte Schnittstelle an, auf der man sniffen möchte, oder aber man gibt keine an und lässt tcpdump selbst eine Schnittstelle wählen (was nicht immer das gewünschte Resultat bringt).
Übrigens: Läuft tcpdump erst einmal, läuft es so lange, bis man es mit Strg + C beendet.
Listing 15.35 tcpdump
# tcpdump
tcpdump: listening on ne3
18:24:18.376898 eygo.sun.38307 > yleigu.sun.ssh: P
3028219738:3028219786(48) ack 3768993598 win 16384
<nop,nop,timestamp 427496211 202175> (DF) [tos 0x10]
18:24:18.377807 yleigu.sun.ssh > eygo.sun.38307: P
1:49(48) ack 48 win 10880 <nop,nop,timestamp 351730
427496211> (DF) [tos 0x10]
18:24:18.497974 eygo.sun.38307 > yleigu.sun.ssh: P
48:96(48) ack 49 win 16384 <nop,nop,timestamp
427496212 351730> (DF) [tos 0x10]
18:24:18.498655 yleigu.sun.ssh > eygo.sun.38307: P
49:97(48) ack 96 win 10880 <nop,nop,timestamp 351743
427496212> (DF) [tos 0x10]
18:24:18.542230 eygo.sun.38307 > yleigu.sun.ssh: P
96:144(48) ack 97 win 16384 <nop,nop,timestamp
427496212 351743> (DF) [tos 0x10]
18:24:18.544097 yleigu.sun.ssh > eygo.sun.38307: P
97:145(48) ack 144 win 10880 <nop,nop,timestamp
351747 427496212> (DF) [tos 0x10]
18:24:18.554155 yleigu.sun.ssh > eygo.sun.38307: P
145:705(560) ack 144 win 10880 <nop,nop,timestamp
351748 427496212> (DF) [tos 0x10]
18:24:18.554254 eygo.sun.38307 > yleigu.sun.ssh: .
ack 705 win 15824 <nop,nop,timestamp 427496212
351747> (DF) [tos 0x10]
18:24:18.554609 yleigu.sun.ssh > eygo.sun.38307: P
705:769(64) ack 144 win 10880 <nop,nop,timestamp
351748 427496212> (DF) [tos 0x10]
18:24:18.750072 eygo.sun.38307 > yleigu.sun.ssh: .
ack 769 win 16384 <nop,nop,timestamp 427496212
351748> (DF) [tos 0x10]
^C
10 packets received by filter
0 packets dropped by kernel
In unserem Fall hat sich tcpdump die Schnittstelle ne3 ausgewählt, um darauf zu sniffen. Dabei wird (sofern nicht der Parameter -p angegeben wurde) diese Schnittstelle in den sogenannten Promiscuous Mode geschaltet. In diesem Modus werden alle Netzwerkpakete angenommen, die die Schnittstelle annehmen kann (auch wenn sie nicht an sie adressiert sind). In Netzwerken mit einem Hub bekommt man auf diese Weise alle Daten des Netzwerks; in Netzwerken mit einem Switch ist dies nicht der Fall. Ob sich eine Netzwerkkarte im Promiscuous Mode befindet, zeigt ein Aufruf von ifconfig durch das PROMISC-Flag.
Listing 15.36 Promiscuous Mode
$ ifconfig ne3
ne3: flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,
PROMISC,ALLMULTI,SIMPLEX,MULTICAST>
mtu 1500
address: 00:50:bf:11:35:a5
media: Ethernet autoselect (10baseT)
inet 192.168.0.1 netmask 0xffffff00 broadcast
192.168.0.255
inet6 fe80::250:bfff:fe11:35a5 %ne3 prefixlen
64 scopeid 0x1
Doch nun zurück zur Ausgabe von tcpdump. Wie ist diese Ausgabe zu interpretieren? Leider ist zum wirklichen Verständnis dieser Daten eine detaillierte Kenntnis der TCP/IP-Protokolle vonnöten, die wir in diesem Buch nicht voraussetzen können. Wir wollen allerdings zumindest den Aufbau und einige Details der Ausgabe erläutern.
Jedes empfangene Paket wird (standardmäßig ohne zusätzliche Parameter zur Detailausgabe) in einer Zeile ausgegeben. Zunächst sieht man den Zeitpunkt, an dem das Paket erhalten wurde – den sogenannten Timestamp (etwa 18:24:18.376898). Darauf folgt in diesem Fall (denn es handelt sich um eine TCP-Verbindung) der Quellhost mit Quellport, worauf der Zielhost und Zielport zu sehen sind. Im obigen Listing kommuniziert also der Host eygo.sun als SSH-Client mit dem SSH-Server yleigu.sun. Die restlichen Ausgaben betreffen Details der TCP-Verbindung, etwa das gesetzte PUSH-Flag, die Sequenz- und Acknowledgement-Nummer und die Window-Size. Zu sehen ist auch das Flag DF (vom Englischen don't fragment), das in Verbindung mit dem IP-Header steht, sowie der Type-of-Service-Wert des IP-Headers.
Listing 15.37 Die erste Zeile der Ausgabe
18:24:18.376898 eygo.sun.38307 > yleigu.sun.ssh: P
3028219738:3028219786(48) ack 3768993598 win 16384
<nop,nop,timestamp 427496211 202175> (DF) [tos 0x10]
Möchte man sich nun einen genaueren Überblick über solche Pakete verschaffen, verwendet man den Parameter -v oder auch -X für hexadezimale Ausgaben des Inhalts. Um eine noch detailliertere Ausgabe zu erzielen, kann man anstelle von -v auch -vv verwenden.
Listing 15.38 Auszug aus tcpdump -vvX
18:38:59.185321 eygo.sun.28042 > yleigu.sun.www: P[tcp sum ok] 1:18(17)
ack 1 win 16384 <nop,nop,timestamp 427497973 439551> (DF) [tos 0x10]
(ttl 64, id 44354, len 69)
0000: 4510 0045 ad42 4000 4006 0c0c c0a8 0001 ................
0010: c0a8 0003 6d8a 0050 e1cc 1457 ced0 2310 ................
0020: 8018 4000 9d3a 0000 0101 080a 197b 19f5 ..@..:.......{..
0030: 0006 b4ff 4845 4144 202f 2048 5454 502f ....HEAD / HTTP/
0040: 312e 300d 0a 1.0..
18:38:59.185615 yleigu.sun.www > eygo.sun.28042: . [tcp sum ok] 1:1(0)
ack 18 win 5792 <nop,nop,timestamp 439806 427497973> (DF) (ttl 64, id
38895, len 52)
0000: 4500 0034 97ef 4000 4006 2180 c0a8 0003 E..4..@.@.!.....
0010: c0a8 0001 0050 6d8a ced0 2310 e1cc 1468 .....Pm........h
0020: 8010 16a0 9f63 0000 0101 080a 0006 b5fe .....c..........
0030: 197b 19f5
Zu sehen ist eine HTTP-Kommunikation zwischen den beiden oben erwähnten Hosts. Dabei wird ein HTTP-HEAD-Request von eygo.sun an yleigu.sun gesendet, der daraufhin dieses TCP-Datenpaket bestätigt.
Ihre Meinung
Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.
