Anhang

Analyse von Iptables-Firewalls

Manchmal muss ich eine mir bisher unbekannte Iptables-Firewall analysieren. Sei es dass ich eine bestehende fremde Firewall übernehmen, warten oder erweitern soll, oder dass ich einen Audit mache, ob die Firewall die Vorgaben einer Sicherheitsrichtlinie erfüllt.

Dann benötige ich eine Aufstellung aller Regeln und Ketten, wie ich sie mit iptables-save oder ip6tables-save bekomme. Um die Regeln in den richtigen Kontext setzen zu können brauche ich außerdem Informationen über die angeschlossenen Netze und die Routen.

Falls vorhanden, lege ich mir die Sicherheitsrichtlinien, die für diese Firewall gelten, bereit.

Dann hängt mein weiteres Vorgehen von den Antworten auf zwei Fragen ab:

Kenne ich die Struktur der Regelketten dieser Firewall?
Kenne ich die Sicherheitsrichtlinie, der diese Firewall unterliegt?

Die Frage nach der Struktur bestimmt mein Vorgehen bei der Analyse der Regeln in den einzelnen Ketten.

Gibt es nur die vordefinierten Ketten oder kenne ich die Struktur, wie zum Beispiel für OpenWrt in diesem Buch beschrieben, kann ich mich sofort an die Analyse der Regeln in den Ketten machen.

Gibt es benutzerdefinierte Ketten und ist mir deren Zusammenspiel nicht klar, beginne ich damit, die Struktur der Regelketten zu analysieren.

Eine Sicherheitsrichtlinie kann mir bei der Interpretation der Regeln helfen. Ist mir die Richtlinie bekannt, kann ich jede Regel danach bewerten, ob sie zu deren Durchsetzung beiträgt und notieren, welchen Teil der Richtlinie sie unterstützt.

Kenne ich die Sicherheitsrichtlinie nicht, muss ich mir bei der Analyse der Regeln nebenher eine Ad-hoc-Richtlinie erarbeiten, um den Sinn der Regeln vielleicht am Ende zu verstehen.

Damit habe ich die Vorbereitungen abgeschlossen und kann beginnen, den Paketfilter zu analysieren. Ich betrachte die Tabellen raw, mangle, nat und filter jeweils für sich und berücksichtige dabei die Erkenntnisse aus den anderen Tabellen.

Struktur der Regelketten

Benutzerdefinierte Regelketten sind ein zweischneidiges Schwert: sie können Paketfilterregeln vereinfachen und übersichtlicher machen oder die Analyse des Paketfilters erschweren, wenn mir der Zusammenhang zwischen den Ketten nicht klar ist.

Für OpenWrt habe ich den Zusammenhang zwischen den Regelketten im Kapitel “Modell der Firewall-Regeln bei OpenWrt” erläutert. Bei einer anderen Firewall oder vielleicht schon einer anderen Version von OpenWrt können ganz andere Ketten im Spiel sein. Dann muss ich deren Struktur erst analysieren.

Damit eine benutzerdefinierte Regelkette überhaupt berücksichtigt wird, muss es einen Sprung aus einer anderen Kette, die selbst berücksichtigt wird, zu ihr geben. Die vordefinierten Ketten werden auf jeden Fall berücksichtigt, sie sind die Einsprungspunkte im Kernel.

Diese Sprünge sind für mich als Graphen - mit den Regelketten als Knoten und den Sprung-Regeln als Kanten dazwischen - am anschaulichsten. Solche Graphen kann ich aus der Ausgabe von iptables-save und ip6tables-save gewinnen. Das Perl-Modul App::Iptables2Dot enthält ein Programm, welches mir die Ausgabe von iptables-save für das Programm dot von Graphviz aufbereitet. Mit dot kann ich mir den Graph als Bild in verschiedenen Formaten ausgeben lassen.

Damit bekomme ich eine graphische Übersicht über die Struktur der Regelketten. Mit dieser graphischen Übersicht kann ich auf einen Blick erkennen, von welcher Kette es zu welcher anderen geht und ob es Regelketten gibt, die überhaupt nicht erreicht werden.

Nun kann ich mir die Regeln anschauen und darüber auf den Zweck der einzelnen Regelketten schließen.

Nachdem ich mich auf diese Art mit der Struktur der Regelketten vertraut gemacht habe, kann ich mit der detaillierten Analyse der einzelnen Ketten beginnen.

Analyse der Regeln in den Ketten

Ich beginne mit den vordefinierten Regelketten. Nacheinander betrachte ich alle Regeln einer Kette und vergleiche meine Erkenntnisse mit der Sicherheitsrichtlinie. Steht mir keine Richtlinie zur Verfügung, formuliere ich eine Ad-Hoc-Richtlinie an Hand der Regeln.

Stelle ich dabei fest, dass eine Regel nur im Verbund mit anderen Regeln arbeiten kann, mache ich mir eine Notiz und schaue später nach, ob die anderen Regeln vorhanden sind.

Bin ich fertig mit allen Regeln einer Kette, mache ich mit der ersten angesprungenen benutzerdefinierten Kette weiter, dann mit den anderen bis ich alle Regelketten abgearbeitet habe. Am Ende habe ich alle Regeln betrachtet und Notizen und Anmerkungen zur Sicherheitsrichtlinie.

Habe ich Regeln gefunden, die von der Sicherheitsrichtlinie nicht gedeckt sind, überlege ich, ob diese Regeln entfernt werden können. Dabei ist es hilfreich, die Meinung anderer Betroffener zu hören. Gibt es ein Change Management, finde ich vielleicht in den Aufzeichnungen Informationen zu diesen Regeln.

Finde ich hingegen Teile der Sicherheitsrichtlinie, die nicht durch Paketfilterregeln abgedeckt sind, überlege ich, mit welchen Regeln ich die Firewall ergänzen kann.

Risikoanalyse

Wenn ich Firewall-Regeln für einen Paketfilter aufstelle, so balanciere ich dabei zwischen dem möglichst ungehinderten Durchlassen erwünschten Datenverkehrs und dem möglichst vollständigen Sperren unerwünschten Datenverkehrs. Die Entscheidungen, die ich treffen muss, sind nicht immer trivial, weswegen ich mich gern auf - vorher erstellte - Sicherheitsrichtlinien stütze.

Eine Sicherheitsrichtlinie bestimmt grob, welcher Datenverkehr wo in meinem Netzwerk erwünscht ist und welcher nicht. Zusätzlich gibt sie eine Vorgabe, ob nicht klassifizierter Datenverkehr erlaubt ist oder verboten. Diese Vorgabe kann in einem größeren Netzverbund an verschiedenen Stellen unterschiedlich ausfallen.

Diese Sicherheitsrichtlinie hilft mir beim Aufstellen konkreter Paketfilterregeln. Dazu muss ich sie aber erst einmal erarbeitet haben. Dem geht die Ermittlung meines Schutzbedarfs voraus, die Risikoanalyse.

Wichtig ist, dass ich die Grenzen des Systems bestimme. Sinnvollerweise liegen diese in meinem Verantwortungsbereich, da eine Sicherheitsrichtlinie nur dann ihren Zweck erfüllt, wenn ich sie auch durchsetzen kann.

Bei der Risikoanalyse identifiziere und bewerte ich Risiken, um dann im Rahmen des Risikomanagements mögliche negative Ereignisse mit geeigneten Maßnahmen zu vermeiden, zu reduzieren oder auf Dritte abzuwälzen. Negative Ereignisse im Rahmen der IT-Sicherheit sind Beeinträchtigungen der Vertraulichkeit, der Integrität oder der Verfügbarkeit von Daten.

Beeinträchtigung oder Verletzung der Vertraulichkeit bedeutet, dass Informationen einem Personenkreis zugänglich werden, der dafür nicht berechtigt ist. Das können private E-Mails sein, geheime Geschäftsunterlagen oder anderes.

Beeinträchtigung oder Verletzung der Integrität ist zum Beispiel die Manipulation von Daten durch Dritte, wie zum Beispiel das Verändern von Websites oder das Injizieren von SQL-Code in ein Content Management System.

