Technische Universität Darmstadt

Transkript

1 Fachbereich Elektrotechnik und Informationstechnik Institut für Datentechnik Fachgebiet Industrielle Prozeß- und Systemkommunikation Prof. Dr.-Ing. Ralf Steinmetz Technische Universität Darmstadt Studienarbeit Konzeption und Entwicklung eines RTSP Firewall Moduls von Patrick Lehti April 2001 Betreuer: Dipl.-Ing. Utz Rödig Nr. KOM-S-0104

2

3 Ehrenwörtliche Erklärung Ehrenwörtliche Erklärung Hiermit versichere ich, die vorliegende Studienarbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen Darmstadt, den 1. Mai 1997 Patrick Lehti - iii -

4

5 Inhaltsverzeichnis Inhaltsverzeichnis Ehrenwörtliche Erklärung... iii Inhaltsverzeichnis...v Abbildungsverzeichnis... vii Tabellenverzeichnis... ix Akronyme... xi 1 Einleitung Grundlagen Firewall Grundlagen Allgemeines IP-Filter Proxies RTSP Grundlagen Allgemeines Aufbau einer RTSP Nachricht Eine typische RTSP Session Anforderungen an eine RTSP Firewall Allgemein Relevante RTSP Nachrichten Die SETUP Anfrage Die SETUP Antwort Die TEARDOWN Anfrage Die TEARDOWN Antwort Eingebettete Daten( interleaved data ) Multicast Sicherheitsanforderungen RTSP Methoden RTSP Header Sonstige Features v -

6 Inhaltsverzeichnis Authentifikation Weitere Anforderungen Proxy Caching Implementierung Allgemeines Die DDFA Firewall Das RTSP Firewallmodul Der Parser Die Security Checker Offene Punkte Andere RTSP Firewall Module RealNetworks RTSP Proxy-Kit Apple s RTSP/RTP Proxy Tool Cisco Secure IS H.323 V2 and RTSP Protocol Inspection IBM s RTSP Toolkit Vergleich der Systeme Zusammenfassung und Ausblick Anhang A - Konfigurationsdatei Literaturverzeichnis vi -

7 Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1 Position der Firewall Abbildung 2 vereinfachtes ISO/OSI Ebenenmodell Abbildung 3 IP-Filter Abbildung 4 Proxy Abbildung 5 Einfache Firewall-Architektur Abbildung 6 Verteilte Firewall-Architektur Abbildung 7 Klassen-Diagramm DDFA Abbildung 8 Sequenz-Diagramm DDFA Abbildung 9 Klassen-Diagramm RTSP-Modul Abbildung 10 Aktivitäts-Diagramm RTSP-Modul Abbildung 11 Klassen-Diagramm Parser Abbildung 12 Sequenz-Diagramm Parsing Abbildung 13 Klassen-Diagramm Security-Checker Abbildung 14 Sequenz-Diagramm SecurityCheck vii -

8 - viii -

9 Tabellenverzeichnis Tabellenverzeichnis Tabelle 1 Vergleich von RTSP Firewalls ix -

10 - x -

11 Akronyme Akronyme AVP DDFA DoS HTTP IETF IGMP IP NAT RDT RFC RTCP RTP RTSP SDP TCP UDP UMTP Audio/Video Profile Distributed Dynamic Firewall Architecture Denial of Service Hypertext Transport Protocol Internet Engineering Task Force Internet Group Management Protocol Internet Protocol Network Address Translation Real Data Transport Request for Comment Real Time Transport Control Protocol Real Time Transport Protocol Real Time Streaming Protocol Session Description Protocol Transmission Control Protocol User Data Protocol UDP Multicast Tunneling Protocol - xi -

12 Akronyme - xii -

