Weil herkömmliche Firewalls Web-Service-Schutz nicht leisten können, hat sich eine neue Gattung herausgebildet: Web-Service-Security-Gateways. Network Computing wollte wissen, wie es um deren Reifegrad bestellt ist, und testete sechs Gateways.

Eine einfache Firewall auf Netzwerkebene 2 und 3 konnte in vergangenen Zeiten die Überwachung des Netzwerkverkehrs am Unternehmenseingang übernehmen. Mittlerweile steht der Port 80 weit offen, und aller möglicher Verkehr läuft über diesen Port. Diese Tatsache schreit nach einer Inspektion des Verkehrs durch die Firewall auf der Ebene 7, also der Anwendungsebene. Dies ist allerdings keine neue Forderung. So genannte Web-Application-Firewalls, die Web-Server und CGI-Anwendungen (Common-Gateway-Interface) schützen, erledigen dies schon seit einiger Zeit. Nun taucht aber eine neue Form von Application-Firewalls auf: WS-Security-Gateways (Web-Service). Diese besitzen zum einen die Funktionen von Web-Application-Firewalls. Zum anderen dekodieren und verstehen sie XML-Nachrichten, an Web-Adressen über SOAP-Dienste (Simple-Object-Access-Protocol) geschickt. Dies scheint relativ einfach zu sein. Aber das einfache Lesen und Interpretieren (Parsing) der SOAP-Nachrichten öffnet die Tür zu einer Welt von Problemen.

Report-Card: Web-Service-Security-Gateways

Features: Web-Service-Security-Gateways

Ein allzu reales SOAP-Szenario soll dies verdeutlichen: In unserem Real-World Lab erzeugten wir eine Sammlung von SOAP-Web-Services auf der Basis von Java. Als Laufzeitumgebung für unsere Web-Services wählten wir das »TME Glue framework« von Mind Electrics. Weiter entwickelten wir eine einzelne Java-Klasse (Programmkomponente) mit drei verschiedenen Funktionen, die ein SOAP-Client aufrufen kann. Nach Übersetzung, Installation und Konfiguration hatten wir eine einzige HTTP-URL, die ein Client aufrufen musste, um eine der drei SOAP-Operationen zu nutzen. Und genau hier liegt das Problem: Wir wollten den Zugriff auf die einzelnen SOAP-Service-Funktionen begrenzen. Dies war aber mit einer herkömmlichen Firewall auf den Netzwerkebenen 2 und 3 nicht möglich, da alle Clients auf den Port 80 zugreifen müssen. Auf der anderen Seite konnten wir die Einschränkungen nicht auf dem Web-Server implementieren, da alle Web-Service-Funktionen über die gleiche URL zur Verfügung standen. Dies lässt sich mit einem CGI-Programm (Common-Gateway-Interface) vergleichen, das alle SOAP-Anfragen beantwortet. Das Problem liegt darin, dass die Authentifizierung erfolgen sollte, bevor das Programm die Anfrage erhält.

Welche Möglichkeiten stehen nun zur Verfügung, den Zugang für bestimmte SOAP-Clients zu begrenzen, wenn nur auf den Funktionsumfang im Standard-SOAP zurückgegriffen werden soll? Neben dem Nichtstun, das uns als keine Möglichkeit erschien, blieben uns folgende drei Optionen:

• Die SOAP-Service-Logik erhält auch Logik für die Zugriffskontrolle. Dies scheidet jedoch aus, wenn das Produkt eines Dritt-Herstellers zum Einsatz kommt, der den Source-Code nicht zur Verfügung stellt. Oder es fehlen einfach die Entwicklungsressourcen. Hinzu kommt, dass für die zusätzlichen Funktionen auf den Clients die Software aktualisiert werden muss.

• Jeder SOAP-Dienst erhält eine andere URL für den Aufruf. Im schlimmsten Fall führt dies dazu, dass jeder SOAP-Dienst auf einem anderen Server liegt. Dieses Vorgehen setzt wieder den Zugang zur SOAP-Dienste-Implementierung voraus. Der SOAP-Application-Server muss dazu die Auftrennung in unterschiedliche URL-Endpunke erlauben. Dies setzte auch entsprechendes Know-how voraus, um die verteilten SOAP-Dienste zu verwalten.

• Schließlich bleibt noch die Möglichkeit eines SOAP-Application-Servers, der Erweiterungen für SOAP-Verschlüsselung und -Authentifizierung besitzt. Aber auch dies kann noch Änderungen an den SOAP-Diensten erfordern.

Keiner dieser Schritte erscheint besonders attraktiv. Glücklicherweise übernehmen WS-Security-Gateways das Parsen (Lesen) und interpretieren der SOAP-Anfragen, wie es auch SOAP-Application-Server tun würden. Weiter verfügen die Gateways über die Tools, um SOAP-Anfragen zu verteilen (Routing), zu autorisieren oder einzuschränken – dies in Abhängigkeit von SOAP-Details, die der Web-Server oder die Firewall nicht kennt.

