Einfache TCP-Verbindung mit netcat

Wenn für Server und Client nicht zwei verschiedene Rechner zur Verfügung stehen, kann man auch beide auf localhost laufen lassen. (Das Zeichen # steht für die Eingabeaufforderung der Konsole.)

In diesem Beispiel lauscht beim Server auf TCP-Port 30000 ein netcat auf eine Verbindung. Diese wird dann vom Client angefordert. Alles, was auf einer der beiden Konsolen eingegeben wird, erscheint auch auf der anderen. Es werden also jeweils Standard-Input des einen mit Standard-Output des anderen verbunden.
wireshark zeigt den Verkehr so an.

(wireshark sollte iübrigens als Superuser gestartet werden um die volle Funktionalität zu bieten.)

Nun soll die Datei eintext.txt vom Client zum Server übertragen werden (die andere Richtung geht analog). Zu diesem Zweck wird auf dem Client die Eingabe umgleitet zur Datei eintext.txt. Die Ausgabe des Servers wird umgelenkt zu test.txt. (Der Server ist zwar hier derjenige, der die Datei empfängt, aber das macht gar nichts. Es ist auch völlig belanglos, welche Art von Datei übertragen wird; es muss keine Textdatei sein.)

Als nächstes soll ein ganzes Verzeichnis als Datei übertragen werden und auf dem Zielrechner wieder als Verzeichnis abgespeichert werden. Dazu werden mit Hilfe von Pipes tar und netcat verbunden. Diesmal machen wir die Übertragung vom Server zum Client, um zu sehen, dass das ebenso einfach geht.

Klartextprotokolle auf einer TCP-Verbindung mit netcat

Eines der einfachsten Protokolle ist daytime, das, wenn es läuft, auf Port 13 lauscht. Wenn ein Client die Verbindung herstellt, muss er gar nichts weiter sagen und bekommt sofort die aktuelle Zeit in Klartext übermittelt. Um den Dienst auf dem Server einzuschalten, muss der Internet-Daemon einmal gestartet werden. Danach stehen dauerhaft mehrere kleine Dienste zur Verfügung, daytime ist einer davon.

wireshark zeigt den Verkehr so an.

Interessanter wird die Sache, wenn der Client vor dem Datenaustausch mit dem Server reden muss, wie dies etwa bei den Protokollen POP oder HTTP der Fall ist. Starten wir also auf dem Serverrechner den Webserver Apache und holen uns mit dem Client eine html-Datei.

Nach Eingabe der leeren Zeile kommt die meist recht lange Antwort vom Webserver, die aus einem Antwortheader und dem HTML-Inhalt besteht.
Da die GET-Anfrage aus drei Zeilen besteht, die man nicht ausreichend schnell tippen kann, wird die Anfrage in zwei oder drei Päckchen (Frames) übertragen. Das funktioniert zwar, entspricht aber nicht dem alltäglichen Verhalten. Um die Anfrage schnell genug bereit zu haben, kann man sie aber auch in einer Datei (httpanfrage) vorrätig halten und mit einer Eingabeumleitung "zuschießen". Die leere Zeile muss dann Teil dieser Datei sein.
Auf der Serverseite steht diesmal kein Befehl, weil angenommen wurde, dass der Apache noch vom Beispiel vorher läuft. Den muss man natürlich nicht jedesmal neu starten.

wireshark zeigt den Verkehr so an.

Übungsaufgabe

Gegeben sind ein Windows- und ein Linux-Rechner jeweils mit Standardsoftwareausstattung. Insbesondere hat der Windows-Rechner kein netcat. Wie bekommt man schnell eine beliebige Datei von Linux zu Windows?

Lösung:

SSL-verschlüsseltes Protokoll mit Mozilla

Damit die übertragenen Daten nicht durch Abhören des Netzwerks mitgelesen werden können, bieten viele Webserver und Browser die Verschlüsselungsschicht SSL. Sie wird verwendet, wenn man den Server über den Port 443 anspricht (oder durch Angabe von https). (Der Apache-Server ist bei Knoppix so konfiguriert, dass er die zu liefernden Dateien nicht im Verzeichnis /var/www, sondern in /var/www-ssl erwartet.) Die Anwendung dieser Schicht kann man aber nicht mehr mit netcat durchspielen, dazu braucht man schon die Fähigkeiten eines Browsers, weil mehrere komplizierte Schritte nötig sind:

1. Der Browser fordert eine Seite mit https an (Port 443)
2. Der Server schickt seinen öffentlichen Schlüssel und sein Zertifikat
3. Der Browser testet, ob das Zertifikat von einer vertrauenswürdigen Stelle ausgegeben wurde, ob es noch gültig ist und ob es sich auf die aktuelle Adresse bezieht. Wenn nicht, wird der Benutzer gewarnt.
4. Der Browser verschlüsselt mit dem erhaltenen öffentlichen Schlüssel einen zufälligen symmetrischen Sitzungsschlüssel und schickt ihn zusammen mit der ebenfalls verschlüsselten URL an den Server.
5. Der Server entschlüsselt alles mit seinem privaten Schlüssel und verwendet den erhaltenen symmetrischen Schlüssel, um die gewünschte URL zu ermitteln und um den weiteren Verkehr zu verschlüsseln, d.h.
6. Der Server sendet die symmetrisch verschlüsselte html-Datei an den Browser
7. Der Browser entschlüsselt die erhaltenen Daten und zeigt sie an.

wireshark zeigt den Verkehr so an.

Netze mit Hub oder Switch: arping

Bis jetzt haben wir den Netzwerkverkehr nur vom Client oder Server her abgehört. Zu einem ordentlichen Abhörangriff gehört aber schon ein dritter, unbeteiligter Rechner, der sich illegal Zugriff verschafft. Dieser Zugriff ist sehr leicht herstellbar, wenn die Rechner alle an einem Hub hängen, weil die Signale dann immer zu allen angeschlossenen Netzwerkkarten gelangen. Die Karten hören nur normalerweise nicht zu, wenn der Inhalt nicht an sie adressiert ist, wenn also die Empfängeradresse nicht die ihre ist.

Ob eine Karte dem vollständigen Verkehr zuhört, ist vom Benutzer root konfigurierbar. Er kann die Karte in den "promiscuous mode" versetzen. Das folgende Bild zeigt einen Lauscher-Rechner, der alle Netzwerk-Päckchen mithört, die ihn erreichen und wegen des Hubs erreichen ihn alle!

Wenn die Rechner jedoch an einem Switch hängen, erreichen den Lauscher nur Pakete, die an ihn adressiert sind. Um mehrere Verbindungen gleichzeitig bedienen zu können, verbindet der Switch nämlich jeweils nur die beiden kommunizierenden Partner. Dies wird erreicht, indem der Switch an Hand der ausgetauschten Pakete mitnotiert, welche MAC-Adressen an welchem seiner Ports hängen. Gleich nach dem Einschalten arbeitet er noch wie ein Hub, aber kurze Zeit später weiß er, welche Pakete wohin müssen. Der Lauscher bekommt dann die ihn interessierenden Pakete nicht, weil sie nicht an ihn gerichtet sind.

Der Switch kann es sich jedoch nicht erlauben, an jedem seiner Ports nur eine MAC-Adresse zu zuzulassen; es könnte ja ein Hub dran hängen mit vielen zu bedienenden Netzwerkkarten und damit MAC-Adressen. Der Switch muss sich also für jeden Port mehrere MAC-Adressen merken können (die kleinen Kästchen an den Ports stehen für die gemerkten MAC-Adressen).

Man kann den Switch auf zweierlei Weise überlisten:

1. Man spielt ihm durch geeigneten Netzwerkverkehr vor, dass die MAC-Adresse, deren Verkehr den Lauscher interessiert auch am Lauscherport hängt und die Pakete also auch dort hin zu senden sind. Der Switch weiß zwar, dass es nicht sein kann, dass die gleiche MAC-Adressen an mehreren Ports hängt, aber er weiß nicht, von welchem Port er belogen wurde und sendet deshalb den Verkehr auch an den Port mit dem Lauscher.
2. Man zwingt den Switch dazu, sich am Lauscherport mehr MAC-Adressen zu merken, als in seinen Speicher passen. Dann gibt er auf und arbeitet wie ein Hub.

Das ist übrigens gar nicht so schwer! Zwar hat jede Netzwerkkarte ihre eigene MAC-Adresse, aber im promiscuous mode muss diese nicht verwendet werden. Jede andere geht auch. Da man im hauseigenen Netz die MAC-Adressen der zu belauschenden Rechner alle schon kennt (z.B. weil man den DHCP-Server konfiguriert hat), schreibt man sie am besten alle in eine Datei - jede in eine eigene Zeile - und führt das folgende Skript aus, um den 1. Ansatz zu durchzuführen:

    while read mac
      do arping -c 1 -p -s $mac 192.168.1.45
    done
  

Beim Aufruf dieses Skripts leitet man als Eingabe die Datei mit den MAC-Adressen um, damit man sie nicht selber eintippen muss. Hier noch eine kurze Erklärung des arping-Aufrufs:

-c 1 erzeugt jeweils nur einen Schuss ins Netz
-p versetzt die Netzwerkkarte in den promiscuous mode, damit die Sender-MAC gefälscht werden kann
-s $mac setzt die MAC-Adresse des gesendeten Päckchens auf den nächsten Eintrag aus der Datei
192.168.1.45 ist eine beliebige IP aus dem zu belauschenden Netz. Unser Rechner soll ja irgendetwas intelligentes ins Netz plappern und stellt deshalb die Frage, wer denn diese IP hat. Die Antwort möge bitte an den Rechner mit der MAC-Adresse $mac geleitet werden. Gut, dass der Switch das mitbekommt und dadurch auf die gewünschte falsche Idee kommt.

Das vollständige Skript finden Sie hier.