SelfLinux Sicherheit IP-Tables Abschnitt 5 | SelfLinux-0.13.0

| IP-Tables | Autor Formatierung GFDL

#### 7 Filterbestimmungen (Filteroptionen)

#### 7.1 Grundlegende Filteroptionen

Wie bereits erwähnt, beinhaltet jede Kette (INPUT, OUTPUT, FORWARD) eine Checkliste von Regeln, die folgendermaßen aussehen:

WENN (Filteroption) DANN Aktion (Löschen, Akzeptieren, ... des Paketes)

Im letzten Abschnitt wurden bereits zwei Filteroptionen (-s und -p) für die INPUT-Kette angewendet:

Verwerfe alle ankommenden ICMP Pakete von localhost

root@linux # iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP

Mit -p wurde das Protokoll ICMP bestimmt, die -s Option legte die Quelladresse der Pakete fest.

Die folgenden Filteroptionen können angegeben werden:

- Quell- und Zieladresse festlegen:
  -s, --source oder -src - Quelladresse
  -d, --destination oder --dst - Zieladresse
  Quell- und Zieladressen können folgendermaßen angegeben werden:
  1. Namen (z.B. "localhost" oder "www.mydomain.com")
  2. IP-Adresse (Bsp. "127.0.0.1")
  3. Subnetz ("192.168.1.0/24" oder "192.168.1.0/255.255.255.0" sind alle IP-Adressen von 192.168.1.0 bis 192.168.1.255)
     Bsp:
     iptables -A INPUT -s 192.168.1.0/24 -j DROP
- Protokoll
  -p oder --protocol. Die Angabe des Protokolls erfolgt durch
  1. Protokollnamen z.B. "TCP", "UDP" oder "ICMP" (Gross- und Kleinschreibung ist egal, es funktioniert beides) oder
  2. die IP-Protokollnummer
     Bsp:
     iptables -A INPUT -s 192.168.1.0/24 -p ! icmp -j DROP
- Netzwerkschnittstelle
  -i oder --in-interface Eingangsschnittstelle
  -o oder --out-interface Ausgangsschnittstelle
  Mit dem ifconfig Kommando können alle aktiven Schnittstellen angezeigt werden.
  Die INPUT-Kette stellt keine Output-Schnittstelle zur Verfügung (siehe Bild oben), in dieser Kette ist die -o Option also zwecklos. Analog dazu hat die OUTPUT-Kette keine INPUT-Schnittstelle, also werden Regeln mit -i Option niemals zutreffen und sind deshalb ebenso obsolet. Nur Pakete, welche die FORWARD-Kette durchwandern, können über INPUT- und OUTPUT-Schnittstelle gefiltert werden.
  Es können auch Schnittstellen zuordnet werden, die beim Anlegen der Regel noch gar nicht existieren (Dialup-PPP Schnittstellen) Kein Paket kann bis zur Aktivierung der Schnittstelle die Regel erfüllen, sie stört somit also keinesfalls.
  Schnittstellennamen, die mit einem + enden, bezeichnen alle Schnittstellen, die mit dieser Zeichenkette beginnen, egal ob diese in dem Moment existieren oder nicht.
  Beispiel: Eine Regel mit der folgenden Option trifft auf alle PPP-Schnittstellen zu: -i ppp+
- Inversion (Verneinung) Jede Option ist invertierbar durch Angabe eines ! hinter der jeweiligen Option:
  Bsp:
  iptables -A INPUT -s ! 127.0.0.1 -p icmp -j DROP
  Die Regel gilt für alle ICMP-Pakete, die NICHT vom lokalen Rechner kommen.

#### 7.2 Fragmente filtern

Zu große Pakete werden in Fragmente aufgeteilt und in mehreren Paketen weiterverschickt. Die Gegenstelle setzt diese Fragmente wieder zusammen, um das gesamte Paket zu rekonstruieren.

Bei connection tracking oder NAT werden alle Fragmente wieder miteinander verschmolzen, bevor sie den Paketfilter erreichen, alles ist also wie gehabt.