Mit dem Einsatz eines WS-Security-Gateways in dem oben beschriebenen Szenario konnten wir kontrollieren, welche Clients welchen SOAP-Dienst nutzen können. Die unzähligen Authentifizierungs-Schemata – typischerweise von den WS-Security-Gateways unterstützt – in den XML-Sicherheitserweiterungen halfen uns dabei. Dieses gelang uns noch dazu ohne eine einzige Änderung in der SOAP-Application-Logik.

WS-Security-Gateways beherrschen jedoch nicht nur die Authentifizierung. WS-Security, mittlerweile im Standardisierungsprozess der OASIS, behandelt außerdem Datenintegrität sowie Verschlüsselung. Beispielsweise erlaubt ein SOAP-Dienst B2B-Partnern (Business-to-Business), direkt Informationen in eine Datenbank zur Weiterverarbeitung einzutragen. Würde nun ein Fremder einen Man-in-the-Middle-Angriff durchführen, könnte dies haufenweise zu falschen oder korrumpierten Daten in der Datenbank führen. Ein Schutz zur Datenintegrität, etwa eine kryptografische Unterschrift (Signature), würde aufzeigen, dass die Daten manipuliert sind und der SOAP-Service daher den SOAP-Request nicht an die Datenbank zur Verarbeitung weitergibt. WS-Security-Gateways schützen auch Web- und Application-Server vor verschiedenen Formen bekannter Angriffe. Daher kann ein Unternehmen Microsofts Dot-Net-SOAP-Framework einsetzen, ohne viel darüber nachdenken zu müssen, dass es auf Microsofts notorisch unsicherem IIS-Web-Server läuft.

Dies alles hört sich in der Theorie gut an. Daher wollten wir wissen, ob es in der Realität auch so zutrifft. Wir luden DataPower Technlogy, Forum Systems, Reactivity, Sarvega, Verisign, Vordel, Westbridge Technology und Xtradyne Technology ein, ihre WS-Security-Gateways in unsere Real-Word Labs zu schicken. Sarvega nahm zuerst an, sagte dann nach einigem Hin und Her wegen mangelnder Ressourcen ab. Vordel nahm ebenfalls aus diesem Grund nicht teil. Alle anderen sandten uns ihre Produkte zu. Nach Abstimmung mit unserem Partner-Labor Neohapsis konnte der Test beginnen.

Kein Rundum-Schutz

Im Widerspruch zur Marketing-Lektüre der Hersteller gibt es kein ultimatives Sicherheitsprodukt, das all Risiken abdeckt – WS-Security-Gateways bilden hier keine Ausnahme. Beides muss ein Administrator wissen: Was ein WS-Security-Gateway kann und was es nicht kann. WS-Security-Gateways helfen dem Administrator zu kontrollieren, wer auf die SOAP-Dienste zugreift. Allerdings bleibt ein großer Teil der Verantwortung, Bedrohungen auf der Anwendungsebene abzuwehren, weiter bei den Anwendungen selbst.

Die gegenwärtigen WS-Security-Gateways verstehen die Daten nicht, die ein SOAP-Service empfängt. Sicherlich überprüfen sie die Datentypen – String, Integer oder Array – gegenüber einem Schema. Ein Schema beschreibt, welche Nachrichtenelemente in welcher Reihefolge in einer Anfrage auftauchen dürfen. Um legale oder illegale Zeichen zu erkennen, muss das Schema sehr detailliert sein. Enthält es diese Information nicht, kann der Administrator das Gateway nicht instruieren, bestimmte Zeichen auszuschließen, wie sie bei einem Angriff mit manipuliertem SQL vorkommen. Oder das Gateway stoppt die Verarbeitung, weil etwas in der Nachricht einer Format-String-Attacke ähnelt. Idealerweise sollten WS-Security-Gateways die Daten pro Element filtern, wie es ihre Web-Application-Verwandten tun. Einige der WS-Security-Gateway-Hersteller geben an, dass sie dieses Problem angingen. Beispielsweise sagt Reactivity, dass ihr Produkt Angriffe durch manipulierte SQL-Aufrufe stoppe. Wir fanden heraus, dass das Produkt einen Vergleich (Pattern-Matching) mit einer kleinen Auswahl von bekannten SQL-Kommandos ausführt. Weder war diese Auswahl jedoch umfassend genug, SQL-manipulierte Angriffe zu stoppen, noch das Pattern-Matching hinreichend robust. Denn es entdeckte die Verwendung von »xp_cmdshell«. »Xp_CmDsHell« ließ das Produkt jedoch durch. Trotzdem ist Reactivity mit seiner Entwicklung weiter als andere Hersteller, die zugaben, dass sie diese Art von Angriffen nicht stoppen.

Als ein weiterer Mangel fehlt eine Verbindung zwischen WS-Security-Gateways und Web-Application-Firewalls. Keines der Gateways, die wir testeten, machte auch nur einen Versuch, etwas anderes zu schützen als SOAP-Dienste oder XML-Dokumente, mittels HTTP verschickt. Damit haben diejenigen Pech, die planen, Web-Daten und SOAP-Dienste auf dem gleichen System zu konsolidieren. Einige wenige Web-Application-Firewalls wie »ScanDo« und »InterDo« von Kavado oder »MulitNet« von Process Software stellen einfache SOAP-Sicherheit bereit. Sie kamen aber nicht in diesen Test, da es ihnen an der vollen Unterstützung von WS-Security fehlt.