13 Einleitung 1 Einleitung Wie allgemein bekannt, hat sich das Internet in den letzten Jahren sehr stark weiterentwickelt. So ist die Zahl der Nutzer und der Netzknoten erheblich gewachsen und außerdem hat sich die Art der Daten geändert. So werden heute vermehrt Multimediadaten im Gegensatz zu reinen Textdaten übertragen. Beispiele hierfür sind Internet-Telefonie oder Audio- und Videostreaming. Ein weiteres sehr aktuelles Thema rund um das Internet ist Sicherheit, wie man an diversen Berichten in den Medien lesen kann. Um interne Netzwerke, wie z.b. Unternehmens- oder Institutsnetzwerke, vor Zugriffen aus dem Internet zu schützen, werden Firewallsysteme eingesetzt. Diese untersuchen den Datenfluß anhand bestimmter Regeln und filtern dabei verdächtige Datenpakete heraus. Das Übertragen von Multimediadaten stellt besondere Anforderungen an die Firewallsysteme. So werden im allgemeinen bei Protokollen für Multimediadaten(z.B. RTSP und H.323) dynamisch zusätzliche Kanäle für die Übertragung der Daten ausgehandelt. Dies muss die Firewall verstehen und die entsprechenden neuen Kanäle ebenfalls durchlassen. Außerdem stellen diese Daten hohe Anforderungen an Bandbreite und Verzögerung. Diese Anforderungen an ein Firewallsystem werden in dieser Studienarbeit für das Multimediaprotokoll RTSP (Real Time Streaming Protocol) untersucht und in einem Firewallmodul für eine vorhandene Firewall beispielhaft implementiert

14 Einleitung

15 Grundlagen 2 Grundlagen Für das Verständnis der Problematik einer RTSP-Firewall sind Grundlagen in Firewalltechniken, sowie Grundlagen für das Protokoll RTSP nötig. Diese Grundlagen werden in diesem Kapitel vermittelt. 2.1 Firewall Grundlagen Allgemeines Eine Firewall ist ein Rechner oder ein System von Rechnern, die ein internes Netzwerk, wie z.b. ein Unternehmens- oder Institutsnetzwerk, vor Zugriffen von außen, z.b. dem Internet, schützen soll. Dies ist nötig, da die einzelnen Rechner meist nicht selbst völlig sicher sind, aufgrund von fehlerhafter Software (einfache Programmierfehler oder konzeptionelle Fehler) oder falscher Konfiguration durch den Anwender. Abbildung 1:Position der Firewall Für einen Systemadministrator, der außer für Fragen der Sicherheit meist auch noch andere Aufgaben, wie Verwalten des Betriebs der Systeme und Benutzerberatung hat, ist es im allgemeinen unmöglich alle lokalen Systeme auf Sicherheitslücken zu überwachen. Deshalb wird eine Firewall zwischen das interne Netzwerk und das Internet gesetzt, welche der Systemadministrator dann mit Hilfe spezieller Regeln konfiguriert. Die Firewall sollte dabei so konfiguriert werden, dass sie alle denkbaren Angriffe abblockt, aber dabei die eigenen Benutzer nicht behindert. Dies ist oft nicht einfach, da man z.b. für eine sichere Firewall grundsätzlich unsichere Dienste, wie Telnet, sperren sollte, welche jedoch die Anwender eventuell nutzen wollen. Bei den möglichen Angriffen kann man zwischen verschiedenen Arten unterscheiden:[str97] Ausspionieren von vertraulichen Daten auf Systemen einer Organisation oder bei der Übertragung der Dateien über ein Netzwerk Manipulieren oder Löschen von Daten Verhindern von normalen Funktionen eines Systems ( Denial of Service )

16 Grundlagen Um festzustellen, ob überhaupt versucht wird, die Organisation aus dem Internet anzugreifen und wenn ja mit welchen Mitteln, schreiben Firewalls meist auch ein Protokoll aller Vorgänge. In einem solchen Protokoll kann jedes einzelne übertragene Datenpaket protokolliert werden Anwendungsschicht Transportschicht Vermittlungsschicht Sicherungsschicht Bitübertragungsschicht Abbildung 2:vereinfachtes ISO/OSI Ebenenmodell Alle Daten im Internet werden mit sog. IP-Paketen versendet. IP ist ein Protokoll auf der Vermittlungsschicht nach dem Ebenenmodell von ISO/OSI. In einem IP-Paket steht die IP- Adresse des Senders, sowie des Empfängers. IP-Pakete werden mit Hilfe von TCP oder UDP versendet. Diese beiden Protokolle liegen auf der Transportschicht im Ebenenmodel und führen Ports für die Unterscheidung der einzelnen Verbindungen eines Rechners ein. Zusätzlich baut TCP Verbindungen zwischen den Rechnern auf, die für Sicherheit vor Datenverlust sorgen, aber deshalb auch etwas langsamer ist als das einfachere UDP. Die Protokolle auf Anwendungsebene benutzen dann TCP oder UDP, entsprechend ihrer Anforderungen bezüglich Sicherheit und Datendurchsatz. Bei Firewalls kann man grob zwischen IP-Filtern und Proxies unterscheiden. Bei höheren Sicherheits- oder Performanceanforderungen werden oft mehrstufige oder verteilte Firewalls eingesetzt, die meist aus verschiedenen IP-Filtern und Proxies bestehen, die sich gegenseitig kontrollieren IP-Filter IP-Filter arbeiten auf Vermittlungs- und Transportschicht und untersuchen die Pakete nach Typ des Pakets, wie TCP oder UDP, nach IP-Adressen des Senders und Empfängers, sowie nach den Portnummern des Senders und Empfängers. Dazu trägt der Systemadministrator im einfachsten Fall statische Regeln in der Konfiguration des IP-Filters ein, die nacheinander geprüft werden. Abbildung 3:IP-Filter

