Um welche Protokolle geht es?

Welche Netzwerkprotokolle sind für mich interessant, wenn ich eine Paketfilter-Firewall betreiben will? Auf einer Seite gehen Datenpakete hinein, auf der anderen Seite sollen sie herauskommen oder auch nicht. Das kann doch nicht so viel sein, könnte man meinen. Erstaunlicherweise sind es recht viele Protokolle, von denen ich mehr wissen muss, als nur den Namen und wofür es verwendet wird.

Betrachten wir den Bereich IPv4, dann haben wir IPv4 selbst, ICMP und IGMP. Dazu kommen TCP und UDP auf denen die meisten Protokolle der höheren OSI-Schichten aufsetzen.

Mit ARP werden bei IPv4 die Ethernet-Adressen den IP-Adressen zugeordnet. Dieses Protokoll interessiert mich, wenn ich meinen Paketfilter als Ethernet-Bridge betreibe.

Im Bereich IPv6 muss ich das Protokoll IPv6 selbst und ICMPv6 kennen. Bei TCP und UDP muss ich nicht viel gegenüber IPv4 dazu lernen. Die Funktionen von ARP und IGMP übernimmt ICMPv6.

Das sind die wichtigsten Protokolle der OSI-Schichten 1-4, die ich beim Paketfilter beachten muss.

Die Protokolle der Schichten 5-7 setzen oft auf TCP oder UDP auf. Bei diesen muss ich oft nur wissen, welche Ports verwendet werden und welche Seite die Verbindung aufbaut.

Es gibt unter diesen Protokollen jedoch einige, wie zum Beispiel FTP, die mit mehr als einer Verbindung arbeiten. Andere, wie zum Beispiel TFTP, verwenden im Laufe einer Sitzung verschiedene Ports. Werde ich mit solchen Protokollen konfrontiert, muss ich deren Eigenheiten kennen.

Die meisten dieser Protokolle werden in RFCs beschrieben, welche ich im Internet von http://tools.ietf.org/ beziehen kann. Nachfolgend gehe ich kurz auf einige davon ein.

Ethernet

Die RFCs 894, 1042 und 2464 beschreiben, wie IPv4 und IPv6 Datenpakete in Ethernet- und 802.3-Frames eingebettet werden. Oft interessieren mich zum Filtern nur die MAC-Adressen. Arbeitet der Paketfilter jedoch als Ethernet-Bridge und nicht als Router, muss ich mich auch mit diesen Protokollen auseinandersetzen.

ARP, das Address Resolution Protocol finde ich in RFC 826 beschrieben. RFC 5227 aktualisiert es beim Thema Erkennung von Adresskonflikten. Das Protokoll spielt eine wesentliche Rolle bei Bonjour, der automatischen Netzwerk-Konfiguration von Apple-Rechnern sowie bei APIPA (Automatic Private IP Adressing) von Windows-Rechnern.

RFC 3927 beschreibt die automatische Konfiguration von link-lokalen IPv4-Adressen. Dabei wird ARP verwendet, um zu ermitteln, ob eine Adresse bereits belegt ist oder um eine IP-Adresse zu reklamieren. Auf diese Art konfigurierte IP-Adressen erkenne ich am Prefix 169.254/16. Datagramme mit dieser Absenderadresse dürfen nicht geroutet werden, da sie nur im lokalen Netzwerksegment gültig sind.

Bei IPv6 übernimmt Neighbor Discovery (ND) via ICMPv6 diese Funktion. Diese ist in RFC 4861 beschrieben. RFC 5942 aktualisiert ND in Bezug auf das IPv6-Subnetz-Modell, speziell für das Verhältnis zwischen Links und Subnetz-Präfixen. RFC 6980 geht auf die Auswirkungen von IPv6-Fragmentierung auf Neighbor Discovery ein.

IPv4

RFC 791 beschreibt das Internet Protokoll in Version 4. RFC 1349 ändert und erläutert einige Aspekte des Type of Service (TOS) Felds im IP-Header. RFC 2474 definiert das Differentiated Services (DS) Feld und RFC 6864 aktualisiert die Definition des ID-Feldes.

Da dieses Protokoll eines der wichtigsten für Firewall-Administratoren ist, gehe ich in einem eigenen Kapitel intensiver darauf ein.

IPv6

IPv6 wurde erstmals 1995 in RFC 1883 beschrieben. 1998 löste RFC 2460 diese inzwischen veraltete Beschreibung ab.

RFC 4303 “IP Encapsulation Security Payload (ESP)” beschreibt die IPv6 Header Extensions für IPsec.