Auch die Leistung der Systeme war für uns ein Thema. Es fiel auf, dass Xtradyne als Software-Produkt mit den Appliances von Data Power und Forum Systems mithalten konnte. Diese setzen auf Hardware-Beschleunigung, um ausfallsichere Leistung zu erbringen. Hybride Application-Produkte, die nichts anderes sind als ein Betriebsystem, Hardware von einem Hersteller und andere Software-Zugaben, konnten bei der Leistung sogar bei einfachen Proxy-Diensten nicht mithalten. Viel gravierender war jedoch, dass diese Produkte uns nicht bei fehlgeschlagenen Transaktionen informierten. Stillschweigend eine Transaktion unter den Tisch fallen zu lassen, darf in einer Umgebung nicht passieren, die zum Umsatz beiträgt.

Eine Rolle spielt auch die Erfahrung, die ein Administrator benötigt, um diese Geräte einzurichten. Glücklicherweise bieten die meisten WS-Security-Gateways einen einfachen Einstieg, da sie die Basis-Regeln von einer WSDL-Datei (Web-Service-Description-Language) eines Web-Services, den sie schützen sollen, importieren können. Die WSDL-Datei beschreibt die Schnittstellen zu einem Web-Service, welche Funktionen mit welchen Parametern ein Web-Service-Dienst ausführt.

Neue Technologie bedeutet junge Produkte

Die sechs WS-Security-Gateways beauftragten wir mit der Sicherung der Web-Services in unserer Network-Computing-Infrastruktur und prüften dies genau auf der Netzwerkebene 4. Wir entdeckten eine Sammlung noch nicht ausgereifter Produkte für Standards, die sich noch in der Entwicklung befinden. Leichte Verwirrung fiel uns auch unter den Herstellern auf, die versuchten, sich als notwendige Ergänzung für das Data-Center zu positionieren.

Am meisten störte uns, dass die Hersteller mit der Interpretation des WS-Security-Standards sehr locker umgingen. Die WS-Security-Spezifikations-Liste muss unterstützt werden, wenn ein Produkt angibt, dass es die Spezifikation einhält: UsernameToken, BinarySecurityToken (X.509 oder Kerberos), SecurityTokenReference, XML-Signature und XML-Encryption. »Unterstützung von« und »Übereinstimmung mit« einem Standard haben eine sehr unterschiedliche Bedeutung. Sowohl Versign als auch Xtradyne fehlt es an der kompletten Unterstützung von WS-Security 1.0. Versign unterstützt nur X.509-Zertifikate. Was nicht unbedingt überrascht, da es zu ihrem Kerngeschäft gehört. Xtradyne dagegen arbeitet nur mit SAML (Security-Assertion-Markup-Language) und nichts anderem. Es fiel uns auch auf, dass der Anspruch der WS-Security-Standard-1.0-Unterstützung in Marketing-Unterlagen normalerweise bedeutete, dass ein begrenzter Ausschnitt aus dem Funktionsumfang implementiert wurde, der vielleicht irgendwie nahe an der Übereinstimmung mit dem Standard liegt. Um die Verwirrung weiter zu erhöhen, gibt es keine klare Definition oder eine Übereinstimmung, was diese Produkte in puncto Sicherheit unterstützen sollten. Es gibt nicht einmal eine einheitliche Sprachregelung, obwohl die meisten Konzepte aus anderen Bereichen stammen und angepasst wurden. Was bei einem Produkt »Client« heißt, nennt ein anderes »Consumer«; des einen »Operation« ist des anderen »Funktion«.

Nach sorgfältiger Überlegung stellen wir unsere kurze Liste der Funktionen vor, die wir bei einem WS-Security-Gateway erwarten: Untersuchung von XML (Content-Inspection), Übereinstimmung mit WS-Security-1.0, Zugangskontrolle sowohl für Dienste als auch die zugehörigen Operationen, Integration in bestehende Verzeichnisse wie LDAP oder Active-Directory, Unterstützung von WSDL, Zero-Failure-Performance – kein Verlust einer Transaktion auch bei hoher Auslastung –, Schema-Validierung und automatische SOAP-Envelope-Überprüfung sowie Logging und Erzeugung komprimierter Audit-Aufzeichnungen sowohl für Transaktionen als auch Regeln (Policies).

Nach intensiven Tests in unseren Real-World Labs vergaben wir unsere Auszeichnung »Referenz« der Network Computing an »Forum Sentry 1504 2.0« von Forum Systems. Das Produkt traf unsere Erwartungen mehr als seine Mitbewerber. Dazu kommt das Produkt als Bonus mit Konfigurations- und Verwaltungswerkzeugen, die wirklich kein Spezialwissen verlangen. Forum-Sentry ist weit davon entfernt, vollkommen zu sein. So verlangen fortgeschrittene Konfigurationen Konvertierung mit XSLT (Extended-Stylesheet-Language-Transformation). Außerdem besitzt Forum-Sentry nur begrenzte Möglichkeiten, Content zu inspizieren. Aber das Produkt besitzt eine gute Basis, um sich zu dem zu entwickeln, was wir uns von einem WS-Security-Gateway erwarten.

Forum Systems Forum-Sentry 1504 2.0