17 Grundlagen Einfache IP-Filter (stateless filter) haben einige Probleme, so können sie nicht auf dynamisch ausgehandelte Datenkanäle regieren und können die Daten nicht auf sicherheitsproblematische Inhalte untersuchen. Außerdem ist die Konfiguration recht aufwendig, da es Regeln für jede Verbindung in Hin- und Rückrichtung geben muss. Sollten die Rechner im internen Netz keine öffentlichen IP-Adressen verwenden, dann muss ein Filter außerdem zusammen mit NAT betrieben werden. Der Vorteil dieser Filter ist aber, dass sie sehr schnell sind. Die Probleme der einfachen IP-Filter können zum Großteil von dynamischen Filtern (stateful filter) behoben werden. Diese Filter merken sich den Zustand von Verbindungen und können so z.b. Antwortpakete ohne zusätzliche Regel durchlassen. Wenn man noch einen Schritt weiter geht, lässt man den Filter die Daten auch auf Anwendungsebene untersuchen, braucht dann aber für jedes Protokoll einen eigenen Parser. Diese Technik benutzt zum Beispiel auch der Marktführer von Firewalls bei seiner Firewall-1. Hierbei verschwimmen dann die Grenzen zwischen Filter und Proxy Proxies Proxies oder Application Gateways arbeiten auf Anwendungsebene. Sie nehmen Verbindungen über ein Netzwerkinterface auf und bauen ihrerseits über ein anderes Netzwerkinterface eine Verbindung zum Zielrechner auf. Danach nimmt er die Daten von der einen Verbindung auf, untersucht sie und leitet sie auf der anderen Verbindung weiter. Dadurch ist die Verbindung zwischen den beiden Rechner komplett getrennt. Abbildung 4:Proxy Da der Proxy auf Anwendungsebene arbeitet, kann er auch den Inhalt der Pakete analysieren und protokollieren. Dadurch ist er sehr sicher und kann auf dynamische Aushandlung von Datenkanälen reagieren. Der Nachteil von Proxies ist allerdings, dass für jede Anwendung bzw. Protokoll ein eigener Proxy entwickelt werden muss, was einen sehr hohen Aufwand bedeutet. Das Aufbauen der eigenen Verbindungen, sowie das Untersuchen des Inhaltes der Daten, kann außerdem zu Performanceproblemen führen. Bei einfachen Proxies müssen die Anwendungen angepasst werden, damit diese mit den Proxies zusammenarbeiten. Dies kennt man beispielsweise von den Proxy-Einstellungen bei einem Web-Browser. Es gibt jedoch auch sog. transparente Proxies, die selbst Adress- und

