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