Hallo,
die konfigurierten Randbedingungen bei Defaultroutenfiltern werden mit LCOS 7.22 (hier: 1811) m. E. nicht korrekt behandelt, so dass zwei Fehler auftreten:
Das Testscenario ist dieses:
- INTRANET : 10.1.0.0/16 : Routing-Tag 1 : Defaultroute für Routing-Tag 1 gesetzt auf WAN-Interface (DSL)
- KEINE globale def rt für r-tag 0
Nun soll ein erweiterer IP-Spoofingfilter in der FW definiert werden (mit Prio 2 ganz an die Spitze der Regeltabelle gesetzt), der frei definierte Quelladressen komplett blocken soll.
Regel SPOOF<
- Prio 2
- Aktion: Verwerfen, nur empfangene Pakete (phys.) also aus WAN-Intf-Sicht) und nur bei Default-Route
- für alle Dienste/Protokolle
- für alle Ziele
- für Quell-IPs in
10.0.0.0/8
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
192.0.2.0/24
192.168.0.0/16
224.0.0.0/4
240.0.0.0/4
Dieser Filter wirkt nicht wie erwartet:
Beispiel aus der "Verbindungsliste"
src dst proto sp dp r-tag ttl flags rule s-rt d-rt
10.1.1.1 195.50.140.250 17 53 53 1 126 80020008 SPOOF< MYISP
Eine DNS-Abfrage aus dem INTRANET nach extern wurde von der SPOOF-Regel behandelt und als Verbindung eintragen
***********************************
1. Fehler: Die Regel registriert die Verbindung für Masquerading/NAT, obwohl sie nicht zu zutrifft.
2. Fehler: Es wird nicht korrekt erkannt, dass das Paket NICHT über eine Defaultroute KOMMT, denn die Quelle sitzt ja im INTRANET
***********************************
Durch eine spezifischere Regel für DNS-Abfragen nach extern wird die Beispielverbindung zugelassen, aber in der Verbindungsliste steht sie nicht mit der zutreffenden Regel.
Die FW-Regel war so konfiguriert, dass sie nur für eingehende Pakete aus der Defaultroute mit physischer Sicht gilt, also streng begrenzt auf Pakete, vom WAN-Interface kommen.
LCOS-Referenzhandbuch/Addendum zu 7.20, Seite 23:
<quot>
In der Firewall besteht die Möglichkeit, Regeln
**** nur dann greifen zu lassen, wenn der Absender oder der Empfänger
**** über die Defaultroute erreicht werden kann.
Da die Funktion der virtuellen Router auf der Auswertung der Schnittstellen-Tags basiert, müssen neben den ungetaggten Default-Routen auch weitere Routen als „Default-Routen“ einbezogen werden:
- Wenn ein Paket auf einem WAN-Interface empfangen wird, dann gilt diese WAN-Schnittstelle für die Firewall als Defaultroute, wenn entweder eine getaggte oder eine ungetaggte Defaultroute auf diese WAN-Schnittstelle verweist.
- Wenn ein Paket auf einem LAN-Interface empfangen wird und auf eine WAN-Schnittstelle geroutet werden soll, dann gilt diese WAN-Schnittstelle als Defaultroute, wenn entweder die ungetaggte Defaultroute oder eine mit dem Interface-Tag getaggte Defaultroute auf diese WAN-Schnittstelle verweist.
</quot>
Habe ich ARF noch nicht ganz verstanden? Oder handelt es sich um einen Bug?
Gruß,
Rougu
LCOS 7.22: FW : Defaultroutenfilter greift nicht/falsch
Moderator: Lancom-Systems Moderatoren
Hi Rougu
die Filter funktionieren korrekt - du hast nur die falsche Erwartung an die Filter...
Dieser Filter wirkt nicht wie erwartet:
Beispiel aus der "Verbindungsliste"
src dst proto sp dp r-tag ttl flags rule s-rt d-rt
10.1.1.1 195.50.140.250 17 53 53 1 126 80020008 SPOOF< MYISP
Der Filter matcht, weil die Quelladresse (10.1.1.1) innerhalb der Quellnetzes 10.0.0.0/8 liegt und die Zieladresse (195.50.140.250) zu "alle Stationen" paßt. Desweitern wird das Paket ja über die Defaultroute geleitet...
Die Firewall des LANCOMs ist KEIN Paketfilter!, sondern eine SPI-Firewall d.h. der Filter reagiert erstmal auf alle Pakete, die Adreßmäßig passen und erstellt einen Session-Eintrag um die Antwortpakte bearbeiten zu können.
Danach werden die Aktionen ausgeführt, an die zusätzlich Bedingungen geheftet werden können (nur auf Defaultroute, nur Empfang/Senden, etc...). Bei den Bedingungen "nur für Empfang/Senden" kommt nun zum Tragen, daß diese für Traffic-Shaping gedacht sind, was du auch siehst, wenn du im Telnet mal "schow filter" eingibst:
Dann wird für deine Regel folgendes stehen:
conditional: if on default route (<= das trifft bei dir zu!)
Limit per conn.: after receiving of 0 kilobits per second on a WAN interface
actions after exceeding the limit: reject
Die Regel reagiert somit auf die abgehende DNS-Anfrage und läßt diese auch passieren. Wenn nun die Antwort kommt, dann matcht das Limit und das Paket wird verworfen.
Gruß
Backslahs
die Filter funktionieren korrekt - du hast nur die falsche Erwartung an die Filter...
Dieser Filter wirkt nicht wie erwartet:
Beispiel aus der "Verbindungsliste"
src dst proto sp dp r-tag ttl flags rule s-rt d-rt
10.1.1.1 195.50.140.250 17 53 53 1 126 80020008 SPOOF< MYISP
Eine DNS-Abfrage aus dem INTRANET nach extern wurde von der SPOOF-Regel behandelt und als Verbindung eintragen
Der Filter matcht, weil die Quelladresse (10.1.1.1) innerhalb der Quellnetzes 10.0.0.0/8 liegt und die Zieladresse (195.50.140.250) zu "alle Stationen" paßt. Desweitern wird das Paket ja über die Defaultroute geleitet...
Die Firewall des LANCOMs ist KEIN Paketfilter!, sondern eine SPI-Firewall d.h. der Filter reagiert erstmal auf alle Pakete, die Adreßmäßig passen und erstellt einen Session-Eintrag um die Antwortpakte bearbeiten zu können.
Danach werden die Aktionen ausgeführt, an die zusätzlich Bedingungen geheftet werden können (nur auf Defaultroute, nur Empfang/Senden, etc...). Bei den Bedingungen "nur für Empfang/Senden" kommt nun zum Tragen, daß diese für Traffic-Shaping gedacht sind, was du auch siehst, wenn du im Telnet mal "schow filter" eingibst:
Dann wird für deine Regel folgendes stehen:
conditional: if on default route (<= das trifft bei dir zu!)
Limit per conn.: after receiving of 0 kilobits per second on a WAN interface
actions after exceeding the limit: reject
Die Regel reagiert somit auf die abgehende DNS-Anfrage und läßt diese auch passieren. Wenn nun die Antwort kommt, dann matcht das Limit und das Paket wird verworfen.
natürlich trifft die Regel zu und natürlich wird für ein DNS-Forwarding ein NAT-Eintrag benötigt.1. Fehler: Die Regel registriert die Verbindung für Masquerading/NAT, obwohl sie nicht zu zutrifft.
aber das Ziel steht im Internet2. Fehler: Es wird nicht korrekt erkannt, dass das Paket NICHT über eine Defaultroute KOMMT, denn die Quelle sitzt ja im INTRANET
wozu überhaupt diese Regel - das macht das IDS des LANCOMs automatisch...Die FW-Regel war so konfiguriert, dass sie nur für eingehende Pakete aus der Defaultroute mit physischer Sicht gilt, also streng begrenzt auf Pakete, vom WAN-Interface kommen.
das hat nichts mit ARF zu tun... Du hast einfach die Firewall nicht verstanden - und das, obwohl du den entsprechenden Abschnitt aus dem Referenzhandbuch zitierest:Habe ich ARF noch nicht ganz verstanden? Oder handelt es sich um einen Bug?
In deinem Fall ist der Empfänger im Internet...In der Firewall besteht die Möglichkeit, Regeln
**** nur dann greifen zu lassen, wenn der Absender oder der Empfänger
**** über die Defaultroute erreicht werden kann.
Gruß
Backslahs
Hi Backslash,
das war sehr aufschlussreich, danke.
Mir war in der Tat nicht klar, dass die Adressen allein genügen, um den Match zu erzeugen, und die Bedingungen erst später greifen. Mit dieser Erkenntnis muss ich nun meine Firewallregeln einmal durchforsten, denn "nur Senden/Empfang" hatte ich bisher immer als Teil der Matchbedingung angesehen.
[quote]wozu überhaupt diese Regel - das macht das IDS des LANCOMs automatisch...[/quote]
Die Regel enthält 169.254.0.0/16 und war u. a. ein Versuch, das IDS zu überlisten, das bei ZeroConf-befähigten
Clients leicht einmal unerwünschten Alarm schlägt.
Gruß,
Rougu
das war sehr aufschlussreich, danke.
Mir war in der Tat nicht klar, dass die Adressen allein genügen, um den Match zu erzeugen, und die Bedingungen erst später greifen. Mit dieser Erkenntnis muss ich nun meine Firewallregeln einmal durchforsten, denn "nur Senden/Empfang" hatte ich bisher immer als Teil der Matchbedingung angesehen.
[quote]wozu überhaupt diese Regel - das macht das IDS des LANCOMs automatisch...[/quote]
Die Regel enthält 169.254.0.0/16 und war u. a. ein Versuch, das IDS zu überlisten, das bei ZeroConf-befähigten
Clients leicht einmal unerwünschten Alarm schlägt.
Gruß,
Rougu