18 Grundlagen Portinformationen in den Paketen umschreiben, und deshalb ohne Anpassungen in den Anwendungen benutzt werden können. Weitere Details zum Thema Firewalls kann man in [CB94] und [Str97] nachlesen. 2.2 RTSP Grundlagen Allgemeines Das Real Time Streaming Protocol oder RTSP wurde im April 1998 als Proposed Standard (RFC 2326) vom IETF [SRL98] veröffentlicht. Es wurde maßgeblich von RealNetworks, Netscape Communications und der Columbia University entwickelt. Es ist ein Protokoll auf Anwendungsebene für die Steuerung der Übertragung von Daten mit Echtzeitanforderungen. Dies kann z.b. das Streamen von Multimediadaten, wie Audio oder Video über das Internet sein. Es ist sowohl für unicast als auch für multicast Anwendungen geeignet. Es wurde bewusst als erweiterbares Framework entwickelt, um flexibel gegenüber zukünftigen Anforderungen zu sein. Die RTSP Nachrichten sind textbasierte Nachrichten mit einem Header und einem optionalen Body und ähneln in ihrem Aufbau sehr stark HTTP. Dadurch kann es gut mit bestehenden Webinfrastrukturen zusammenarbeiten, z.b. erbt es die Authentifizierung von HTTP. Der RTSP Kontrollkanal ist im Normalfall ein vom Client initiierter TCP-Kanal auf Port 554. Dies ist jedoch nicht zwingend von RTSP vorgeschrieben, sondern könnte ebenfalls über UDP oder einzelne TCP-Verbindungen laufen. Das Übertragen der eigentlichen Multimediadaten geschieht im Normalfall über dynamisch ausgehandelte RTP-Kanäle. Doch auch dies ist nicht zwingend von RTSP vorgeschrieben, sondern kann prinzipiell beliebig erfolgen, z.b. mit RDT-Kanälen oder eingebettet im Kontrollkanal Aufbau einer RTSP Nachricht Eine RTSP Anfrage besteht aus dem Namen der RTSP Methode, wie z.b. DESCRIBE, SETUP, PLAY, RECORD, PAUSE oder TEARDOWN, der URI für die angeforderte Resource mit rtsp als Protokollname, der RTSP Version, sowie verschiedener Headerzeilen. In diesen Headerzeilen können beispielsweise Angaben über Datum, Transportparameter, Abspielparameter oder Bodyinformationen enthalten. Eine RTSP Antwort besteht aus der RTSP Version, einem Statuscode, einer textuellen Beschreibung des Statuscodes, sowie ebenfalls verschiedener Headerzeilen. In diesen Headerzeilen stehen beispielsweise Bestätigungen für die Anfrage. Eine Headerzeile die bei Anfrage und Anwort immer vorhanden ist, ist die Angabe der Sequenznummer - CSeq

19 Grundlagen Sollte eine RTSP Nachricht einen Body besitzen, dann enthält der Header eine Angabe über Länge und Typ des Bodys. Der Body ist durch eine Leerzeile vom Header getrennt und könnte z.b. Informationen in Form von SDP beinhalten Eine typische RTSP Session C->S: S->C: DESCRIBE rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 1 RTSP/ OK CSeq: 1 Content-Type: application/sdp Content-Length: 123 v=0 o= IN IP s=rtsp Session i=an Example of RTSP Session Usage t=0 0 m=video 0 RTP/AVP 26 Der Client fragt der Server nach einer Beschreibung für eine Videoresource. Der Server antwortet mit OK und schickt im Body eine 123 bytes lange SDP Beschreibung des Videos. Die Sequenznummer für diese Nachrichten ist die 1. C->S: SETUP rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 2 Transport: rtp/avp/udp;unicast;client_port= , x-real-rdt/udp;client_port=3058 S->C: 5003 RTSP/ OK CSeq: 2 Session: Transport: rtp/avp/udp;unicast;client_port= ;server_port=5002- Der Client initiiert eine neue Session und gibt dazu in der Transportzeile der Setup-Nachricht, die von ihm akzeptiert Transportparameter an. Dies ist erstens eine unicast RTP-Übertragung über die Ports 3058 und 3059 oder zweitens eine RDT-Übertragung auf Port Der Server antwortet mit OK und einer neuen eindeutigen Sessionnummer und gibt in der Transportzeile an, welche Tranportoptionen er für die Übertragung ausgewählt hat. C->S: S->C: PLAY rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 3 Session: Range: smpte=0:10:00- RTSP/ OK CSeq: 3 Session: Range: smpte=0:10:00-0:20:00 Der Client möchte den Video nun abspielen und zwar ab der Minute 10:00 des Videos. Der

20 Grundlagen Server antwortet mit OK und gibt an das der Video von Minute 10:00 bis 20:00 abgespielt wird. Dabei muss bei Anfrage und Antwort jeweils die im Setup bestimmte Sessionnummer mitgegeben werden. C->S: S->C: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 4 Session: RTSP/ OK CSeq: 4 Der Client beendet die Session und gibt dazu lediglich die Sessionnummer an. Der Server antwortet mit OK

