Weiter Zurück [Inhalt] Online Suche im Handbuch LITTLE-IDIOT NETWORKING

9.11 Dienste mit UDP Protokollen

Ein Problem gibt es, wenn außergewöhnliche Protokolle die Firewall passieren müssen, z.B. FTP, RPC, oder REALVIDEO/AUDIO. Hier zu mehr später.

Die Firewall, so wie oben konfiguriert, ist momentan, mit allen aktivierten Firewallregeln, von außerhalb nicht angreifbar. Es existiert kein einziger offener Port, der angreifbar wäre. Ganz anders sieht dies von innen aus. Hier ist jeder Port der Firewall von einem Host aus dem Intranet aus erreichbar. Es bieten sich verschiedene Dienste an, wie z.B. Mail, POP3, WWW, DNS, SMB- Fileservices, NOVELL - Server, PROXY Cache, u.s.w.

Auch an dieser Stelle möchte ich noch einmal betonen, daß auf der Firewall selber absolut kein Dienst etwas zu suchen hat. Eine Firewall ist eine Firewall, jede weitere Software ist ein Risiko. Leider halten einige Systemadministratoren das Risiko eines Angriffes auf die Firewall über eine Arbeitsstation für gering. Dem kann ich im Prinzip zustimmen, wenn ich selber nicht das Angriffswerkzeug in meiner Schublade hätte....

Betracht man einmal die Installation eines DNS - Servers auf der Firewall. Das DNS Protokoll basiert auf TCP und auf UDP. UDP ist ein Protokoll, welches kein ACK Bit benötigt. Dieses ACK Bit ist für die Firewall aber ein Zeichen, daß die Pakete passieren dürfen, sofern vorher ein Paket mit SYN Bit aus dem Intranet in das Internet versandt worden ist. Die Firewall speichert intern dann in einer HASH Tabelle, deren HASH - Werte sich aus Port - und IP - Nummer errechnen. Auch hier ergeben sich bei billigen Firewalls neue Angriffsmöglichkeiten, siehe auch die Ausführungen bei der SINUS-Firewall. Genaugenommen ist das SYN Bit ein Zeichen für die Firewall, sich genau zu merken, von welchem Host aus eine Verbindung aus dem Intranet zu einem Host ins Internet aufgebaut werden soll, also für welchen Host aus dem Internet Antwortpakete zurück erwartet werden. Die Pakete, die aus dem Intranet zurück in das Intranet gesendet werden, ist durch das SYN Bit dann autorisiert. Die Firewall muß nur noch schauen, ob diese ein ACK Bit besitzen, ob die Port - Adresse korrekt ist, und die IP - Nummer stimmt. TCP Verbindungen benutzen nach dem 3-Wege Handshake, also dem Verbindungsaufbau, höhere Ports über 1024, auch unpriviligierte Ports genannt. Leider wurde diese Konvention, die aus Zeiten der BSD - Stacks noch stammt, von vielen Herstellern aufgeweicht. UDP hingegen hat einen wesentlich kleineren Overhead und ist somit viel schneller, insbesondere bei kleineren Datenmengen. Dafür besitzt es keinerlei Möglichkeit, verlorene Pakete zu erkennen, und diese wie bei TCP evtl. nochmals neu anzufordern. UDP Pakete benutzen die Ports, die für den Verbindungsaufbau verwendet wurden, auch weiterhin, außer die Programme selber haben diesen Mechanismus implementiert. Für die Erstellung von Prüfsummen ist ebenfalls das Programm selber verantwortlich. Da UDP Pakete ein SYN/ACK Mechanismus besitzen, kann eine Firewall bei diesen Paketen nicht feststellen, ob diese von einem Host im Intranet auch angefordert worden sind. Entweder die UDP Ports auf der Firewall sind frei geschaltet, oder die Antwortpakete aus dem Internet prallen an der Firewall ab. Für DNS muß als ein intelligenter Mechanismus gefunden werden, der TCP und UDP Pakete miteinander kombiniert, damit nicht alle UDP Ports auf der Firewall geöffnet werden müssen. IBM hat diese Problem dadurch gelöst, daß generell der DNS Server mit TCP arbeitet. Andere Hersteller haben komplexe Proxy´s eingeführt, die die Datenpakete zur Sicherheit filtern, das generelle Problem mit UDP bleibt aber bestehen. Noch einfacher ist es, in der Datei /etc/services die Zeile: 

domain          53/udp          nameserver

zu entfernen. Damit kann der DNS - Server das UDP Protokoll nicht mehr verwenden. (Leider machen nicht alle DNS Server dieses Spiel mit)

Fassen wir einmal die Unterschiede zwischen TCP und UDP zusammen:

TCP Pakete

UDP Pakete

Die Nachteile bei der Sicherheit von UDP müssen teilweise von den Anwendungsprogrammen abgefangen werden. Hierzu gehören:

