Kritik an Proxies als Massnahme
Marc Ruef | 03.03.2014

Im klassischen Firewalling werden die beiden Technologien Packet Filter und Application Gateway vorgesehen. Letztere ist durch das Anbieten dedizierter Application Level Proxies für einzelne Anwendungsprotokolle darum bemüht, eine Entkoppelung eines Dienstes vorzunehmen. Als Common Point of Trust wird das Sicherheitselement zwischen Client und Server geschaltet:

centerClient ↔ Proxy ↔ Server/center

Ein Proxy ist darum bemüht, die Unstimmigkeiten einer Kommunikation zu erkennen, einzuschränken und zu protokollieren. Wird also eine deformierte HTTP-Anfrage über einen Webproxy geschickt, sollte er entsprechend darauf reagieren können. Die Angriffsmöglichkeit gegenüber dem Zielsystem – dem eigentlichen Server -, soll durch das vorgeschaltete Element abgefangen und neutralisiert werden. Im besten Fall erreicht der Angriffsversuch also nie das angegriffene System, unabhängig von einer etwaigen Verwundbarkeit dessen:

centerClient → Proxy ↛ Server/center

Gehen wir nun davon aus, dass auf dem Server eine Schwachstelle existiert. Diese kann durch eine böswillige HTTP-Anfrage ausgenutzt werden. Ein Direktzugriff führt also zum Erfolg der entsprechenden Attacke. Der Proxy erkennt jedoch die Deformierung und kann den Angriff frühzeitig abblocken. Damit übernimmt er eine zentrale Aufgabe, die eigentlich dem Server hätte zuteil werden sollen. Denn eigentlich ist letzterer selbst dafür zuständig, sich selbst sicher anzubieten. Durch einen Proxy kann damit eine mehrschichtige Sicherheit (Multilevel Security) erreicht werden.

Mit diesem Prinzip gehen jedoch Einschränkungen einher. Weist zum Beispiel das vorgeschaltete Sicherheitslement eine Schwachstelle auf – sei dies nun eine programmtechnische Verwundbarkeit oder ein versehentlich eingeführter Fehler in den Konfigurationseinstellungen -, kann dieses seine Aufgabe nicht mehr wahrnehmen. Wird auf das Erreichen des gewünschten Sicherheitsstands auf der Applikation verzichtet, ist diese trotz Sicherheitselement – aufgrund seiner Transparenz – angreifbar. Es ist also wichtig, eine echte mehrschichtige Sicherheit zu erreichen, indem auf allen Ebenen Massnahmen angestrebt werden.

centerClient ↔ Proxy mit Schwachstelle ↔ Server/center

Das zweite Problem besteht in einem grundlegenden Missverständnis, welches Proxy-Lösungen entgegengebracht wird. Es wird oftmals fälschlicherweise per se angenommen, dass diese Angriffe pauschal erkennen und verhindern können. Tatsächlich ist es jedoch in erster Linie nur die Aufgabe des Proxies, Verletzungen der Standardisierung des eingesetzten Protokolls anhand eines wohldefinierten Prototyping zu erkennen. Dies können zum Beispiel fehlerhafte Werte in einer Header-Zeile sein.

Wird jedoch ein Angriff angestrebt, der keine Verletzungen dieser Art erfordert, kann der Proxy nicht ohne weiteres reagieren. Ein durch ihn erlaubter Zugriff wird voraussichtlich auch durch den Server als solchen wahrgenommen (das gleiche Problem haftet seit jeher Antiviren- (http://www.computec.ch/news.php?item.271) und IDS-Lösungen an):

centerClient ↔ Proxy erlaubt Zugriff ↔ Server erlaubt Zugriff/center

Es ist wichtig zu verstehen, dass Proxies a) in erster Linie als ergänzende Massnahme im Rahmen einer mehrschichtigen Sicherheitslösung eingesetzt werden sollten und b) netzwerk- und applikationsindividuelle Anpassungen an der Installation vorgenommen werden müssen. Hierzu muss sowohl die Funktionsweise der Proxylösung als auch jene der zu schützenden Dienste umfassend verstanden und eingeschränkt werden. Oftmals ginge mit einem solch durchdringenden Verständnis ebenfalls die Möglichkeit einer umfassenden Absicherung des Endpunkts einher. Und dadurch generiert sich das klassische Dilemma:



"Ein Proxy ist erst dann von echtem Nutzen, wenn er nicht mehr erforderlich wäre. q.e.d."



Ein Proxy-Element kann dann von unweigerlichem Nutzen sein, wenn keine direkte oder mittelfristige Möglichkeit besteht, den Server bzw. die darauf angebotene Applikation sicher zu machen. Zum Beispiel, weil eine geschlossene Lösung eingesetzt wird, die man nicht nach Belieben anpassen kann. Oder weil die Betreuung der betroffenen Komponenten durch eine externe Firma vorgenommen wird, und man deren Massnahmen nicht beeinflussen kann. In solchen Momenten vermag ein Proxy-Element ein gewisses Mass an Flexibilität und Unabhängigkeit zu erlangen.

Mit dem Einführen eines Proxies wird aber – abgesehen von der Gefahr einer falschen Sicherheit bei einer fehlerhaften Nutzung – ebenfalls eine zusätzliche Komplexität eingeführt. Diese kann zu Problemen im Betrieb führen, die sich ebenfalls direkt oder indirekt auf die Sicherheit der Umgebung auswirken können. Ein typisches und nicht zu unterschätzendes Beispiel ist die versehentliche Abschaltung der Proxy-Komponente, wodurch ungwollt eine unmittelbare Exponierung der (potentiell) verwundbaren Dienste stattfindet. Schon so manches Unternehmen musste in schmerzvoller Weise (http://blog.barracuda.com/pmblog/index.php/2011/04/12/waf-importance/) erfahren, dass damit die errichtete Sicherheit nur von temporärem Nutzen war.

iDieser Beitrag ist ursprünglich in den scip Labs (http://www.scip.ch/?labs) erschienen./i