21 Anforderungen an eine RTSP Firewall 3 Anforderungen an eine RTSP Firewall Nachdem im vorangegangenen Kapitel die notwendigen Grundlagen vermittelt wurden, befasst sich dieses Kapitel nun mit den konkreten Anforderungen an eine RTSP Firewall. Dazu werden als erstes allgemeine Anforderungen beschrieben, danach die betroffenen zu untersuchenden RTSP Nachrichten mit den entsprechenden Headerzeilen. Weiterhin werden mögliche Sicherheitseinstellungen und zusätzliche mögliche Features für eine solche Firewall vorgestellt. 3.1 Allgemein Parsen: Da bei RTSP die Datenkanäle dynamisch ausgehandelt werden, muss die Firewall die RTSP Kontrollnachrichten lesen und verstehen und bei Bedarf die entsprechenden Kanäle öffnen. Wenn eine RTSP Session geschlossen wird, sollten ebenfalls alle mit der Session verbundenen Kanäle wieder geschlossen werden. Dies verlangt nach einem dynamischen Filter mit eigenem RTSP Parser oder einem RTSP Proxy. Dabei muss man bedenken, dass Proxies die Client und Server Ports, Filter mit NAT normalerweise nur die Client Ports und reine Filter gar keine Ports in den RTSP Nachrichten umsetzen müssen. Lesen: Beim Lesen der Nachrichten muss die Firewall beachten, dass in einem TCP- Paket mehr als eine, genau eine oder nur Teile einer RTSP Nachricht enthalten sein können. Erkennen kann man das daran, dass eine RTSP Nachricht immer mit einer Leerzeile endet. Sollte die RTSP Nachricht eine Content-Length: -Headerzeile haben, dann müssen nach der Leerzeile noch die angegebene Anzahl Bytes des Bodys gelesen werden. Performance: Eine RTSP Firewall muss zumindest für die Datenkanäle sehr performant sein, da die Multimediadaten sehr hohe Anforderungen an Durchsatz und Verzögerung stellen. Dies spricht für einen Filter oder auch für eine performante verteilte Firewall. Sicherheit: Die Firewall soll den Server und dessen Daten vor unbefugtem Zugriff und anderen Angriffen schützen. Dazu muss jede Nachricht anhand verschiedener Regeln untersucht werden und nur Nachrichten weitergegeben werden, die definitiv für den Server keine Gefahr darstellen. Dadurch können auch Fehler im Protokoll-Stack des RTSP Server umgangen werden, in dem die Firewall die Nachricht bei Bedarf umschreibt. Bis jetzt wurde lediglich der Schutz des Servers erwähnt und vorausgesetzt, dass der Client der Angreifer ist. Es ist jedoch auch denkbar, dass der Angreifer sich die Kontrolle über den Server verschafft hat und das Ziel seines Angriffes das Netzwerk des Clients ist. Dies ist sicherlich die seltenere Variante, aber auch das sollte die RTSP Firewall verhindern. Flexibilität: Weiterhin sollte die Firewall sehr flexibel konfigurierbar und einfach erweiterbar sein, um sie für verschiedenste Anwendungsszenarien benutzen, an neue Anforderungen anpassen und gegen neue Sicherheitslücken schützen zu können. Die Konfigurierbarkeit könnte durch Konfigurationsdateien erfolgen, in denen man sämtliche Sicherheitseinstellung manipulieren kann. Für eine sehr gute Erweiterbarkeit bietet sich ein Framework an, dem man bei Bedarf eigene Sicherheitsprüfungen hinzufügen kann. Abdeckung: Prinzipiell sollte die Firewall alle Möglichkeiten, die RTSP bietet, auch unterstützen, um die Benutzer hinter der Firewall nicht unnötig zu behindern. Es ist aller

