12
PFSense 2.3.2 Captive Port, Administrator Zugriffsteuerung sperren
Hallo,
ich habe auf meiner PFSense ein Captive Portal laufen. Nun möchte ich den Administrator Zugriff aus dem Gästelan sperren, natürlich soll die Captive Funktion weiter laufen.
Im Beitrag von aqui ist folgender Hinweis:
Captive Portal von Meister aqui
•sämtlichen Traffic auf den Router geblockt?
Leider habe ich die Umsetzung nicht verstanden, bzw. wie und wo blocke ich den Zugriff auf die Firewall/Router. Erst blocken und dann erlauben?
Ich bin mir nicht sicher, ob mir mein toller "Vlan Switch" in die Quere kommt. Der braucht manchmal einen Neustart. Ich hatte ich gedacht, dass ich schon alle Möglichkeiten durch gespielt habe.
Danke! der Horst
ich habe auf meiner PFSense ein Captive Portal laufen. Nun möchte ich den Administrator Zugriff aus dem Gästelan sperren, natürlich soll die Captive Funktion weiter laufen.
Im Beitrag von aqui ist folgender Hinweis:
Captive Portal von Meister aqui
•sämtlichen Traffic auf den Router geblockt?
Leider habe ich die Umsetzung nicht verstanden, bzw. wie und wo blocke ich den Zugriff auf die Firewall/Router. Erst blocken und dann erlauben?
Ich bin mir nicht sicher, ob mir mein toller "Vlan Switch" in die Quere kommt. Der braucht manchmal einen Neustart. Ich hatte ich gedacht, dass ich schon alle Möglichkeiten durch gespielt habe.
Danke! der Horst
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 317179
Url: https://administrator.de/contentid/317179
Printed on: April 27, 2024 at 02:04 o'clock
12 Comments
Latest comment
Hi,
Meine Empfehlung für das Gastnetz (Regeln werden von oben nach unten abgearbeitet bis eine Regel zutrifft):
Regel 1: verbiete alles von Source all nach LAN
Regel 2: erlaube ICMP von Source Gastnetz auf auf Firewall-IP Gastnetz
Regel 3: erlaube 53/UDP (DS) von Source Gastnetz auf auf Firewall-IP Gastnetz
Regel 4: erlaube 8000/TCP von Source Gastnetz auf auf Firewall-IP Gastnetz
Regel 5: verbiete alles von Source all nach Firewall-IP Gastnetz (enable logging)
Regel 6: erlaube alles von Source Gastnetz nach alles (bzw. nur das was du ins "Internet" erlauben willst.
ggf. mußt du noch die DHCP Ports nach Regel 2 einstellen, kannst du anhand der Logs von Regel 5 erkennen.
Gruß
CH
Meine Empfehlung für das Gastnetz (Regeln werden von oben nach unten abgearbeitet bis eine Regel zutrifft):
Regel 1: verbiete alles von Source all nach LAN
Regel 2: erlaube ICMP von Source Gastnetz auf auf Firewall-IP Gastnetz
Regel 3: erlaube 53/UDP (DS) von Source Gastnetz auf auf Firewall-IP Gastnetz
Regel 4: erlaube 8000/TCP von Source Gastnetz auf auf Firewall-IP Gastnetz
Regel 5: verbiete alles von Source all nach Firewall-IP Gastnetz (enable logging)
Regel 6: erlaube alles von Source Gastnetz nach alles (bzw. nur das was du ins "Internet" erlauben willst.
ggf. mußt du noch die DHCP Ports nach Regel 2 einstellen, kannst du anhand der Logs von Regel 5 erkennen.
Gruß
CH
Schalte ganz einfach die Anti Lockout Rule in den Advanced Settings aus und definiere von deinem Trusted Interface (das von dem du Konfig Zugang haben willst) eine entsprechende Firewall Rule indem du HTTP und HTTPS auf den pfSense Port erlaubst.
Beim Gast Interface machst du es genau andersrum, dort blockst du jeglichen Traffic auf das dortige pfSense Interface.
Aber aufpassen das die syntaktisch korrekt ist und du nicht den (Zugangs) Ast absägst auf dem du selber sitzt
Ein paar Anmerkungen zu den o.a. Regeln vom Kollegen Christoph-Bochum:
1.)
Das könnte man besser modifizieren indem Reply Packets mit gesetztem ACK Bit aus dem Gastnetz ins LAN erlaubt sind. Das blockt dann den Zugang von Gästen ins LAN erlaubt aber die remote Administration von APs oder anderen Dingen im Gastnetz aus dem Trusted LAN sofern deren Mac Adressen natürlich beim CP ausgenommen sind.
Macht aber eben nur Sinn wenn man die Device dort remote administrieren will. Wer ganz sicher gehen will lässt sie weg, muss dann aber APs usw. immer aus dem Gastnetz selber administrieren.
2.)
Sollte man besser NICHT machen. Gäste sollen nicht auch noch per Ping die Firewall pingen können. Es reicht wenn sie ins Internet pingen können. Also alles IP mäßig auf die pfSense IP als Destination im Gastinterface blocken.
3.)
DNS verwendet UDP und TCP ! Man sollte deshalb niemals DNS 53 nur auf UDP beschränken um DNS Probleme zu minimieren.
4.)
Dort sollte man eine Portrange nehmen von TCP 8000-8002 da das CP diese Ports für die Portalseite verwendet.
5.)
Diese Regel ist vollkommen wirkungslos und damit unsinnig ! Sorry, aber lokaler Gastenetz IP Traffic untereinander wir rein lokal per Layer 2 abgewickelt, damit hat die Firewall nichts zu tun !
Beim Gast Interface machst du es genau andersrum, dort blockst du jeglichen Traffic auf das dortige pfSense Interface.
Aber aufpassen das die syntaktisch korrekt ist und du nicht den (Zugangs) Ast absägst auf dem du selber sitzt
Ein paar Anmerkungen zu den o.a. Regeln vom Kollegen Christoph-Bochum:
1.)
Das könnte man besser modifizieren indem Reply Packets mit gesetztem ACK Bit aus dem Gastnetz ins LAN erlaubt sind. Das blockt dann den Zugang von Gästen ins LAN erlaubt aber die remote Administration von APs oder anderen Dingen im Gastnetz aus dem Trusted LAN sofern deren Mac Adressen natürlich beim CP ausgenommen sind.
Macht aber eben nur Sinn wenn man die Device dort remote administrieren will. Wer ganz sicher gehen will lässt sie weg, muss dann aber APs usw. immer aus dem Gastnetz selber administrieren.
2.)
Sollte man besser NICHT machen. Gäste sollen nicht auch noch per Ping die Firewall pingen können. Es reicht wenn sie ins Internet pingen können. Also alles IP mäßig auf die pfSense IP als Destination im Gastinterface blocken.
3.)
DNS verwendet UDP und TCP ! Man sollte deshalb niemals DNS 53 nur auf UDP beschränken um DNS Probleme zu minimieren.
4.)
Dort sollte man eine Portrange nehmen von TCP 8000-8002 da das CP diese Ports für die Portalseite verwendet.
5.)
Diese Regel ist vollkommen wirkungslos und damit unsinnig ! Sorry, aber lokaler Gastenetz IP Traffic untereinander wir rein lokal per Layer 2 abgewickelt, damit hat die Firewall nichts zu tun !
Hallo und ein schönes Wochenende,
also meine 2.3.2 PFsense hat das bei der Installation für den "normalen Lan Port schon gleich so gemacht.
Also Anti Log ist schon unchecked und aus dem Lan alles erlaubt, somit kann ich keinen Blödsinn mehr machen, die PFsense sollte immer vom Lan aus erreichbar bleiben, solange ich an diesen Firewall Regeln nicht mehr rumschraube??? Ist das richtig?
So dann blocke ich GastWlan alles und hebe 53 über UDP und TCP, TCP 8000-8002 wieder auf. Der Eintrag Firewall ist hier nicht richtig? Sondern ich muss auf das Lan gehen?
Danke!! der Horst
also meine 2.3.2 PFsense hat das bei der Installation für den "normalen Lan Port schon gleich so gemacht.
Also Anti Log ist schon unchecked und aus dem Lan alles erlaubt, somit kann ich keinen Blödsinn mehr machen, die PFsense sollte immer vom Lan aus erreichbar bleiben, solange ich an diesen Firewall Regeln nicht mehr rumschraube??? Ist das richtig?
So dann blocke ich GastWlan alles und hebe 53 über UDP und TCP, TCP 8000-8002 wieder auf. Der Eintrag Firewall ist hier nicht richtig? Sondern ich muss auf das Lan gehen?
Danke!! der Horst
Schräg? das eine Bild ist bei mir doppelt und ich kann das nicht entfernen??
Ganz vergessen, einen Proxy betreibe ich auch noch. Das muss man hier nicht berücksichtigen??
Ganz vergessen, einen Proxy betreibe ich auch noch. Das muss man hier nicht berücksichtigen??
Also so?
Ist das richtig?
Yepp, das ist so richtig !dann blocke ich GastWlan alles und hebe 53 über UDP und TCP, TCP 8000-8002 wieder auf.
Ahem...das ist jetzt etwas wirr, sorry !Du blockst alles was auf die IP Adresse der pfSense im Gast WLAN will (Destination: GASTWLAN_address !)
Vorher musst du aber noch DNS mit TCP und UDP erlauben und auch die Portalseite ansonsten sperrst du das aus. Denk dran "First match wins !" bei den FW Regeln !
Die von dir oben im ersten Screenshot gezeigte Schrotschussregel, erlaube alles auf dem Gast WLAN Port ist natürlich tödlich. Damit erlaubts du generell alles auf dem Port und da das dann matched für alle Pakete hier werden die folgenden Regeln dort gar NICHT mehr abgearbeitet !!!
Das wäre dann natürlich tödlich fürs Gast WLAN. Da kannst du die Firewall dann auch gleich ganz weglassen.
Vermutlich ist das nur eine Testregel, oder ???
Schräg? das eine Bild ist bei mir doppelt und ich kann das nicht entfernen??
Bahnhof ? Ägypten ?Also so?
Nein, leider nicht !!!Wieder genau der gleiche Denkfehler wie oben. !
Du blockst in der ersten Regel ALLES was auf die IP Adresse des GastWLAN Ports zugreifen will. Das matched dann natürlich auch für DNS und die Portalseite.
Die beiden dann folgenden Regeln die es wieder erlauben werden somit gar nicht mehr abgearbeitet (First match wins !) und sind damit überflüssig. Bzw. was dann passiert ist das DNS und Portalseite geblockt werden !
Das willst du ja nicht. Denk immer an die Logik und wie sich IP Pakete im netz bewegen mit ihren Source und Destination Adressen !
Fazit: Erst das erlauben, dann alles auf die IP blocken
Hallo Aqui,
Hmm.
Meine Kommentare zu deinen Kommentaren:
1.) massiver Denkfehler deinerseits: Zugriff auf z.B. APs im Gästenetz aus dem LAN wird nicht durch Regeln auf dem Interface des Gästenetzes, sondern mit Regeln auf dem Lan Interface.
2.) Imho Doch ! ICMP auf das Gateway zu erlauben zählt für mich als Standard. Vereinfacht im Fehlerfall die Fehlersuche. Wenn ICMP auf das Interface ein Sicherheitsproblem für die pfSense sein sollte (Dos Buffer overflow etc.), sollte man sich generell überlegen ob pfSense die richtige Wahl ist.
3.) OK. In Realität wird aber (fast) nur UDP verwendet, bzw mir ist kein Fehler bei Nichtvorhandensein von TCP bekannt.
4.) OK
5.) Du hast den Sinn dieser Regel nicht verstanden.
Diese Regel soll nicht den Traffic im Gastnetz selber einschränken bzw. loggen.
Ohne diese Regel wird natürlich aller Zugriff auf die Firewall der nicht explizit erlaubt ist nicht erlaubt (geblockt), nur wird er nicht geloggt.
Dies will ich aber durch diese Regel erzwingen.
Gruß
CH
Hmm.
Meine Kommentare zu deinen Kommentaren:
1.) massiver Denkfehler deinerseits: Zugriff auf z.B. APs im Gästenetz aus dem LAN wird nicht durch Regeln auf dem Interface des Gästenetzes, sondern mit Regeln auf dem Lan Interface.
2.) Imho Doch ! ICMP auf das Gateway zu erlauben zählt für mich als Standard. Vereinfacht im Fehlerfall die Fehlersuche. Wenn ICMP auf das Interface ein Sicherheitsproblem für die pfSense sein sollte (Dos Buffer overflow etc.), sollte man sich generell überlegen ob pfSense die richtige Wahl ist.
3.) OK. In Realität wird aber (fast) nur UDP verwendet, bzw mir ist kein Fehler bei Nichtvorhandensein von TCP bekannt.
4.) OK
5.) Du hast den Sinn dieser Regel nicht verstanden.
Diese Regel soll nicht den Traffic im Gastnetz selber einschränken bzw. loggen.
Ohne diese Regel wird natürlich aller Zugriff auf die Firewall der nicht explizit erlaubt ist nicht erlaubt (geblockt), nur wird er nicht geloggt.
Dies will ich aber durch diese Regel erzwingen.
Gruß
CH
Hallo,
so mein letzter blödsinniger Einfall für heute
Gegessen habe ich schon, mir nochmals Gedanken gemacht, von oben nach unten die Firewall Regeln, welche Quelle zu welchen Ziel....
So was brauche ich von Gästewlan: hier müssen die Ports 8000-8002TCP und 53 TCP/UDP erreichbar sein. Das sollte dann hoffentlich richtig sein.
So danach will der Nutzer doch nur noch ins Internet, also auf die WAN Schnittstelle? Da bräuchte man für Gastnetz doch nur von Port 80 und 443??
Wenn ich nur das erlaube und der Proxy sowieso auf 80 hört, dann hätte ich alles?? Ich müsste dann nichts verbieten, da ich nur sehr wenig erlaube?
man ist das schwierig
Das mit dem AP habe ich in Euer Diskussion nicht verstanden. Mein AP hängt an einem untagged Port, somit ist er natürlich vom Gastnetz aus erreichbar... das könnte ich vorerst akzeptieren,
Danke!!
so mein letzter blödsinniger Einfall für heute
Gegessen habe ich schon, mir nochmals Gedanken gemacht, von oben nach unten die Firewall Regeln, welche Quelle zu welchen Ziel....
So was brauche ich von Gästewlan: hier müssen die Ports 8000-8002TCP und 53 TCP/UDP erreichbar sein. Das sollte dann hoffentlich richtig sein.
So danach will der Nutzer doch nur noch ins Internet, also auf die WAN Schnittstelle? Da bräuchte man für Gastnetz doch nur von Port 80 und 443??
Wenn ich nur das erlaube und der Proxy sowieso auf 80 hört, dann hätte ich alles?? Ich müsste dann nichts verbieten, da ich nur sehr wenig erlaube?
man ist das schwierig
Das mit dem AP habe ich in Euer Diskussion nicht verstanden. Mein AP hängt an einem untagged Port, somit ist er natürlich vom Gastnetz aus erreichbar... das könnte ich vorerst akzeptieren,
Danke!!
geht natürlich nicht.... Klasse Einfall von mir. Portal ist erreichbar, aber dann geht es nachher nicht ins Internet....
Ok,
ich habe das vorerst so gemacht.
ICMP habe ich nicht aktiviert. Wenn Ihr Euch einig seit, dann ändere ich das zum Optimum ab.
Vielen Dank an Euch!!
ich habe das vorerst so gemacht.
ICMP habe ich nicht aktiviert. Wenn Ihr Euch einig seit, dann ändere ich das zum Optimum ab.
Vielen Dank an Euch!!
Was jetzt leider nicht mehr geht, sind die Fehlermeldungen vom Proxy Filter.
Der gibt die Meldung natürlich über 192.168.1.1 raus, die haben wir jetzt ja endlich ausgesperrt.
Somit müsste man die Fehlermeldung jetzt umleiten, wobei ich habe keinen eigenen Webserver im Netz laufen.
Daher muss da jetzt vermutlich mit Leben.
der Horst
Der gibt die Meldung natürlich über 192.168.1.1 raus, die haben wir jetzt ja endlich ausgesperrt.
Somit müsste man die Fehlermeldung jetzt umleiten, wobei ich habe keinen eigenen Webserver im Netz laufen.
Daher muss da jetzt vermutlich mit Leben.
der Horst
@christoph-bochum
1.)
Meine Erachtens Jein ! Auch du erliegst hier einem partiellen Denkfehler.
Es ist richtig was du sagst, du musst dann aber auf dem LAN dediziert ein Permit auf die Management IPs durchlassen.
Eigentlich überflüssig denn es existiert ja schon ein Permit any any dort, denn der Admin darf ja überall hin.
Folglich muss ich auf dem LAN Interface eigentlich nichts konfigurieren.
Die entscheidenen Regeln sind auf dem GastInterface denn um das ganz wasserdicht zu machen lässt man dort diese dedizierten Host IPs mit gesetztem ACK Bit passieren ins LAN.
Das blockt alles was so ins LAN will und falls jemand diese Management IP kapert kann er keine Session ins LAN aufbauen da er kein ACK Bit gesetzt hat.
Das wäre wasserdicht und involviert eigentlich nur eine Rule auf dem Gastnetz inbound.
Wie hättest du es denn nur mit dem LAN Interface wasserdicht gelöst ??
2.)
Das ist sicher wie immer Ansichtssache. M.E. sollte niemand mit einem Ping Scan interne Management IPs auskundschaften können. Das animiert gerade in einem offenen WLAN nur und zeigt Bösewichten explizit das da was Aktives ist was sich lohnt anzugreifen.
Wer testen will kann auch auf die 8.8.8.8 oder anderswo in die weite Welt Ping Tests oder Traceroutes machen.
5.)
Gut, da hast du Recht. Die Frage der Sinnhaftigkeit muss man hier aber stellen. Sich permanent alle Verfehlungen anzusehen müllt eher nur das Log voll und birgt die Gefahr bei einem Angriff die Performance runterzuziehen.
Kann man machen wenn man es temporär beobachten will. Auf Dauer würd ichs nicht machen. Auch hier Ansichtssache
@horstvogel
Hier spielt dir deine IP Adressdenke wieder einen Streich !! Wenn du auf www.administrator.de gehst auf dem Gast LAN steht in der Destination IP doch niemals die pfSense IP Adresse !
Du willst doch zu www.administrator.deund der Host hat die Destination IP 82.149.225.21. Diese IP Adresse steht im IP Paket als Ziel logischerweise !
Also musst du diese eintragen in der FW Regel !
Damit du nun aber nicht zig Millionen Webseiten eintragen musst die deine Gäste irgendwann mal besuchen gibst du generell den Zugriff mit
PASS, Source: Gast_LAN_net, Port: any, Destination: any, Port TCP 80 (HTTP) //
frei !
Das wiederholst du dann noch im Gast Netz für die Ports
HTTPS = TCP 443
und damit die Gäste auch emailen können
SMTP = TCP 25
SMTPS = TCP 465 und TCP 587
POP = TCP 110
Secure POP = TCP 995
IMAP = TCP 143
IMAPS = TCP 993
Damit können deine Gäste dann erstmal Surfen und Emailen fürs erste !
Wenn du pfiffig bist, dann trägst du das nicht alles einzeln ein sondern gehst du auf die pfSense unter Alias und legst dir für die Gäste Ports eine Alias Liste an. Damit wird deine Regel dann wieder übersichtlich.
Mehr sollen sie ja nicht dürfen, oder ??
Das ist aber die Kür und kommt später...
1.)
Meine Erachtens Jein ! Auch du erliegst hier einem partiellen Denkfehler.
Es ist richtig was du sagst, du musst dann aber auf dem LAN dediziert ein Permit auf die Management IPs durchlassen.
Eigentlich überflüssig denn es existiert ja schon ein Permit any any dort, denn der Admin darf ja überall hin.
Folglich muss ich auf dem LAN Interface eigentlich nichts konfigurieren.
Die entscheidenen Regeln sind auf dem GastInterface denn um das ganz wasserdicht zu machen lässt man dort diese dedizierten Host IPs mit gesetztem ACK Bit passieren ins LAN.
Das blockt alles was so ins LAN will und falls jemand diese Management IP kapert kann er keine Session ins LAN aufbauen da er kein ACK Bit gesetzt hat.
Das wäre wasserdicht und involviert eigentlich nur eine Rule auf dem Gastnetz inbound.
Wie hättest du es denn nur mit dem LAN Interface wasserdicht gelöst ??
2.)
Das ist sicher wie immer Ansichtssache. M.E. sollte niemand mit einem Ping Scan interne Management IPs auskundschaften können. Das animiert gerade in einem offenen WLAN nur und zeigt Bösewichten explizit das da was Aktives ist was sich lohnt anzugreifen.
Wer testen will kann auch auf die 8.8.8.8 oder anderswo in die weite Welt Ping Tests oder Traceroutes machen.
5.)
Gut, da hast du Recht. Die Frage der Sinnhaftigkeit muss man hier aber stellen. Sich permanent alle Verfehlungen anzusehen müllt eher nur das Log voll und birgt die Gefahr bei einem Angriff die Performance runterzuziehen.
Kann man machen wenn man es temporär beobachten will. Auf Dauer würd ichs nicht machen. Auch hier Ansichtssache
@horstvogel
So danach will der Nutzer doch nur noch ins Internet, also auf die WAN Schnittstelle?
Nein !Hier spielt dir deine IP Adressdenke wieder einen Streich !! Wenn du auf www.administrator.de gehst auf dem Gast LAN steht in der Destination IP doch niemals die pfSense IP Adresse !
Du willst doch zu www.administrator.deund der Host hat die Destination IP 82.149.225.21. Diese IP Adresse steht im IP Paket als Ziel logischerweise !
Also musst du diese eintragen in der FW Regel !
Damit du nun aber nicht zig Millionen Webseiten eintragen musst die deine Gäste irgendwann mal besuchen gibst du generell den Zugriff mit
PASS, Source: Gast_LAN_net, Port: any, Destination: any, Port TCP 80 (HTTP) //
frei !
Das wiederholst du dann noch im Gast Netz für die Ports
HTTPS = TCP 443
und damit die Gäste auch emailen können
SMTP = TCP 25
SMTPS = TCP 465 und TCP 587
POP = TCP 110
Secure POP = TCP 995
IMAP = TCP 143
IMAPS = TCP 993
Damit können deine Gäste dann erstmal Surfen und Emailen fürs erste !
Wenn du pfiffig bist, dann trägst du das nicht alles einzeln ein sondern gehst du auf die pfSense unter Alias und legst dir für die Gäste Ports eine Alias Liste an. Damit wird deine Regel dann wieder übersichtlich.
Mehr sollen sie ja nicht dürfen, oder ??
Mein AP hängt an einem untagged Port, somit ist er natürlich vom Gastnetz aus erreichbar... das könnte ich vorerst akzeptieren,
Die Diskussion ging darum ihn auch wasserdicht von deinem LAN Netz erreichbar zu machen ohne das die Gäste in dein Netz kommen. Erspart dir das Umklemmen des PC ins Gastnetz zum Konfigurieren. Das ist aber die Kür und kommt später...