Wer vertraut eigentlich einem Betriebssystemhersteller? Vertrauen Sie Microsoft? Apple? Sun? Den Entwicklern von Linux, BSD und Co? Wirklich? Ich gehe durch einen kleinen FreeBSD-basierten Router ins Internet, und habe daher die Gelegenheit, dem Traffic auf die Finger zu schauen, den meine Rechner als eine Art "Grundrauschen" erzeugen. Denn eigentlich kein Betriebssystem will heute noch davon ausgehen, dass es nicht nach draussen telefonieren kann. Interessant waere natuerlich auch noch zu wissen, wer da denn was nach draussen tratscht -- aber so weit gehe ich dann doch nicht. Hier eine kurze Anleitung, wie man seiner ganz persoenlichen Paranoia nachgehen kann.

Das Nezwerksetup

Zunaechst einmal, die Beschreibung, mit welchem Aufbau man die Uebung nachturnen kann: Benoetigt wird eine Maschine, auf der, ein FreeBSD oder ein andere unixoides System, auf welchem iftop zum laufen zu bringen ist, installiert ist. Ferner muss die Maschine ueber zwei Netzwerkkarten verfuegen, wenn man sie als transparente Bruecke nutzen will. Transparente Bruecke bedeutet dabei schlicht und einfach, dass die angeschlossenen Rechner nicht sehen, dass diese Maschine mitliest; fuer die "Opfer" verhaelt sich dieser Rechner wie ein Stueck Kabel.
Sodann kann man sich der Einrichtung einer Bruecke zuwenden. Das sieht konkret z.B. so aus:

[ad001@glas /usr/home/ad001]$ sudo ifconfig bridge0 create
[ad001@glas /usr/home/ad001]$ sudo ifconfig bridge0 addm em0
[ad001@glas /usr/home/ad001]$ sudo ifconfig bridge0 addm rue0
[ad001@glas /usr/home/ad001]$ sudo ifconfig bridge0 up
[ad001@glas /usr/home/ad001]$ sudo ifconfig rue0 up
[ad001@glas /usr/home/ad001]$ sudo ifconfig em0 up
Zur Erklaerung:
Mit dem ersten Befehl wird eine neue Bruecke namens bridge0 erstellt. Danach werden der Bruecke die beiden anderen Netzwerkkarten (also diejenige, die ins Internet verbunden ist und diejenige, an der das zu beobachtende Objekt (z.B. ein Mac mit Mac OS) angestoepselt wird) hinzugefuegt. In meinem Falle ist em0 die Kabelverbindung zum zu beobachtenden Subjekt und rue0 die Verbindung in die weite Welt.
Uebrigens: Keine der beiden Seiten der Bruecke muss eine IP erhalten -- das Bridgeing geschieht auf ISO/OSI-Layer 2 (Datalink-Layer, fuer mehr Infos siehe z.B. http://de.wikipedia.org/wiki/OSI-Modell). Anschliessend kann die Bruecke in Betrieb gesetzt werden, das Gleiche geschchieht danach noch mit den betiligten Anschluessen.
Der Rechner verhaelt sich nun prinzipiell wie ein Netzwerkkabel -- was auf der einen Seite rein geht, kommt auf der anderen wieder raus und das voellig transparent fuer angeschlossene Geraete. Diese koennen einzig aus den (etwas) schlechteren Latenzwerten vermuten, dass das Kabel etwas intelligenter geworden ist.
Natuerlich kann man sich den Aufwand, eine Maschine mit Tunnel zu bauen, auch sparen, wenn man einen Router hat, auf dem man iftop laufen lassen kann :)

Die Software

