Deny-All-Strategie: Wissenslücke, Denkfehler oder Bug?

Transcendence · Beitrag von **Transcendence** » 13 Aug 2007, 14:32

Hallo,

ich stoße auf eine Schwierigkeit beim Einrichten der Firewallregeln im Rahmen einer deny-all-Strategie:

Firewall/Router ist ein 1722, Softwearestand 6.32. Über ADSL sind zwei ADSL-Gegenstellen angebunden, eine für Mailserver usw. via NAT in einer DMZ mit fester IP-Adresse [GEGENSTELLESTAT], die andere mit dynamisch vergebener IP-Adresse [GEGENSTELLEDYN] für den direkten Internetverkehr der Arbeitsplatzrechner via NAT im LAN. Die DMZ hat, wie laut Handbuch und FAQ beschrieben, einen eigenen Adresskreis und einen eigenen dafür konfigurierten Switchport am Router (DMZ1), der im Private Mode betrieben wird; das LAN hat einen eigen Adresskreis und einen eigenen dafür konfigurierten Switchport am Router (LAN1), der ebenfalls im Private Mode betrieben wird (wahrscheinlich hier unnötig, aber sicher ist sicher).

Zunächst habe ich bis auf die "WINS"-Regel alle bisherigen Firewallregeln gelöscht.

Dann habe ich eine deny-all-Regel "D-ALL<->ALL" angelegt, mit der jeglicher Netzwerkverkehr von "Alle Stationen" zu "Alle Stationen" und für alle Protokolle und Ports durch Zurückweisen mit SNMP-Nachricht unterbunden werden soll. Diese Regel unterbindet auch tatsächlich jeglichen Netzwerkverkehr zwischen allen Netzen. Auf den Router kann ich jedoch weiterhin zugreifen (ich kann LANconfig und LANmonitor vom LAN aus weiter verwenden und muss für die weitere Konfiguration nicht auf die serielle Schnittstelle ausweichen, was ich bei "Alle Stationen" erwartet hätte).

Als Nächstes habe ich via Policy Based Routing, so wie in Handbuch und FAQ beschrieben und im Rahmen einer allow-all-Strategie bisher auch erfolgreich angewendet, den Internetverkehr von den Arbeitsplatzrechnern aus zunächst testweise ohne Einschränkungen über GEGENSTELLEDYN geroutet. Dazu habe ich eine neue Regel "AR-LANSTATION->GEGENSTELLDYN" eingerichtet, mit Routingtag 1, sofort Übertragen, vom Adresskreis der Arbeitsstationen im LAN zur Gegenstelle GEGENSTELLEDYN, alle Protokolle und Ports. Dem entsprechen die notwendigen Einträge in der Routingtabelle und bei den Gegenstellen.

Das funktioniert auch, wie in LANmonitor zu beobachten ist. Leider kann ich vom LAN aus nun aber nicht nur auf das Internet über GEGENSTELLEDYN zugreifen, sondern auch auf die DMZ. Und von der DMZ kann ich auf das LAN zugreifen. Nachdem ich die SNMP-Nachrichten für die allow/route-Regel eingeschaltet habe, ist im LANmonitor auch zu sehen, dass die Pakete zwischen LAN und DMZ tatsächlich mit Hilfe der "AR-LANSTATION->GEGENSTELLDYN"-Regel transportiert werden.

Sollte der Netzverkehr zwischen LAN und DMZ, der die Gegenstelle GEGENSTELLEDYN doch gar nicht betrifft, unter den genannten Umständen nicht in die deny-all-Regel laufen?

Erliege ich einer Wissenslücke, einem Denkfehler oder ist das ein Bug?

Grüße
T.

backslash · Beitrag von **backslash** » 13 Aug 2007, 18:29

Hi Transcendence

Auf den Router kann ich jedoch weiterhin zugreifen (ich kann LANconfig und LANmonitor vom LAN aus weiter verwenden und muss für die weitere Konfiguration nicht auf die serielle Schnittstelle ausweichen, was ich bei "Alle Stationen" erwartet hätte).

Die Firewall bezieht sich nur auf geroutete Pakete (sog. FORWARDING-Zweig) und greift nicht, wenn das LANCOM direkt angesprochen ist. Der direkte Zugriff wird über die Access-Listen (LANCAPI, Config) geregelt (INBOUND-Zweig). Ein expliziter OUTBOUND-Zweig ist nicht notwendig, da auf dem LANCOM keine weiteren Applikationen installiert werden können, die überwacht werden müßten.