Welche Auswirkungen hat dies auf die Firewallregeln ? Zuerst muß festgestellt werden, wie die Firewall mit UDP Paketen umgeht. Hierzu kann man entweder einige Tests durchführen, oder - den Quellcode anschauen. Wir möchten z.B. wissen, ob auf der Firewall generell alle UDP Pakete aus dem Internet freigegeben werden müssen, oder ob die Firewall genau weiß, wann ein Paket gesendet wurde, und ob ein Datenstrom auf genau diesem Port zurück erwartet wird. UDP Pakete von anderen Hosts mit anderen Ports sollte sie ablehnen können. Im Gegensatz zu normalem Paketfiltering beherrscht natürlich LINUX das dynamische Paketfiltering. LINUX führt stets sowohl für TCP und UDP Tabellen, in denen vermerkt wird, ob ein Paket aus dem Internet angefordert wurde, welche IP - Nummern beteiligt sind, und welche Ports diese Benutzen. Ein Angreifer hätte dann wohl kaum Chancen, von außerhalb irgendeinen Server hinter der Firewall zu erreichen zu können.

Wie ist es denn mit Spoofing ? Gespoofte TCP Pakete werden erkannt und abgelehnt, wie ist das mit UDP Paketen ? Nun, der Test auf gespoofte Pakete wird auf der IP Ebene vorgenommen. Da TCP und UDP auf IP Ebene aufsetzen, existiert also auch hier Schutz vor spoofing.

Wo liegen also die angeblichen Gefahren von UDP ? Nun, um die Gefahren genau abschätzen zu können, muß man bei der Installation der Firewall genau wissen, ob ein Angreifer in den Datenstrom, der aus dem Internet über die Firewall zu einem Host strömt, evtl. eigene Pakete einschleusen kann. Das hängt dann davon ab, welche Auswirkungen auf das Client Programm dies hätte.

Wie kann er zusätzliche Pakete einschleusen ? Kennt der Angreifer Portnummern und IP Nummern der beteiligten Partner, so kann er Portnummer und IP Nummer spoofen, und diese Pakete an die Firewall senden. Diese würde die Pakete akzeptieren, und an den Host im Netzwerk weiterleiten.

Die Firewall verhindert doch spoofing ! Wie kann das sein ? Die Firewall kann nur innere von äußeren Adressen unterscheiden, d.h. wenn ein Paket mit der IP - Nummer aus dem Intranet direkt auf das äußere Gateway trifft, dann ist offensichtlich etwas falsch und des wird geblockt. Die Firewall kann aber nicht feststellen, ob Pakete aus dem Internet alle authentisch sind, also ein Paket auch tatsächlich von dem angegebenen Host stammt.

Wir halten fest: UDP ist nur dann unsichererer als TCP, wenn:

Wie könnte also ein Angreifer mit UDP Unheil stiften ?

Ein solcher Angriff ist komplexer, als man denkt, aber einfach zu zeigen. Wer mit einem älteren Netscape oder IE Browser animierte GIF Bilder betrachtet, der wird bemerken, daß hier GIF Bilder schnell hintereinander angezeigt werden. Problematisch wird dies erst dann, wenn das Format der Bilder plötzlich größer wird. Der intern vom Browser reservierte Speicherplatz für die Animation reicht dann plötzlich nicht mehr aus. Ist das Bild genügend groß, werden eventuell wichtige Bereiche im RAM der Arbeitsstation überschrieben. Ein sogenannter schwerer Ausnahmefehler (wo da die Ausnahme ist, weiß wahrscheinlich Microsoft selber nicht) tritt auf. In den meisten Fällen ist dieses Problem mit einem Absturz verbunden. Wird jedoch die Bytefolge im GIF Bild so gewählt, daß sich ein sinnvolles Programm dahinter verstecken kann, dann kann der Angreifer hierüber auf der Arbeitsstation beliebige Programme starten. Diesen Effekt nennt man buffer overflow und ist im Prinzip bei allen Protokollen, TCP sowie UDP möglich. Hier wurde der Effekt anhand einer GIF Animation aufgezeigt, dieser Effekt kann aber auch bei (REAL)VIDEO Sequenzen, DNS Paketen, NFS oder RPC Paketen o.ä. auftreten. Gelingt es einem Angreifer also, in einen UDP Datenstrom mit gespooften Paketen eigene Daten einzuschleusen, dann kann er viel Unheil anstiften. Aus diesem Grunde ist bei RPC, NFS, DNS - Datenpaketen immer große Vorsicht angebracht. Ohne spezialisierte PROXY´s sollte man diese Pakete von einer Firewall tunlichst nicht transportieren lassen.


Weiter Zurück [Inhalt] Online Suche im Handbuch LITTLE-IDIOT NETWORKING