Teil 2: Client / Server

Bevor wir tiefer in das eigentlich Thema TCP/IP einsteigen, müssen wir uns zunächst die im ersten Teil gezeigte Kommunikation noch einmal genauer anschauen.

Wenn eine Software auf meinem Rechner mit einer Software auf einem anderen Rechner kommunzieren möchte, dann liegt einer von zwei Fällen vor:

1. Mein Rechner fragt bei dem anderen Rechner Daten ab.
2. Der andere Rechner fragt von meinem Rechner Daten ab.

Im 1. Fall handelt es sich bei mir um einen Client.
Im 2. Fall ist es bei mir ein Server.

Der Unterschied ist folgender:

Ein Client sendet über das Betriebssystem (dieser Teil wird auch TCP/IP-Stack genannt) Anfragen an einen Server, z.B. mein Firefox an den Server, auf dem www.computerproblemboard.de liegt.

Der TCP/IP-Stack weiß, daß es sich beim Firefox um einen Client handelt. Deswegen reicht er an den Firefox nur solche Pakete (= Daten) weiter, die auf seine Anfrage passen.
Ein Client nimmt also nur Antworten auf Fragen entgegen. Hat er keine Frage gestellt oder passt eine Antwort nicht zu der von ihm gestellten Frage, dann wirft der TCP/IP-Stack diese Antwort schlicht und einfach weg. Der Sender wird darüber informiert.
Beispiele für Clients: Browser, Mailprogramme, FTP-Programme zum Herunterladen von einem FTP-Server, Instant-Messenger-Programme (mit Einschränkungen).

Ein Server dagegen nimmt Anfragen entgegen und antwortet darauf. Von wem diese Anfrage kommt, ist zunächst einmal völlig egal. Alle Pakete, die die Adresse des Servers tragen (dazu später mehr) werden vom TCP/IP-Stack an den Server durchgereicht.
Ein Server ist also, solange keine Sicherheitsmaßnahmen getroffen werden, von Krethi und Plethi zu erreichen (oder von Hans und Franz).
Beispiele für Server: Webserver wie Apache und IIS (Microsoft), FTP-Server, SAMBA-Dateiserver.

Wichtig:
Eine Sonderrolle nehmen die Dienste unter Windows ein, von denen viele bestimmt schon gehört haben. Dazu gehört z.B. der berüchtigte RPC-Dienst, über den der Blaster hereinkam.
Diese Dienste sind technisch gesehen ebenfalls Server, d.h. sie nehmen jede Anfrage entgegen. Sie arbeiten mit Systemrechten, d.h. sie dürfen auf dem betroffenen System alles.

Wir halten fest:
Clients können aus dem Internet heraus schlecht angegriffen werden, da sie nur Antworten auf ihre eigenen Fragen zugestellt bekommen.

Server dagegen nehmen prinzipiell jede Anfrage aus dem Internet entgegen. Weist der Server nun einen Fehler auf, kann man über geeignete Anfragen (Pakete) den Server dazu bringen, daß er Dinge tut, die man eigentlich nicht möchte, z.B. Programme ausführen, die ein Angreifer dem Server zuschiebt.

Achtung:
Wir müssen nun noch zwei Fälle unterscheiden.
Im ersten Falle habe ich bewußt einen Server am Laufen, z.B. einen Webserver, um meine private Homepage anzubieten. Das ist ok, solange ich mir über die Sicherheitsrisiken im klaren bin.
Im zweiten Falle läuft auch auf meinem Rechner ein Server, von dem ich aber nichts weiß. Dieser Server nimmt Anfragen seines eigentlichen Herren und Meisters entgegen. Anders ausgedrückt: Der Server nimmt Befehle entgegen.
Mögliche Folgen: Diebstahl persönlicher Daten, Weiterverbreiten des Servers an andere, ahnunglose User (bzw. deren Rechner), Angriffe auf andere Rechnersysteme.
Bei einem solchen Server handelt es sich also um Schadsoftware.

Das Problem ist nun, daß solche Server selten offen arbeiten, so daß man sie einfach erkennen und beseitigen könnte. Häufig tarnen sich diese Programme, so daß die Suche danach aufwendig und für den Laien idR nicht durchführbar ist. Da zudem die Gefahr besteht, daß nach Belieben Programme "nachgeladen" und installiert werden, ist ein System, auf dem ein fremder Server läuft, nicht mehr vertrauenswürdig. Es ist sofort vom Netz zu trennen und neu aufzusetzen.

Weiter geht es mit IP-Adressen und Ports im 3. Teil.

MfG
Vimes

Teil 4: TCP/IP

TCP ist ein verbindungsorientiertes Protokoll. Das heißt, der Client baut zum Server eine Verbindung auf, die Daten werden nach dem Senden quittiert, so daß man Übertragungsfehler erkennen und korrigieren kann und am Schluß wird die Verbindung beendet, so daß der Server weiß, daß nun keine Anfragen mehr kommen.

Das funktioniert so:

