Frage zu Firewall

[Greg]

Hey leute,

ich schreibe gerade eine wissenschaftliche arbeit über haftung in wlan netzwerken und habe eine verständnis frage zu firewalls:

Wie genau funktionieren SPI Firewalls? Ich hab die deutschen & englischen artikel auf wiki gelesen, meine Kernfrage dazu ist aber offen geblieben: Kann ich über SPI Firewalls effektiv protokolle blocken? z.B. Bittorrent als Protokoll blocken, ohne dabei wie bei portfiltern den jeweiligen Port einzustellen. Wenn ja, was unterscheidet eine SPI firewall von eine Application firewall (http://en.wikipedia.org/wiki/Application_firewall)

Kurzum: Kann eine SPI-Firewall bereits am header des Packets das verwendete Protokoll erkennen und verwerfen und wie schwer wäre eine solche firewall zu umgehen wenn man verschlüsselung als mittel aussenvor lässt?

thx!

 

[Zweifeuerkraut]

SPI = Stateful Packet Inspection?

Das macht doch heute jede Firewall. Steht doch, dass die auf Layer 4 operieren, mehr als Source, Destination und Port geht da also auch nicht. Der einzige Vorteil gegenüber einem Packetfilter ist, dass du die Verbindung zurück nicht auch noch explizit erlauben musst.

Und bei der Application Firewall steht: It is able to control applications or services specifically, unlike a stateful network firewall which is - without additional software - unable to control network traffic regarding a specific application.

Eine solche Firewall zu umgehen ist dann auch nicht ganz einfach. Da hilft dir dann auch Verschlüsselung nix, weil du kannst ja nirgendswohin eine Verbindung aufbauen, da alle Ports, ausser sagen wir mal NTP, geschlossen sind.

Sind aber gewisse Ports offen, könntest du mit einem manipulierten Server im Internet die FW umgehen und deinen gewünschten Traffic dann über einen dieser Ports schicken. Das ist dann auch der Grund, wieso man aus Clientnetzen grundsätzlich nix raus lässt und das alles über dedizierte Server löst, sprich Mailserver & Mailgateway und http/https/ftp Proxy.

 

[Greg]

ja, SPI = Stateful Packet Inspection

Mich hat folgender punkt bei wiki stutzig gemacht

"Stateful packet inspection can determine what type of protocol is being sent over each port, but application-level filters look at what a protocol is being used for. For example, an application-level filter might be able to tell the difference between HTTP traffic used to access a Web page and HTTP traffic used for file sharing, whereas a firewall that is only performing packet filtering would treat all HTTP traffic equally."

Thema verschlüsselung und application based firewalls: Warum soll das nicht möglich sein? Der witz an application based firewalls is doch gerade dass du nicht mehr alle ports dichtmachen musst wie bei nem Portfilter. Insofern sind alle verbindungen erlaubt die nicht unter die gesperrten kategorien wie filesharing fallen und verschlüsselten Traffic als solchen wird man im regelfall nicht sperren.

 

[HERR 2FICKENDEHUNDE]

Die Filter einer Proxy Firewall (auch Application Layer Firewall genannt) beachten zusätzlich zu den reinen Verkehrsdaten wie Quelle, Ziel und Dienst typischerweise noch die Nutzdaten, also den Inhalt der Netzwerkpakete. Im Unterschied zur Stateful Inspection Technologie, die abhängig vom Produkt mitunter auch auf die Nutzdaten zugreift, reicht der typische Proxyfilter die Netzwerkanfrage des Quellsystems nicht einfach an das Zielsystem weiter. Vielmehr baut er selbst eine eigene Verbindung zum Zielsystem auf. Da er stellvertretend für den anfragenden Client mit dem Zielsystem kommuniziert, kann er die Pakete zusammenhängend analysieren und Einfluss auf die Verbindung nehmen. So ist er in der Lage, Anfragen auch in Bezug auf den Kommunikationsfluss der Nutzdaten zu filtern und kann entscheiden, welche Antworten des Zielsystems er an den anfragenden Client weiterreicht. Dabei kann er den Paketinhalt beliebig verändern.

http://de.wikipedia.org/wiki/Firewall#Proxy_Firewall_.28auch_Application_Layer_Firewall.29

 

[Shihatsu]

Jetzt bringst du aber Blacklist/Whitelist und Inspektionsart gewagt radikal durcheinander.
Der Witz bei Application ist eben das du ports nicht komplett dichtmachen musst. Kannst zb surfen erlauben aber skype verbieten (Was so ziemlich standard ist).
Btw: SSL funzt schon, allerdings nur für den Verbindungsaufbau - danach funktioniert die firewall als SSL-terminierender Proxy, damit sie ihre funktion erfüllen kann. Sie ist ja letzlich der "Mann in der Mitte".

 

[Greg]

Warum durcheinander? Das ist doch was ich meine: Über den selben Port kann man z.B. einen rotokolltyp erlauben und einen anderen sperren. Die frage ist nur: Prüft die SPI Firewall bereits den header und kann sie an ihm das verwendete Protokoll erkennen, oder ist dafür eine application-firewall notwendig. i.E.: Wäre eine application firewall, wenn sie die pakete vollständig untersucht nicht bereits wie eine DPI-Firewall zu behandeln?

SSL: Versteh ich dich richtig: Der SSL request als solcher ist noch unverschlüsselt, deswegen könnte man ihn theoretisch auch verhindern. Sobald die SSL verbindung steht aber nicht mehr, da die Firewall dann nicht mehr den inhalt entschlüsseln kann.

 

[Zweifeuerkraut]

Mich hat folgender punkt bei wiki stutzig gemacht

"Stateful packet inspection can determine what type of protocol is being sent over each port, but application-level filters look at what a protocol is being used for. For example, an application-level filter might be able to tell the difference between HTTP traffic used to access a Web page and HTTP traffic used for file sharing, whereas a firewall that is only performing packet filtering would treat all HTTP traffic equally."

Da wird meiner Meinung nach verschmischt. SPI-FWs operieren wie gesagt auf Layer 4 des OSI Modells, also bis hoch zu TCP. Und da gibt es nicht mehr als Source, Destination und Port. Weitere Protokolle (HTTP etc.) kommen weiter oben.
Das einzige, was SPI von einem Packetfilter unterscheidet, ist die Session Table.

Wenn du also einen Ping (ICMP Echo Request) vom LAN ins Internet erlauben willst, brauchst du nur eine Rule, welche das erlaubt.
Die Antwort, also der ICMP Echo Reply, braucht dagegen keine eingehende Rule mehr um zu funktionieren, da diese Verbindung bereits in der Session Table besteht.

Beim Packetfilter bräuchtest du dagegen auch noch eine Rule von Internet nach LAN für ICMP Echo Reply. Und das ist dann natürlich schnell mal ziehmlich doof.

Natürlich werden diese ganzen Technologien heute gemischt und es gibt SPI FWs mit IDS/IPS Funktionen und Application/Protocol Awareness/Inspection etc. pp. Deshalb wohl das Blah in dem Wiki Artikel.

Thema verschlüsselung und application based firewalls: Warum soll das nicht möglich sein? Der witz an application based firewalls is doch gerade dass du nicht mehr alle ports dichtmachen musst wie bei nem Portfilter. Insofern sind alle verbindungen erlaubt die nicht unter die gesperrten kategorien wie filesharing fallen und verschlüsselten Traffic als solchen wird man im regelfall nicht sperren.

Err, du hast im Eingangspost was von SPI Firewall umgehen geschrieben.

Ich habe noch nie eine reine Application FW (z.B. Palo Alto) administriert, aber ich kann mir nicht vorstellen, dass da am Ende kein ANY/ANY/BLOCK vorkommt. Das wär ja hirnrissig, wenn ich alles mögliche sperren müsste, als einfach explizit das zuzulassen, was man wirklich braucht.

 

[Shihatsu]

Wenn du das meintest - gut. Hörte sich für mich jedoch nach nem Blacklist-Verfahren an: ich erlaube * auf ports * und verbiete http/skype auf port 80. das macht aber in der Realität niemand. Was gemacht wird ist: ich verbiete * auf * und erlaube http/native auf port 80.
Was deine Frage nach dem header angeht bin ich überfragt - wirklich auskennen tue ich mich nur mit NAT und den dicken dingern und die machen eh alle dpi.

und natürlich ist der initiale ssl request unverschlüsselt, das ist er immer. erst wenn der handshake sauber durch ist steht die encryption. zur terminierung: http://de.wikipedia.org/wiki/Proxy_(Rechnernetz) und da dann dedicated proxy lesen.

 

[Greg]

ok, danke. Für meine zwecke die entscheidende Frage: Auf einem handelsüblichem router für den Privatgebrauch gibt es bis auf SPI/Firewall mit vollständigem Portblock keine möglichkeit bestimmte Protokolle zu erkennen und auszuschließen. Dafür müsste man praktisch schon DPI ebene ansetzen und das gibts erst in enterprise lösungen

Bei SSL: Kann ich am header des Handshake bereits erkennen ob es eine verschlüsselte HTTP oder bittorent verbindung werden wird und sie entsprechen durchlassen oder blocken?

 

[HERR 2FICKENDEHUNDE]

ok, danke. Für meine zwecke die entscheidende Frage: Auf einem handelsüblichem router für den Privatgebrauch gibt es bis auf SPI/Firewall mit vollständigem Portblock keine möglichkeit bestimmte Protokolle zu erkennen und auszuschließen. Dafür müsste man praktisch schon DPI ebene ansetzen und das gibts erst in enterprise lösungen

oder unter linux. es gibt projekte wie zb http://code.google.com/p/opendpi/ die man zb auf openwrt fähigen routern zum laufen bringen könnte. alternativ http://l7-filter.clearfoundation.com/docs/readme

 

[Greg]

ah danke, gut zu wissen. Aber reicht die hardware eines normalen routers überhaupt dafür aus ums vernünftig zum laufen zu bringen?

 

[Zweifeuerkraut]

Stellt sich natürlich die Frage, was ein normaler Router und was vernünftig ist.

Meine Erfahrung mit DPI ist beschränkt, aber klar ist, dass die benötigte Rechenleistung mit mehr Regeln steigt. Sprich je mehr Protokolle du prüfen willst, desto aufwändiger wirds.
Wenn du NUR prüfen willst, ob jemand Bittorrent am laufen hat ist das halt etwas anderes, als wenn du ein volles IPS und VOIP-Schnüffelung etc. möchtest...

Dürfte aber schwierig werden da verlässliche Zahlen im Internet zu finden, weil das einfach sehr Produkt- und Anwendungsspezifisch ist. Gerade im Firewallbereich, wo es keine klaren Benchmark-Richtlinien gibt und jeder Hersteller Zahlen veröffentlicht, die sein Produkt im besten Licht dastehen lassen.
(https://www.sans.org/reading_room/w...rison-shopping-scalable-firewall-products_796)