Wenn man mit dem Beobachten anfangen will, muss man sich zunaechst einmal die Frage stellen, was man denn eigentlich erwartet und was man will. Will man nur eine Uebersicht ueber die Verbindungen, die wer mit wem eingeht? Oder will man vielleicht auch mitlesen, was da (z.B. beim "Aktivieren" eines Windows) ausgetauscht wird? Hiernach richtet sich, wie man jetzt weitermacht. Man sollte allerdings bedenken, dass die folgenden Analysemethoden gerade bei viel Traffic auf der Bruecke nicht unbedingt CPU-schonend sind -- und das wiederunm kann die Leistungsfaehigkeit der Bruecke beeinflussen.
Nichtsdestoweniger: Interessiert einen nur, wer mit wem redet (und wie derjeniger heisst, auf welchem Port das stattfindet und wieviel Bandbreite sie verbraten), dann ist man mit iftop gut beraten. Will man hingegen in die Tiefe gehen und wissen, was ausgetauscht wird, dann sollte man zu tcpdump greifen. Der Aufruf gestaltet sich dabei wie folgt: 

[ad001@glas /usr/home/ad001]$ sudo iftop -i bridge0
Damit bekommt man eine mehr oder weniger huebsche Anzeige. Hat man sich selbst nun keine IP-Adresse gegeben, so kann man natuerlich auch keine Namensaufloesung erwarten (denn wie soll die Maschine auch DNS-Anfragen per UDP durchfuehren, wenn sie im Netzwerk keine Daten austauschen kann). Also kann man dem Netzwerkinterface, dass in Richtung Welt (Internet) schaut (WAN-seitig) eine IP geben und sich einen Nameserver eintragen. Gerne auch per DHCP.
Interessiert man sich dann doch fuer den genauen Inhalt, dann kann man zu tcpdump greifen, welches z.B. wie folgt gestartet wird: 
[ad001@glas /usr/home/ad001]$ sudo tcpdump -i bridge0 -s0 -A
Die Parameter bewirken, dass der Puffer pro Paket nicht begrenzt wird (-s0) und dass alle Paketdaten einfach in ASCII-Form nach stdout geschrieben werden. Das ist natuerlich nur dann wirklich sinnvoll, wenn auch Klartext-Daten uebers Netz geschickt werden; andernfalls bediene man sich der Parameter, die die Daten 1:1 in eine Datei schreiben. Hier sei noch davor gewarnt, dass mit tcpdump in kurzer Zeit zimlich viele Daten gesammelt werden koennen -- vor allem, wenn man tcpdump auf die Konsole durch ssh ueber eine beobachtete Verbindung laufen laesst -- und so eine Rueckkopplung baut.

Die Ergebnisse

Um es kurz zu machen: So kann der Output von iftop aussehen: 

                50.0Kb          100Kb           150Kb           200Kb      250Kb
+---------------+---------------+---------------+---------------+---------------
sc16.frf.llnw.net          => 192.168.0.191              137Kb   135Kb   131Kb
                           <=                           5.69Kb  5.16Kb  4.83Kb
192.168.0.1                => 192.168.0.191             2.70Kb  2.77Kb  2.47Kb
                           <=                             208b    208b    247b
email.uni-rostock.de       => 192.168.0.121                 0b   1.11Kb   355b
                           <=                               0b    698b    228b
192.168.0.1                => 192.168.0.2                   0b    689b   1.18Kb
                           <=                               0b    820b   1.33Kb
nbg.holzhauer.it           => 192.168.0.191                 0b      0b   13.3Kb
                           <=                               0b      0b   1.10Kb
192.168.1.1                => 192.168.0.121                 0b      0b     23b
                           <=                               0b      0b     37b
192.168.0.255              => 192.168.0.110                 0b      0b      0b
                           <=                               0b      0b     57b
ec2-79-125-9-9.eu-west-1.  => 192.168.0.191                 0b      0b     26b
                           <=                               0b      0b     26b
--------------------------------------------------------------------------------
TX:             cumm:   630KB   peak:    317Kb  rates:    140Kb   168Kb   158Kb
RX:                    50.6KB           70.9Kb           5.89Kb  22.2Kb  12.7Kb
TOTAL:                  681KB            333Kb            146Kb   190Kb   170Kb
...und nun kommt die spannende Frage, was da was anstellt. Die 192.168.0.0/255.255.255.0-Adressen sind das lokale, beobachtete Netz. Die 192.168.1.1 ist ein via Routing erreichbares Nachbarnetz. Jetzt bleiben noch diejenigen Peers, die einen Namen haben. Fangen wir oben mit sc16.frf.llnw.net an -- das ist ein Webstream (aber das weiss man auch nur, wenn man es herauszubekommen versucht), der gerade laeuft. email.uni-rostock.de ist einigermassen selbsterklaerend und mit einem Mailer auf der 192.168.0.121 verbunden. Aber was ist nbg.holzhauer.it? Hier wird es schwierig, denn nun haben wir DNS als Problem vor uns. Um es kurz mit einer *raeusper* Graphik zu veranschaulichen: 
ad001.de -----------------[DNS-Aufloesung]------------.
                                                       \
