Will Android am liebsten alle Ports offen haben?
-
Hallo,
Der Punkt den Teddy zu recht fragt ist: Warum willst du dir den Streß geben, jedes Fitzelchen für bspw. Android manuell freizugeben? Es wird immer was dazu kommen, sei es mit OS Updates, sei es wegen anderen Apps etc etc. Entweder will man, dass die Dinger gehen, oder du willst, dass sie nicht gehen (oder nur ein definierter Teilaspekt davon). Wenn sie gehen sollen, pack sie ggf. in ein eigenes Mobile Netz, erlaube den Zugriff ins Netz und gut.
Ja so habe ich es auch verstanden und an sich na ja wurde ich es auch so machen - ABER (und hier kommt ggf. das mit dem Wald und den Bäumen)
Wie mache ich das ohne so zu sagen gleich die ganze FW-Sache absurdum zu stellen?
Also mir ist nicht klar wie kann ich denn Geräten aus einem Netz erlauben kann "alles" zu machen ohne andere Netze zu gefährden? Wie meine Netze z.Z aussehen habe ich hier https://forum.pfsense.org/index.php?topic=124514.0 dargestellt. Nehmen wir doch an die Mobile Geräte kommen ins Netz 192.168.1.0. Wie verhindere ich dann, dass sie auch alles im Netz 192.168.2.0 machen können wenn ich in der Regel sowohl Ziel wie auch Ports auf "any" stelle?Hintergrund der Frage ist relativ einfach - ja das OS und Apps sollen tun was die tun müssen. Nur wenn z.B ein von diesen Geräten plötzlich von irgendwelchen "Bösen" geknackt wird, soll der/diejenigen nicht gleich auf alles Zugriff bekommen wenn so ein Gerät sich dann im WLAN befindet. Kontakt zu DHCP/DNS brauchen die aber logischerweise schon.
Womöglich irgendetwas übersehe ich … nur was weiß ich nicht :(
Tobi
-
Moin,
Du erstellst als erste Regel eine Blockregel auf dem Interface des Netzes 192.168.1.0 Source * Destination 192.168.2.0/24 und danach die erlaubten Verbindungen die dann auch any enthalten dürfen da ja die erste Regel bereits blockt und damit die Bearbeitung dieses Paketes beendet.
-teddy
-
Wie mache ich das ohne so zu sagen gleich die ganze FW-Sache absurdum zu stellen?
Inwiefern?
Also mir ist nicht klar wie kann ich denn Geräten aus einem Netz erlauben kann "alles" zu machen ohne andere Netze zu gefährden
Hat Teddy ja schon geschrieben, indem du nur Zugriff aufs Internet erlaubst, die anderen Internen Netze aber ausklammerst (bspw.)
Also einfach Block Rules über der Allow any(thing else) Regel einpacken.Am Einfachsten ein Alias mit allen internen Netzen der VLANs machen und das verbieten, dann den Rest erlauben.
-
Danke Teddy,
Du erstellst als erste Regel eine Blockregel auf dem Interface des Netzes 192.168.1.0 Source * Destination 192.168.2.0/24 und danach die erlaubten Verbindungen die dann auch any enthalten dürfen da ja die erste Regel bereits blockt und damit die Bearbeitung dieses Paketes beendet.
das heißt in meinem Fall
Netz 192.168.1.0 - Source * Destination DNS_IP Port 53 erlauben
Netz 192.168.1.0 - Source * Port 67-68 Destination * Port 67 erlauben
Dann alles andere zu 192.168.2.0/24 verbieten
Und any any erlauben.Richtig? Also DNS/DHCP stehen in Netz 192.168.2.0 und die sollen auch genutzt werden dürfen.
Tobi
-
Richtig? Also DNS/DHCP stehen in Netz 192.168.2.0 und die sollen auch genutzt werden dürfen.
Könntest du auch anders lösen, indem du den DHCP Relay bzw. DNS Forwarder auf der pfSense nutzt. Dann können die Clients diesen nutzen (bzw. könntest du gleich den DHCP auf der pfSense laufen lassen für das 1.er Netz) und dann hast du volle Isolation.
Grüße
-
Könntest du auch anders lösen, indem du den DHCP Relay bzw. DNS Forwarder auf der pfSense nutzt.
Da muss ich noch mal nachfragen. Vielleicht ist das Wissenslücke bei mir.
DHCP Relay habe ich bereits auf pfSense aktiv, sonst wurden die Klients aus anderen Netzen keine IP bekommen. Dabei geht es doch meines Wissens darum, dass die DHCP Requests in das Netz wo der DHCP Server steht weitergeleitet werden. Sonst gehen solche Broadcasts in eigenem Netz stecken. -
DHCP Relay habe ich bereits auf pfSense aktiv, sonst wurden die Klients aus anderen Netzen keine IP bekommen. Dabei geht es doch meines Wissens darum, dass die DHCP Requests in das Netz wo der DHCP Server steht weitergeleitet werden. Sonst gehen solche Broadcasts in eigenem Netz stecken.
Richtig, aber wofür? Natürlich kannst du zentral von bspw. einem Windows-AD Server DHCP machen, dann hast du ggf. die Clients in deiner AD Domain mit ihrer dynamischen IP. Fragt sich nur: wofür? Im Prinzip brauchen die Kisten nur eine IP, aber DNS? Eher weniger. Ergo wäre es auch völlig legitim, DHCP auf dem Interface der pfSense laufen zu lassen, an dem sich die Smartphones etc. anmelden und denen dann dort eine IP zuzuweisen. DNS Forwarder kann man hier auch konfigurieren und ggf. auf den/die AD Server zeigen einrichten, damit interne Dienste auch auf dem Telefon ausgeführt werden können sofern gewünscht, ansonsten macht man einfach nen Forwarder auf irgendeinen externen DNS Server. Damit kann man die Verbindung in so einem VLAN eingrenzen auf:
- DNS + DHCP sowie ggf. Ping muss auf die Interface IP der pfSense im Netz gehen
- Alles andere an internen IPs wird verboten
- alles an restlichen IPs erlaubt
Und fertig
-
Ich habe DNS und DHCP auf dem XenServer laufen. Damit habe ich (aus meiner Sicht) etwas was pflegeleichter ist als die Dienste auf einem Windows AD Controller zu laufen. Das die Handys da jetzt sich IP abholen tut mir jetzt nicht wirklich weh. kann bei dem Netz als DNS, Kisten von Telekom eintragen. Dadurch wurde sich auch der unnötiger Trafic nach innen verringern.
Rest liest sich doch plausibel an. Werde ich wohl so machen, wenn ich das "Problem" mit der Hardware gelöst habe. Quasi alles auf ein Schlag, damit ich hier keine Dauerbaustelle mir aufmache.
Tobi
-
Auf nem XenServer? Auf den Hypervisor selbst?! Also da würde ich ja viel machen, aber keine Clientdienste bereitstelle… kopfkratz Eigentlich will ich überhaupt nicht, dass irgendwer außer Management auf meine Xen Dom0 zugreifen kann...
-
Auf nem XenServer? Auf den Hypervisor selbst?
jupp. Ist so zu sagen durch diverse Umstände historisch gewachsen. Soll sich dann ändern wenn eben pfSense auf eigener Hardware läuft.