Ansonsten hat unseren Paketfilter nun folgendes Problem: das erste Fragment enthält die kompletten Header-Felder (IP + TCP, UDP und ICMP), die nachfolgenden Fragmente besitzen nur Teilstücke der Header (IP ohne die zusätzlichen Protokoll-Felder) Daher ist es nicht möglich, in nachfolgenden Fragmenten nach Protokoll-Headern zu suchen (wie es zum Beispiel bei TCP, UDP und ICMP Erweiterungen getan wird).

Anders formuliert: Das erste Fragment kann wie jedes andere Paket gefiltert werden, bei dem zweiten und alle weiteren Fragmenten greifen die bisher bekannten Regeln nicht. So wird beispielsweise -p TCP --sport www (die einen Quellport von www filtert) ausschließlich auf das erste Fragment zutreffen.

Die Lösung des Problems besteht im Hinzufügen einer Regel für Fragmente mittels -f (--fragment) Option.

Normalerweise gilt es als sicher, wenn man zweite und weitere Fragmente akzeptiert und nur das erste Fragment herausgefiltert wird. Trotzdem: Werden Fragmente akzeptiert, dann können durch das Ausnutzen von Software-Bugs Rechner zum Absturz gebracht werden. (DOS Attacke)

Anmerkung:
Missgeformte Pakete (die z.B. zu klein sind, um Ports oder ICMP Code oder Type zu lesen) werden verworfen. TCP-Fragmente starten also bei Position 8.

Die folgende Regel verwirft jegliche Fragmente, die an 192.168.1.1 gehen:

root@linux # iptables -A OUTPUT -f -d 192.168.1.1 -j DROP

#### 7.3 iptables MATCH-Erweiterungen

#### 7.3.1 Grundlegendes zu Erweiterungen

Sowohl der iptables Kernel-Code als auch das iptables Tool können erweitert werden. Viele dieser Erweiterungen sind für eine sichere Firewall unumgänglich. Jeder kann Erweiterungen entwickeln und diese anbieten.

Kernelerweiterungen residieren normalerweise im Unterverzeichnis für Kernelmodule, z.B. /lib/modules/2.4.24/net und werden bei Bedarf geladen. Wenn im Kernel die Option CONFIG_KMOD gesetzt ist, dann erfolgt das Laden vollautomatisch.

Erweiterungen für das Tool iptables sind Shared Libraries, die gewöhnlich unter /usr/local/lib/iptables , unter /lib/iptables oder bei manchen Distributionen auch unter /usr/lib/iptables zu finden sind.

Wir betrachten hier erst einmal MATCH-Erweiterungen, es geht also um eine Erweiterung der Filterbedingungen. Implizite Erweiterungen (tcp, udp, icmp) werden mit der Option -p geladen, explizite Erweiterungen mit der Option -m.

Die Hilfe für eine Erweiterung erhält man, wenn nach der Option zum Laden der Erweiterung (-p oder -m) ein -h oder --help angegeben wird.

Zum Beispiel:

root@linux # iptables -p udp --help

#### 7.3.2 TCP Erweiterungen

Manchmal sollen bestimmte Dienste innerhalb des Netzes von außen (bzw. anderen Netzbereichen) nicht erreichbar sein. Viele Dienste benutzen das verbindungsorientierte TCP-Protokoll. Der Aufbau dieser TCP-Verbindungen erfolgt nach dem Three-Way-Handshake Protokoll, hier ist nochmals eine Kurzzusammenfassung:

Der Server wurde mit S bezeichnet, der Client mit C.

1. (C) --> [SYN] --> (S)
   Der Client sendet ein Synchronisationspaket (Synchronize) und erklärt damit, dass er eine Verbindung aufbauen möchte.
2. (C) <-- [SYN/ACK] <--(S)
   Der Server akzeptiert den Verbindungswunsch und sendet ein SYN/ACK Paket (Synchronize/Acknowledgement) zurück.
3. (C) --> [ACK] --> (S)
   Der Client wiederum bestätigt, dass die Verbindung nun aufgebaut ist/wird mit einem ACK-Paket (Empfangsbestätigung)

[Ein SYN-Paket ist ein TCP-Paket, bei dem ausschließlich das SYN-Flag gesetzt ist.]

Alle weiteren TCP-Pakete dieser Verbindung haben übrigens auch ein gesetztes ACK-Flag.