lando.cc -----------------[DNS Aufloesung]---------.    |
                                                    \   |
AurraSing.lando.cc -------[DNS Aufloesung]-----------87.106.187.149----[Reverse DNS]-----AurraSing.lando.cc
                                                    /   |
hypftier.de --------------[DNS Aufloesung]---------`    |
                                                       /
popoclub-deutschland.de --[DNS Aufloesung]------------`
...was will die Graphik sagen? Egal, welche Domain auf der linken Seite jemand besucht, wenn wir nur die IP-Adresse haben und eine Reverse-DNS-Aufloesung mit iftop machen, immer den auf der rechten Seite angegebenen Namen erhalten werden. Zu lustigen DNS-Phaenomenen, siehe auch ard-tagesschau-host.html.
Und nun, zumindest ansatzweise, ein Bisschen was zu tcpdump. Der Output kann ungefaehr wie folgt aussehen: 
[ad001@glas /usr/home/ad001]$ sudo tcpdump -i bridge0 -s0 -A port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vr0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:44:47.481511 IP glas.ad001.de.home.59670 > nbg.holzhauer.it.http: P 1:473(472
) ack 1 win 8208 
E...."@.@.h.....S......P1.      Qk=N... ..<.....
(.-^M,-Y.GET / HTTP/1.1
User-Agent: Opera/9.64 (X11; FreeBSD 8.0-BETA2 i386; U; en) Presto/2.1.1
Host: www.lawblog.de
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Cache-Control: no-cache
Connection: Keep-Alive, TE
TE: deflate, gzip, chunked, identity, trailers


10:44:47.530121 IP nbg.holzhauer.it.http > glas.ad001.de.home.59670: . ack 473 win 14 
E..4..@.6...S........P..k=N.1..)...........
,-Y.(.-
10:44:47.546406 IP nbg.holzhauer.it.http > glas.ad001.de.home.59670: . 1:1369(1368) ack 473 win 14 
E.....@.6...S........P..k=N.1..).....G.....
[...und so weiter...]
Um viel Rauschen auszufiltern, habe ich hier tcpdump noch mit einem Filter ausgestattet. Was man hier nun sehen kann, ist der Inhalt der Verbindung -- und zwar auch, was ich von nbg.holzhauer.it will und auf welchem Port. In solchen Logs wuerde man im uebrigen auch nichtverschluesselte Passworte wiederfinden. Und nun kommt der erschreckende Teil, der die Paranoia im Titel rechtfertigt: So eine Beobachtungsstation kann natuerlich auch beim ISP stehen. Oder dazwischen. Oder beim netten Mitbewohner, der seinen Leitung bereitwillig teilt. Wer Spass an sowas hat, kann ja mal ein tcpdump durch ein grep pipen, welches nach den passworten sucht... und dann ausgibt, wo wann welches Passwort im Klartext uebertragen wurde. Heisse Kandidaten sind Webseiten, die kein https benutzen, Mailer, die kein POP3s benutzen und Menschen, die telnet benutzen. Und erwaehnte ich, dass dies natuerlich auch die ideale Stelle waere, um die Daten zu veraendern?

Rechtliches Magengrummeln

Solange man das nur bei seinen eigenen Rechnern macht, ist das alles gar kein Problem. Wenn man aber derjenige in einer WG ist (oder Vermieter), der Internetzugang (als Teil des Mietobjektes) anbietet, dann sollte man sich hier in seiner Neugierde bremsen. Aufschlussreich ist es bestimmt, aber auch so indiskret. Und (zumindest moralisch ohne Zweifel) Unrecht...

Impressum