fenris14
Goto Top

PfSense: Probleme mit Wirksamkeit von Rules

Hallo,

ich habe gerade ein Problem mit einem Setup für LAN-Rules. Dieses hatte ich vor einiger Zeit schon eingerichtet und auch erfolgreich getestet, doch leider musste ich heute feststellen das es nun wieder nicht funktioniert. Folgendes hatte ich mir gedacht:

Ich wollte den Clients in einem bestimmten Subnetz die Möglichkeit entziehen das Internet auf direktem Wege zu erreichen... also habe ich folgende zwei Rules erstellt...

Reject IPv4/TCP 10.0.1.0/24 * * 80 * none
Reject IPv4/TCP 10.0.1.0/24 * * 443 * none

Da gesamte Netz lautet 10.0.0.0/20. Damit die Clients dennoch im Internet surfen können, habe ich ein WPAD und einen Squid. Es soll alles über Port 3128 laufen. Das würde, nach meinem Verständnis, bedeuten das alle Rechner die nicht den Proxy konfiguriert haben, auch nicht ins Internet kommen. Oder?

Leider ist dies nicht der Fall, alle Clients könnten auch in Internet ohne den Proxy zu verwenden. Wo also liegt der Fehler? Rules die ganz oben angeordnet sind, genießen doch höhere Priorität, oder? Also wenn es oben geblockt wird und unten eine Rule die es reintheoretisch wieder aufheben würde, sollte es dennoch geblockt werden. Oder ist es anders herum?

Gruß

Content-Key: 326842

Url: https://administrator.de/contentid/326842

Ausgedruckt am: 19.03.2024 um 05:03 Uhr

Mitglied: ChriBo
ChriBo 19.01.2017 um 13:19:05 Uhr
Goto Top
Hi,
Es ist richtig: alle Regeln werden von oben nach unten abgearbeitet.
alle Clients könnten auch in Internet ohne den Proxy zu verwenden
Alle (aus dem 10.0.0.0/20er Netz), oder auch bzw nur die aus dem 10.0.1.0/24 er Netz ?

Gruß
CH
Mitglied: Fenris14
Fenris14 19.01.2017 um 13:22:19 Uhr
Goto Top
Nur die Clients die im 10.0.1.0/24-Netz sind, sollen gezwungen werden über den Proxy zu gehen. Diese Regel sieht aber irgendwie nicht.

Also von Oben nach unten? Bedeutet wenn ich oben blocke und unten passe, ist es letztendlich pass? Also müssten die Rules ans untere Ende der Liste?
Mitglied: LordXearo
Lösung LordXearo 19.01.2017 aktualisiert um 13:26:51 Uhr
Goto Top
Nein, die Regeln werden von oben nach unten abgearbeitet. Was zuerst zutrifft wird angewendet.

Wenn du oben was blockst und das gleiche unten wieder freigibst, macht das keinen Sinn.
Mitglied: Fenris14
Fenris14 19.01.2017 um 13:30:14 Uhr
Goto Top
Ok. Jetzt habe ich es gerallert und jetzt funktioniert es auch so wie es soll. Danke!
Mitglied: ChriBo
Lösung ChriBo 19.01.2017 um 13:30:48 Uhr
Goto Top
Die Erste zutreffende Regel von "oben" wird angewendet.
Die weiteren Regeln werden nicht mehr angewendet.
Dein Setup scheint im Ansatz richtig zu sein:
1. Reject IPv4/TCP 10.0.1.0/24 * * 80 * none
2. Reject IPv4/TCP 10.0.1.0/24 * * 443 * none
3. Allow IPv4/TCP 10.0.0.0/20 * * 80 * none
4. Allow IPv4/TCP 10.0.0.0/20 * * 80 * none

verbietet 10.0.01.0/24 Zugriff nach 0.0.0.0 auf HTTP(S)

enable mal logging für die allow Regeln

CH
Mitglied: Fenris14
Fenris14 19.01.2017 um 13:33:45 Uhr
Goto Top
Zitat von @ChriBo:

Die Erste zutreffende Regel von "oben" wird angewendet.
Die weiteren Regeln werden nicht mehr angewendet.
Dein Setup scheint im Ansatz richtig zu sein:
1. Reject IPv4/TCP 10.0.1.0/24 * * 80 * none
2. Reject IPv4/TCP 10.0.1.0/24 * * 443 * none
3. Allow IPv4/TCP 10.0.0.0/20 * * 80 * none
4. Allow IPv4/TCP 10.0.0.0/20 * * 80 * none

verbietet 10.0.01.0/24 Zugriff nach 0.0.0.0 auf HTTP(S)

enable mal logging für die allow Regeln

CH