Die »Forum Sentry«-Linie wurde entworfen, um für Sicherheit bei XML-Dokumenten zu sorgen. Der Schritt, Web-Services zu unterstützen, lag daher nahe. Die Appliance hat eine Höhe von einer Unit und zwei 10/100-MBit/s-Netzwerkkarten wegen des Einsatzes als Proxy. Ein separater Management-Port sorgt für eine sichere Konfiguration.

Forum-Sentry bringt ein Cisco-IOS-ähnliches CLI (Command-Line-Interface) für die Konfiguration mit. Über eine Web-Konsole verwaltet der Administrator alle Aspekte, ausgenommen die Regel-Definition (Policies) und das Management. Dies übernimmt Forums »XML Workbench«. Die XML-Workbench besitzt einen einfachen Mechanismus, um »Task Lists« zu definieren, Forums Name für Regeln. Das Produkt zeugt von dem Know-how von Forum auf dem XML-Gebiet durch die hierarchische, auf Grafik basierende Methode, Dokumente zu identifizieren. Dabei kann das Produkt jedes XML-Element oder den Wert innerhalb eines Elements dazu auszuwählen. Wir wollten beispielsweise das Gerät so konfigurieren, dass es einen einzelnen Abschnitt (Node) innerhalb eines Antwort-Dokumentes verschlüsselt. Dazu mussten wir uns nur durch die Hierarchie der Elemente klicken, um zu dem gewünschten Abschnitt zu kommen; bei allen anderen Produkten mussten wir mit XPath (XML-Path-Language) arbeiten, um die gewünschten Elemente zu bezeichnen. XPath dient dazu, mit Hilfe der Strukturdefinition (Schema) des Dokumentes durch ein XML-Dokument zu navigieren.

Forum-Sentry arbeitet als reiner Proxy. Clients schicken Anfragen an das Gerät, das das Dokument an Hand seiner vorgegebenen Regeln identifiziert, die entsprechenden Task-Lists (Regeln) anwendet und das Ergebnis an das entsprechende Backend weiterleitet. Das Gerät gibt den Pfad im URI (Uniform-Resource-Identifier) an das Backend-System weiter – hier wünschen wir uns im Produkt eine Verbesserung. Forum-Sentry weiß nicht, welche Dinge den Service-Endpunkt verwirren können – eine Eigenschaft, die wir bei allen anderen getesteten Produkten sahen.

Das Forum-Sentry unterstützt kein WSDL, was sich als problematisch erwies. In der nachfolgenden Version 2.5 hat sich dies allerdings geändert. Anstatt eine WSDL-Datei zu importieren und entsprechenden Dienste sowie Operationen daraus zu entnehmen, mussten wir eine Abfrage an ein Backend-System aufnehmen (Capture), diese abspeichern und die Datei anschließend in Forum-Sentry importieren. Es wäre einfacher gewesen, das Original-Schema (DTD/Dokument-Typ-Definition oder XML) zu importieren. Ein Schema beschreibt den inhaltlichen Aufbau einer XML-Datei wie bei einer SOAP-Nachricht. Forum sagte, dass es einen etwas einfacheren Weg noch implementieren wolle.

Forum-Sentry bedient sich des »nCipher HSM« (Hardware-Security-Module), um kryptografische Operationen zu beschleunigen, und für die Schlüsselverwaltung. Forum-Sentry profitiert davon, wie unsere Performance-Tests zeigten. Denn Sentry stellte als einziges von dreien Zero-Failure-Tolerance während der Verschlüsselung sicher.

Anstatt eine Regel mit einem bestimmten TCP-Port zu verknüpfen, verwendet Sentry Prioritäten und Identification-Tasks, um zu entscheiden, welche Regel es auf die Anfrage oder Antwort anwendet. Dies bedeutet zwar mehr Arbeit beim Entwurf von Regeln. Es verhilft dem Produkt aber zu der herausragenden Fähigkeit, Signaturen und Verschlüsselung in Abhängigkeit von dynamischen Werten anzuwenden, Anwender-Identifikationen (User-Credentials) eingeschlossen. Jetzt stellte Sentry das XML-WS-Security-Gateway auf der Karte »PCI card - Sentry TYPE-PCI« zur Verfügung.

Data Power XS40 XML Security Gateway 2.3

Dicht hinter Forum-Sentry folgt das »XS40« von Data Power, das uns zugleich beeindruckte und enttäuschte. Wie Forum-Sentry ist das XS40 eine 1U-hohe Appliance mit zwei 10/100-MBit/s-Netzwerk-Interfaces, einem separaten Management-Port und einer seriellen Konsole. Der Administrator kann das XS40 über ihr IOS-ähnliches CLI oder auf Web basierende Konsole konfigurieren. Die Appliance arbeitet mit XSLT, was bei der engen Verwandtschaft mit dem XS35, einem Beschleuniger für XSLT-Verarbeitung, nicht verwundert. Das XS40 erfüllte unsere Wunschliste für die Konfiguration mit Leichtigkeit. Allerdings verlangt dies sehr gute Kenntnisse in XSLT, was die Konfiguration zu einer komplexen Aufgabe macht. Jedoch versicherte Data Power, dass es die Administrationskonsole überarbeite und eine größere Bandbreite an vordefinierten XSLT-Code-Stücken mitliefern wolle, um bestimmte Aufgaben wie Content-Inspektion zu erledigen.