Wenn man nur die [SYN] Pakete eines Rechners blockt, können Verbindungsversuche von diesem unterbunden werden. Die Filterung dieser Pakete erfolgt durch die TCP Erweiterungen, die mit -p tcp geladen werden. Inversionen (Verneinungen) sind durch ein ! hinter der Option möglich.

Es gibt folgende Optionen:

--tcp-flags

> gefolgt von zwei Zeichenketten. Die erste Zeichenkette enthält eine Liste von Flags, die untersucht werden. Die zweite Zeichenkette sind die Flags, die gesetzt sein sollen. Mögliche Flags sind:
> SYN, ACK, FIN, RST, URG, PSH bzw. ALL für alle und NONE für keine Flags.

--syn

> entspricht --tcp-flags SYN,RST,ACK SYN.

--source-port oder --sport

> Gefolgt von einem bzw. mehreren TCP-Ports. Ports können durch Namen (/etc/services) oder Portnummer angegeben werden. Auch ganze Bereiche sind möglich. (z.B. 10000-11000)

--destination-port oder --dport

> bedeutet Zielport

--tcp-option

> Gefolgt von einer Nummer, welche die TCP-Option angibt. TCP-Pakete ohne kompletten Header werden bei dem Versuch, die TCP-Option zu bestimmen, automatisch verworfen.

Beispiel:

root@linux # iptables -A INPUT -p TCP -s 192.168.1.0/24 --tcp-flags SYN,RST,ACK SYN -j DROP

#### 7.3.3 UDP Erweiterungen

Diese Erweiterungen werden mit -p udp automatisch geladen. Sie bieten die Optionen --source-port (--sport) und --destination-port (--dport), wie sie bereits oben für TCP detailliert beschrieben wurden.

#### 7.3.4 ICMP Erweiterungen

Diese Erweiterungen werden mit -p icmp geladen und bieten nur eine neue Option:

--icmp-type

> Gefolgt vom ICMP-Typnamen (zum Beispiel 'host-unreachable'), oder einer entsprechenden Nummer.
> Eine Liste verfügbarer ICMP Typnamen erhält man mit der Option "-p icmp --help".

#### 7.3.5 Explizite Erweiterungen

Die expliziten Erweiterungen im netfilter-Paket sind keine Standarderweiterungen. Man muss dazu spezielle Kernelmodule (z.B. ipt_mac, ipt_limit, ipt_owner) laden, eine Auflistung der Module befindet sich im Anhang.

Die Erweiterung ruft man mit der Option -m auf.

mac (-m mac oder "--match-mac")

> Dieses Modul wird verwendet, um die MAC-Adressen einkommender Pakete zu filtern. Hinter der Option --mac-source wird eine Netzwerkadresse in durch Doppelpunkte getrennter Hex-Notation angegeben. (z.B. -m mac --mac-source 00:60:08:91:CC:B7).

limit (-m limit oder --match-limit )

> Limit schränkt die Paketanzahl auf eine vorgegebene Rate ein. Vorstellen kann man sich das System wie ein Rückhaltebecken mit konstantem Abfluss. Damit das Speicherbecken nicht überläuft, wird im Falle eines zu großem Stromes ein anderer Weg eingeschlagen.

Unser Strom besteht nicht aus Wasser sondern aus Datenpaketen, der normale Weg ins Rückhaltebecken bedeutet das Erfüllen der Regelbedingung und mit dem alternativen Weg (Überlaufschutz) ist das Nichterfüllen der Regel gemeint.

Das System kann mit zwei Parametern beschrieben werden:

- Das Speichervolumen (Parameter "--limit-burst") beschreibt die Anzahl der Maximaltreffer.
- Die Abflussgeschwindigkeit ("--limit") legt die Anzahl der maximalen Treffer pro Zeiteinheit fest. Werden diese beiden optionalen Parameter nicht angegeben, dann gelten die die Standardwerte (3 Treffer/Stunde und Maximalgrenze von 5 Treffern).

Limit kann verwendet werden, um Pakete zu loggen:

root@linux # iptables -A FORWARD -m limit -j LOG

Limit bietet Schutz vor "Syn-Flood-Attacken":

root@linux # iptables -A FORWARD -p tcp --syn -m limit 1/s -j ACCEPT

Schutz vor "Ping of Death":

