In diesem Kapitel sollen Techniken und häufig auftretende, bekannte Angriffe kurz vorgestellt werden.
Ein gefälschtes Paket läßt sich dadurch leicht in ein geschütztes lokales Netz einschleusen.
IP-Spoofing wird beispielsweise von Angreifern verwendet werden, um von sich abzulenken, und einem Anderen den Angriff anzulasten.
Außer dem IP-Spoofing gibt es noch weitere Arten von Spoofing, nämlich
DNS- und Web-Spoofing. Auf diese soll jedoch hier nicht näher eingegangen
werden.2
Es ist möglich, Informationen über die Route, die das Paket gehen will, im Paket zu speichern. Die Router werten diese Informationen aus und leiten das Paket entsprechend weiter.
Hiermit lassen sich von einem Angreifer Pakete generieren, die vorgeben aus dem eigenen lokalen Netz (hinter der Firewall) zu stammen. Liegt das Ziel innerhalb des lokalen Netzes wird die Firewall diese Pakete auch dorthin senden. Dem Angreifer wäre es dadurch gelungen, die Firewall zu umgehen.3
Source routed traffic sollte deshalb grundsätzlich nicht zugelassen werden.
Anmerkung: Source routed traffic läßt sich schon auf Kernelebene
deaktivieren.4
Denial of Service (DoS) Angriffe binden Systemressourcen des Zielrechners.
Dies kann im schlimmsten Fall dazu führen, daß das System nicht
mehr erreichbar ist.
DoS Angriffe lassen sich in Floods (binden Bandbreite und nutzen Rechenzeit
des Ziels) und Disconnects (verhindern, daß andere Computer den Server
erreichen) unterteilen.
Bsp. Ping Flooding: Das Ziel wird mit Ping-Paketen (ICMP Message Type 8) beschossen und wird damit ausgelastet, die Ping-Pakete mit Echo-Reply-Paketen (ICMP Message Type 0) zu beantworten.
Bsp. Identification Flooding (Inetd): Dieser Angriff ähnelt einem gewöhnlichen ICMP Flood, es werden aber zusätzlich Informationen von TCP Port 113 angefordert. Dieser Angriff verbraucht mehr Rechenzeit als ein gewöhnlicher ICMP Flood, da die Antwort generiert werden muß.6
Bsp. TCP SYN Flooding: Das SYN Flooding macht sich dem gewöhnlichen dreistufigen TCP Verbindungsaufbau zunutze. Das Ziel wird mit gespooften IP-Paketen beschossen, die eine Verbindung zu einem TCP basierten Dienst (z.B HTTP) aufbauen wollen. Es wird ein Paket mit gesetztem SYN Flag gesendet. Das Ziel beantwortet dieses Paket mit einer Nachricht, die SYN- und ACK-Flag gesetzt hat. Da die IP-Adresse gespooft ist, kommt es nie zu einer Antwort mit gesetztem ACK-Flag des Angreifers. Die TCP Verbindung bleibt in Ihrem halb geöffneten Zustand und verbraucht Systemressourcen, bis es zu einem Timeout der Verbindung kommt. Da neue Pakete schneller eintreffen, als alte Verbindungen durch den Timeout beendet werden, sind nach kurzer Zeit sämtliche Ressourcen des Ziels belegt. Es können keine weiteren Verbindungen beantwortet werden. Das Ziel ist damit ausgeschaltet.
Bsp. SMTP Session Hijacking: Hier wird der Mailserver des Ziels mit
Mails überflutet, bis dieser für andere Computer nicht mehr erreichbar
ist.7
Portscans dienen der Informationsgewinnung, verbrauchen aber auch Systemressourcen. Sie sind damit ein weiterer DoS Angriff, wenn auch weniger effizient wie andere DoS Formen. Portscans gehen häufig wirklichen Angriffen voraus.8
Portscans beschränken sich häufig auf einige wenige, ausgesuchte Zielports, auf denen verbreitete Netzwerkdienste laufen. Diese Dienste haben in der Vergangenheit oft Schwachstellen in der Sicherheit aufgezeigt und sind ein idealer Ausgangspunkt für Angriffe.9
Portscanning gilt trotz dieser für die Informationsgewinnung wichtigen
Funktion als klassischer DoS Angriff, da eine entsprechende Anzahl an Scans
gleichzeitig den Zielrechner blockieren kann.
Bsp. ICMP Destination Unreachable: Bei diesem DoS Angriff wird ein gespooftes
Destination-Unreachable-Paket (ICMP Message Type 3) an das Ziel gesendet.
Das Ziel erhält die Nachricht, daß der Quellrechner nicht mehr
erreichbar ist und beendet alle Verbindungen mit diesem Computer.10
Bsp. Boink: Der Boink Hack ähnelt anderen Hacks, wie Bonk, Teardrop oder New Tear. Durch ungültige Paketfragmente, die nicht mehr korrekt zusammengefügt werden können, wird das Ziel zum Absturz gebracht.
Bsp. Land: Beim Land Hack versucht ein gefälschtes, angeblich vom Ziel stammendes Paket eine Verbindung zum Ziel aufzubauen. Das Ziel versucht mit sich selber eine Verbindung aufzubauen und stürzt ab.
Bsp. Jolt: Jolt, auch als SSping und IceNuke bekannt. Ein übergroßes, fragmentiertes Paket wird an das Ziel gesandt. Das Ziel stellt seine Arbeit ein und muß neu gestartet werden.
Bsp. Winnuke: Winnuke nutzt einen Fehler im TCP/IP Stack der bekannten
Windows Versionen (Win3.x, Win9x, WinNT 3.51, WinNT 4) aus. Spezielle Daten
(out of bound data) werden an TCP Port 139 des Ziels geschickt. Als Folge
davon stürzt das TCP/IP Protokoll ab und der Computer muß neu
gebootet werden, will man die Funktionalität des Protokolls wieder
herstellen.
Siehe folgende Grafiken:
Abbildung 1 , Anbindung per Modem/ISDN
Ist die Firewall per Modem oder ISDN-Leitung an das Internet angeschlossen, genügt eine Netzwerkkarte (NIC - Network Interface Card) für die Anbindung an das lokale Netz.
Abbildung 2, Anbindung per Kabelmodem, Router oder DSL
Bei Einsatz eines Kabelmodems, eines DSL Routers oder eines vergleichbaren
Anschlusses an das Internet, ist die Firewall mit zwei Netzwerkkarten auszustatten.
Eine für den Anschluß an das Modem oder den Router und Eine
für die Verbindung zum lokalen Netz.
Zu aktivieren sind:
Aktiviert die allgemeine Netzwerkunterstützung.
Aktiviert die im Kernel integrierten Firewallfunktionen.
Unterstützung für das TCP/IP-Protokol.
Bindet Kernelcode ein, der SYN Flooding Angriffe20
abblockt. Der Code muß bei jedem Rechnerstart mit "echo 1 > /proc/sys/net/ipv4/tcp_syncookies"
aktiviert werden.
Aktiviert den NAT Support im Kernel.
In älteren Versionen des Kernels treten folgende Optionen auf,
die zusätzlich zu aktivieren sind:
Source routed traffic21
wird durch Aktivierung dieser Kerneloption automatisch geblockt.
Defragmentierung von IP-Paketen aktivieren.
Routingfähigkeiten aktivieren.
Logging- und Überwachungsfunktionen.
Abbildung 3, Kerneloptionen der Firewall Teil 1
Abbildung 4, Kerneloptionen der Firewall Teil 2
Ipchains löst im neuen 2.2er Kernel das Tool ipfwadm ab, welches in Kerneln < 2.2 die Schnittstelle bildete. Bei ipchains handelt es sich um eine komplette Neuimplementierung des Linux Ipv4 Firewall Codes und somit auch um eine Neuimplementierung von ipfwadm.
Es gibt zahlreiche Wrapperprogramme, die alte ipfwadm Regeln in neuen ipchains Code umsetzen.23
Es sei noch angemerkt, daß im in der Entwicklung befindlichen
Kernel 2.4 eine weitere neue Schnittstelle Einzug finden wird: netfilter/iptables.24
Der neue Kernel wird voraussichtlich im dritten Quartal 2000 veröffentlicht.
Die für eine Firewall wichtigen Verbesserungen des Kernels 2.2
gegenüber 2.0 im Einzelnen :
Diese neue Funktion kann beispielsweise dazu genutzt werden, einzelne
Clientgruppen über verschiedene Provider ins Internet gehen zu lassen.
Beispielsweise werden alle Clients mit der Adresse192.168.1.x durch einen
ISDN-Router mit dem Internet verbunden, während Clients mit der Quelladresse
192.168.2.x die Verbindung über ein Modem aufbauen.
Auf einem bestimmten Port eingehende Pakete werden an einen beliebigen
Rechner und Port weitergeleitet. Damit lassen sich z.B. transparente Proxies
realisieren: Alle aus dem lokalen Netz auf Port 80 ankommenden Pakete gehen
an Port 3128 der Firewall, auf dem ein Proxyserver, z.B. Squid, installiert
ist.26
Ein Vorteil eines transparenten Proxies ist, daß er für
die Benutzer nicht "sichtbar" ist. Sie müssen deshalb auch keine Einstellungen
im Browser vornehmen.
Unterstützung weiterer Netzwerktypen
Prioritätenvergabe an IP-Pakete
Unterstützung des zukünftigen Internet Protokolls (Version
6)
Die Zähler der IP Filter sind jetzt 64bit breit.
Die Regeln greifen auf die Informationen im Header des Pakets zurück, um zu entscheiden, ob das Paket ans Ziel weitergeleitet (accept), einfach verworfen (deny) oder abgelehnt und eine Fehlermeldung an den sendenden Computer zurückgeschickt wird (reject).
Folgende Informationen stehen einer Paketfilter-Firewall zur Verfügung:28
Die Firewall regelt den ein- und ausgehenden Datenverkehr und zusätzlich auch noch den Verkehr zwischen den verschiedenen Netzwerkschnittstellen des Firewallrechners. Die Regeln für eingehende Daten können sich komplett von denen für ausgehende Daten unterscheiden.
Die Gesamtheit aller Regeln einer Regelliste wird chain (engl. für Kette) genannt. Die einzelnen Regeln entsprechen den Gliedern der Kette. Jedes Paket wird der Reihenfolge nach mit jeder Regel verglichen, bis eine Übereinstimmung gefunden wird oder die chain zu Ende ist.
Default Policy29
Jede chain hat eine default policy. Wenn ein Paket mit keiner der Regeln in der chain übereinstimmt oder die chain zu Ende ist, tritt die default policy in Kraft.
Es gibt zwei grundlegende Vorgehensweisen beim Aufstellen einer default policy:
Alles abzulehnen und einzelne Regeln für Dienste aufzustellen, die angenommen werden sollen (deny everything by default).
oder
Alles zu akzeptieren und einzelne Regeln für Pakete aufzustellen, die abgelehnt werden sollen (accept everything by default)
Die Letztere ist die empfehlenswertere Methode. Sie garantiert eine sichere Firewall, da jeder Dienst, der nicht ausdrücklich erlaubt ist, abgelehnt wird. Allerdings ist diese Methode mit viel Arbeitsaufwand verbunden, da jeder Dienst, der benutzt werden will, auch aktiviert werden muß. Dies verlangt einiges an Hintergrundwissen über die einzelnen Dienste und deren Protokolle. Eine deny everything by default Firewall ist somit schwerer zu realisieren.
Eine accept everything by default Firewall ist sehr viel leichter aufzusetzen,
da sämtliche Dienste erlaubt sind, solange sie nicht ausdrücklich
durch Regeln verboten sind. Verdächtige oder gefährliche Dienste
müssen also gesperrt werden. Die Gefahr besteht darin, daß gefährliche
Dienste nicht oder zu spät als solche erkannt werden, und dadurch
große Sicherheitslücken in der Firewall bestehen. Mit dieser
Methode ist es sehr viel schwerer eine sichere Firewall zu betreiben.
Eigenschaften der IP-Pakete:
Die möglichen Aktionen der Regeln:
Das Paket wird angenommen und normal weiterverarbeitet.
Das Paket wird abgelehnt und verworfen.
Das Paket wird abgelehnt und zusätzlich wird ein ICMP-Paket
des Typs 3 (destination unreachable) an den Absender gesendet.
Das Paket wird auf einen beliebigen Computer auf einen anderen Port
umgeleitet, um dort verarbeitet zu werden. Beispielsweise lassen sich alle
eingehenden Pakete auf Port 80 aus dem Internet an einen beliebigen Port
weiterleiten, auf dem ein Webserver läuft.
Die IP-Adresse des Pakets wird mit der IP-Adresse des Firewallrechners
ersetzt. Das Paket scheint nun von der Firewall selber zu kommen. Diese
Aktion wird für ausgehende Pakete des lokalen Netzes genutzt, um deren
private IP-Adressen in eine gültige IP-Adresse umzuwandeln.32
Die Inputliste gilt für eingehende Pakete
Die Outputliste ist für ausgehende Pakete
Die Forwardliste ist für Pakete, die von einem Netzwerkinterface
zu einem anderen weitergeleitet werden. Pakete des lokalen Netzes, die
in das Internet wollen, passieren diese Liste.
Die Regeln einer Liste werden der Reihe nach von oben nach unten abgearbeitet. Die erste Regel, die eine Übereinstimmung liefert, wird ausgeführt. Spezielle Regeln müssen deshalb unbedingt vor Allgemeineren stehen.
Zusätzlich zu diesen drei Standardregellisten besteht die Möglichkeit,
eigene, benutzerdefinierte Regellisten zu erstellen. Beispielsweise können
alle eingehenden Pakete des Typs TCP an die Regelliste "tcp" gehen, in
der alle Regeln für TCP Pakete definiert sind. In der input Regelliste
steht dann nur eine Regel, die TCP Pakete an die speziell eingerichtete
tcp-Liste weiterleitet. Dadurch läßt sich das Firewallskript
besser gliedern und übersichtlicher gestalten.34
Befehl | Kurzbezeichnung | Parameter | Beschreibung |
--add | -A | <name der regellsite> | Hängt die Regel an die Regelliste an |
--delete | -D | <n d r> <position/regel> | Löscht die Regel aus der Regelliste. Es muß entweder die Position der Regel oder die Regel selber angegeben werden |
--insert | -I | <n d r> <position> <regel> | Fügt die Regel an der angegebenen Position an |
--replace | -R | <n d r> <position> <regel> | Ersetzt die Regel an der angegebenen Position durch die neue Regel |
--list | -L | [ <n d r> ] | Zeigt alle Regellisten oder die Regelliste mit all ihren Regeln an |
--flush | -F | [ <n d r> ] | Löscht alle Regellisten oder alle Regeln in der angegebenen Liste |
--check | -C | <n d r> | Testet die Reaktion der Regellsite auf dieses Paket |
--new | -N | <n d r> | Legt eine neue nicht-standard Regelliste an |
--delete | -X | <n d r> | Löscht eine leere(!) nicht-standard Regelliste. |
--policy | -P | <n d r> <accept/ reject/ deny> | Legt die Default Policy für die angegebene Regelliste fest. |
-masquerade | -M | -L | Gibt Liste aktuell maskierter Verbindungen aus |
Option | Kurzbezeichnung | Parameter | Beschreibung |
--bidirectional | -b | Erstellt automatisch eine Regel, für die entgegengesetzte Richtung, bei der die Quell- und Zieladresse vertauscht sind, um den Pakettransfer in beide Richtungen zu erlauben | |
--proto | -p | [!] <protokoll> | Protokolltyp des Pakets, wie tcp,udp, icmp |
--source | -s | [!] <address>[/<mask>] [!] [<port>[:<port>]] | Spezifiziert die Quelladresse und optional den Quellport des Pakets |
--source-port | [!][<port>[:<port>]] | Spezifiziert den Quellport des Pakets, sollte die Angabe -s in der Regel fehlen | |
--destination | -d | [!] <address>[/<mask>] [!] [<port>[:<port>]] | Spezifiziert die Zieladresse und optional den Zielport |
--destination-port | [!][<port>[:<port>]] | Spezifiziert den Zielport, sollte die Angabe -d in der Regel fehlen | |
--icmp-type | [!] <typ> | Festlegung des ICMP Typs. Entweder als Nummer oder Bezeichnung |
--interface | -i | [!] <Netzwerkschnittstelle> [+] | Legt die Netzwerkschnitt-stelle fest. Ein "+" steht für alle Schnittstellen des Typs |
--numeric | -n | Gibt die Nummern von IP-Adressen und Ports aus | |
--log | -l | Das Paket wird in /var/log/messages mitprotokolliert | |
--verbose | -v | Erzeugt eine detailliertere Ausgabe | |
--exact | -x | Anzeige der Paket und Bytezähler | |
[!] -syn | [!] -y | Bezeichnet Pakete, bei denen das SYN-Flag gesetzt ist, also Pakete, die einen Verbindungsaufbau einleiten wollen |
Hinweise zu den Tabellen:
Durch "!" wird die jeweilige Option negiert.
Beispielsweise steht "! -d 134.127.13.3" für alle Zieladressen außer 134.127.13.3
IP-Adressen und Subnetze lassen sich entweder in der Form 192.168.0.0/255.255.255.0 oder in der Form 192.168.0.0/24 angeben.
Durch ":" können nicht nur einzelne Ports, sondern ganze Bereiche
angeben. "0:443" z.B. steht für alle Ports von 0 bis 443.
Verweise im Text
1
Vgl. Anonymous. Maximum Linux Security, S.272f
2
Weitere Informationen finden sich unter:
DNS-Spoofing: http://www.auhof.asn-linz.ac.at/dely82/themen/dns_spoofing.htm
Web-Spoofing: http://www.intern.de/97/01/02.htm
3
Vgl. Stähle, Samuel. Firewalling unter Linux, S.3 und Ziegler, Robert.
Linux Firewalls, S.37
4
Siehe Kapitel 1.3.1 - Kernel
5
Vgl. Ziegler, Robert. Linux Firewalls, S.34f
6
Vgl. Conceal Firewall Homepage: http://www.candc1.com/conseal/attack.htm
7
Stähle, Samuel. Firewalling unter Linux, S.5
8
Vgl. Ziegler, Robert. Linux Firewalls, S.30f
9
Vgl. Ziegler, Robert. Linux Firewalls, S.266f
10
Vgl. Conceal Firewall Homepage: http://www.candc1.com/conseal/attack.htm
11
Vgl. Conceal Firewall Homepage: http://www.candc1.com/conseal/attack.htm
12
Vgl. Bernard, Frank. Brandschutz 2.2, S.86f
13
Eine hervorragende Sammlung von Linux Software findet sich unter http://www.freshmeat.net
14
Vgl. Schmidt, Jürgen, Dasein oder Nicht-Sein, S.174f
15
Unter http://www.linhardware.com
befindet sich eine Liste mit zu Linux kompatibler Hardware.
16
Das Linux Documentation Project hat sich die Erstellung einer umfangreichen
und freien Dokumentation zu Linux zum Ziel gemacht. Zu finden ist das LDP
unter http://www.linuxdoc.org
17
Die GPL ist ein Lizenzvertrag der Free Software Foundation. Mehr nformationen
über die FSF und der GPL finden sich unter http://www.gnu.org
18
Vgl. Grennan, Mark. Firewall and Proxy Server HOWTO, S.10
19
Umfangreiche Informationen zum Linux Kernel, sowie Downloadmöglichkeiten
finden sich auf der Kernelhomepage unter http://www.kernel.org
20
Siehe Kapitel 3.3.1 - Flooding
21
Siehe Kapitel 3.2 - Source routed traffic
22
Weitere Informationen zu ipchains, sowie eine Downloadmöglichkeit
finden sich auf der ipchains Homepage unter http://netfilter.filewatcher.org/ipchains
23
Eines dieser Wrapperprogramme ist ebenfalls unter http://netfilter.filewatcher.org/ipchains
zu finden.
24
Weitere Informationen zu netfilter/iptables finden sich unter http://netfilter.filewatcher.org
25
Vgl. Emmrich, Henning. Netzwerk in Ketten, S.194f
26
Siehe Kapitel 2.7 - Port Mapping
27
Siehe Kapitel 2.4 - Quality of Service
28
Vgl. Stähle, Samuel. Firewalling unter Linux, S.8
29
Ziegler, Robert. Linux Firewalls, S.23
30
Stähle, Samuel. Firewalling unter Linux, S.8
31
Siehe Kapitel 4.7.5 - ipchains Optionen
32
Siehe Kapitel 2.5 - NAT
33
Vgl.Stähle, Samuel. Firewalling unter Linux, S.8
34
Vgl.Emmrich, Henning. Netzwerk in Ketten. S.194f
35
Stähle, Samuel. Firewalling unter Linux, S.9f
36
Stähle, Samuel. Firewalling unter Linux, S.10f
37
Vgl. Emmrich, Henning. Netzwerk in Ketten, S.194f
Feedback ist wichtig für die Verbesserung des Service |
Autor: Felix
Mack
Datum: 04. Dezember 2000 - Pro-Linux.de |