Danke dir. Ich hatte noch eine Fehlkonfiguration drin, über den Reject-Regeln hatte ich noch eine Allow-Regel übersehen. Nun funktioniert es.
Mitglied: aqui
aqui 19.01.2017 aktualisiert um 18:19:45 Uhr
Goto Top
3. Allow IPv4/TCP 10.0.0.0/20 * * 80 * none
4. Allow IPv4/TCP 10.0.0.0/20 * * 80 * none
Ist ja auch ein bischen sinnfrei hier ! 2mal die gleiche Regel ist ja etwas überflüssig. Vermutlich aber ein Dreckfuhler und die 2te 80 sollte sicher eine 443 sein, oder ?!
So oder so wäre diese Regel auch unsinnig für das was der TO vorhat, sprich also nur Traffic für TCP 3128 passieren zu lassen aus einem /20er Netz.
Welchen tieferen Sinn sollte es dann haben gerade den Hostbereich von 10.0.1.1 bis 10.0.1.254 aus seinem gesamten /20er Netz rauszufiltern, das wäre ja Blödsinn !
Sein Host Adressbereich geht ja von 10.0.0.1 bis 10.0.15.254 !!
Wenn ein Endgerät also eine 10.0.2.1 hat oder irgendwas was nicht in dem o.a. Bereich liegt, kommt es ja trotzdem durch. Insofern ist der Filer mit der /24er Maske doch sinnfrei.
Richtig müsste es lauten:
Allow IPv4/TCP Source: 10.0.0.0/20, Port: any -> Desination: <ip_adresse_proxy>, Port: TCP 3128

Fertig !
Deny any any ist danach dann default so das kein explizites Deny mehr erforderlich ist.
Das lässt dann nur Connections aus dem 10.0.0.0 /20 Segment auf die Proxy IP mit Port TCP 3128 zu. Alles andere wird geblockt, natürlich auch inklusive TCP 80 und 443.
Sinnigerweise erlaubt man vorher auch noch DNS, damit auch Namensauflösungen klappen face-wink
Mitglied: Fenris14
Fenris14 20.01.2017 um 11:45:59 Uhr
Goto Top
Ich möchte aber nur das die Adressen aus dem Subnetz 10.0.1.0/24 nicht direkt ins Internet kommen. Ansonsten habe ich noch definiert welche Netze überhaupt von der Firewall gehändelt werden dürfen. Bedeutet, wenn sich beispielweise jemand eine Adresse aus meinetwegen 10.0.2.1 nimmt und dieses Netz aber nicht in meiner Allow-Rule (NAT oder Firewall)drin ist, dann geht da sowieso nichts.
Mitglied: aqui
aqui 20.01.2017 aktualisiert um 15:06:43 Uhr
Goto Top
Ich möchte aber nur das die Adressen aus dem Subnetz 10.0.1.0/24 nicht direkt ins Internet kommen.
So ein Subnetz hast du ja aber gar nicht auf deiner Firewall !!!
Du gibst ja selber oben an das dein LAN Segment einen /20er Prefix hat also 10.0.0.0/20. Das bedeutet dann einen Hostadressbereich von 10.0.0.1 bis 10.0.15.254 !!
Die /24er Regel oben filtert damit lediglich einen Host (Endgeräte) Adressbereich von 10.0.1.1 bis 10.0.1.254 heraus ignoriert aber alle anderen IP Endgeräte Adressen in deinem /20er Netzwerk Segment.
Folglich kommen also ALLE anderen IP Endadressen außer der .1.1-.254 Range weiterhin direkt ins Internet.
Es reicht also wenn sich jemand nur statisch selber eine IP aus dem freien Bereich gibt um dann am Proxy vorbei direkt ins Internet zu kommen.
Ist das so gewollt ?? Vermutlich wohl nicht, oder ?
Gut, wenn du die inverse Logik nimmst also eine ALLOW Rule einzig nur für diesen Hostbereich, dann kommen nur Hosts aus dem Bereich nach draussen bzw. auf den Proxy und alles andere ist geblockt, das ist natürlich richtig.
Es wird aber so aus dem Posting nicht so ganz klar was das genaue Ziel deiner Regeln sein soll.
Ein Netzwerk Segment bzw. L2 Collision Domain mit 4094 möglichen Hosts zu verwenden ist ja nun auch nicht gerade das gelbe vom Ei aber egal, wenns nun rennt ist alles gut... face-smile
Mitglied: Fenris14
Fenris14 23.01.2017 um 11:04:10 Uhr
Goto Top
Soweit ich das mit Pfsense getestet habe, konnte ich feststellen das man explizit Allow-Rules für die Netze machen muss damit diese überhaupt NAT (selbes gilt für Firewall) machen können. Solange man nicht explizit eine Regel in NAT für das Netz hinterlegt, geht garnichts. Ich habe auch tatsächlich nur für die Teil-Netze die ich verwende eine Allow-Rule und habe dann aber in der Firewall eine Block-Rule für das entsprechende Netz, da diese internet gehen sollen, aber eben über den Proxy.
Mitglied: aqui
aqui 23.01.2017 aktualisiert um 11:14:20 Uhr
Goto Top
Das ist schlicht falsch !
NAT hat nichts mit Allow Rules zu tun und vice versa. Erstmal ist es abhängig davon an welchem Port überhaupt NAT aktiviert ist.
Allow Rules kann man ja auch zwischen nicht NAT aktivierten Ports machen wie den LAN oder ggf. VLAN Ports. Richtig ist nur das auf jedem Port einer Firewall im Default Deny any any gilt und alles explizit verboten ist. Erlaubt ist nur was auch explizit mit Allow Regeln definiert ist. Klassischer Grundsatz einer Firewall....
Du würfelst hier also diverse Dinge im freien Fall völlig durcheinander.
Mitglied: Fenris14
Fenris14 23.01.2017 um 11:29:04 Uhr
Goto Top
Ja, Ok. Zumindest muss ich ebenfalls im NAT eine Regel erstellen, damit ich überhaupt ins Internet komme. Natürlich neben der auch benötigten Firewall Allow-Rule.