10.4 Netzwerkverbindungen 
Das Tool netstat kennen Sie bereits. Netstat ist in der Lage – der Name lässt bereits darauf schließen – eine Übersicht über den »Status« des Netzwerks zu geben. Das beinhaltet zum Beispiel eine Übersicht über bestehende IPv6-Verbindungen oder die Nutzung der Netzwerkschnittstellen.
Letztere erhält man im Übrigen auch via ifconfig.
10.4.1 Datenaufkommen von Schnittstellen 
Das Datenaufkommen kann entweder durch ifconfig oder via netstat abgefragt werden.
$ 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:0xd400Listing 10.26 Informationen zur Ethernet-Schnittstelle
$ 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
Listing 10.27 netstat
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. <MAC steht für Medium Access Control.> Die Adressierung auf 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 für Sie wahrscheinlich neu. Über diese Adresse lassen sich alle Hosts in diesem (Sub-)Netzwerk auf einmal erreichen (sofern diese 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. <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 ist der Ersteren 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.
10.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.
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:
...Listing 10.28 Protokollstatistiken
10.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 seiner Spezialität. Für jede aktive TCP-Verbindung gibt netstat -a das Flag ESTABLISHED aus. <Es gibt noch diverse andere TCP-Flags wie FIN_WAIT. Stevens beschreibt diese Flags hervorragend in seinem leider etwas veralteten Buch »TCP/IP Illustrated Vol. 1«.>
netstat -a | grep ESTABLISHED tcp 0 48 faust.sun:ssh 192.168.0.1:40406 ESTABLISHED
Listing 10.29 Aktive TCP-Verbindungen
Durch einen Doppelpunkt getrennt sind dabei zunächst der eigene Host und der lokale Port und anschließend der Remote-Host und dessen Port aufgelistet.
10.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 (und es gibt 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.
$ 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 ...
Listing 10.30 netstat -a
Verwendet man hier zusätzlich den Parameter -n, 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 Portnamen aus der Datei /etc/services – in diese können gegebenenfalls auch eigene Dienste eingetragen werden. Diese Datei baut sich in der Form Name Portnummer/Protokoll auf: <Analoge Informationen zu den einzelnen Protokollen finden Sie in der Datei /etc/protocols.>
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 ...
Listing 10.31 Auszug aus /etc/services
10.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 die MAC-Adressen und IP-Adressen aus. Diese Informationen werden im so genannten ARP-Cache abgelegt, den man über das Programm arp abfragen und administrieren kann. In diesem ARP-Cache werden Zuordnungen zwischen IP- und MAC-Adresse hergestellt. Dadurch kann also von der MAC-Adresse auf die IP-Adresse und andersherum geschlossen werden.
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.
# arp -an ? (192.168.0.2) at <incomplete> on eth0 ? (192.168.0.1) at 00:50:BF:11:35:A5 [ether] on eth0
Listing 10.32 ARP-Cache abfragen
Der Rechner 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. Das erzwingen wir, indem wir eine TCP/IP-Kommunikation (der Einfachheit halber über das Tool ping) mit dem Host starten.
# 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
Listing 10.33 Anpingen von 192.168.0.5
Nun enthält der ARP-Cache auch die IP- und MAC-Adresse des Hosts 192.168.0.5:
# 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
Listing 10.34 Der aktuelle ARP-Cache
10.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.
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 dies möglich ist.
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 Sniffingsoftware 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 weiter, bis man es durch Strg+C beendet.
# 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
Listing 10.35 tcpdump
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 die Schnittstelle adressiert sind). In Netzwerken mit einem Hub bekommt man so 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.
$ 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 0x1Listing 10.36 Promiscuous Mode
Doch nun zurück zur Ausgabe von tcpdump. Was soll das alles bedeuten? 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 Ausgaben 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 (Don't Fragment), was in Verbindung mit dem IP-Header steht, sowie der Type-of-Service-Wert des IP-Headers.
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]
Listing 10.37 Die erste Zeile der Ausgabe
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. Übrigens: Um eine noch detailliertere Ausgabe zu erzielen, kann man anstelle von -v auch -vv verwenden. Damit die Ausgabe der Seitenbreite gerecht wird, mussten wir leider eine kleinere Schriftart verwenden.
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 19f5Listing 10.38 Auszug aus tcpdump -vvX
Zu sehen ist eine HTTP-Kommunikation zwischen den beiden oben bereits erwähnten Hosts. Dabei wird ein HTTP HEAD-Request von eygo.sun an yleigu.sun gesendet, der darauf dieses TCP-Datenpaket bestätigt.
