Download - FESG - Technische Universität München

126 KAPITEL 4: DIE VERBESSERUNG DER DIENSTGÜTE
Weitere Möglichkeiten
Bisher keine sofort vefügbare,
zufriedenstellende Lösung greifbar
In der Literatur findet man dazu andere Möglichkeiten, welche dazu genutzt
werden können.
1. SOCKS-Proxies: Sockets Secure (SOCKS) ist ein Standard der Internet
Engineering Task Force (IETF) , welcher hauptsächlich
die clientseitige Firewallüberwindung auf Transportebene ermöglicht.
Ein Client kann dabei bestimmen, mit welchem Server hinter der Firewall er
verbunden werden will, so dass eine Art dynamischer TCP -Proxy entsteht.
Benötigt wird dazu nur, dass der Firewall einen SOCKS -Server stellt und
der Client statt der Standardbibliothek zur Kommunikation die modifizierte
SOCKS -Bibliothek mit korrespondierenden Befehlen nutzt (dies wird als
„Socksifikation“ bezeichnet) 33 . Über eine Konfigurationsdatei kann nun der
SOCKS -Server angegeben werden 34 . Eine mögliche Konfiguration sowohl
mit clientseitiger als auch mit serverseitiger Firewall unter zusätzlicher Nutzung
von SSL ist in Abb. 4.11 auf Seite 125 dargestellt 35 .
Nachteil: Auch hier muss in die Middleware eingegriffen werden. Der IOR
verliert an Bedeutung und damit auch seine Dynamik. Callbacks o.ä. werden
nicht unterstützt.
2. Tunnel z.B. über HTTP : Bei dieser Methode werden die Pakete des IIOP -
Datentransfers in HTTP eingebettet. Da herkömmliche clientseitige Firewalls
HTTP -Proxies nutzen, um dieses Protokoll für das Browsen im Netz
offenzuhalten, kann so die Firewall quasi durchtunnelt werden 36 .
Nachteil: Standardkomponenten dazu nutzen nichts, weil wiederum die IOR
manipuliert werden müsste. Getestete, frei erhältliche Standardkomponenten
wie HTTHost 1.7.1 oder Gnu HTTP Tunnel 3.3 zeigen dieses Verhalten. So
ist wiederum ein Eingriff in die Middleware notwendig.
3. Ersatzprotokolle (SOAP ): Eine weitaus zukunftsorientiertere Methode ist
die Nutzung von anderen Protokollen. Interworking Spezifikationen z.B. zur
standardisierten Umsetzung von CORBA nach Web-Service Description
Language (WSDL) und damit nach SOAP erlauben die Nutzung
des auf HTTP basierten Internetprotokolls für Web Services 37 . Somit wird
zur Kommunikation nicht mehr IIOP genutzt, sondern die für die neuen
Dienste entwickelten Protokollumgebungen.
Nachteil: IIOP als eigentliches Protokoll wird nicht mehr verwendet. Die
Hersteller der CORBA -Implementierung müssen die Erweiterungen einbringen.
Zusammengefasst bestätigten die durchgeführten Tests die Problematik, Firewalls
zu überwinden. Bisher konnte kein zufriedenstellender Weg gefunden werden,
der sofort zur Verfügung stehen würde. Erst im Rahmen zukünftiger Entwicklungen
bei den CORBA -Implementierungen kann auf eine Verbesserung dieses
Missstands gehofft werden. Allerdings bleibt dabei weiterhin offen, welches Risiko
es beinhaltet, entfernte Prozeduraufrufe offen zugänglich zu machen. Bisher
kann niemand abschätzen, wie anfällig ein CORBA -Server für direkte Attacken ist.
Schließlich wurden diese nicht von Sicherheitsexperten programmiert, was sich
immer wieder durch zufällige Feststellungen zeigt (z.B. durch Vorspielen eines
33 vgl. dazu [ABI02] a.a.O. S. 8 f.
34 vgl. dazu [SCHR299]
35 vgl. dazu auch [LANG02]
36 vgl. dazu [ABI02] a.a.O. S. 13
37 vgl. dazu [OMGSOAP04]