Beeinträchtigung der Verfügbarkeit heißt, dass legitime Nutzer ein System nicht mehr in vollem Umfang nutzen können. Das kann im einfachsten Fall durch Denial-of-Service-Attacken passieren, entweder durch Überlastung des Systems oder durch vollständige Abschaltung, wie zum Beispiel mit Ping of Death.

Strukturanalyse

Ein wichtiger Bestandteil der Risikoanalyse ist die Strukturanalyse, das Erfassen aller IT-Komponenten, die mit dem betrachteten System verbunden sind. Die IT-Systeme in einem privaten Haushalt lassen sich meist in wenigen Minuten erfassen. Bei einer kleinen Firma dauert es vielleicht einen Tag, bei großen Organisationen muss ich mit mehreren Wochen rechnen und bin auf die Mitarbeit anderer angewiesen.

Habe ich alle IT-Systeme erfasst, kann ich diese nach Typen, das heißt Kategorien gleichartiger Geräte, wie Arbeitsplatzrechner, Server, Router, Switch usw., gruppieren. Für jedes IT-System in einer dieser Gruppen muss ich mit den gleichen Bedrohungen rechnen wie für alle IT-Systeme der gleichen Gruppe. Dementsprechend stehen mir dafür die gleichen Präventionsmaßnahmen zur Verfügung.

Es wäre jedoch Verschwendung, alle Systeme gleich behandeln zu wollen, ihr Risiko bezüglich Vertraulichkeit, Integrität und Verfügbarkeit mit gleichem Aufwand zu bewerten und entsprechende Maßnahmen einzuleiten.

Anforderungen an die Sicherheit

Darum ist der nächste Schritt, der auch parallel zur Strukturanalyse ablaufen kann, die Ermittlung der Aktivposten: wo habe ich welches Vermögen, womit verdiene ich wie viel Geld, wie gebe ich Geld aus. Natürlich kann ich auch versuchen, immaterielle Güter wie Ansehen und Reputation zu bewerten. Zu jedem der Aktivposten ermittle ich die Anforderungen bezüglich Vertraulichkeit, Integrität und Verfügbarkeit.

Wenn ich zum Beispiel Internet-Banking betreibe, dann hat dieser Aktivposten sehr hohe Anforderungen bezüglich Vertraulichkeit (die Kennworte und TANs) und Integrität (die eingegebenen Beträge und Kontonummern) aber meist geringe Anforderungen an die Verfügbarkeit, es sei denn, ich würde meine Rechnungen immer erst zum letztmöglichen Termin bezahlen.

Bei einem Monitoring-System sind die Ansprüche bezüglich Vertraulichkeit geringer, dafür aber hoch bezüglich Integrität (ich möchte keine Fehlalarme) und in Bezug auf Verfügbarkeit, da ich keinen Alarm verpassen will.

Ich gruppiere im nächsten Schritt alle in der Strukturanalyse ermittelten Systeme entsprechend den Aktivposten. Die Anforderungen an die Systeme in den einzelnen Gruppen ergeben sich aus den Anforderungen der Aktivposten. Bei IT-Systemen, die für mehrere der Aktivposten genutzt werden, nehme ich die höchste Anforderung bezüglich Vertraulichkeit, Integrität und Verfügbarkeit.

Nachdem ich so den Schutzbedarf aller Systemkomponenten bestimmt habe, schaue ich als nächstes auf die konkreten Bedrohungen der Komponente und wähle je nach Bedarf die Maßnahmen aus, die mich davor schützen können. Hierbei betrachte ich die IT-Komponenten nach ihrem Typ. Die IT-Grundschutzkataloge des BSI kann ich dabei als Ausgangspunkt für eigene Überlegungen verwenden. Mehr zum IT-Grundschutz finde ich unter [BSI Grundschatz].

Finde ich für eine Komponente keine geeigneten Schutzmaßnahmen, muss ich eine Änderung der Struktur des IT-Systems in Betracht ziehen. Das würde eine erneute Strukturanalyse nach sich ziehen.

Alle ermittelten Maßnahmen fasse ich in Sicherheitsrichtlinien zusammen, aus denen ich am Ende unter anderem die Regeln für die Paketfilter ableite.

Fallstricke

Viele IT-Infrastrukturen, in denen Firewalls eingesetzt werden, sind aus Insellösungen entstanden, kleinen Netzen oder einzelnen Rechnern, die irgendwann mit anderen Netzen oder dem Internet verbunden wurden. Dabei bot sich die Vorstellung eines einzigen Schutzwalls, einer Firewall zwischen dem bestehenden - internen - Netz und dem anderen - externen - Netz an. Einerseits vereinfacht diese Betrachtungsweise die Konfiguration der Firewall am Perimeter, dem Verteidigungsring zwischen innen und außen. Andererseits lassen sich damit vordergründig Kosten sparen.

Das Hauptproblem bei der Beschränkung auf diese simple Betrachtungsweise ist, dass ein einziger Weg von außen nach innen ausreicht, um das gesamte Konzept unwirksam zu machen.

Aus diesem Grund ist es essentiell, bei der Risikoanalyse und den darauf aufbauenden Sicherheitsrichtlinien die verwendeten Modelle stets kritisch zu hinterfragen.

Sicherheitsrichtlinien

Die beste Risikoanalyse nützt wenig, wenn ihre Erkenntnisse nicht praktisch angewendet werden. Nun kann man in der Praxis nicht für jede einzelne Entscheidung dutzende oder gar hunderte Seiten wälzen. Hier benötigt man kurze, präzise Dokumente, die die wesentlichen Punkte in Erinnerung rufen - Richtlinien, für das Thema des Buches: Sicherheitsrichtlinien.

Damit diese kurz und präzise sein können, müssen sie sich jeweils auf ein eng begrenztes Thema beschränken. Das bedeutet wiederum, dass für manche Themenbereiche mehrere Richtlinien gelten. Hier muss ich darauf achten, dass die einzelnen Richtlinien einander nicht widersprechen. Dafür ist es sinnvoll, diese nicht nur nach dem Thema sondern zusätzlich nach dem Geltungsbereich abzugrenzen.

Damit man die benötigten Informationen in den Richtlinien leicht findet, empfiehlt es sich, ein einheitliches Format zu schaffen und Templates zu verwenden.

Beispiele für Sicherheitsrichtlinien finden sich beim SANS Institute.

Generell sollten Sicherheitsrichtlinien die folgenden Punkte enthalten:

Überblick
Zweck
Geltungsbereich
Anweisungen
mitgeltende Unterlagen
Einhaltung
Änderungsverzeichnis

Die aktuelle Version sowie der Name oder die Nummer der Richtlinie sollte auf jeder Seite zu finden sein, zum Beispiel in den Kopf- oder Fußzeilen.

Der Überblick gibt kurz und knapp den Kontext der Richtlinie an. Dafür reicht oft ein Satz.

Der Zweck beschreibt die Ziele, die mit dieser Richtlinie erreicht werden sollen. Da das Thema der Richtlinie eng begrenzt ist, sollte auch dieser Abschnitt nicht allzu groß werden.

Der Geltungsbereich schränkt ein, wo die Richtlinie anzuwenden ist.

Diese ersten drei Punkte helfen dabei, zu bestimmen, ob eine vorliegende Richtlinie beim konkreten Problem überhaupt anwendbar ist und gehören daher an den Anfang.

Die Anweisungen stellen den Kern der Richtlinie dar. Das kann der umfangreichste Abschnitt sein, die Richtlinie kann aber auch nur aus einer einzigen Anweisung bestehen.

Unter dem Punkt mitgeltende Unterlagen finden sich Hinweise auf weitere Dokumente oder andere Richtlinien, die in dem betreffenden Geltungsbereich zusätzlich zu berücksichtigen sind.

Diese beiden Punkte sind der Kern der Richtlinie. Auf sie folgen noch ein paar Punkte, die sich mehr mit der Richtlinie und dem Umgang mit ihr beschäftigen als mit dem eigentlichen Thema. Da diese Punkte seltener benötigt werden, kommen sie nach dem Hauptteil.

Der Abschnitt Einhaltung beschäftigt sich mit der Durchsetzung der Richtlinie. Wie wird das kontrolliert? Wie können Ausnahmen geregelt werden? Was passiert bei Nichteinhaltung der Richtlinie? Damit regelt dieser Abschnitt auch, wie die Richtlinie geändert werden kann.