Das funktioniert auch, wie in LANmonitor zu beobachten ist. Leider kann ich vom LAN aus nun aber nicht nur auf das Internet über GEGENSTELLEDYN zugreifen, sondern auch auf die DMZ. Und von der DMZ kann ich auf das LAN zugreifen

Das ist auch korrekt, da eine Gegenstelle in der Zielspalte keine Bedingung ist, sondern nur zur Ermittlung der in der Regel verwendeten Adressen dient (und GEGENSTELLEDYN ist hier das gleiche wie "alle Stationen", da ja das Internet dran hängt). Die Gegenstelle kann auch keine Bedingung für eine Regel sein, da sie ja erst über die Routing-Tabelle zugewiesen wird...

Anders sieht es aus, wenn die Gegenstelle in der Quell-Spalte steht - da ist ja bekannt, über welche Gegenstelle das Paket gekommen ist und somit kann hier die Gegenstelle auch Bedingung für das Greifen der Regel sein.

Sollte der Netzverkehr zwischen LAN und DMZ, der die Gegenstelle GEGENSTELLEDYN doch gar nicht betrifft, unter den genannten Umständen nicht in die deny-all-Regel laufen?

Wenn du Traffic vom Intranet in die DMZ verhindern willst, dann mußt du nun eine explizite Regel erstellen, die das verhindert (Quelle: Intranet-Netz, Ziel DMZ-Netz). Genauso solltest du auch eine Regel erstellen, die den Traffic von der DMZ ins Intranet verhindert.

Normalerweise will man zumindest den Traffic vom Intranet in die DMZ zulassen (denn schließlich kann ja auch jeder aus dem Internet darauf zugreifen) und nur den umgekehrten Weg (also von der DMZ ins intranet) unterbinden

Gruß
Backslash

Transcendence · Beitrag von **Transcendence** » 15 Aug 2007, 20:05

Hallo backslash,

Die Firewall bezieht sich nur auf geroutete Pakete (sog. FORWARDING-Zweig) und greift nicht, wenn das LANCOM direkt angesprochen ist. Der direkte Zugriff wird über die Access-Listen (LANCAPI, Config) geregelt (INBOUND-Zweig). Ein expliziter OUTBOUND-Zweig ist nicht notwendig, da auf dem LANCOM keine weiteren Applikationen installiert werden können, die überwacht werden müßten.

Aaah, so ist das.

Das ist auch korrekt, da eine Gegenstelle in der Zielspalte keine Bedingung ist, sondern nur zur Ermittlung der in der Regel verwendeten Adressen dient (und GEGENSTELLEDYN ist hier das gleiche wie "alle Stationen", da ja das Internet dran hängt). Die Gegenstelle kann auch keine Bedingung für eine Regel sein, da sie ja erst über die Routing-Tabelle zugewiesen wird...

Anders sieht es aus, wenn die Gegenstelle in der Quell-Spalte steht - da ist ja bekannt, über welche Gegenstelle das Paket gekommen ist und somit kann hier die Gegenstelle auch Bedingung für das Greifen der Regel sein.

s.o.

Wenn du Traffic vom Intranet in die DMZ verhindern willst, dann mußt du nun eine explizite Regel erstellen, die das verhindert (Quelle: Intranet-Netz, Ziel DMZ-Netz). Genauso solltest du auch eine Regel erstellen, die den Traffic von der DMZ ins Intranet verhindert.

Ausgehend von der beschriebenen Konfiguration, in der der Verkehr zur GEGENSTELLEDYN nicht weiter eingeschränkt wird:

Das bedeutet, dass ich in der beschriebenen Konfiguration in Grunde wie bei einer allow-all-Strategie vorgehen muss, da durch die GEGENSTELLEDYN-Regel, jedenfalls soweit die Gegenstelle in der Zielspalte steht, die deny-all-Regel eh nicht mehr greift. Habe ich das so richtig verstanden?

Mit Hilfe der Regelpriorisierung ist dann das gewünschte Verhalten einzustellen.

Normalerweise will man zumindest den Traffic vom Intranet in die DMZ zulassen (denn schließlich kann ja auch jeder aus dem Internet darauf zugreifen) und nur den umgekehrten Weg (also von der DMZ ins intranet) unterbinden

