< Das Simple Object Access Protocol
Inhalt
Problembereich SOAP und klassisches Firewalling >

 

Konzepte klassischer Firewalls

Firewalls werden dazu benutzt, Netzwerke von Aussen aber auch von Innen, also mittels eines Perimeter-Netzwerks(DMZ), vor Angreifern zu schützen, wobei immer wieder betont werden muss, dass dies nur eine Komponente eines Sicherheitskonzepts ist. Das FW-Konzept hat, obwohl es ein technisches ist, organisatorische Wurzeln, nämlich zentralisiert an einem Ort und somit kosten- und wartungseffizient mehrere Rechner bzw. Dienste zu schützen. [Zwicky et al. 2001]
Dies geschieht mit einfachen Heuristiken indem z.B. einem Host von der Firewall zwar Zugriff auf einen Server gewährt wird, dieser jedoch nicht alle seine Dienste anbietet, sondern nur bestimmte, wie z.B. http. Diese Entscheidungen basieren auf Regeln welche über IP-Adressen und Ports selektiert werden. Somit ist es zwar möglich einen bestimmten Dienst freizugeben, welche Daten aber über diese erlaubte Verbindung fließen ist nur mehr bedingt kontrollierbar.
Um dieses Problem zu kompensieren wurde als zweite Stufe das Stateful (oder Deep) Inspection-Firewall-Modell entwickelt welches zwar immer noch nach den oben genannten Regeln filtert, jedoch zusätzlich zu dieser Funktion auch eine Wissensbasis über den Protokollaufbau der wichtigsten Dienste wie http, FTP, SMTO usw. besitzt und so bestimmen kann ob es sich bei den abgesetzten Requests überhaupt um gültige Daten dieses Protokolls handelt. Anhand dieses Wissens kann dann z.B. eine Anfrage geblockt werden, die vorgibt Daten an einen Dienst zu senden, obwohl niemals ein vollständiger Handshake stattgefunden hat. Diesen Request würde die oben genannte, nur Pakete filternde Firewall nicht verbieten, da er ja eine gültige Adresse und einen gültigen Port aufweißt. Die gesamte Filterung basiert aber immer noch nur auf Layer 3 und 4 im OSI Modell, was bedingt, dass nun zwar die Verbindung, der Dienst und der Zustand der Kommunikation geprüft werden, dies jedoch alles wenig hilft, falls der Dienst an sich Sicherheitslöcher besitzt.
Hier setzt die nächste Stufe moderner Netzwerkssicherheit an, nämlich Intrusion Dedection Systems (IDS) und Proxies. Mit Hilfe eines IDS kann z.B. nach verdächtigen Stringketten innerhalb eines Requests gesucht und bei einer positiven Übereinstimmung Alarm in Form von Mail, SMS usw. gegeben werden. Beispiel dafür wäre eine Attacke bei der ein Angreifer versucht ein Sicherheitsloch in einem Microsoft IIS Server auszunützen und über diesen eine Command Shell mit vollen Systemrechten zu erlangen. Dazu sucht das IDS in jedem http Request z.B. nach den String „cmd.exe“ und alarmiert sofort die IT-Abteilung sollte so ein Request eintreffen.
Nun ist es so, dass solche Angriffe heutzutage im Internet sehr häufig auftreten und besonders bei bekannten Vulnerabilities die Anzahl der Versuche bald ein konstantes Hintergrundrauschen in den Logs darstellt, sodass ernstzunehmende Angriffe nur noch schwer aus den IDS-Logs zu filtern sind. Deswegen wird für bestimmte Dienste auch sehr oft der Konzept eines Proxies eingesetzt, welcher den eingehenden Request aufnimmt, ihn auf Sicherheitslücken untersucht, indem er z.B. den Inhalt eines Requests noch mal parset und so z.B. Sonderzeichen, die z.B. für SQL-Injections oder den oben genannten Mechanismus verwendet werden könnten einfach wegnimmt, was zur Folge hat, das der Angriff dadurch verhindert wird, da der Request, welchen der Proxy nun absetzt ohne diese Zeichen geschickt wird. Dieses Konzept der Applikation Level Firewall stellt auch eine guten Ansatzpunkt für SOAP-Security dar, wie in Folge beschreiben wird.

 

< Das Simple Object Access Protocol
Inhalt
Problembereich SOAP und klassisches Firewalling >