Der Client (z.B. ein Browser) reicht seine Anfrage beim TCP/IP-Stack ein. Der Stack weist ihm einen Port zu, über den dann die Anfrage rausgeschickt wird.

Das kann man sich vorstellen wie bei einem Brief: Auf den Umschlag wird der Absender mit allen notwendigen Angaben geschrieben. Also meine IP-Adresse und der Port, über den die Anfrage hinausgeht.
Ebenso kommt auf den Umschlag der Empfänger, d.h. die IP-Adresse des Servers und sein Port.

Die Verbindung wird nun aufgebaut, indem Client und Server ein Frage-Antwort-Spiel ablaufen lassen:

Client: "Bist Du da? Ich möcht was wissen"
Server: "Kann Dich hören. Bin da."
Client: "Super. Hab Dich verstanden. Sende jetzt Daten."

Die Verbindung steht damit. Der TCP/IP-Stack sendet nun meine Anfrage raus.
Dabei werden die Daten so verpackt, daß der Server auf der Empfängerseite immer sehen kann, wie er sie wieder zusammenzusetzen hat, damit das Ganze einen Sinn ergibt.

An einem Beispiel:
Mein Browser möchte die Startseite des Problemboards haben.
Als Anfrage soll dann rausgehen:
"Zeig mir die Startseite des Problemboards".

Diese Anfrage ist so zu groß, sie muß zerlegt werden [1]. Wir erhalten dann:

[Ziel Port 80][1][Zeig]
[Ziel Port 80][2][mir]
[Ziel Port 80][3][die]
[Ziel Port 80][4][Startseite]
[Ziel Port 80][5][des]
[Ziel Port 80][6][Problemboards]

[1] Es komme mir jetzt bitte keiner, daß das typische TCP-Paket solche Inhalte locker transportieren kann, ich bin zu faul, mir ein geeignetes Beispiel zu überlegen, das auch die Profis zufriedenstellt...

Egal, in welcher Reihenfolge diese Päckchen ankommen, der Server kann sie wieder in der richtigen Reihenfolge zusammensetzen, da sie ja numeriert sind. (Natürlich ist's in der Realität ein wenig komplexer, aber wir wollen ja nur einen Überblick.)

Der Server (hier: das Problemboard) sendet dann die gewünschten Daten zurück. Das funktioniert im Prinzip genauso wie oben. Sender und Empfänger quittieren jeweils den Empfang, so, wie man beim Postboten ein Einschreiben quittieren muß.

Ganz am Schluß sagt der Client dem Server noch einmal explizit, daß er fertig ist. Die Verbindung wird dann wieder abgebaut. Das ist so, wie wenn man nach einem Telefonat auflegt.

Weiter gehts mit UDP/IP.

MfG
Vimes

Teil 6: Schlußbemerkungen / Fragen und Antworten

Damit sind wir am Ende der Lektion TCP/IP angelangt.
Stellt sich vielleicht noch folgende Frage:

Was hat das ganze mit Sicherheit zu tun? Ist doch ein Sicherheitsworkshop hier...

1. Ohne Kenntnisse über die Art und Weise, wie Rechner sich unterhalten, habe ich keine Ahnung, welchen Gefahren mein Rechner im Internet überhaupt ausgesetzt ist.

Erst, wenn ich weiß, was einen Client von einem Server unterscheidet, weiß ich überhaupt, daß ich das eine bedenkenlos benutzen kann, das andere aber Sachverstand und Sicherheitvorkehrungen erfordert, wenn ich nicht Ziel für diverse Möchtegern-Hacker werden möchte.

2. Ohne solche Kenntnisse kann ich keine Personal Firewall und auch keinen Router sinnvoll einsetzen, geschweige denn, meinen Rechner gescheit konfigurieren (z.B. durch das Abschalten von Diensten).

Wer schon einmal hinter einem Router spielen wollte, kennt das Problem: Das Spiel geht nicht. Warum nicht? Was muß man dagegen tun? Mit Begriffen wie Portforwarding kann man erst dann etwas anfangen, wenn man überhaupt weiß, was ein Port ist und was er tut.

Zum Schluß noch eine Anekdote aus dem Usenet.
Fragestellung war, wie man die Sicherheit eines Apache-Webservers bezüglich Hacker-Angriffen testen könnte.

"Man baue eine 160 GB-Platte ein, installiert darauf den Apache und setzt dann in einem einschlägigen IRC-Channel [Chat-Kanal, Anm. von Vimes] die Botschaft ab: 'Achtung, Webserver mit schöner, großer Platte unter $IP-Adresse, sieht ungesichert aus, schnappt ihn Euch!!!'
Nach 24 Stunden schaue man wieder nach dem System. Ist das System sicher, ist es gut, im anderen Falle baut man die Platte aus und freut sich über 160 GB an Warez, MP3s, Nacktbildern und Filmen..."
(c) Urs Tränkner in de.comp.security.misc


MfG
Vimes


Damit Ihr die Anleitung auch offline betrachten könnt', steht diese, ab sofort zum Download im PDF Format zur Verfügung!