Das XS40 verwendet XSLT für alle Kontrollaufgaben bei ein- oder ausgehenden SOAP-Nachrichten. Out-of-the-Box-Unterstützung für Authentifizierung und Integration mit bestehenden Directories wie LDAP gibt es nicht. Wir mussten daher XSLT-Code schreiben, um ein lokales Verzeichnis zu erzeugen und zu verwalten. Obwohl auch die getestete Version von Forum-Sentry keine Verzeichnisintegration mitlieferte, brachte es doch eine Anwender-Authentifizierung mit.

Als es darum ging, das XS40 zu konfigurieren, um ein einzelnes Element innerhalb eines Antwort-Dokumentes zu verschlüsseln, mussten wir unser Referenz-Handbücher für XPath hervorkramen. Jedes getestete Produkt – mit der Ausnahme von Forum-Sentry – erfordert Kenntnisse von XPath für einige Aufgaben bei der Konfiguration. Die Verschlüsselung eines einzelnen Elementes anstatt des ganzen Dokumentes gehörte dabei zu den typisch häufigen Aufgaben.

Die Konfiguration über die Web-Administrations-Konsole war einfach, was die anderen Aufgaben anbelangt. Eine Drag-und-Drop-Funktion hilft dabei, die Verarbeitungspipeline mit Filtern und Transformationen zu füllen sowie ein- und ausgehende Nachrichten zu manipulieren. Wir richteten unterschiedliche Ports und Regeln für jeden unserer Testfälle ein, was die Verwaltung von Mehrfach-Regeln sehr erleichterte. Uns gefiel diese Modularisierung von Regeln in allen Produkten, da es die Wiederverwertung von Regeln erleichtert.

Die größten Pluspunkte des XS40 sind seine Flexibilität und seine Performance. Upgrades sowie die Unterstützung von neuen Standards vereinfacht das Gerät dadurch, dass nur die XSLT-Sprache und nicht andere Teile der Software ein Upgrade erhalten. Obwohl keines der getesteten Produkte sich wie ein Rennwagen verhielt, verarbeiteten doch diejenigen von Data Power, Forum und Xtradyne konstant 250 Nachrichten pro Sekunde, unabhängig von den eingestellten Regeln und Konfigurationen. Unser Test von Web-Service-Plattformen im Herbst vergangenen Jahres (siehe »Seifenblasen-Diener« in der Network Computing 16-17/2003, S. 12ff) zeigt, dass dies bis auf die Implementierung von Sun ausreicht, um mit den Web-Service-Plattformen Schritt zu halten. Aber wir erwarten, dass die Skalierbarkeit der Geräte weiter zunimmt und gegenüber der Skalierbarkeit der Backend-Systeme, für die die Geräte als Proxy arbeiten, größer ist, damit sie nicht für diese zum Flaschenhals werden. Durch die nicht mehr getestete, neue Firmware 2.5 arbeitet XS40 jetzt auch mit Radius, XKMS oder »Sun Identity Server« oder Netegrity zusammen. Die Verkettung verschiedener Schritte wie Nachrichtenaufteilung, XML-Routing oder Anwendung digitaler Signaturen soll jetzt einfacher sein. Außerdem arbeitet XS40 mit dem Web-Service-Mangement von »Unicenter« oder »BIG-IP« von F5 Networks für Management von Anwendungsverkehr zusammen.

Reactivity XML Firewall 2300

Gemeinsam mit einem »Dell 1650« mit zwei 2,6-GHz-Xeon-Prozessoren und 2-GByte-RAM unter »Redhat Linux Advanced Server 2.1« liefert Reactiviy seine »XML Firewall 2300« aus. Reactivity hat ein gutes Gespür dafür, was notwendig ist, um ganz oben mit dabei zu sein. Dieses Produkt fällt mit einigen mehr exotisch wirkenden Eigenschaften auf, wie der Archivierung von Regeln und Rollback. Allerdings schaffte es die XMl-Firewall nicht, mit Zero-Failure-Level zu arbeiten. Dies verhinderte, dass es mit Forum-Sentry um die Spitze in unserem Test wetteiferte. Davon ausgehend, dass die XML-Firewall N-Cipher-HSM unterstützt und auch damit getestet wurde, waren wir sehr von der schlechten Performance überrascht. Die Gespräche mit Reactivity führtem zu dem Schluss, dass die Größe der Daten sowie die Anforderungen bei der Verschlüsselung kein Szenario waren, wofür die Lösung geplant war. Aber das Unternehmen konnte auch nicht erklären, warum das Ganze nicht optimal arbeitete.

Auf jedem anderen Gebiet glänzt die XML-Firewall. Auch wenn wir das Produkt bei der Out-of-Box-Content-Prüfung für SQL-Injection-Angriffe überlisten konnten: Es war das einzige, dass standardmäßig, wenn auch minimale, Unterstützung für diese Art der Content-Inspektion leistete. Die große Menge an Optionen für WS-Security ermöglichte es uns, statische Identitätsnachweise für den Backend-Zugriff zu definieren. Die XML-Firewall bringt auch einfache Web-Service-Management-Funktionen mit wie Antwortzeit-pro-Operation, Zugriffszähler oder durchschnittliche Dokumentengröße. Das Produkt beherrscht Schlüssel-Management, Global-Exception-Mapping oder komplettes SOAP-Request/-Response-Logging. Das Console-Audit-Log kann auf Wunsch die SQL-Statements mitprotokollieren, die Regeln und Konfiguration verändern. Eine lokale Postgres-Datenbank-Instanz speichert das Log.