Das Änderungsverzeichnis ist oft nur für diejenigen interessant, die die Richtlinie erstellen und kommt daher ganz zum Schluss. Hier reicht eine tabellarische Aufführung der veröffentlichten Versionen.

Glossar

6rd: IPv6 Rapid Deployment on IPv4 Infrastructures, ein Verfahren zum Tunneln von IPv6 über IPv4-Netze, in RFC 5569 und RFC 5969 beschrieben.
6to4: Connection of IPv6 Domains via IPv4 Clouds, ein Verfahren zum Tunneln von IPv6 über IPv4-Netze, in RFC 3056 beschrieben.
Advanced Persistent Threats, APT: Gezielte Angriffe, bei denen Angreifer mit Nachdruck und umfangreichen Ressourcen versuchen in Rechnersysteme beziehungsweise -netzwerke einzudringen.
APIPA: Automatic Private IP Addressing, Implementierung von Microsoft für die automatische Netzwerk-Konfiguration Zeroconf.
Application Gateway, Application Layer Gateway: Ein anwendungsspezifischer Dienst, der Hosts in einem Adressbereich erlaubt sich mit Hosts in einem anderen Adressbereich zu verbinden. Definiert in RFC 2663.
ARP: Address Resolution Protocol, ermittelt die zu einer IP-Adresse gehörende Adresse der Netzzugangsschicht. Beschrieben in RFC 826.
Arptables: Programm des Netfilter-Frameworks von Linux, mit dem die Regeln für ARP-Einträge verwaltet werden können.
Basic NAT: ein Block von externen Adressen wird reserviert für die Adressen von Hosts in einem privaten Netzbereich, wenn sie Verbindungen zum externen Bereich aufbauen.
Bi-directional NAT: erlaubt den Aufbau von Verbindungen von beiden Seiten (intern und extern). Wird auch Two-Way-NAT genannt.
Bonjour: Implementierung von Apple für die automatische Netzwerk-Konfiguration Zeroconf.
Broadcast: Broadcast-Nachrichten werden an alle Teilnehmer eines Teilnetzwerks gesendet, im Gegensatz zu Multicast und Unicast.
Broadcast-Domain: Bereich eines Netzwerkes, bis zu dem Broadcast-Nachrichten gesendet werden. Üblicherweise alle Geräte im selben Layer2-Netzwerk.
Captive Portal: Ein Captive Portal leitet einen Webbrowser in einem Netzwerk auf eine spezielle Seite um, bei der er sich anmelden muss, bevor er alle Funktionen des Netzwerkes nutzen kann.
CLI: Command Line Interface, die Kommandozeile, ein oft schwarzer Kasten, in dem man Befehle als Text eingibt und Ausgaben als Text präsentiert bekommt.
Connection Tracking: Auf Deutsch auch Verbindungsverfolgung. Die Statusinformationen von Verbindungen werden gespeichert, um ankommende Datagramme besser auf Gültigkeit prüfen zu können. Für bestimmte Protokolle, wie FTP, SIP, TFTP gibt es spezielle Connection Tracking Module, die den Inhalt der Daten untersuchen, um weitere zur Sitzung gehörende Verbindungen identifizieren zu können.
Datagramm: Eine einzelne, unabhängige Dateneinheit, die vom Sender an den Empfänger geschickt wird. Auch Datenpaket genannt.
Datagramm-Header: Die Verwaltungsinformationen für das Versenden eines Datagramms werden diesem üblicherweise vorangestellt und als Header bezeichnet. Da die Datenübertragung gemäß dem OSI-Modell in Schichten unterteilt wird und die höheren Schichten die Dienste der tieferen Schichten nutzen, wird ein Datagramm um so länger, je tiefer die betrachte Schicht ist. So wird beispielsweise einem Datagramm, das per UDP über Ethernet versendet wird, zunächst der UDP-Header vorangestellt, diesem wiederum der IP-Header und diesem der Ethernet-Header. Auf dem Kabel gehen dem eigentlichen Datenstrom ein paar Takte voraus, um dem Empfänger die Synchronisierung zu ermöglichen.
DHCP: Dynamic Host Configuration Protocol, ein Protokoll, dass die Zuweisung der Netzwerk-Konfiguration an Clients durch einen Server ermöglicht. Da dieses Protokoll auch über Router verwendet werden kann, ist es möglich, dass ich es bei der Firewall-Konfiguration berücksichtigen muss. Beschrieben in RFC 2131.
DMZ: Demilitarisierte Zone, ein Teilnetz eines Computernetzwerkes mit kontrollierten Zugriffsmöglichkeiten. Eine DMZ wird meist zwischen Netzen, deren Verkehr reguliert werden soll, eingerichtet, zum Beispiel zwischen dem lokalen Netz und dem Internet.
DNAT: Destination NAT, Änderung der Zieladresse, siehe dazu auch NAT.
DNS: Domain Name System, einer der wichtigsten Dienste in IP-basierten Netzwerken, beantwortet unter anderem Anfragen zu Rechner- und Dienstnamen, Adressen und Zertifikaten.
DPI: Deep Packet Inspection, ein Verfahren zur Überwachung und Filterung von Netzwerk-Datagrammen. Während klassische Paketfilter nur die Datagramm-Header untersuchen, werden hier sowohl Header als auch Daten berücksichtigt.
Dual-Stack-Betrieb: Gleichzeitiger Betrieb von IPv4 und IPv6.
Ebtables: Programm des Netfilter-Frameworks von Linux zu Administration von Ethernet-Bridges.
ECN: Explicit Congestion Notification, eine Erweiterung von TCP/IP zur Überlastkontrolle, beschrieben in RFC 3168.
Encapsulation: Das Verpacken von Datagrammen, einschließlich Headern, als Nutzdaten in einem anderen Protokoll. Encapsulation wird zum Beispiel bei VPNs verwendet, aber auch um IPsec-Datagramme über einen NAT-Router zu transportieren. Aufgrund der beschränkten maximalen Größe eines Datagramms, reduziert sich die MTU des eingepackten Protokolls.
Ethernet: Bezeichnung für die Technologie, das Protokoll und die Hardware für kabelgebundene Datennetze. Bildet die Schichten 1 und 2 des OSI-Modells ab.
Ethernet-Bridge: Ein Gerät, dass zwei Ethernet-Netze miteinander verbindet. Das kann ein einfacher Switch sein, oder eine Firewall, bei der man dann Datagramme der OSI-Schichten 1 und 2, die normalerweise nicht über Router gesendet werden, filtern kann.
Firewall-Cluster: Eine Gruppe von Firewalls, die Zustandsinformationen austauschen, um entweder bei Ausfall eines Geräts unverzüglich mit einem anderen weiter zu arbeiten, oder den Datenverkehr im Sinne einer Lastverteilung gleichzeitig zu filtern.
Firmware: Software, die in einem Gerät eingebettet ist und vom Anwender gar nicht oder nur mit speziellen Mitteln ausgetauscht werden kann.
Fragmentierung: Ein Computernetz kann Datagramme nur bis zu einer bestimmten Maximalgröße am Stück transportieren. Überschreitet ein Datagramm diese Größe, muss es aufgeteilt (fragmentiert) werden.
FTP: File Transfer Protocol, ein Protokoll zur Übertragung von Dateien. Ein wesentliches Merkmal dieses Protokolls ist, dass für Befehle und Daten verschiedene TCP-Sitzungen verwendet werden. Um dieses Protokoll sauber filtern zu können, müssen die TCP-Sitzungen verfolgt und die Ports für die Daten dynamisch freigegeben werden.
GRE: Generic Routing Encapsulation, dient dazu, andere Protokolle einzukapseln und über das Internet-Protokoll zu transportieren, beschrieben in RFC 2890.
Hair-Pinning: Manchmal auch NAT Loopback genannt, meint die Kommunikation zwischen zwei Geräten hinter demselben NAT-Router über dessen öffentliche Adresse. Damit das funktioniert, muss es vom NAT-Router unterstützt werden. Beim OpenWrt-Filter wird das bei der Konfiguration via LuCI meist automatisch eingestellt.
Hole-Punching: Meint ein Verfahren, mit dem zwei Geräte, die beide hinter NAT-Routern angeschlossen sind, trotzdem eine direkte UDP-Verbindung aufbauen können. RFC 3489 beschreibt eine weiterentwickelte Form des Verfahrens.
ICMP: Internet Control Message Protocol, dient dem Austausch von Informations- und Fehlermeldungen für IPv4, definiert in RFC 792.
ICMPv6: ICMP für IPv6.
IDS: Intrusion Detection System, dient der automatischen Erkennung von Angriffen gegen ein Computersystem oder -netz.
IETF: Internet Engineering Task Force, beschäftigt sich mit der technischen Weiterentwicklung des Internet.
IGMP: Internet Group Management Protocol, dient zur Organisation von Multicast-Gruppen bei IPv4. Bei IPv6 werden dessen Aufgaben von ICMPv6 übernommen.
IP: Internet Protokoll
Ip6tables: Programm des Netfilter-Frameworks von Linux, mit dem die Regeln für den IPv6-Paketfilter verwaltet werden können.
IPS: Intrusion Prevention System, soll Funktionen bereitstellen, die einen aktuellen Angriff gegen ein Computersystem oder -netz abwehren können.
IPsec: Internet Protocol Security, ein Satz von Protokollen, die eine kryptographisch gesicherte Kommunikation über unsichere Netze ermöglichen soll.
Iptables: Programm des Netfilter-Frameworks von Linux, mit dem die Regeln für den IPv4-Paketfilter verwaltet werden können.
IPv4: Internet Protocol Version 4, wurde 1981 im RFC 791 definiert.
IPv6: Internet Protocol Version 6 ist der Nachfolger von IPv4.
ISATAP: Intra-Site Automatic Tunnel Addressing Protocol, ein Verfahren, um IPv6-Datagramme über IPv4-Netze zu übertragen.
ISP: Internet Service Provider, ein Dienstleister, der einen Zugang zum Internet anbietet.
L1, L2, L3: Die untersten Ebenen des OSI-Modells, L1 die Bitübertragungsschicht, L2 die Sicherungsschicht, L3 die Vermittlungsschicht.
Layer2-Domain: Bereich eines Netzwerkes, in dem alle angeschlossenen Geräte in der selben Sicherungsschicht verbunden sind. Bei IPv4 alle Geräte, die über die Broadcast-Adresse erreicht werden können, bei IPv6 alle Geräte, die über ihre link-lokalen Adressen erreicht werden können.
link-lokale Adresse: durch Autokonfiguration ermittelte Adresse. Bei IPv4 via Zeroconf ausgehandelt, bei IPv6 durch SLAAC.
MAC-Adresse: Media Access Control Address, die Hardware-Adresse jedes einzelnen Netzwerkadapters.
Masquerading: das Verbergen ganzer Netzwerke hinter einer einzelnen IP-Adresse bei NAT.
Monitoring: das Überwachen von Computern und Netzwerk-Komponenten auf Fehlerzustände.
MSS: Maximum Segment Size, die maximale Anzahl von Bytes, die als Nutzdaten in einem TCP-Segment (einem Datagramm) versendet werden können. Ist immer bezogen auf eine TCP-Sitzung, wird beim Verbindungsaufbau ausgehandelt und ist geringer als die MTU.
MSS-Clamping: Ein Hack, mit dem die MSS auf einem Datenpfad von einem Router begrenzt wird, damit die einzelnen Datagramme nicht größer werden wie die MTU. Funktioniert nur mit TCP.
MTU: Maximum Transmission Unit, maximale Größe eines nicht fragmentierten Datagramms in einem Computernetzwerk. Ist größer als die MSS bei TCP, da für diese noch die Größe des IP- und des TCP-Headers von der MTU abgezogen werden muss.
Multicast: Multicast-Nachrichten werden an eine Gruppe von Empfängern gesendet, im Gegensatz zu Broadcast und Unicast.
Multicast-DNS: Bestandteil der automatischen Konfiguration von Zeroconf zur Auflösung von Namen. Im Gegensatz zu normalem DNS, bei dem wenige DNS-Server für die Namensauflösung zuständig sind, antwortet bei Multicast-DNS jeder Knoten auf Anfragen zu den von ihm beanspruchten Namen.
NAPT: Network Address Port Translation, eine Art von NAT, bei der sowohl die Adressen als auch die Ports geändert werden. Wird zum Beispiel verwendet, wenn mehrere Adressen eines Netzes zu einer einzigen Adresse umgesetzt werden sollen. Masquerading bei Linux ist eine Form von NAPT.
NAT: Network Address Translation, das Verändern der Quell- und/oder Ziel-Adressen von Datagrammen, die einen Router oder eine Firewall passieren.
NATBlaster: Verfahren und Software zum Aufbau von direkten TCP-Verbindungen zwischen zwei Geräten, die sich beide hinter NAT befinden.
NAT-Traversal: Verfahren zum Errichten und Aufrechterhalten von Netzwerkverbindungen über NAT-Geräte. Es gibt verschiedene Verfahren, die abhängig sind vom Verhalten der NAT-Geräte und von den Anforderungen der transportierten Daten. Wird zum Beispiel benötigt für Peer-to-Peer-Dateiaustausch, Voice-over-IP oder IPsec.
Neighbor Discovery: Das Auflösen von IPv6-Adressen zu Link-Layer-Adressen. Ersetzt ARP von IPv4.
Netfilter: Software-Projekt, das Paketfilter, NAT und weitere für Firewalls relevante Werkzeuge für Linux bereitstellt. Darum geht es in diesem Buch.
Network Realm: Netzwerkbereich, in dem Adressen eindeutig vergeben sind. Bei der Kommunikation zwischen verschiedenen Network Realms wird oft NAT eingesetzt, wenn die Adressräume überlappen oder wenn Adressen aus einem Realm ungültig im anderen sind.
OpenVPN: Programm zum Aufbau von VPN über verschlüsselte TLS-Verbindungen. Kann mit UDP oder TCP arbeiten.
OPKG Package Manager: Programm zu Software-Verwaltung unter OpenWrt.
OSI-Modell: Schichtenmodell, das als Grundlage für den Entwurf von Kommunikationsprotokollen entwickelt wurde.
Packet Flow: Richtung in der sich ein Datagramm bewegt, bezogen auf ein Netzwerkinterface.
Path-MTU: Die kleinste MTU aller Teilnetze, die ein Datagramm durchquert um vom Sender zum Empfänger zu gelangen. TCP hat einen Mechanismus, um die Path-MTU automatisch zu bestimmen, der durch einen unsachgemäß eingestellten Paketfilter gestört werden kann.
Perimeter-Router: Router an der Grenze zwischen zwei Netzen, die zu verschiedenen Verantwortungsbereichen gehören. Zum Beispiel ein Internet-Zugangsrouter.
Port-Scan: Ausprobieren verschiedener Ports an einem oder mehreren Rechnern, um zu überprüfen, ob an diesen Ports Dienste angenommen werden.
PPP: Point-to-Point Protocol, ursprünglich ein Protokoll für Wählleitungen, ist heute das Standardprotokoll für Internetprovider.
Privacy Extensions: Erweiterung für IPv6, durch die sich Client-Rechner selbst regelmäßig wechselnde Adressen zuweisen damit ein Rechner nicht an Hand seiner IPv6-Adresse wiedererkannt werden kann. Für Server eher nicht geeignet.
Proxy: Programm, dass stellvertretend für ein Client-Programm eine Verbindung aufbaut. Dabei baut das Client-Programm die Verbindung zum Proxy auf und dieser wiederum zum Server.
Receive-Window: Bei TCP die maximale Datenmenge, die ein Computer empfangen kann, ohne diese bestätigen zu müssen. Will der Sender mehr Daten schicken, muss er auf eine Bestätigung der bisher gesendeten Daten warten.
RFC: Request for Comments, Name für eine Reihe von Dokumenten zum Internet, in denen die meisten im Internet verwendeten Protokolle beschrieben sind.
Router: Netzwerkgerät, dass Datagramme zwischen verschiedenen Layer2-Domains weiterleiten kann.
SELinux: Security Enhanced Linux, Erweiterung des Linux-Kernels für verbesserte Sicherheit.
Session Flow: Richtung, in der eine Verbindung initiiert wurde, bezogen auf ein Netzwerkinterface. Da eine Verbindung in den meisten Fällen aus Datagrammen in zwei Richtungen besteht, ist der Session Flow mitunter verschieden vom Packet Flow.
SIP: Session Initiation Protocol, Protokoll zum Aufbau, zur Steuerung und zum Abbau von Verbindungen zwischen zwei und mehreren Teilnehmern, wird häufig in der IP-Telefonie verwendet und ist in RFC 3261 beschrieben.
SLAAC: siehe Stateless Address Auto Configuration.
SMTP: Simple Mail Transfer Protocol, zum Austausch von E-Mails im Internet.
SNAT: Source NAT, die Veränderung der Quelladresse eines Datagramms.
SNMP: Simple Network Management Protocol, einfaches Protokoll zu Überwachung und Steuerung von Geräten in einem Computernetz.
SOHO: Small Office Home Office, Bezeichnung für kleine Büros und Heimarbeitsplätze und für alles, was in diesem Zusammenhang verkauft wird, zum Beispiel SOHO-Router.
SSH: Secure Shell, Bezeichnung für ein Protokoll und das entsprechende Programm, mit dem eine verschlüsselte Verbindung zu einem entfernten Rechner hergestellt kann.
stateful: zustandsorientiert/zustandsbehaftet, bei einem Paketfilter bedeutet das, dass dieser sich den Zustand der Verbindungen, die über ihn laufen, merkt und bei der Bewertung der Datagramme berücksichtigt.
stateless: zustandslos, bei einem Paketfilter bedeutet das, dass jedes Datagramm ausschließlich nach den Regeln und den im Paket enthaltenen Daten bewertet wird.
Stateless Address Auto Configuration: Verfahren zur zustandslosen automatischen Adresskonfiguration von Geräten in einem IPv6-Netz. Zustandslos meint, dass die Adresse weder zentral vergeben noch gespeichert wird.
STUN: Session Traversion Utilities for NAT, ein einfaches Protokoll um NAT-Router zu erkennen und direkte Verbindungen von Geräten, die sich hinter verschiedenen NAT-Routern befinden, zu ermöglichen. Benötigt einen Rendezvous-Server im Internet.
TCP: Transmission Control Protocol, ein zuverlässiges, verbindungsorientiertes, paketvermitteltes Transportprotokoll für Computernetze. Paketvermittelt meint, dass das Protokoll Datagramme für die Verbindung verwendet. Zuverlässig meint, dass verlorene Datagramme automatisch wiederholt werden. Verbindungsorientiert meint, dass die Daten beim Empfänger in der Reihenfolge ankommen, in der sie beim Sender versandt werden.
TCP-Stealth: Eine Erweiterung für TCP, die konform mit dem Standard ist, aber ermöglicht, offene Ports an einem Server vor Port-Scans zu verbergen.
Telnet: Protokoll und Programm zur unverschlüsselten Datenübertragung über TCP.
Teredo: IPv6-Übergangsmechanismus mit dem IPv6-Datagramme über IPv4-Netz übertragen werden können.
TFTP: Trivial File Transfer Protocol, ein sehr einfaches Protokoll zur Übertragung von Dateien. Wird zum Beispiel beim Starten von Rechnern aus dem Netzwerk oder zum Sichern von Konfigurationsdateien von Routern verwendet.
Twice-NAT: Sowohl Quell- als auch Zieladresse von Datagrammen werden übersetzt. Twice-NAT wird verwendet, um Netzwerkbereiche mit überlappendem Adressraum und Adresskollisionen zu verbinden.
UDP: User Datagram Protocol, ein minimales, verbindungsloses Protokoll zur Datenübertragung. Es gibt keine Gewähr, dass die Daten überhaupt oder in der richtigen Reihenfolge ankommen.
Unicast: Eine Unicast-Nachricht geht vom Sender zu genau einem Empfänger, im Gegensatz zu Broadcast und Multicast.
VoIP: Voice over IP, Telefonieren über das Internet
VPN: Virtual Private Network, ein Netzwerk, das zum Datentransport andere Netzwerke, zum Beispiel das Internet verwendet. Zum Schutz der Kommunikation im VPN werden die Datagramme oft verschlüsselt über das Transportnetz verschickt.
WAN: Wide Area Network, System von Computern, die über große Entfernungen miteinander vernetzt sind. Bei SOHO-Routern meist die Bezeichnung für den Internet-Anschluss.
WLAN: Wireless Local Area Network, lokales Funknetz.
X86: Abkürzung für eine Mikroprozessor-Architektur, die auf die Prozessoren der 8086/8088 Reihe von Intel zurückgeht.

