DENY-ALL Regel greift trotz höher priorisierter ACCEPT-Regel

[hanabi]

Hallo zusammen,
ich habe versucht, Firewall-Regeln zu setzen, die die Verbindung von einem Gerät aus einem bestimmten IP-Bereich zu einem Server zulassen soll und alle anderen dementsprechend blockt.
Beim Anwenden dieser Regeln wird aber auch die Verbindung zum Server geblockt.

Code: Alles auswählen

tab  Name		Prot.       Source				Destination		Action		LB-Policy	LB-Switchover  Linked      Prio   	Firewall-Rule  VPN-Rule   Stateful  Src-Tag    Rtg-tag  Comment                                                         
add  "ALLOW-DEVICE"	"ANY"       "%A195.150.7.2-195.150.7.250"	"%A70.5.99.110"		"ACCEPT"	""		No             No          1		Yes            No         Yes       0          0        ""
add  "DENY-ALL"		"ANY"       "%A195.150.7.2-195.150.7.250"	"%A0.0.0.0 %M0.0.0.0"	"REJECT"	""		No             No          0		Yes            No         Yes       0          0        ""

Um zu prüfen, dass die erste Regel auch greift, hatte ich ACCEPT und REJECT mal vertauscht, wodurch alles außer die Server-IP erlaubt wäre. Das funktionierte wie erwartet. An den IPs sollte es also nicht liegen. (Die Prioritäten hatte ich auch mal invertiert, wodurch der REJECT nicht mehr angwendet wird, aber auch das funktioniert wie erwartet. Die Prio sollte auch nicht das Problem sein.)

Meinem Verständnis nach sollte die DENY-ALL-Regel eigl. nicht mehr angewendet werden, wenn die erste Regel passt.

Kann mir jemand bitte erklären, was ich übersehe? Welches Regel-Setup benötige ich, um das zu erreichen, was ich am Anfang beschreibe?

[hotzenplotz]

Moin!

Was sagt denn der Firewall-Trace dazu?

Code: Alles auswählen

tr# firewall

Je nach Regelwerk auch mit Filter:

Code: Alles auswählen

tr# firewall @ 195.150.7

Grüße!

[backslash]

Hi hanabi

eigentlich sollten die Regel das machen, was du erhoffst: Ein Zugriff von einer der Adressen 195.150.7.2-195.150.7.250 auf den Server 70.5.99.110 solltre erlaubt sein und ein Ugriff von dieseb Adressen auf alle anderen sollte verboten werden

gib auf dm CLI mal "show filter" an um zu sehen welche Filter da erzeugt werden - Aber Achtung, das wird in deinem Fall unüberichtlich, weil aus dem Range 195.150.7.2-195.150.7.250 jede Menge Subnetze erzeugt werden - du solltest da am Besten einfach das passnede /24 Netz eintragen ("%A195.150.7.0 %M255.255.255.0")

BTW: eine "DENY-ALL" Regel sollte als Quelle auch "%A0.0.0.0 %M0.0.0.0" haben denn sonst ist es genau genommen keine deny-ALL Regel...

Gruß
Backslash

[hanabi]

Vielen Dank für eure Vorschläge.

Mit 'show filter' bekomme ich folgenden output bzgl. der genannten Regeln:

Code: Alles auswählen

> show filter             
Filter 00000001 from Rule ALLOW-DEVICE:
  Protocol: 0
  Src: 195.150.7.0/24 0-0
  Dst: 70.5.99.110/32 0-0
  use routing tag 0
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      accept
      send email to administrator
      
Filter 0000000c from Rule DENY-ALL:
  Protocol: 0
  Src: 195.150.7.0/24 0-0
  Dst: 0.0.0.0/0 0-0
  use routing tag 0
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      reject

Der trace zeigt mir bzgl. der IP 70.5.99.110 nichts an.
Wenn ich jedoch die DENY-ALL-Regel auf ACCEPT stelle, greift plötzlich die ALLOW-DEVICE-Regel.