22 Anforderungen an eine RTSP Firewall dings vertretbar, wenn einige Features aus Sicherheitsgründen nicht von der Firewall unterstützt werden. Allgemeine Anforderungen an eine RTSP Firewall, sowie die dabei zu beachtenden RTSP Nachrichten kann man auch in [Rea98] und [SRL98] finden. 3.2 Relevante RTSP Nachrichten Die wichtigsten RTSP Nachrichten für eine RTSP Firewall sind die SETUP und die TEAR- DOWN Nachricht, sowie deren Antworten. In der SETUP Nachricht werden die erforderlichen Transportparameter ausgehandelt, anhand derer die Firewall Kanäle für die Daten öffnen muss. Mit der TEARDOWN Nachricht müssen die geöffneten Kanäle der Session wieder geschlossen werden Die SETUP Anfrage SETUP rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 2 Transport: rtp/avp/udp;unicast;client_port= ,x-real-rdt/ udp;client_port=3058 Die SETUP Anfrage enthält eine Transport-Headerzeile, in der durch Komma getrennt verschiedene vom Client akzeptierbare Transport Möglichkeiten angegeben sind. Die Transport Möglichkeiten sind nach Vorliebe des Clients sortiert. Jede Transport Möglichkeit besteht aus verschiedenen durch Semikolon getrennten Transport-Parametern. Die Firewall muss die Transport-Headerzeile in einer Tabelle mit der Sequenznummer als Schlüssel speichern, um sie später mit der Antwort vergleichen zu können. Sollte die Firewall nicht alle Transport Möglichkeiten unterstützen können, dann sollte sie die nicht unterstützten vor dem Weiterleiten aus der Transportzeile entfernen. Ist die Firewall ein Proxy oder ein Filter mit NAT, so müssen außerdem die Ports modifiziert werden. Die möglichen Ports sollten dann auch bis zur Antwort des Servers reserviert werden, um zu verhindern, dass diese dann bereits vergeben sind Die SETUP Antwort RTSP/ OK CSeq: 2 Session: Transport: rtp/avp/udp;unicast;client_port= ;server_port= Die SETUP Antwort enthält wiederum eine Transport-Headerzeile mit der tatsächlich vom Server gewählten Transport Möglichkeit. Sollte die Transportzeile fehlen und war in der SETUP Anfrage lediglich eine Transport Möglichkeit angegeben, so gelten diese Transport Parameter

23 Anforderungen an eine RTSP Firewall Die Firewall besorgt sich als erstes die Transport Parameter der zugehörigen Anfrage über mit Hilfe der angegebenen Sequenznummer aus der entsprechenden Tabelle. Jetzt müssen die Transport Parameter mit denen der Anfrage verglichen werden zum Schutz des Clients vor serverseitigen Angriffen. Stimmen die Parameter überein, dann analysiert die Firewall diese, um die ausgehandelten Ports zu öffnen. Dabei spielt vor allem das Transportprotokoll eine wichtige Rolle, denn z.b. für RTP muss auf dem geraden Port ein unidirektionaler Kanal vom Server zum Client(RTP) und ein bidirektionaler Kanal auf dem darauf folgenden ungeraden Port(RTCP) geöffnet werden. Für RDT hingegen ein unidirektionaler vom Server zum Client und ein weiterer vom Client zum Server. Sollte als Transportmodus record gewählt sein, so kehren sich die Richtungen um. Eine destination Angabe, die nicht der Adresse des Clients entspricht, sollte eine Firewall grundsätzlich aus Sicherheitsgründen verbieten(s. auch Kapitel 3.4). Für interleaved müssen keine Ports geöffnet werden, sondern die Firewall auf das Lesen der eingebetteten Daten vorbereitet werden(s. auch Kapitel 3.3). Sollte multicast gewünscht sein, müssen zusätzliche Besonderheiten beachtet werden(s. auch Kapitel 3.5). Abschließend muss sich die Firewall die neu geöffneten Kanäle in einer Tabelle mit der angegebenen Sessionnummer als Schlüssel merken. Dies ist nötig um sie beim TEARDOWN wieder schließen zu können Die TEARDOWN Anfrage TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 4 Session: Bei einer TEARDOWN Anfrage sucht sich die Firewall mit Hilfe der angegebenen Sessionnummer in der entsprechenden Tabelle die geöffneten Kanäle dieser Session und schließt diese wieder und gibt dabei die belegten Ports für andere Kanäle wieder frei. Wenn über einen längeren Zeitraum keine Daten mehr über die Kanäle einer Session übertragen worden sind, dann sollte die Firewall die Kanäle auch ohne eine entsprechende TEAR- DOWN Nachricht schließen. Denn ansonsten könnten durch einen fehlerhaften Client diese Kanäle geöffnet bleiben und damit potentielle Sicherheitslücken entstehen und Ressourcen gebunden werden