Literatur

Bücher

Hagen2014

Hagen, Silvia; IPv6 Essentials - Integrating IPv6 into your IPv4 Network; O’Reilly, Sebastopol, 2014; ISBN 978-1-449-31921-2

Die Bücher von Silvia Hagen sind hilfreich für das Einarbeiten in das Thema IPv6.

SteChe2005

Steinberg, Daniel H., Cheshire, Stuart; Zero Configuration Networking: the Definite Guide; O’Reilly, Sebastopol, 2005; ISBN 978-0-596-10100-8

Die Autoren beschreiben detailliert die Mechanismen zur automatischen Netzwerkkonfiguration von elektronischen Geräten. Wer nur einen kurzen Überblick möchte, kann zunächst zu dem Artikel [ctRudl2014] greifen.

Weidner2012

Weidner, Mathias; Linux kopflos mit PC Engines ALIX; Lulu Press, Raleigh, 2012; ISBN 978-1-4717-2849-5

In einem Kapitel dieses Buches hatte ich mich mit der Konfiguration des Paketfilters bei einer älteren Version von OpenWrt beschäftigt.

Artikel

BiFeWiPe2005

Andrew Biggadike, Daniel Ferullo, Geoffrey Wilson, Adrian Perrig; NATBLASTER: Establishing TCP Connections Between Hosts Behind NATs; Proceedings of ACM SIGCOMM ASIA Workshop 2005 http://www.netsec.ethz.ch/publications/papers/natblaster.pdf