Dienste und Definitionen kann der Administrator entweder von Hand eingeben oder mit Hilfe von WSDL importieren. Der XML-Firewall steht eine große Bandbreite an Sicherheitsfunktionen zur Verfügung, die sie sowohl auf ein- als auch ausgehende Nachrichten anwenden kann. Außerdem kann sie Nachrichten auf die Einhaltung der XSD-Definition (XML-Schema-Definition-Language) überprüfen (Validierung), die sie aus der WSDL-Definition erstellt hat. Aber das Produkt kann sich auch darauf beschränken, zu überprüfen, ob das Dokument die allgemeinen Regeln eines XML-Dokumentes einhält (well-formed). Außerdem kann der Administrator XSLT-Caching, Zugangskontrolle, Verschlüsselung oder digitale Signaturen für jede Operation des Web-Services individuell einstellen.

Die Konfiguration der Authentifizierung war ein Kinderspiel. Das Produkt unterstützt alle WS-Security-Optionen. Wir verwendeten dafür eine Anwendername/Passwort-Kombination, indem wir mit »htppassword« eine Passwortdatei erzeugten und über die Administrationskonsole auf das Gerät luden. Zertifikate kann der Administrator ebenfalls leicht verwalten und in den Authentifizierungsmechanismus einbinden.

In puncto WSDL-Sicherheit hat die XML-Firewall einen Pluspunkt, weil sie WSDL-Definitionen von verschiedenen Diensten aggregieren kann, auf die ein Client Zugriff hat. Dies behebt das Problem, gegenüber dem Client alle Services offenlegen und den Zugang zu diesen Daten auf authentifizierte Clients zu beschränken. Kein anderes Produkt brachte einen solchen Funktionsumfang mit, aber wir würden sie gerne in allen WS-Security-Gateways sehen.

Westbridge Technologies XML Message Server

Der »XML Message Server« (XMS) kommt als 1U-hohe Appliance mit zwei 1-GBit/s-Kupfer-Netzwerkinterfaces. In der Appliance arbeitet die »EnGarde Secure Linux«-Distribution, die für mehr Sicherheit auf Netzwerk- und Transportschicht sorgt als ein normales Linux. Der XMS hätte diesen Test gewonnen, wenn da nicht die schlechte Performance gewesen wäre. Obwohl das Produkt Hardware-Kryptografie-Beschleuniger unterstützt, wird es ohne einen solchen geliefert. Mit der »XA2700-Appliance« integrierte Westbridge jetzt den XMS mit einem Ncipher-Hardware-Beschleuniger. Nach dem Test in der Konfiguration als einfacher Proxy mit direkter Durchleitung waren wir nicht überzeugt, dass ein Beschleuniger die notwendige Leistung bringe, um auf die Performance-Ebene der Produkte von Data Power, Forum Systems und Xtradyne zu kommen. Allerdings hat Westbridge in der nachfolgende Version 3.0 unter dem Stichwort »SmartParser« einige Verbesserungen vorgenommen, so dass, laut Westbridge, einige XML-intensive Operationen zehnmal schneller ablaufen sollen.

Bei dem XMS beeindruckte uns die Reife, was die Konfigurations- und Managementaspekte anbelangt. In den Eigenschaften und Funktionen ähnelt es Reactivities XML-Firewall. Dabei stellt der XMS eine Fülle von Konfigurationsoptionen zur Verfügung, eingeschlossen viele Optionen, die sich typischerweise in Web-Service-Management-Produkten finden. Dies schließt QoS (Quality-of-Service), SLA-Unterstützung (Service-Level-Agreement) oder Zugangsbegrenzung in Abhängigkeit von der Zeit oder Anwender-Identität mit ein. Das Identitätsmanagement war auch ausgezeichnet. Zusätzlich zum einfachen Management wie bei den Mitbewerbern kann XMS sehr detailierte Regeln definieren, die auf LDAP-Attributen wie Abteilung oder Funktion basieren. Ähnlich wie beim XS40 kann der Administrator Regeln wieder nutzen. Diese können auch nach Operationen oder in Abhängigkeit von Corporate-Policies-Definitionen gruppiert werden.

Wie bei allen anderen Produkten, außer von Forum-Sentry, erfordert die Verschlüsselung einzelner Elemente XPath. Außerdem mussten wir Schemata im Gerät ablegen, um auf der Content-Ebene ein Dokument zu überprüfen (validieren). Obwohl dies auch beim XS40 der Fall war, gab es jedoch noch ein separates Werkzeug, das aus dem WSDL des Services eine Schema-Definition erstellt. Westbridge gab an, dass es an diesem Thema arbeite.

Xtradyne Web Services DBC 1.3