Klar. Im Versuchsaufbau sollte allerdings nichts gehen, was ich nicht explizit erlaubt habe - darum ja die deny-all-Strategie.

Vielen Dank für Deine ausführliche Antwort!

Grüße
T.

backslash · Beitrag von **backslash** » 16 Aug 2007, 18:27

Hi Transcendence

Das bedeutet, dass ich in der beschriebenen Konfiguration in Grunde wie bei einer allow-all-Strategie vorgehen muss, da durch die GEGENSTELLEDYN-Regel, jedenfalls soweit die Gegenstelle in der Zielspalte steht, die deny-all-Regel eh nicht mehr greift. Habe ich das so richtig verstanden?

jain...
du mußt nur eine passende Deny-Regel anlegen, die den Traffic zwischen Intranet und DMZ blockt, und kannst dann wie bei einer Deny-All Strategie weitermachen...

Mit Hilfe der Regelpriorisierung ist dann das gewünschte Verhalten einzu stellen.

genau - das sollte aber auch automatisch gehen, weil die Regel, die den Traffic zwischen Intranet und DMZ blockt, an sich schon eine höhere Priorität hat, als die Regel die den Traffic zwischen Intranet und "allen Stationen" (bzw. in deinem Fall GEGENSTELLEDYN). Die höhere Priorität ergibt sich einfach dadurch, daß das Zielnetz "kleiner" ist...

Gruß
Backslash

Transcendence · Beitrag von **Transcendence** » 16 Aug 2007, 18:49

Hallo backslash,

Deine Antwort und ein Editieren meinerseits haben sich gerade überschnitten. Ich habe es darum oben wieder gelöscht und setze es das als Antwort hier hinein, da Du den Punkt ansprichst:

genau - das sollte aber auch automatisch gehen, weil die Regel, die den Traffic zwischen Intranet und DMZ blockt, an sich schon eine höhere Priorität hat, als die Regel die den Traffic zwischen Intranet und "allen Stationen" (bzw. in deinem Fall GEGENSTELLEDYN). Die höhere Priorität ergibt sich einfach dadurch, daß das Zielnetz "kleiner" ist...

Nur wird eine solche Regel, in LANconfig gestzt, *hinter* der GEGENSTELLEDYN-Regel eingeordnet, die bereits alles frei gibt - daher meine Vermutung, dass sie gar nicht mehr zum Einsatz kommt, und der Gedanke der Priorisierung.

Natürlich ist das hier ein Grenzfall, denn eine deny-all-Strategie, in deren Rahmen *alles* aus dem LAN ins WAN erlaubt werden soll, ist in der Praxis wenig sinnvoll. Für das Verständnis, wie die Firewall genau funktioniert, finde ich das dennoch sehr interessant.

Danke für Deine Erläuterungen!

Grüße
T.

backslash · Beitrag von **backslash** » 16 Aug 2007, 19:31

Hi Transcendence

Nur wird eine solche Regel, in LANconfig gestzt, *hinter* der GEGENSTELLEDYN-Regel eingeordnet, die bereits alles frei gibt

das könnte daran liegen, daß LANconfig u.U. der Meinung ist, daß, wenn eine Gegenstelle ausgewählt wird, für diese nur eine IP-Adresse gilt - und sie somit nach oben soll.

daher meine Vermutung, dass sie gar nicht mehr zum Einsatz kommt, und der Gedanke der Priorisierung

klar, mit einer manuellen Priorisierung zwingst du sie natürlich nach oben - unabhängig davon, was LANconfig meint...

Gruß
Backslash

Transcendence · Beitrag von **Transcendence** » 16 Aug 2007, 21:14

Hallo backslash,

ok, ich glaube ich habe das Prinzip jetzt verstanden und weiß nun, worauf ich achten muss. Jetzt kann ich daran gehen, die Firewall so aufzubauen, wie sie tatsächlich funktionieren soll. Danke noch mal für Deine Auskünfte!

Inzwischen habe ich die 7.20 aufgespielt, dort verhält sich die Firewall ebenso. Aber ich kann mehr Netze definieren

Das ist wirklich *sehr* nützlich!

Sehr schön ist auch die Möglichkeit, das Port-Forwarding jetzt in der Port-Forwarding-Tabelle an eine bestimmte Gegenstelle zu binden. Das macht das Firewallregelwerk kürzer und übersichtlicher.

Einen schönen Abend
T.