Einfache Firewall Regel klappt nicht

unique24

Sorry, das pingen scheint zu täuschen ... die Regel passt wohl, da ich den RDP nicht öffnen kann.

Pings werden jedoch beantwortet .. nach einiger zeit aber dann nicht mehr ... als wäre da irgendwo ein cache

Bob.Dig

@unique24 Versuche mal unter Diagnostics > States > Reset States den Reset the firewall state table.

Die entsprechende Regel unter Domaincontroller sollte tatsächlich überflüssig sein.
Und WAN net ist nicht das Internet.

unique24

Hallo,

danke ... ich schau mir das an.

Warum ist das Wan net nicht das Internet? Ich habe dort die öffentliche IP per DHCP zugewiesen bekommen.

Bob.Dig

@unique24 Ist so eine Falle in pfSense.
Damit ist tatsächlich nur das Netz gemeint, welches sich aus deiner WAN-IP und der dazugehörigen Netzmaske, zu sehen unter Status > Interfaces für WAN, ergibt. Für Internet muss dort also Sternchen stehen.

unique24

Du meinst statt WAN net soll ein Sternchen (also any) sein?

Ich war der Meinung das dann aus dem Netz alles erlaubt ist. Also auch Zugriff auf andere Netze.

Bob.Dig

@unique24 Nicht, wenn es vorher eine Block/Reject Regel gab. Wird ja von oben nach unten abgearbeitet und beim ersten Trefffer terminiert.

unique24

ah, denk nun hab ich es verstanden. Aber nur zum Schluss:

erste Zeile erlaubt zugriff auf den Domain Controller
dann 3 Zeilen damit keiner die pfSense aufruft. Ganz blocken kann ich ja nicht, da die pfSense auch DHCP ist
eine Zeile das die pfSense aufgerufen werden kann (DHCP .. aber die ist wohl überflüssig, durch die nächste zeile?)
letzte Zeile für Internet

Aber die letzte Zeile sagt ja, es darf überall hin? ... wenn ich verhindern möchte das eine Verbindung in ein anderes Netz möglich ist, muss ich diese erst setzen, oder?
dachte ich erlube "nur" Internet und der Rest wird sowieso blockiert ... aber das geht nicht?

Rico

RFC1918 Alias anlegen der alle privaten Netzbereiche beinhaltet und diesen dann in einer Firewall Regel verwenden.

-Rico

unique24

@Rico Danke .. aber ich muss einmal nachfragen: Du meinst ich erstelle eine Alias für alle erlaubten oder verbotenen Netzen?

Bob.Dig

@unique24 Du würdest mit so einem Alias z.B. alles verbieten. Davor legst Du dann noch die Ausnahmen an, z.B. DNS, etc.
Als letztes dann die Internet (any)-Erlauben-Regel.

Rico

Es geht beides. :-)
Der Alias selbst ist ja erst mal ohne Funktion, da werden lediglich IP Adressen, Netzbereiche, etc. zusammengefasst.

Anschließend kannst du den Alias in beliebigen Firewall Regeln verwenden.
Ich mach bei dem was du vor hast gerne "Invert Match", da man es dann in einer einzelnen Regel zusammenfassen kann:

Du kannst aber genauso über deiner SCHUELER net - any Regel ein Block (oder "besser" REJECT) auf RFC1918 machen.

-Rico

Bob.Dig

@unique24 Ich würde statt der drei Blocks besser eine erlauben Regel machen, nämlich für DNS, wenn Du das denn von der pfSense beziehen willst. Mehr brauchst Du eigentlich eh nicht von der Firewall. DHCP ist eh auf einem anderen Level und kommt immer durch.

Danach dann ein Block oder Reject auf RFC1918 und anschließend Internet allow any.
Damit bist Du dann maximal abgesichert im Schülernetz.

Irgendwo weiter oben dann noch deine Erlauben-Regel für Domaincontroller etc.

Rico

Brauchen die Schüler wirklich Vollzugriff auf den DC, also alle Ports? D.h. RDP ect. pp.?
Soll ja schon Würmchen gegeben haben die sich z.B. über RDP ausbreiten ;-) Gerade in solchen Netzwerken in denen du dich anscheinend bewegst würde ich wirklich nur das absolut nötigste frei machen, Rest alles dicht nageln.

-Rico

JeGr

@unique24 said in Einfache Firewall Regel klappt nicht:

Warum ist das Wan net nicht das Internet? Ich habe dort die öffentliche IP per DHCP zugewiesen bekommen.

@Bob-Dig said in Einfache Firewall Regel klappt nicht:

@unique24 Ist so eine Falle in pfSense.

Das ist keine Falle, das ist einfach ein Verständnisproblem, was begünstigt wird durch das dumme Verahlten anderer Hersteller, die Aliase für "Internet" oder Begrifflichkeiten wie DMZ in den Raum werfen, die eben einfach nicht stimmen. Für pfSense ist jedes XYZ_net das Netz, was dort auf dem Interface aufliegt. Ganz egal welches. Somit ist WAN_net nicht das Internet -> steht da ja auch nicht -> sondern schlicht das Netzsegment vom WAN. Nicht mehr und nicht weniger :)

