Online Suche im Handbuch

LITTLE-IDIOT NETWORKING

18.13 Generelle Gefahren bei UDP - Protokollen

Viele der hier aufgezählten Protokolle basieren unter anderem auf UDP. Hierzu gehören Windows NT PDC, NFS, RPC allgemein, REALVIDEO, REALAUDIO, Videokonferencing wie Netmeeting, u.s.w. UDP hat generell, wie schon beschrieben, den Nachteil, daß es kein SYN/ACK Mechanismus besitzt, d.h. daß die Firewall nicht feststellen kann, ob die Verbindung von innerhalb heraus geöffnet worden ist, oder ob evtl. jemand von außen Pakete zusätzlich einschleust, z.B. mit gespooften Paketen. Für NFS findet man hier zahlreiche Beispiele auf http://www.rootshell.com, die aufzeigen, wie man bei NFS Verbindungen File-Handels erraten kann, um somit eigene Programme über die Firewall hinweg auf die Festplatte einzuschleusen. Dasselbe ist prinzipiell auch möglich bei allen anderen Protokollen, die UDP einsetzen. Bei DNS Servern ist dieses ebenfalls möglich, da kurze DNS Anfragen über UDP abgewickelt werden, längere jedoch über TCP, aus Gründen der Übertragungssicherheit. Es sollte also jedem klar sein, daß ein Angreifer von außerhalb die DNS Server eines Unternehmens auf diese Art und Weise mit gespooften Paketen bezüglich den DNS Informationen ausgelieferter Mail (MX-Einträge) manipulieren kann. Er kann ohne Probleme alle ausgehenden Mails eines Unternehmens auf seinen Server lenken. IBM hat sich daher für die generelle Abwicklung des DNS Verkehrs über TCP entschieden. In vielen Fällen können, je nach Implementierung von DNS auf der Firewall, von außerhalb Informationen über das interne Netzwerk eingeschleust werden. Dieser Trick funktioniert über "additional informations", also der Einschleusung weiterer Informationen, obwohl nicht danach gefragt wurde. Er funktioniert aber auch über die Manipulation von Clients mit trojanischen Pferden, z.B. über Makroprogramme unter WINWORD und EXCEL.

Generell müssen die PROXY´s, die solche TCP/UDP gemischten Protokolle absichern, genaue Kenntnisse über die Protokollmechanismen und die Art und Zulässigkeit der übertragenen Daten besitzen. Diese Proxy´s sind hoch komplex, überaus teuer und in vielen Fällen, z.B. bei REAL AUDIO / REAL VIDEO nach kurzer Zeit schon völlig veraltet. Noch etwas schlechter sieht das bei MS Netmeeting und PDC´s aus. Da Microsoft die genauen Protokolldetails in den RFC´s nicht offenlegt, kann also kein sicherer PROXY für diese Protokolle existieren. Wer also Microsoft Windows NT in großen Netzwerken einsetzt, und mit Microsofts Primary / Secondary Domain Controller (PDC) arbeitet, der hat ein großes Problem. Es bringt in diesem Falle nichts, einzelne Abteilungen mit Firewalls gegen Übergriffe eventueller Angreifer abzusichern. Es gibt momentan keine Firewalls, die eine korrekte Implementierung dieses Protokolls im Proxy besitzen. In diesem Fall (ich denke, daß hiervon auch alle Banken, Versicherungen und großen Industrieunternehmen betroffen sind) sollte man dringenst auf bewährte Software aus der UNIX Welt zurückgreifen, sprich NIS+, Kerberos....u.s.w. Microsoft hat zwar angekündigt, diese Protokolle mit NT 5.0 unterstützen zu wollen, nun ja...

Streaming Protokolle, wie REAL AUDIO/VIDEO haben ein großes Problem. Erstens öffnen Sie unnötig viele UDP Ports beim Aufbau einer Verbindung (alle >1024), andererseits sind in vielen Fällen bei Manipulation im Datenstrom möglich, die zu buffer overflows führen. Für die Firewall bedeutet dies, daß Sie UDP Traffic auf dem PORT 31375 ebenfalls zulassen muß, was bedeutet, daß ein Angreifer mit BO von der Firewall unbemerkt Arbeitsstationen im Intranet fernsteuern kann, sofern es ihm gelingt ein solches trojanisches Pferd einzuschleusen. Der Systemadministrator erfährt trotz aktiver Firewall nichts von einem Angriff. Damit ist der Sinn einer Firewall völlig in Frage gestellt. In der Praxis kann man bei vielen Clients jedoch den Bereich von Ports einschränken, was aber prinzipiell nichts ändert, da sich auch Programme wie BO anpassen lassen.

Online Suche im Handbuch

LITTLE-IDIOT NETWORKING