Bis auf die Performance und die automatische Überprüfung (Validierung) auf die Einhaltung von SOAP-Schemata konnte Xtradyne uns nicht beeindrucken. Der Domain-Boundary-Controller (DBC) war schwierig zu konfigurieren, und es war das einzige Produkt, das einen Fat-Client – trotz Java-Einsatzes – für alle Aspekte von Konfiguration und Administration verlangte. Es fehlte an Unterstützung für WS-Security und im Gesamten für XML-Encryption. Trotzdem überraschte das Produkt mit umfangreichen Möglichkeiten zur Konfiguration der Zugangskontrolle auf Operations-Ebene für die Web-Services.

Der DBC unterstützt LDAP-Directories

out-of-the-Box und bringt auch einen lokalen Identitätsspeicher mit. Auf der Basis des internen Speichers erzeugten wir verschiedene Anwender und Gruppen. Services, die der DBC »Ressourcen« nennt, importierten wir einfach durch die Angabe des Speicherortes der WSDL-Datei des Dienstes. Einmal importiert, kann der DBC den Service-Endpunkt verbergen, so dass alle Clients mit einer URL arbeiten, während der DBC mit den tatsächlichen Services kommuniziert. Diese Funktion ist typisch für Load-Balancer, die auf Ebene 7 arbeiten, und es kann ein gewisses Maß an Sicherheit bieten. Erfreulicherweise fanden wir diese Funktionen in allen getesteten Produkten bis auf Forum-Sentry.

Die Regeln können es Anwendern oder Gruppen erlauben oder verbieten, auf bestimmte Ressourcen zuzugreifen. Dies geschieht entweder auf IP-Basis oder mittels Identitätsangabe über eine SAML-Zuordnung.Außerordentlich bemerkenswert war die automatische Überprüfung der SOAP-Struktur auf die Einhaltung des zugehörigen Schemas (Validierung). Obwohl auch andere Produkte diese Fähigkeit besaßen, musste sie hier innerhalb einer Regel erst aktiviert werden. DBC geht hier einen besseren Weg, indem es die Validierung durchführt, bevor es die Anfrage verarbeitet. Wir hoffen, dass auch andere Hersteller diesem Beispiel folgen. Es ist kein besonders gutes Vorgehen, jede Client-Anfrage ungeprüft anzunehmen – Valdierung vor Verarbeitung ist Pflicht.

In der Version 1.4 hat Xtradyne das Management etwa um auf Rollen basierende Administrationsrechte erweitert. Für Policies gibt es jetzt eine Versionierung. Außerdem kommt zur XML-Schema-Validierung für SOAP die Inspektion über XPATH hinzu. Deren Konfiguration soll sich laut Xtradyne über ein grafisches Interface erledigen lassen. In der kommenden Version 1.5 will Xtradyne nun auch XML-Encryption einbringen.

VeriSign Trust Gateway 1.0.1

Bei Verisign dreht sich alles um PKI (Public-Key-Infrstructure), was auch bei dem ersten Release ihres »Trust Gateways« auffällt. Angesichts der Komplexität von digitalen Zertifikaten vereinfacht das Produkt den PKI-Einsatz deutlich. Als Besonderes überprüft das Gateway Zertifikate in Echtzeit über einen externen Service. In der nachfolgenden Version 1.1 unterstützt Verisign jetzt auch Hardware-Security-Module (HSM) von nCipher und Chrysalis zur Schlüsselspeicherung und Beschleunigung der Verschlüsselung.

Uns gefielen zwar der Umfang der PKI-Unterstützung innerhalb des Trust-Gateways und die Leichtigkeit mit der es solche typischerweise komplexe Umgebung beherrscht. Aber uns enttäuschte, dass die volle WS-Security-Unterstützung fehlte und die Verschlüsselungsfähigkeiten begrenzt waren. Die XML-Encryption-Spezifikation verlangt, dass sowohl ein ganzes XML-Dokument als auch nur ein Teil davon verschlüsselt werden kann. Verisign unterstützt die Verschlüsselung auf Element-Ebene nicht. Dies sollte aber geschehen, bevor SOAP 1.2 sich weit verbreitet hat. Denn Web-Services-Transaktionen können bei der Verarbeitung durch verschiedene Web-Service-Produkte laufen. Dabei sollte nur der betroffene SOAP-Endpunkt bestimmte Daten des SOAP-Dokumentes aus Datenschutzgründen lesen können. Dieses erfordert die Verschlüsselung einzelner Elemente.

Das Trust-Gateway verlangt auch, dass Name-Spaces bei der erweiterten Konfiguration des Routings in Abhängigkeit der URL des Endpunktes fest kodiert werden. Dies bindet das Gateway sehr eng an diese Endpunkte und verletzt einen zentralen Kernpunkt einer Service-Oriented-Architectur (SOA): lose Bindung, um die Wiederverwendung zu fördern, ohne dabei die Clients anzupassen.