Ich war der Meinung das dann aus dem Netz alles erlaubt ist. Also auch Zugriff auf andere Netze.

Genau aus DEM NETZ, nicht aus den Netzen/dem ganzen Internet. Das ist der Denkfehler.

Pings werden jedoch beantwortet .. nach einiger zeit aber dann nicht mehr ... als wäre da irgendwo ein cache

Unbedingt mal einlesen, was Stateful Filtering ist und was States sind. Dein Cache ist ein aktiver State. Solang der weiterhin aktiv bleibt wird der Ping weiter erlaubt bleiben. Ein Block ändert nichts daran solange der alte State noch aktiv ist. Umgekehrt funktioniert die Änderung von Block zu Pass natürlich sofort, da Blocks ja States ablehnen und bei Erlaubnis dann sofort einer erzeugt werden kann und dann gilt. Daher: block->pass geht sofort, pass->block geht nur sofort wenn alte States gelöscht werden oder man entsprechend den State Verfall abwartet.

JeGr

@Rico said in Einfache Firewall Regel klappt nicht:

Brauchen die Schüler wirklich Vollzugriff auf den DC, also alle Ports? D.h. RDP ect. pp.?
Soll ja schon Würmchen gegeben haben die sich z.B. über RDP ausbreiten ;-) Gerade in solchen Netzwerken in denen du dich anscheinend bewegst würde ich wirklich nur das absolut nötigste frei machen, Rest alles dicht nageln.

-Rico

Da stimme ich zu, die Regeln sind noch suboptimal, die sollten dringend angepasst werden. Kein Client braucht Vollzugriff zum DC. Mehrere Blocks auf "this firewall" sind unnötig, einfach nur erlauben, was gehen muss (DNS, NTP) statt umgekehrt zu blocken und alles zu erlauben. Falscher Ansatz an der Stelle :) Außerdem vor die letzte Regel noch nen RFC1918 Block rein damit das Segment gegen andere interne abgeriegelt ist. Und dann überlegen, ob die Schüler ausgehend überhaupt ALLES erlaubt bekommen. Ich würde da ggf. nochmal scharf nachdenken. Gerade wenn die eigentlich DNS intern machen sollen und ggf. das sogar noch gefiltert wird, ist es dann widersinnig, extern bspw. DNS zu erlauben.

Da sollte man sich dringend mal hinsetzen und ein sauberes Konzept haben/entwerfen bevor man einfach mal alles rauslässt und macht, sonst kann es schnell sein, dass man da die Hölle aufreißt ;)

unique24

Hallo,

ok danke .. das mit WAN und warum die Pings noch liefen, nachdem ich den Block gesetzt hatte ist klar.

Wenn ihr so nett wärt, mir noch ein paar Verständnisfragen zu beantworten:

hinter jeder Rule liegt ein "deny all"? Wenn ich AUS dem eigenen Netz1 die Verbindung in Netz2 erlaube, ist Netz3 automatisch geblockt?
Dadurch wäre es einfacher alle Regeln auf die ausgehenden Traffic anzuwenden
Wenn ich am Ende eine * * Rule setze, erlaube ich damit automatisch ins WAN Netz und das dahinter liegende Internet, sofern ich das WAN nicht zuvor geblockt habe
Wenn ich vom Netz1 aus, nur eine IP im Netz2 freigeben möchte, muss ich zuerst die "Allow IP" sezten (denn dadurch werden keine weiteren Regeln mehr geprüft) und danach das ganze Netz2 ja noch "blocken", richtig?
selbes wie oben für IP/Port .. danach muss ich erst das ganze Netz blocken
wenn ich vom Netz1 den Zugriff auf Netz2 komplett blocke, aber es kommt eine Kommunikation vom Netz2 ins Netz1 ... was passiert mit den Antwort Paketen. Diese sind ja wieder vom Netz1 nach Netz2. Die Kommunikation wurde aber aus dem Netz2 initiert und das klappt dann wohl mit den States

Bob.Dig

Moin,

Nicht hinter jeden Rule aber am Ende aller Rules auf einem Interface könnte man das bejahen.
Keine Ahnung.
Nope, damit erlaubst Du in alle Netze! Du musst diese Regel daher einschränken (Beispiel siehe weiter unten) oder vorher Blockregeln erstellen.
Klingt vernünftig. Das gilt insbesondere, wenn noch eine any erlauben Regel folgt wegen Internet. Ansonsten wäre der zweite Schritt auch entbehrlich.
Jo.
Jau, denke ich zumindest. Lerne noch jeden Tag was neues zu pfSense.

Auch für dich sicher interessant ist der hier schon erwähnte RFC1918 Alias, den Du erst mal selbst anlegen musst. Damit kannst du z.B. die Any-Regel auf nur das Internet einschränken. Gilt natürlich nur für IPv4...