24 Anforderungen an eine RTSP Firewall Die TEARDOWN Antwort RTSP/ OK CSeq: 4 Die TEARDOWN Antwort sollte normalerweise von der Firewall ignoriert werden können. 3.3 Eingebettete Daten( interleaved data ) RTSP ermöglicht es ebenfalls die Daten eingebettet im Kontrollkanal zu übertragen. Dazu wird beim SETUP als Transportparameter interleaved angegeben, gefolgt von ein bis zwei channel Angaben. Beim Abspielen folgen dann die Daten beginnend mit einem $, dann der ein Byte langen Nummer des channel, gefolgt von 2 Bytes, die die Anzahl der Bytes der binären Daten angeben, und unmittelbar danach den Daten selbst. Wenn die Firewall die interleaved Übertragung im SETUP erkannt hat, muss sie danach beim Lesen der RTSP Nachrichten auf das $ Zeichen achten und die entsprechende Anzahl binärer Daten einlesen und ohne zu Parsen weiterleiten. 3.4 Multicast Eine Firewall die Multicast unterstützen soll, muss mehrere Dinge beachten. So muss es für den Firewalladministrator möglich sein Multicastgruppen, sowie deren Ports, auszuwählen, die potentiell weitergeleitet werden sollen. Weiterhin muss die Firewall entscheiden können, ob es nötig ist diese Multicastpackete weiterleiten, d.h. ob es auf der anderen Seite der Firewall Teilnehmer an dieser Multicastgruppe existieren. Dies kann z.b. durch Abhören der IGMP Nachrichten geschehen. Das tatsächliche Weiterleiten ist abhängig von der Firewall-Architektur. Für den typischen Fall, dass die Firewall aus zwei Knoten besteht, einem auf der Internet und einem auf der Intranet Seite, müssen die Multicastpackete zwischen diesen beiden Knoten über ein Tunnel-Protokoll(z.B. UMTP[Fin01]) weitergeleitet werden. Damit die Firewall überhaupt Multicastpackete weiterleiten kann, muss außerdem ein Multicast-Routing-Prozess(MRoute-Demon) installiert sein. D.h. die Firewall ist dann selbst ein Multicast-Router. Für den Fall der RTSP Firewall gestaltet sich die Sache etwas einfacher. So kann man die Einstellungen für einzelne Multicastgruppen und Ports als spezielle Sicherheitseinstellung betrachten und entsprechend wie diese behandeln(s. Kapitel 3.5). Ob ein Multicastpacket weitergeleitet werden soll, entscheidet die RTSP Firewall anhand der SETUP Nachricht. D.h. nur wenn zuvor in einer SETUP Nachricht eine Multicastsession initialisiert wurde, werden die entsprechenden Packete weitergeleitet

25 Anforderungen an eine RTSP Firewall Das eigentliche Weiterleiten der Packete ist weiterhin abhängig von der tatsächlichen Firewall- Architektur und muss bei der Implementierung beachtet werden. Zum Thema Multicast und Firewalls siehe auch [Fin99], [Dee89] und [JJ97]. 3.5 Sicherheitsanforderungen Eine RTSP Firewall sollte vor folgenden Angriffen schützen: Zugriff eines Unbefugten auf die Daten des Servers Manipulation der Daten Ablegen von eigenen Daten Stören der Funktion oder völliges Lahmlegen des Servers(DoS) Zugriff auf andere Teile des Netzwerkes durch manipulierte RTSP Nachrichten Missbrauch des Server für andere Zwecke, z.b. für einen DoS-Angriff auf einen anderen Rechner Um vor diesen Angriffen schützen zu können, müssen verschiedene Teile der RTSP Nachrichten untersucht werden. Mit diesem Hintergrund werden nun im folgenden sämtliche RTSP Features durchleutet. Siehe dazu auch [SRL98] und [FGM+97] RTSP Methoden In RTSP gibt es verschiedene sog. Methoden, wovon einige von RTSP Geräten unterstützt werden müssen, andere jedoch nur optional sind. Geforderte Methoden muss auch die Firewall weiterleiten, während die optionalen evtl. von der Firewall verboten werden könnten. Als erstes ist hierbei sicherlich die RECORD Methode zu nennen, die durch den Datenfluss vom Client zum Server ein prinzipielles Sicherheitsrisiko darstellt. Deshalb sollte die RTSP Firewall standardmäßig oder zumindest durch entsprechende Konfiguration diese Anfragen verbieten. Ähnlich verhält es sich mit der ANNOUNCE Methode, die eine Medienbeschreibung zum Server schickt oder beim Client aktualisiert. Jedoch sind hierbei die Daten in der RTSP Nachricht selbst enthalten und könnten so von der Firewall analysiert werden, statt die gesamte Nachricht zu verbieten. Über die DESCRIBE Methode erhält der Client Medienbeschreibungen vom Server, da diese Methode nicht optional ist, macht es keinen Sinn sie komplett zu verbieten. Allerdings ist es denkbar sie nur für bestimmte IP-Adressen(-Bereiche) oder Benutzer(-gruppen) zu erlauben. Mit der OPTIONS Methode erfragt der Client oder der Server vom jeweiligen Partner unterstützte Features ab. Sie ist in Client-Server-Richtung verpflichtet und in Server-Client-Richtung optional. Es macht daher wenig Sinn sie zu verbieten, vor allem auch weil es nur schwer