Trust-Gateway verwendet für die Sicherheit Vertrauensbeziehungen. Um für eine bestimmte Operation die Zugangskontrolle zu definieren, muss der Administrator nur das Zertifikat des Clients importieren und anschließend ein Kästchen anklicken, um zu kennzeichnen, dass diesem Zertifikat für diese Operation vertraut werden soll. Die Zertifikate zu importieren, war unglaublich einfach: Wir gaben die URL für eine Vertrauensbeziehung an. Das Gateway verband sich mit der Adresse und importierte das Zertifikat über die verwendete HTTPS-Session. Im Gegensatz dazu verlangte Westbridges XMS von uns, mittels Securecopy die Zertifikate und Schlüsselpaare zu übertragen. Was zwar auf der einen Seite entschieden sicherer war, aber eben genauso unangenehm. Leider lässt Verisign für diese überzeugende Vorstellung Anwender bei den Lizenzen tief in die Tasche greifen. Die Kosten betragen 50000 Dollar pro Jahr.

Info

So testete Network Computing

Wir testeten die Produkte in unseren Green-Bay-Business-Application-Labs. Die auf Software basierenden Produkte von Verisign und Xtradyne installierten wir auf einer »Dell 2650«-Maschine mit zwei Dual-2,6-GHz-Prozessoren, einem Gigabyte RAM und einem 1-Gigabit-Kupfer-Interface, mit Redhat-Linux-9.0 laufend. Jedes Produkt wurde als Proxy für einen Dot-Net- und einen J2EE-Web-Service (Java-2-Enterprise-Edition) konfiguriert. Der J2EE-Web-Service lief unter »Mind Electric Glue« auf Solaris 9.0 mit einer »SunFire V480«-Hardware. Dabei ging es darum, die Interoperabilität zwischen den Plattformen und dem SOAP-Encoding-Modell zu untersuchen.

Die Produkte wurden dann für vier unterschiedliche Szenarien konfiguriert:

1. Straight-through: Das Produkt soll die Anfragen zum Backend-Server durchreichen und die Antwort an den Client zurückgeben.

2. Verschlüsseltes Element: Das Produkt soll ein vorher definiertes Element sowie zugehörige Unterelemente innerhalb des XML-Dokumentes verschlüsseln, bevor es die Antwort an den Client zurückschickt.

3. Validierung von XML: Das Produkt soll die Korrektheit des SOAP-Requests und des enthaltenen XML-Dokumentes überprüfen (Validierung).

4. Authentifizierung und Autorisierung: Das Produkt soll entweder WSSEC (WS-Security-Specification 1.0), SAML-Beglaubigung (Security-Assertion-Markup-Language) oder den Identitätsnachweis (User-Credentials) aus dem empfangenen XML-Dokument entnehmen und anschließend entscheiden, ob es den Identitätsnachweis für den Request akzeptiert oder nicht.

Diese vier Szenarien erlauben es uns, alle Aspekte von Konfiguration und Management abzudecken. Es gab uns außerdem die Möglichkeit, Integration mit einem Directory zu überprüfen, welche die Produkte anboten. Wir schauten uns auch an, welche Fähigkeiten das Produkt zur Konfiguration verlangt — die meisten Produkte erforderten spezialisiertes Teilwissen, etwa für XSLT (Extensible-Stylesheet-Language-Transformation) oder XML-Schema. Diese Szenarien verwendeten wir auch, um für jedes Produkt seine Zertifikats- und Schlüssel-Verwaltungsfähigkeiten zu beurteilen.

Für Performance-Tests konfigurierten wir Spirents »Communication Reflector« so, dass er auf SOAP-Anfragen antwortete. Ein »Spirent Avalanche« simulierte die Last von Hunderten von Clients, die SOAP-Requests an jedes Produkt im Test abschickten. Avalanche versuchte in zwei separaten Tests, so viele von 500 Requests wie möglich zu erzeugen. Der erste Test leitete die Daten direkt durch das Gateway, der zweite Test arbeitete mit Verschlüsselung. Beide Performance-Tests schickten einen zwei KByte großen SOAP-Request ab.

Xtradyne war beim zweiten Performance-Test nicht dabei, da es keine Verschlüsselung unterstützt. Verisigns Produkt konfigurierten wir so, dass es die ganze Nachricht verschlüsselt, da es die Kodierung auf Element-Ebene nicht unterstützt. Während der Performance-Tests reduzierten wir die Log-Stufe auf Warnung.

Danach untersuchten wir jedes Produkt auf Verwundbarkeit auf den Ebenen 2 bis 7 wie durch SQL-Injection-Angriffe. Dafür entwickelten wir einen J2EE-Web-Service, der eine verwundbare Version des SQL-Servers-2000 als seine Datenbank verwendete.

Trust-Gateway signiert seine Konfigurationsdateien, um sie gegen Manipulationen zu schützen. Wir editierten die auf XML basierenden Konfigurationsdateien des Gateways von Hand und versuchten, das System von neuem zu starten. Dieses informierte uns, dass die Dateien entweder geändert oder unbrauchbar seien, und weigerte sich zu starten. Nachdem wir die Konfigurationsdateien wieder in den ursprünglichen Zustand gebracht hatten, startete das System ohne Probleme. Anders als bei Reactivities XML-Firewall signiert Trust-Gateway die Logdateien nicht, was die Integrität der Auditaufzeichungen in Frage stellt. Wir schlugen vor, dass die Logdateien, wenn sie rotieren, eine Signatur erhalten. Verisign wollte die Eigenschaft in einem künftigen Release integrieren. [ wve, nwc ]