Die Autoren beschreiben ein Verfahren, um direkte TCP-Verbindungen zwischen zwei Hosts hinter NAT-Geräten aufzubauen.

ctAhlers2014

Ernst Ahlers; Ersatzteil - Alt-PC zum Router umrüsten; c’t Magazin für Computertechnik 2014 Heft 5, S. 96-99; ISSN 0724-8679

Der Autor beschreibt wie sich ein Windows-Rechner mit VirtualBox in wenigen Schritten zum Router mit OpenWrt umrüsten lässt, falls der existierende Zugangsrechner nicht mehr verwendbar ist.

ctKaps2014

Reiko Kaps; Schilde hoch! - Angriffen auf Router vorbeugen; c’t Magazin für Computertechnik 2014 Heft 9, S. 90-91; ISSN 0724-8679

Der Autor vermittelt einige grundlegende Hinweise, die zumindest das automatisierte Ausnutzen von Schwachstellen in Routern erschweren können.

ctKGEAPM2014

Julian Kirsch, Christian Grothoff, Monika Ermert, Jacob Appelbaum, Laura Poitras, Henrik Moltke; TCP Stealth vs. Five Eyes - Mit Technik gegen staatliche Geheimdienst-Botnetze; c’t Magazin für Computertechnik 2014 Heft 22, S. 170-173; ISSN 0724-8679

Die Autoren beschreiben kurz die Wirkungsweise von TCP-Stealth und wie der Linux-Kernel damit ergänzt werden kann.

ctLindner2014

Felix ‘FX’ Lindner; Licht aus! - Sicherheit kritischer Infrastrukturen im Test; c’t Magazin für Computertechnik 2014 Heft 9, S. 150-155; ISSN 0724-8679

ctRudl2014

Tomas Rudl; Finden ohne Suche - Bonjour konfiguriert und findet Geräte im Netz; c’t Magazin für Computertechnik 2014 Heft 15, S. 162-165; ISSN 0724-8679