Code: Alles auswählen

Packet matched rule ALLOW-DEVICE
DstIP: 70.5.99.110, SrcIP: 195.150.7.108, Len: 114, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 1194, SrcPort: 33177

send email to administrator
packet accepted

Habt ihr eine Idee, was es damit auf sich hat?

[backslash]

Hi hanabi,

das show filter zeigt die Regeln in der richtigen Reihenfolge. Beim Anlegen einer Session geht die Firewall nun von oben nach unten durch die Liste und der erste Match wird genommen - und das ist beim Zugeriffg aus dem Netz 195.150.7.x auf die IP 70.5.99.110 IMMER die Regel ALLOW-DEVICE - unabhängig davon, welche Action in der DENY-ALL Regel seht

Der Firewall-Trace zeigt nur etwas an, wenn eine neue Session angelegt werden und dabei die Aktion das Paket verwirft (DROP/REJECT) oder wenn die Aktion eine Benachtigung (Syslog/SNMP/Mail) enthält
Für bestehende Sessions bleibt er stumm. Um zu sehen, welche Regel bei bestehende Sessions gegriffen hat, mußt du im CLI unter /Status/IP-Router/Connection-List bzw. /Status/IP-Router/Open-Port-List nachschauen (Spalte "Filter-Rule")

Ob für ein bestimmtes Paket eine Drop/Reject- oder eine Accept-Aktion aufegeführt wurde siehst du nur am IP-Router-Trace - ggf. gefiltert auf die gewünchten Adressen. Der sagt die, ob das Paket weitergeleitet oder gefiltert wurde

Gruß
Backslash

[hanabi]

Der IP-Router Trace zeigt mir bei bestehenden Regeln, dass die Verbindung zu einem privaten Netz verworfen wird:

Code: Alles auswählen

[IP-Router] 2023/05/12 08:06:16,163
IP-Router Rx (LAN-1, 195.150.7.2-195.150.7.250, RtgTag: 3):
DstIP: 10.123.226.100, SrcIP: 195.150.7.108, Len: 60, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: TCP (6), DstPort: 30001, SrcPort: 51234, Flags: S
Seq: 4054545818, Ack: 0, Win: 64240, Len: 0
Option: Maximum segment size = 1460
Option: SACK permitted
Option: 08 = 5d 01 97 82 00 00 00 00
Option: NOP
Option: Window scale = 7 (multiply  by 128)
Network unreachable (no route) => Discard

Aber sobald ich die Deny-Regel von REJECT auf ACCEPT stelle, erhalte ich als erstes (die ALLOW-DEVICE Regel sollte hier eigentlich greifen wegen höherer Prio):

Code: Alles auswählen

[IP-Router] 2023/05/12 09:01:49,223
IP-Router Rx (LAN-1, 195.150.7.2-195.150.7.250, RtgTag: 3):
DstIP: 70.5.99.110, SrcIP: 195.150.7.108, Len: 114, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 1194, SrcPort: 60951
Route: WAN Tx (INTERNET)

Es scheint so, als ob das Gerät nur eine Verbindung aufbauen will, wenn die Deny-Regel nicht gesetzt ist, was unplausibel ist., weil das externe Gerät ja nicht die Filterregeln kennt.
Scheinbar gehen da noch vor dem tracing Pakete verloren?

[backslash]

Hi hanabi

hier hat aber nicht die Firewall-Regel zugeschlagen....

Network unreachable (no route) => Discard

im Kontext des Routing-Tags 3 ist das die Adresse 10.123.226.100 nicht erreichbar (show ipv4-fib zeigt die komplette Routing-Tabelle).

BTW: in deiner ALLOW-DEVICE-Regel soll doch die Acdresse 70.5.99.110 erreicht werden und nicht die 10.123.226.100...

also paßt der Trace nicht zu dem beschriebenen Problem...

Gruß
Backslash