root@linux # iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

Portscanner ausschalten:

root@linux # iptables -A FORWARD -p tcp --tcp-flags ALL NONE -m limit --limit 1/h -j ACCEPT root@linux # iptables -A FORWARD -p tcp --tcp-flags ALL ALL -m limit --limit 1/h -j ACCEPT

owner (-m owner)

> Diese Erweiterung filtert Charakteristika von Paketen und bestimmt damit deren Herkunft (lokaler Prozess). Man darf es nur in der Output-Kette benutzen:

--uid-owner userid

> Das Paket wurde von einem Prozess mit der angegebenen effektiven User ID generiert.

--uid-owner groupid

> Das Paket wurde von einem Prozess mit der angegebenen effektiven Gruppen ID generiert.

--pid-owner processid

> Das Paket wurde von einem Prozess mit der angegebenen effektiven Prozess ID generiert.

--sid-owner processid

> Das Paket wurde von einem Prozess in der angegebenen session group generiert.

state (-m state oder --state)

> Mit dieser Erweiterung können durch die Option --state Verbindungszustände von Paketen gefiltert werden. Zustände sind:

> NEW

> Ein Paket, das eine neue Verbindung aufbaut, erfüllt diese Regelbedingung.

> ESTABLISHED

> Trifft für Pakete zu, die zu einer bereits aufgebauten Verbindung gehören

> RELATED

> Trifft für verwandte Pakete zu. Verwandt sind z.B. ICMP Fehler einer Verbindung, oder (mit dem eingefügten FTP-Modul) ein Paket, das eine FTP Datenverbindung aufbaut.

> INVALID

> Ein Paket, das nicht identifiziert werden konnte. (Pakete sollten verworfen werden!)

> Die Möglichkeiten, die diese Option bietet, werden noch sehr detailliert im Kapitel Verbindungsverfolgung (Connection Tracking) bespochen werden.

Beispiel:

root@linux # iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

tos (-m )

Die TOS-Bits (Table-Of-Service) sind Flags im IP-Header, die eine Dienstgüte beschreiben. Im Einzelnen sind dies:

Dienstgüte | Parameterwert | numerischer Wert
Normal | Normal-Service | 0x00
Minimale Kosten | Minimize-Cost | 0x02
Maximale Zuverlässigkeit | Maximize-Reliability | 0x04
Maximaler Durchsatz | Maximize-Throughput | 0x08
Minimale Verzögerung | Minimize-Delay | 0x10

- Minimale Verzögerung (minimum delay)
  Die Übertragungsdauer ist das wichtigste Gütekriterium. Verbindungen über Glasfaser sind in diesem Falle einer Übertragung per Satellit vorzuziehen.
  Beispiel: ftp, telnet, ssh
- Maximaler Durchsatz (maximum throughput)
  Der Umfang der zu übertragenden Daten ist wichtig,Verzögerungen werden in Kauf genommen.
  Beispiel: ftp-data, www
- Maximale Zuverlässigkeit (maximum reliability)
  Das Paket sollte möglichst zuverlässig übertragen werden, so dass keine Wiederholungen der Übertagung erforderlich sind.
  Beispiel: snmp, dns
- Minimale Kosten (minimum cost)
  Das Paket ist äußerst unwichtig und sollte demnach den billigsten Weg einschlagen.
  Beispiel: nntp, smtp

Diese Bits können gesetzt und ausgelesen werden, indem der numerische Wert oder der Name angegeben wird. Kombinationen sind nicht sinnvoll.

Bsp:

root@linux # iptables -A FORWARD -m tos --tos 0x10 -j ACCEPT root@linux # iptables -A FORWARD -m tos --tos Minimize-Delay -j ACCEPT

mark (-m mark)

> Im IP-Header ist etwas Platz zum Markieren von Paketen. Diese Markierungen können mit der Option --mark ausgelesen werden. Zum Setzen der Markierung kann die PREROUTING Kette in der mangle-Tabelle dienen

Bsp:

root@linux # iptables -t filter -A FORWARD -m mark --mark 5 -j Drop

unclean

> Dieses Modul ist bislang zu wenig getestet und sollte nicht verwendet werden.

> multiport, nat, ...

> werden an dieser Stelle nicht betrachtet.