Da dieses Protokoll immer wichtiger für Firewall-Administratoren wird, gehe ich in einem eigenen Kapitel intensiver darauf ein.

ICMP

Das Internet Control Message Protocol ist in RFC 792 beschrieben. RFC 4884 erweitert ICMP für Multipart-Nachrichten.

RFC 6633 und RFC 6918 begründen die Ablehnung von wenig genutzten ICMP-Nachrichten. Damit helfen mir diese beiden RFCs bei der Entscheidung für oder gegen diese Datagramme.

Auch auf dieses Protokoll gehe ich in einem eigenen Kapitel intensiver ein, da gerade hier sehr viele Nuancen stecken, bei denen durch unbedachte Sperrung oder Freigabe potentiell Schaden angerichtet werden kann.

ICMPv6

Das Internet Control Message Protocol for IPv6 wurde erstmals 1995 in RFC 1885 beschrieben. 1998 wurde dieses RFC durch RFC 2463 obsolet, welches dann im Jahr 2006 durch RFC 4443 abgelöst wurde. RFC 4884 aktualisiert und ergänzt diesen Draft Standard.

Für mich als Firewall-Administrator ist RFC 4890 “Recommendations for Filtering ICMPv6 Messages in Firewalls” interessant, welches begründete Empfehlungen für die Behandlung von ICMPv6 gibt.

Auch bei diesem Protokoll gehe ich auf wesentliche Punkte in einem eigenen Kapitel intensiver ein.

IGMP

RFC 1112 beschreibt Host Extensions for Multicasting und in seinem Anhang Version 1 von IGMP.

Version 2 des Internet Group Management Protocol ist in RFC 2236 beschrieben. Diese Version erlaubt es, dem Router die Beendigung der Gruppenmitgliedschaft mitzuteilen, was Vorteile bei Multicast-Gruppen mit hoher Bandbreite bringt.

RFC 3376 beschreibt Version 3. Diese ergänzt das Protokoll um Quellenfilterung, das heisst ein Mitglied einer Multicast-Gruppe kann dem Router mitteilen, dass es nur an Datagrammen von bestimmten Routern oder nicht an solchen interessiert ist.

Bei IPv6 übernimmt ICMPv6 die Steuerung der Multicast-Zugehörigkeit.

TCP

RFC 793 beschreibt das Transmission Control Protocol. RFC 1122 erläutert die Anforderungen für Internet-Hosts und geht dabei auch näher auf TCP, UDP, ICMP und IP ein. Explicit Congestion Notification (ECN) und deren Anwendung bei TCP ist in RFC 3168 beschrieben.

UDP

RFC 768 beschreibt das User Datagram Protocol bereits seit 1980. Das Protokoll ist so simpel, dass drei Seiten für die Beschreibung und weiterführende Referenzen ausreichen.

Für IPv6 ergab sich lediglich die Notwendigkeit, die UDP-Checksumme obligatorisch zu machen, da im IPv6-Header keine Checksumme enthalten ist. RFC 768 erlaubt noch das Senden von UDP-Datagrammen ohne Checksumme.

Tunnelprotokolle

Für die Übergangszeit, in der sowohl IPv4 als auch IPv6 nebeneinander existieren, gibt es verschiedene Protokolle, mit denen IPv6-Datagramme über IPv4-Netze übertragen werden können und umgekehrt. Diese muss ich kennen, wenn ich sie im Paketfilter regulieren will.

6to4 ist ein Protokoll, bei dem IPv6-Datagramme in einem Tunnel durch IPv4-Netze übertragen werden. Es ist in RFC 3056 beschrieben.

6rd (IPv6 Rapid Deployment on IPv4 Infrastructures) baut auf 6to4 auf und ist in RFC 5569 und RFC 5969 beschrieben.

ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) ist in RFC 5214 beschrieben.

Teredo tunnelt Pakete via UDP und funktioniert damit auch via NAT. RFC 4380 beschreibt dieses Protokoll.

GRE (Generic Routing Encapsulation) erlaubt es, beinahe beliebige Protokolle in beliebigen anderen Protokollen zu kapseln. In RFC 2748 finde ich Informationen dazu.

IP Encapsulation within IP erlaubt ebenfalls beinahe beliebige IP-Protokolle zu kapseln indem vor den inneren IP-Header ein äußerer gesetzt wird. RFC 2003 beschreibt das Verfahren für die Kapselung von IPv4 in IPv4. RFC 4213 beschreibt es für die Kapselung von IPv6 in IPv4. Auf BSD-Systemen ist diese Art der Kapselung als GIF-Interface (generic tunnel interface) bekannt.