Dieser Artikel führt kurz und verständlich in das Protokoll Bonjour für die automatische Netzwerk-Konfiguration ein.

ctSchmidt2006

Jürgen Schmidt; Der Lochtrick - Wie Skype & Co. Firewalls umgehen; c’t Magazin für Computertechnik 2006 Heft 17, S. 142ff; ISSN 0724-8679

Der Autor beschreibt anschaulich das “UDP hole punching” bei NAT-Geräten und zeigt, wie man das Prinzip mit einfachen Mitteln selbst ausprobieren kann.

ctSchoeler2014

Timo Schöler; Gemächliche Revolution - iptables Nachfolger für Linux; c’t Magazin für Computertechnik 2014 Heft 5, S. 106-109; ISSN 0724-8679

Dieser Artikel stellt das neue Firewall-Framework für Linux nftables kurz vor, hilft bei ersten Schritten und verweist für weitergehende Informationen auf geeignete Onlinequellen.

ctSKL2012

Christian Schneider, Martina Kannen, Martin Leischner; Bringdienst - IPv6 Autokonfiguration für Clients; c’t Magazin für Computertechnik 2012 Heff 11, S. 72-76

Die Autoren erläutern mehrere Verfahren der IPv6-Autokonfiguration von Clients und berichten über den Stand der Unterstützung verschiedener Client Betriebssysteme von 2012. Vom Thema dieses Buches her ist die Erläuterung der Verfahren interessant.

FoSriKe2005

Bryan Ford, Pyda Srisuresh, Dan Kegel; Peer-to-Peer Communication Across Network Address Translators; Proceedings of the USENIX Annual Technical Conference (Anaheim, CA), April 2005, S.179-192

Die Autoren fassen die verschiedenen Verfahren, um direkte UDP- und TCP-Verbindungen über NAT-Geräte aufzubauen, zusammen und gehen auch auf die Eigenschaften von P2P-freundlichen NAT-Geräten ein.

ixGK2014

Christian Grothoff, Julian Kirsch; Gut verschlossen - Unsichtbare Server mit TCP Stealth; iX Magazin für professionelle Informationstechnik 2014 Heft 10, S.136-138; ISSN 0935-9680

Die Autoren beschreiben die von ihnen entwickelte, mit dem TCP-Standard kompatible Erweiterung, die es erlaubt, bereits das erste Datenpaket einer TCP-Verbindung zu authentifizieren und damit die Entdeckung von durch TCP Stealth geschützten Diensten durch Portscans zu vereiteln.

ixPlura2014

Michael Plura; Zutritt verboten - Freie Firewall-Appliance pfSense 2.1; iX Magazin für professionelle Informationstechnik 2014 Heft 5, S.100-105; ISSN 0935-9680

Der Autor beschreibt die auf FreeBSD aufsetzende Firewall pfSense, die nicht nur Paketfilter ist, sondern zu einer vollwertigen Firewall ausgebaut werden kann. Auf X86-Systemen ist sie damit mehr als eine Alternative zum Paketfilter von OpenWrt.

ixStrobel2014

Stefan Strobel; Abwehrstrategien - Technische Ansätze zum Schutz vor APTs; iX Magazin für professionelle Informationstechnik 2014 Heft 2, S. 109-111; ISSN 0935-9680

Der Autor gibt einen Überblick über technische Ansätze, um Advanced Persistent Threats zu begegnen. Ein Paketfilter findet dabei seinen Platz bei den klassischen Ansätzen am Übergang zwischen verschiedenen Netzen.

ixWegener2013

Christoph Wegener; Breit gefasst - Monitoring nach der Einführung von IPv6; iX Magazin für professionelle Informationstechnik 2013 Heft 3, S. 114-118; ISSN 0935-9680

Der Autor geht auf einige Besonderheiten ein, die sich beim Monitoring nach der Einführung von IPv6 ergeben.

Online-Qellen

BSI Grundschatz

https://www.bsi.bund.de/DE/Themen/ITGrundschutz/itgrundschutz_node.html
Aufgerufen: 2016-11-10

Der vom Bundesamt für Sicherheit in der Informationstechnik entwickelte IT-Grundschutz hilft, notwendige Sicherheitsmaßnahmen zu identifizieren und umzusetzen. Für die Risikoanalyse ist insbesondere der BSI-Standard 100-3 “Risikoanalyse auf der Basis von IT-Grundschutz” interessant, für die Einarbeitung in das Thema der BSI-Standard 100-2 “IT-Grundschutz-Vorgehensweise”, die beide über den Link IT-Grundschutz-Standards zu finden sind.

Secure use of iptables and connection tracking helpers

https://home.regit.org/netfilter-en/secure-use-of-helpers/ Aufgerufen: 2016-11-22

Die Autoren geben Hinweise auf Fallstricke beim Einsatz von Iptables Session-Helpern für das Tracking von Protokollen wie FTP oder SIP.

Firewall configuration (OpenWrt Wiki)

https://wiki.openwrt.org/doc/uci/firewall
Aufgerufen: 2016-08-13

Die Wiki-Seite zur Firewall-Konfiguration gibt detaillierte Hinweise insbesondere zur Konfiguration mit UCI. Viele Details, die in diesem Buch keinen Platz gefunden haben, finden sich dort.

Netfilter/Nftables (OpenWrt-Wiki)

https://wiki.openwrt.org/doc/howto/netfilter Aufgerufen: 2016-11-22

Die Seite zu den Netfilter-Modulen mit weiteren Hinweisen und etlichen externen Referenzen.

nftables (OpenWrt-Wiki)

https://wiki.openwrt.org/doc/howto/nftables Aufgerufen: 2016-11-10

Nftables ist der Nachfolger von Netfilter, der Grundlage dieses Buches. Auf dieser Wiki-Seite finden sich Hinweise zum Stand der Integration von nftables in OpenWrt sowie Verweise zu weiteren Informationen.

Table of Hardware (OpenWrt-Wiki)

https://wiki.openwrt.org/toh/start Aufgerufen: 2016-08-13

Auf dieser Seite findet man einen Überblick, welche Hardware von OpenWrt unterstützt wird und vor allem wie gut. Bevor ich ein Gerät für den Einsatz mit OpenWrt kaufe, schaue ich immer erst hier herein.

Comparison of firewalls (Wikipedia)

https://en.wikipedia.org/wiki/Comparison_of_firewalls Aufgerufen: 2016-08-13

Diese Seite eignet sich als Einstiegspunkt für die Suche nach Alternativen zu OpenWrt als Firewall. Hier finden sich sowohl proprietäre als auch Open Source Firewalls.

List of router and firewall distributions (Wikipedia)

https://en.wikipedia.org/wiki/List_of_router_and_firewall_distributions Aufgerufen: 2016-08-13

Ein weiterer Einstiegspunkt für die Suche nach Alternativen zu OpenWrt. Das ist eine Liste von Betriebssystemen (Distributionen) für den Einsatz von Computern als Router oder Firewall. Die meisten dieser Betriebssysteme basieren auf Linux oder BSD.

RFC - Requests for Comment

RFCs bilden die Grundlage für die Internet-Standards. Traditionell werden RFC von der Internet Engineering Task Force (IETF) herausgegeben.

Ein Verzeichnis aller RFC ist unter http://tools.ietf.org/rfc/index zu finden.

RFC 768

User Datagram Protocol

Dieser RFC von 1980 ist die noch heute gültige Beschreibung dieses Protokolls.

RFC 791

INTERNET PROTOCOL
DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION

Die Beschreibung des heute als IPv4 bekannten Internet Standards wurde durch die RFCs 2474 und 6864 aktualisiert und ergänzt.

RFC 792

INTERNET CONTROL MESSAGE PROTOCOL
DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION

Dieser Internet Standard wurde durch die RFCs 950, 4884, 6633 und 6918 aktualisiert und ergänzt.

RFC 793

TRANSMISSION CONTROL PROTOCOL
DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION

Dieser Internet Standard wurde unter anderem durch die RFCs 1122, 3168 und 6093 aktualisiert und ergänzt.

RFC 826

An Ethernet Address Resolution Protocol
– or –
Converting Network Protocol Addresses
to 48.bit Ethernet Address
for Transmission on
Ethernet Hardware