Hier ein Beispiel, das Gateway kannst Du ignorieren:

Die gezeigte Regel erlaubt alles, was nicht(!) lokal ist... also quasi ausschließlich das Internet und eben nicht alles.

JeGr

Wenn ihr so nett wärt, mir noch ein paar Verständnisfragen zu beantworten:

natürlich!

hinter jeder Rule liegt ein "deny all"? Wenn ich AUS dem eigenen Netz1 die Verbindung in Netz2 erlaube, ist Netz3 automatisch geblockt?

Nicht ganz. Es ist generell ein "block any any" auf jedem Interface stehend aktiv. Daher: alles was nicht explizit in Form von Regeln erlaubt wird, wird am Ende durch die "block any" Regel weggeworfen. Sieht man auch schön in den Firewall Logs, dass der meiste Kram wegen "default block rule" weggefiltert wird.

Dadurch wäre es einfacher alle Regeln auf die ausgehenden Traffic anzuwenden

Der Logik kann ich nicht folgen. Ausgehender Traffic ist überhaupt nicht auf den Interfaces filterbar. Zumindest nicht das, was man als ausgehend bezeichnet. Ausgehend wäre den Verkehr nicht eingehend beim Ankommen auf dem Interface bspw. LAN zu erlauben/blocken, sondern erst abgehend auf dem WAN bspw. bevor er ins Internet geht. Das ist so ohne weiteres nicht möglich. Technisch ist es das mit Floating Regeln, aber das willst du nicht. Das Filterprinzip der pfSense und generell von pf ist, den Traffic dort zu filtern, wo er DAS ERSTE MAL die Firewall betritt. Dort wird gefiltert, erlaubt oder verworfen, und dann weitergemacht. Hat man sich an den letzten Satz gewöhnt, ist das Regel erstellen auch recht einfach zu durchdenken.

Wenn ich am Ende eine * * Rule setze, erlaube ich damit automatisch ins WAN Netz und das dahinter liegende Internet, sofern ich das WAN nicht zuvor geblockt habe

Vielleicht wäre es einfacher, wenn du genauer schreiben würdest, was eine * * Rule ist. Ich gehe mal von "source any, destination any" aus? Wenn ja erlaubt das schlichtweg alles. Alles - egal ob legitim oder nicht darf dann vom Interface, auf dem die Regel liegt überall hin. Egal wo. Intern, extern egal. Sowas will man eigentlich nicht. Source sollte meistens das "XY_net" sein, also bspw. LAN_net wenn wir von innen nach außen oder innen nach innen reden. Nur auf dem WAN sind Regeln meistens von "any", ansonsten sollte das immer beschränkt sein, schon allein um Miskonfigurationen auszuschließen.

Wenn ich vom Netz1 aus, nur eine IP im Netz2 freigeben möchte, muss ich zuerst die "Allow IP" sezten (denn dadurch werden keine weiteren Regeln mehr geprüft) und danach das ganze Netz2 ja noch "blocken", richtig?

Das ist richtig. Erst die einzelne IP erlauben, dann das komplette Netz rejecten (blocken wäre intern hart, ich würde rejecten damit die Clients auch ne Antwort bekommen). Die zweite Regel ist aber wie Bob sagt nur nötig, wenn danach noch eine größere Allow Regel kommt. Wenn danach nichts mehr kommt, würde eh die block any Regel greifen.

selbes wie oben für IP/Port .. danach muss ich erst das ganze Netz blocken

Mutmaßlich ja, am konkreten Beispiel kann man das sicher besser erläutern.

wenn ich vom Netz1 den Zugriff auf Netz2 komplett blocke, aber es kommt eine Kommunikation vom Netz2 ins Netz1 ... was passiert mit den Antwort Paketen. Diese sind ja wieder vom Netz1 nach Netz2. Die Kommunikation wurde aber aus dem Netz2 initiert und das klappt dann wohl mit den States

Die Firewall ist "stateful", das solltest du ggf. nachlesen. Das heißt, dass bei Zugriff von N2->N1 - sofern die Verbindung per Regel erlaubt ist - ein State erzeugt wird, der diesen Traffic (hin & zurück) erlaubt. Es wird immer nur der Verbindungsaufbau gefiltert. Nicht der danach folgende Verkehr (und Rückverkehr), daher ist der Rücktraffic für eine stateful Firewall immer irrelevant da durch den State implizit gestattet. Bei Stateless Filtering, was viele sog. L3 Switche anbieten, ist genau das ein Problem, dort muss gezielt bei jeder Freigabe der Hin- und Rückverkehr konkret angegeben werden, ansonsten wird geblockt. Da das recht schnell komplex ausartet, will man das eigentlich nicht ;)

Ansonsten kann ich nur auf den Freitag hinweisen: https://forum.netgate.com/post/932803
Vielleicht ist das ja mal was für dich zum Frage in den Raum werfen :)

Grüße