Will Android am liebsten alle Ports offen haben?
-
Also Microsoft kommuniziert sehr viel mit dem www und Android ebenso. Cloud, sync, update und natürlich auch noch Userdaten weiter reichen.
Ich habe meine mobile devices in ein separates Netz gepackt und im LAN gibt es nur Linux was nicht ganz so kommunikativ ist wie Windows. Cloud gibt es auch nur auf einem internen NAS. -
Moin,
imho ist Deine Fragestellung nicht ganz eindeutig. Ich kenne es so das mit offene Ports eingehend gemeint ist, und da sollte tatsächlich nur das nötigste offen & natürlich gesichert sein. Die Destination Ports reguliere ich nur im Gastnetz weil ich dort auch nur wenige Dienste erlauben will.
Du musst auch noch unterscheiden ob das Betriebssystem raus will oder eine APP (Oder eine APP ein Aufruf übers BS absetzen will?)
Was versprichst Du dir von diesem Aufwand?-teddy
-
Hallo,
Du musst auch noch unterscheiden ob das Betriebssystem raus will oder eine APP (Oder eine APP ein Aufruf übers BS absetzen will?)
Was versprichst Du dir von diesem Aufwand?Vielleicht habe ich jetzt die Intention nicht verstanden. Selbstverständlich aus WWW geht nur das rein was ich brauche. Dennoch sehe ich irgendwie wenig Sinn für Geräte wie Android eine Regel nach dem Motto Source "Android" Port "*" Ziel " Port "" zu erstellen.
Bei Windows, Linux, OSX/ iOS habe ich immer irgendwo eine Liste der notwendigen Ports für Dienst der App gesehen. Bei Android (mag meine Einstellung zu dem Zeug auch dazu beigetragen haben) ist mir so etwas noch nie über den Weg gelaufen. Und wie ich bei dem System herausfinden kann ob das OS selbst oder irgendeine "berechtigte" App nach draußen will ist mir auch nicht klar.
Vielleicht sehe ich aber den s.g Wald vor lauter Bäume nicht.Tobi
-
Bei Windows, Linux, OSX/ iOS habe ich immer irgendwo eine Liste der notwendigen Ports für Dienst der App gesehen.
Wirklich? Also m.E. hängt jedes OS stark davon ab, was installiert ist. Klar als default brauchen die im Netz sehr wenig und meist reicht denen common web ports aus. Aber es gibt genug Subdienste und Services, die mit anderen Ports kommunizieren und das völlig legitim. Linux? Mac? Bspw. Schlüssel prüfen (GPG/PGP/etc) brauch eigene Ports, diverse andere Applikationen brauchen auch nach extern spezifische Ports etc. etc.
Genauso kannst du heute kaum definiert sagen, dass das "böses Android" ist, das ständig neue Ports will, es könnte auch schließlich nur eine App sein, die die Kommunikation will.Dazu kommt, dass Android wie jedes mobile OS ganz andere Anforderungen erfüllen soll und muss. Ständige Benachrichtungen der Apps, Push, Sync etc. was man auf einem Desktop in der Form meist gar nicht hat. Dass hierfür diverse Websockets, Ports etc. notwendig sind, versteht sich m.E. von selbst.
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. Wenn nicht - nunja dann machst du die Einschränkungen selbst. Aber bei jedem Klick nachzuschauen ob was geht oder nicht ist an der Stelle Irrsinn. Das käme den alten Personal Firewalls gleich, die im Lernmodus jede abgehende Verbindung angefragt haben - die meisten haben dann entweder deinstalliert oder einfach "allow all" irgendwann angeklickt. Weil man selbst einfach irgendwann nicht mehr weiß ob das jetzt noch erlaubt ist oder nicht und warum. Für ein einzelnes Gerät mag das noch gehen, aber für alle? Puh…
Grüße
-
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.