26 Anforderungen an eine RTSP Firewall denkbar ist, die gewonnenen Daten für Angriffe zu missbrauchen. Statt dessen wäre es möglich, dass die Firewall selbst diese Methode benutzt, um Informationen über den Server zu erhalten, um daraufhin nur noch unterstützte Optionen weiterzuleiten. Mit den Methoden GET_PARAMETER und SET_PARAMETER können Client und Server Parameter austauschen und ändern. Diese Parameter sind beliebig und implementierungsspezifisch, deshalb ist es auch denkbar, dass damit sicherheitskritische Optionen betroffen sind und so von der Firewall verboten werden sollte. Zumindest sollte die Firewall die Möglichkeit haben diese Methoden nur für bestimmte Benutzer zuzulassen. Die REDIRECT Methode informiert den Client, dass er sich für die geforderten Daten mit einem anderen Rechner verbinden muss. Da danach vom Client die alte Verbindung komplett abgebaut und eine neue Verbindung zum anderen Rechner aufgebaut wird, ist die REDIRECT Nachricht als sicherheitsunkritisch zu werten, und muss deshalb von der Firewall nicht weiter beachtet werden. Die Methoden SETUP, PLAY, PAUSE und TEARDOWN müssen von der Firewall weitergeleiten werden und können so nur anhand der Header untersucht werden RTSP Header Die Accept, Accept-Encoding und Accept-Language Header beziehen sich auf Medienbeschreibungen und können z.b. in DESCRIBE Nachrichten auftauchen. Wenn die Firewall die Medienbeschreibungen analysieren will, dann sollte sie sich diese Informationen anschauen und bei Bedarf nicht unterstützte Typen herausfiltern. Diese Accept Header können allerdings auch private Informationen über den Client enthalten, die nicht öffentlich gemacht werden sollen. Das Gegenstück zu den Accept Headern sind die Content-Type, Content-Encoding und Content-Language Header. Sie kommen entsprechend in DESCRIBE Anworten, ANNOUNCE Anfragen oder auch in GET_PARAMETER oder SET_PARAMETER Anfragen vor. Will die Firewall den Inhalt analysieren, so muss sie diese Angaben unterstützen. Der Content-Length Header gibt die Länge des Inhaltes in Bytes an. Eine falsche Angabe in diesem Feld zusammen mit einem fehlerhaften Protokollstack, könnte Probleme verursachen und sollte somit von der Firewall überprüft werden. Der Via Header beschreibt über welche Proxies diese Message weitergeleitet wurde. Die Firewall sollte diesen Header von der geschützten zur öffentlichen Seite nicht weiterleiten, da sonst Informationen über den internen Aufbau des Netzes bekannt werden. Der Server Header beschreibt den Typ des Servers, diese Angabe könnte durch bekannte Fehler in diesem Typ für Angriffe genutzt werden. Weiter private Angaben, die evtl. Rückschlüsse für Angriffe bieten, können im Referer und From Header stehen. Der für Firewalls interessanteste Header ist der Transport Header, da dieser die Einstellungen