iptables - Die Firewall des Kernels 2.4
Protokollieren
Nicht nur zum Test, auch zur Überwachung von "schrägen" Mustern von IP-Paketen ist es sinnvoll, über diverse Dinge Protokoll zu führen. Dies kann mit dem LOG-Target sehr einfach geschehen. Alles Protokollierte wird im Syslog (/var/log/messages) mitgeschrieben.
Aufrufkonventionen:
| -j LOG | Falls die vorher spezifizierten Bedingungen zutreffen, wird das Paket geloggt. Im Gegensatz zu anderen Targets wird die Kette nach dieser Regel nicht verlassen, sondern die nächste Regel weiterhin getestet. | |
| --log-level <level> | Legt den Grad der Meldung fest, die hiermit geloggt wird. Über das eigentliche Verhalten entscheidet die Einstellung des Syslog. | |
| --log-prefix <text> | Stellt den angegebenen Text vor die eigentlich geloggte Meldung. Damit lassen sich verschiedene Nachrichten schnell unterscheiden. | |
| --log-tcp-sequence | Mitloggen der TCP Sequence-Nummer. | |
| --log-tcp-options | Optionen im TCP Header werden mitgeschrieben | |
| --log-ip-options | Optionen im IP Header werden mitgeschrieben | |
| -m limit | Dieses Modul ist als Zusatz zum "LOG"-Target gedacht, um die Anzahl der Log-Einträge zu beschränken (bei DoS-Attacken). | |
| --limit <rate> / <zeit> | Gibt die maximal durchschnittlich zu erreichende Rate pro Zeiteinheit an. z.B. 3/second, 5/minute, 3/hour, 100/day. Bei Überschreitung dieser Rate greift diese Regel nicht mehr. | |
| --limit-burst <zahl> | Bei Überschreiten dieser Zahl wird das nachfolgende Target nicht mehr getroffen. Diese Option, deren Standardwert auf 5 steht, ist gedacht, um vor allem Log-Einträge nicht zu überfluten. | |
Sonstiges
Es gibt noch einige Kleinigkeiten, die erwähnenswert sein könnten. In diesem kleinen Workshop möchte ich mich jedoch auf das Erstellen eigener Chains beschränken. Eigene Chains - wozu? Eigene Chains verhalten sich wie "Unterprogramme", so daß öfter benötigte Aktionen (z.B. Loggen und Verwerfen) nur einmalig definiert werden müssen.
Beispiele:
# Alle benutzerdefinierten Chains der Tabelle "filter" Löschen # iptables -X # # Log and drop definieren als benutzerdefinierte Chain # iptables <strong>-N logdrop</strong> iptables -A logdrop -j LOG --log-prefix "IPTABLES packed died: " iptables -A logdrop -j DROP . . . # # Alles Unnütze verbieten, bestehende Verbindungen -> OK # iptables -A FORWARD -s $mynet -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD <strong>-j logdrop</strong>
Ein Blick unter die Haube
Einige der bereits im Text genannten Dateien des /proc Dateisystems seien an dieser Stelle nochmals genannt. Sie ermöglichen in beschränktem Umfang, einen Blick in die Arbeitsweise der Netfilter-Architektur zu werfen:
| /proc/net/ip_conntrack | zeigt alle derzeit aktiven Verbindungen (selbst bei verbindungslosen Protokollen wie UDP oder ICMP) an. |
| /proc/net/ip_tables_names | Enthält die Liste aller zur Zeit geladenen Tables. |
| /proc/net/ip_queue | Wird von den UserSpace-Queue-Routinen zur Kommunikation genutzt. |
Verwendete Quellen
Folgende Quellen aus dem Internet sowie die man-Page von iptables halfen mir bei der Zusammenstellung zu diesem Workshop:
