Einfache Firewall Regel klappt nicht

Bob.Dig

@unique24 Ich meinte, nutzt Du einzelne Rechner zum Testen oder nur pfSense selbst?

unique24

achso, bin von meinem notebook über das WLAN (Management net) verbunden und pinge den Windows Server im Domaincontroller net

Ich muss 2 Aufgaben öfter umsetzen:

Komplett sperren von manchen Interface übergreifende Kommunikation
Teilweise erlauben auf gewisse IP´s vom anderen Interface zu kommunizieren

Bob.Dig

@unique24 Und die Rechner haben ihre jeweiligen eigenen IPs bekommen vom jeweiligen DHCP oder kann da was vermischt sein? Für mich als Laie sieht die Regel so eigentlich ok aus.

unique24

Ja, jeder hat seine IP und wird zugewiesen.

Ist die Regel im Normalfall gleich aktiv oder dauert das länger bis die greift?

So habe ich es mal:

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