Normalerweise muss ich mich bei einem Paketfilter nicht mit dem ARP-Protokoll, das dieser RFC beschreibt, beschäftigen. Ausnahmen sind Paketfilter, die nicht als Router sondern als Bridge betrieben werden.

RFC 894

A Standard for the Transmission of IP Datagrams over Ethernet Networks

Dieser RFC beschreibt, wie IP-Pakete in Ethernet-Frames eingekapselt werden.

RFC 950

Internet Standard Subnetting Procedure

Dieser Internet Standard beschreibt das Aufteilen von Netzen in Teilnetze.

RFC 6918 aktualisiert und ergänzt diesen RFC.

RFC 1042

A Standard for the Transmission of IP Datagrams over IEEE 802 Networks

Dieser Internet Standard beschreibt, wie IP-Pakete in IEEE 802 Netzwerke eingekapselt werden, ähnlich wie RFC 894 für Ethernet. Die IEEE 802 Spezifikationen beschreiben eine Familie von LAN Protokollen, die sich mit den OSI-Schichten 1 und 2 beschäftigen.

RFC 1112

Host Extensions for IP Multicasting

Dieser Internet Standard die notwendigen Ergänzungen der IP-Implementation eines Hosts, damit dieser am Multicasting teilnehmen kann.

RFC 2236 aktualisiert und ergänzt diesen RFC.

RFC 1122

Requirements for Internet Hosts – Communication Layers

Dieser Internet Standard beschreibt die Anforderungen an Internet Host Software bezüglich der OSI-Schichten 1 bis 4. Die Anforderungen bezüglich der OSI-Schichten 5 bis 7 behandelt RFC 1123.

Das Verständnis der Anforderungen dieses RFCs ist fundamental, wenn man beim Betrieb einer Paketfilter-Firewall den erlaubten Datenverkehr nicht behindern will.

Die RFCs 4379, 6093, 6633 und 6864 aktualisieren und ergänzen RFC 1122.

RFC 1123

Requirements for Internet Hosts – Application and Support

Dieser Internet Standard beschreibt einige Anwendungsprotokolle, wie zum Beispiel FTP, TFTP, SMTP, DNS.

Für den Betrieb einer Paketfilter-Firewall ist deren Kenntnis nur dann notwendig, wenn ihr Datenverkehr darüber läuft. In diesem Fall kann dieses RFC als Einstieg in die Vertiefung mit dem betreffenden Protokoll dienen.

Die RFCs 2181 und 5966 aktualisieren und ergänzen diesen RFC.

RFC 1858

Security Considerations for IP Fragment Filtering

IP-Fragmentierung kann verwendet werden, um TCP-Pakete vor den Paketfiltern in Routern und Hosts zu verschleiern. Dieser RFC beschreibt zwei Angriffsmethoden und Abhilfen dagegen.

RFC 3128 aktualisiert und ergänzt diesen RFC.

RFC 1883 (obsolet durch RFC 2460)

Internet Protocol, Version 6 (IPv6) Specification

Dieser ehemalige Proposed Standard von 1995 ist nur noch von historischem Interesse.

RFC 2460 beschreibt den aktuellen Draft Standard für IPv6.

RFC 1885 (obsolet durch RFC 2463 und 4443)

Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

Dieser ehemalige Proposed Standard von 1995 ist nur noch von historischem Interesse.

RFC 4443 beschreibt den aktuellen Draft Standard für ICMPv6.

RFC 1918

Address Allocation for Private Internets

Dieser RFC beschreibt die Verwendung der Adressbereiche 10/8, 172.16/12 und 192.168/16 für private, nicht direkt mit dem Internet verbundene IPv4-Netzwerke.

RFC 2003

IP Encapsulation within IP

Dieses Dokument von 1996 beschreibt die Kapselung von IPv4-Datagrammen in IPv4-Datagrammen. Damit können generische Tunnel zwischen zwei Netzen aufgebaut werden.

RFC 2131

Dynamic Host Configuration Protocol

DHCP stellt eine Grundstruktur bereit um Konfigurationsinformationen für Hosts in einem IP-Netzwerk zu verbreiten.

RFC 2181

Clarifications to the DNS Specification

Aus dem Blickwinkel der Paketfilter-Firewall ist an diesem RFC der Punkt 4 “Server Reply Source Address Selection” interessant.

RFC 2236

Internet Group Management Protocol, Version 2

Dieser RFC interessiert nur, falls noch IGMP in Version 2 im Netz verwendet wird. Aus dem Blickwinkel der Paketfilter-Firewall sind an diesem RFC die Punkte 9. “Message destinations” und 10. “Security Considerations” interessant.

RFC 3376 beschreibt die Version 3 dieses Protokolls.

RFC 2460

Internet Protocol, Version 6 (IPv6) Specification

Dieser Draft Standard von 1998 beschreibt IPv6.

Die RFCs 5095, 5722, 6437, 7045 und 7112 aktualisieren und ergänzen diesen RFC.

RFC 2463 (obsolet durch RFC 4443)

Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

Dieser ehemalige Draft Standard von 1998 ist nur noch von historischem Interesse.

RFC 4443 beschreibt den aktuellen Draft Standard für ICMPv6.

RFC 2464

Transmission of IPv6 Packets over Ethernet Networks

Dieser Proposed Standard beschreibt den Transport von IPv6 über Ethernet, so wie RFC 894 für IPv4. Neben dem Frame-Format geht er unter anderem auf Stateless Autoconfiguration, link-lokale Adressen und Address Mapping für Multicast ein.

RFC 2474

Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

Das Differentiated Services Field ist für Paketfilter wichtig, wenn diese zur Unterstützung von QoS herangezogen werden.

Die RFCs 3168 und 3260 aktualisieren und ergänzen diesen RFC.

RFC 2663

IP Network Address Translator (NAT) Terminology and Considerations

Das Motiv für diesen RFC ist, Klarheit in einige Begriffe zu bringen, die in Verbindung mit Netzwerk-Adressübersetzern verwendet werden.

RFC 2784

Generic Routing Encapsulation (GRE)

Das ist ein Versuch, einen einfachen, allgemeinen Mechanismus für die Kapselung eines Protokolls in einem anderen bereitzustellen.

RFC 2894

Router Renumbering for IPv6

Dieses Dokument definiert Mechanismen um eine Reihe von Routern über Netzumnummerierungen zu informieren. Das will ich definitiv nur von vertrauenswürdigen Knoten aus übertragen.

RFC 3027

Protocol Complications with the IP Network Address Translator

Dieser informatorische RFC von 2001 zeigt einige Probleme mit NAT auf identifiziert Protokolle, die durch NAT gestört werden.

RFC 3128

Protection Against a Variant of the Tiny Fragment Attack

Paketfilter, die konform zu RFC 1858 eingestellt sind, können für eine Variante eines der dort beschriebenen Angriffes anfällig sein. Dieses RFC beschreibt diese Angriffsvariante und empfiehlt Maßnahmen zur Abhilfe.

RFC 3168

The Addition of Explicit Congestion Notification (ECN) to IP

ECN ist ein Verfahren, dass die traditionellen Verfahren zur Bestimmung der aktuell verfügbaren Bandbreite bei TCP auf dem Weg vom Sender zum Empfänger unterstützen soll.

Dieses RFC liefert die nötigen Informationen, um einen Paketfilter so aufzusetzen, dass er ECN nicht behindert.

Die RFCs 4301 und 6040 aktualisieren und ergänzen diesen RFC.

RFC 3260

New Terminology and Clarifications for Diffserv

Die Diffserv Working Group beschäftigt sich mit Differentiated Services. Dieses RFC klärt einige Begriffe und hilft beim Verständnis der anderen RFCs.

RFC 3376

Internet Group Management Protocol, Version 3

Aus dem Blickwinkel eines Paketfilters sind die Abschnitte 4. “Message Formats” und 6. “Description of the Protocol for Multicast Routers” interessant. Neben diesen sind noch die Abschnitte 9 und 10 aus RFC 2236 (IGMP v2) empfehlenswert.

RFC 4213

Basic Transition Mechanisms for IPv6 Hosts and Routers

Dieses Dokument beschreibt zwei Kompatibilitätsmechanismen für IPv6-Hosts oder -Router. Der eine Mechanismus ist Dual Stack, der andere die Kapselung von IPv6-Datagrammen in IPv4-Datagrammen ähnlich der in RFC 2003 für das Tunneln von IPv4 in IPv4 beschriebenen.

RFC 4301

Security Architecture for the Internet Protocol

Dieser RFC spezifiziert die grundlegende Architektur von IPsec-konformen Systemen. Wenn IPsec eingesetzt wird, bietet dieser RFC einen guten Einstieg.

RFC 6040 aktualisiert und ergänzt diesen RFC.

RFC 4379

Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures

Dieser RFC ist eher interessant, wenn man MPLS einsetzt und die Paketfilter darauf abstimmen will.

RFC 4380

Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)

Teredo ist ein älterer Mechanismus für das Tunneln von IPv6 Datenverkehr über IPv4-Netze. Es ist für den Firewall-Administrator aus zwei Gründen interessant: einerseits ist es ein Tunnel-Protokoll, das Daten von IPv6 in IPv4-Datagrammen kapselt und andererseits ist es zumindest in einigen Fällen in der Lage direkte Verbindungen über NAT-Geräte herzustellen.

RFC 4443

Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

Dieser Draft Standard von 2006 beschreibt die aktuelle Version von ICMPv6. Da ICMPv6 mehr Aufgaben wahrnimmt, als ICMP bei IPv4 ist es für den Betrieb eines Paketfilters für IPv6 unverzichtbar, sich damit vertraut zu machen.

RFC 4884 aktualisiert und ergänzt diesen RFC.

RFC 4884

Extended ICMP to Support Multi-Part Messages

Einige ICMP-Nachrichten, die sich auf andere Datenpakete beziehen, wie zum Beispiel “Destination Unreachable”, zitieren am Ende die ersten Bytes des Datenpaketes, auf die sich die ICMP-Nachricht bezieht. Es gibt kein Feld, das die Länge dieses zitierten Datenpakets angibt, so dass man die ICMP-Nachricht nicht durch Anfügen weiterer Felder erweitern kann.

Dieser Proposed Standard beschreibt ein Verfahren, mit dem man auch diese ICMP-Nachrichten erweitern kann.

RFC 4890

Recommendations for Filtering ICMPv6 Messages in Firewalls

Dieser RFC trägt hilfreiche Hinweise zum Filtern von ICMPv6-Nachrichten zusammen. Die Nachrichten werden klassifiziert, Überlegungen zur Sicherheit werden dargelegt und schließlich konkrete Empfehlungen ausgesprochen.

RFC 5095

Deprecation of Type 0 Routing Headers in IPv6

IPv6 wird mit Extension Headers erweitert. Einer dieser Extension Headers heißt “Routing Header”. Ein bestimmter Typ des Routing Headers (Type 0) kann zu DoS-Angriffen verwendet werden.

Dieser Proposed Standard beschreibt das Problem ausführlich und erläutert, wie man damit am besten - insbesondere bei einem Paketfilter - umgeht.

RFC 5128

State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)

Dieser informatorische RFC von 2008 dokumentiert verschiedene Methoden um direkte Kommunikation über NAT-Geräte zu ermöglichen.

RFC 5227

IPv4 Address Conflict Detection

Dieser Proposed Standard beschreibt, wie bei IPv4 Adresskonflikte entdeckt werden können. Das Verfahren macht extensiven Gebrauch von ARP.

Für Paketfilter, die als Router arbeiten, ist das eher nicht von Belang. Bei Paketfiltern, die als Bridge arbeiten, ist es wichtig, den Mechanismus zu verstehen, um die doppelte Vergabe von IP-Adressen zu entdecken. Beziehungsweise, falls auf beiden Seiten der Bridge eine IP-Adresse von unterschiedlichen Hosts bedient werden soll, kann man aus diesem RFC ableiten, wie das ermöglicht werden kann.

RFC 5389

Session Traversal Utilities for NAT (STUN)

STUN ist ein Protokoll, das anderen Protokollen als Werkzeug dienen kann, um NAT zu traversieren. Das ist eine Weiterentwicklung des originalen STUN RFCs (3489), der einige Probleme aufwies.

RFC 5722

Handling of Overlapping IPv6 Fragments

Die Empfehlungen aus RFC 1858 zu fragmentierten Datenpaketen bei IPv4 können leider nicht exakt für IPv6 übernommen werden. Dieser Proposed Standard erläutert das Problem und verbietet überlappende Fragmente bei IPv6.

RFC 5966

DNS Transport over TCP - Implementation Requirements

Abschnitt 7. “Security Considerations” ist relevant für Paketfilter.

RFC 6040

Tunnelling of Explicit Congestion Notification

Dieser Proposed Standard erläutert die Nutzung von ECN über Tunnel-Verbindungen.

RFC 6093

On the Implementation of the TCP Urgent Mechanism

Mit dem TCP Urgent Mechanism ist es möglich, in einer bestehenden Datenverbindung Out-of-Band-Daten zu senden. Die Protokolle Telnet und FTP zum Beispiel machen davon Gebrauch. In einem Artikel des Magazins Phrack (Ausgabe 57, Datei 3) ist beschrieben, wie man diesen Mechanismus nutzen kann um Network Intrusion Detection Systems (NIDS) zu verwirren.

Dieser Proposed Standard erläutert das Problem und die Auswirkungen von Lösungsansätzen.

RFC 6437

IPv6 Flow Label Specification

Vom Standpunkt eines Paketfilters ist insbesondere Abschnitt 6. “Security Considerations” interessant. Zum Beispiel kann das Flow Label als verdeckter Datenkanal verwendet werden.

RFC 6633

Deprecation of ICMP Source Quench Messages

ICMP Source Quench Messages gehören zu den ICMP-Nachrichten, die bedenkenlos an einem Paketfilter verworfen werden können, wenn sie überhaupt noch auftauchen. Dieser Proposed Standard lehnt sie formell ab.

RFC 6864

Updated Specification of the IPv4 ID Field

Das IPv4-ID-Feld ermöglicht das Fragmentieren und Zusammensetzen von Datenpaketen.

Dieser Proposed Standard erläutert Probleme mit der traditionellen Definition und Verwendung dieses Feldes in modernen Netzen und schlägt eine geänderte Nutzung vor. Insbesondere Abschnitt 5.3 “Impact on Middleboxes” ist für Paketfilter mit NAT von Belang.

RFC 6918

Formally Deprecating Some ICMPv4 Message Types

Dieser Proposed Standard missbilligt einige ICMPv4 Nachrichten formell. Für den Paketfilter heißt das, dass diese Nachrichten verworfen werden können.

RFC 7045

Transmission and Processing of IPv6 Extension Headers

Dieser Proposed Standard diskutiert das Verhalten von Hosts und Middleboxes (zum Beispiel Paketfilter) gegenüber Standard Extension Headers und gegenüber experimentellen oder kürzlich standardisierten Extension Headers.

RFC 7112

Implications of Oversized IPv6 Header Chains

IPv6 erlaubt Headerketten von beliebiger Größe.

Dieser Proposed Standard diskutiert die Interoperabilität und Sicherheitsprobleme bei Datenpaketen mit übermäßig langen Headerketten.

Kolophon

Dieses Buch ist im Markdown-Format mit Erweiterungen von Leanpub geschrieben. Daraus wurden die PDF-, EPUB- und MOBI-Versionen erzeugt.

Die Diagramme für die Datenpakete im Kapitel über IPv4 habe ich mit ditaa erstellt.

Die Graphen im Kapitel zum Modell der Firewall-Regeln habe ich ursprünglich mit iptables2dot aus Backups der Firewall-Regeln mit iptables-save erzeugt, dann mit dem Editor etwas nachbearbeitet und schließlich mit dem Programm dot von GraphViz in eine PNG-Datei für das Buch umgewandelt.

Das Titelbild ist von einer Zeichnung gescannt, mit Inkscape vektorisiert und in passender Auflösung als Rastergraphik exportiert. Die gesamte Titelseite ist mit GIMP erstellt.

Index

Up next

Analyse von Iptables-Firewalls