Internet Zugang für Amazon Kindle blockieren
-
@jegr Hallöchen
Vielen Dank für Deine ausfürhliche Antwort. Ich habe jetzt die egel folgendermassen geändert, denke aber das es noch nicht die von Dir vorgeschlagene Lösung ist.
Vielleicht ist es auch gut, wenn ich meinen kompletten Aufbau und mein Ziel beschreibe - das erklärt auch, warum der Kindle nicht ins Internet darf/soll.
Also, ich betreibe einen NextCloud Server, welcher per öffentlicher IP Adresse erreichbar ist. Die pfSense hat dabei mehrere fixe IP Adresse hinterlegt und leitet mit Regeln den Internetzugriff auf die diversen Server weiter (Mail, Web, NextCloud usw).
Die pfSense ist gleichzeitig der DNS Server in dieser Konstellation - heisst wenn ich von ausserhalb meinen Nextcloud Server anpinge, dann erhalte ich Antwort von der öffentlichen IP Adresse, wenn ich von intern anpinge, dann erhalte ich die 172.16.1.100 Adresse. Auf diesem Nextcloud Server sind unter anderem mein Kalender, meine Kontakte, Notizen usw gespeichert. Der Kindle selbst hat bei mir nicht die primäre Aufgabe das ich darauf lesen will, sondern wurde von mir softwaretechnisch so verändert, dass er mir als Tablet dient um Kalender und Notizen darzustellen und zu erfassen. Da der Kindel zu dem Zeitpunkt wo ich ihn erworben habe das günstigste Andorid Tablet war (knapp 50,- EUR) und ich den ganzen anderen Mist nicht brauche, will ich verhindern das Amazon im Hintergrund a) Daten absaugt welche sie nichts angehen und b) nicht klangheimlich irgendwelche Dienste wieder aktiviert. (Was leider vorkommt).
Deswegen will ich den Kindle nur bei mir zuhause im Netz LAN betreiben, da alle Daten die ich auf dem Dinge benötige ausschliesslich von meinem Nextcloud Server kommen.
Werde heute Nachmittag mal versuschen die DNS Regel umzusetzen.
Gruss
Sohei -
Siehst ja am Screenshot, das Kindle will raus. :)
Zum Verständniss, das "LAN net" ist dein Subnet, wo sich alle tummeln. LAN address ist die IP der pfSense in deinem Subnet, normalerweise wäre das bei Dir die 172.16.1.1.
Um einige Dienste wie DHCP, DNS oder einen Zeitserver, welches die Sense ja bereitstellt, zu nutzen, muss vor der deny rule noch eine allow rule mit "LAN address" als destination inkl. den gewünschten Ports erstellt werden. Zumindest die Zeit würde ich ihm erlauben, von der Sense zu holen. Ohne eine korrekte Zeit laufen einige Apps nicht.
pfSense klappert die Rules von oben ab, First Match Wins eben. :) -
@jegr said in Internet Zugang für Amazon Kindle blockieren:
@fireodo WAN ist NIEMALS das Internet. Bitte ganz dringend merken.
Hab ich jetzt auch gecheckt! Bin genauso wie andere diesem Trugschluss anheim gefallen.
Nicht böse gemeint, aber der Fehler taucht immer und immer und immer wieder auf und es hält sich hartnäckig!
Ja, das kann ich JETZT verstehen ... Aber zum Lernen ist bekanntlich niemand zu alt
Ein gutes Neues übrigends,
fireodo -
@mike69 said in Internet Zugang für Amazon Kindle blockieren:
Um einige Dienste wie DHCP, DNS oder einen Zeitserver, welches die Sense ja bereitstellt, zu nutzen, muss vor der deny rule noch eine allow rule mit "LAN address" als destination inkl. den gewünschten Ports erstellt werden.
Nein, das geht mit eine einzigen Regel, indem man eine Deny Regel mit der Quell IP auf !Lan-Netz anlegt.
Dann darf diese IP nur mit den LAN IPs sprechen, aber mit keiner anderen.
Da alle anderen hinter der Sense im WAN liegen, kein internet.
Zugleich ist aber alles intern erlaubt, wenn man das sauber mit RFC1918 aufbaut, kann das Ding dann auch mit anderen privaten IPs in anderen VLANs sprechen, sollte man diese haben.Zudem sind dann DNS, NTP usw. von der Sense gleich mit erlaubt. Und das mit einer einzigen Regel.
Aber warum simpel wenn man es doch auch kompliziert aufbauen kann.
-
@nocling said in Internet Zugang für Amazon Kindle blockieren:
Nein, das geht mit eine einzigen Regel, indem man eine Deny Regel mit der Quell IP auf !Lan-Netz anlegt.
Dann darf diese IP nur mit den LAN IPs sprechen, aber mit keiner anderen.
Da alle anderen hinter der Sense im WAN liegen, kein internet.
Zugleich ist aber alles intern erlaubt, wenn man das sauber mit RFC1918 aufbaut, kann das Ding dann auch mit anderen privaten IPs in anderen VLANs sprechen, sollte man diese haben.Zudem sind dann DNS, NTP usw. von der Sense gleich mit erlaubt. Und das mit einer einzigen Regel.
Stimmt.
Sobald mehrere interne Netze vorhanden sind, war es das mit einer Regel. Ob dann 6 oder 5 Rules da stehen, ist egal.
@nocling said in Internet Zugang für Amazon Kindle blockieren:
Aber warum simpel wenn man es doch auch kompliziert aufbauen kann.
Fehlt da ein Smiley am Ende?
Wie dem auch sei, liegt es im Auge des Betrachters. Wer mit den invertierten Regeln klar kommt, soll sie nutzen. Persönlich komme sehr gut ohne damit aus. Aber das kann jeder selber entscheiden.
-
-
Das sollte reichen, weil DNS und NTP sind meist UDP, erstes ist aber teilweise auch über TCP nutzbar, wird aber selten eingesetzt.
Oder brauchst du noch andere spezielle Protokolle Richtung Sense?
Kannst aber auch any verwenden, viel Unterschied sollte das nicht machen bei deinem Einsatz von Split DNS und NTP.
-
@nocling danke schön - Nein, ich brauch keine spezielle Routings, mir ist nur wichtig das alle ins Internet kommen, ausser der Kindle ;)
-
@sohei said in Internet Zugang für Amazon Kindle blockieren:
Vielen Dank für Deine ausfürhliche Antwort. Ich habe jetzt die egel folgendermassen geändert, denke aber das es noch nicht die von Dir vorgeschlagene Lösung ist.
Vielleicht ist es auch gut, wenn ich meinen kompletten Aufbau und mein Ziel beschreibe - das erklärt auch, warum der Kindle nicht ins Internet darf/soll.
Hallö :)
Nein, ich meinte in meiner Erklärung ganz obendrüber (über den Block) noch eine Regel mit
- erlaube TCP/UDP, 172.16.1.77 Port * nach LAN_address (pfSense) Port DNS (53)
- dann den Block (aber mit block any, nicht nur tcp/udp)
Alternativ statt nur DNS erlauben zu "LAN Address" eben alle Ports erlauben, dann kannst du vom Kindle Tablet auch noch die Sense UI aufrufen oder auch NTP machen statt nur DNS. Und wenn man mal ggf. mit HAproxy spielt, klappt auch das. :)
Ah verstehe, den Kindle ggf. sogar mit Ads billig gekauft, gerootet oder neu geflasht und soll jetzt nicht mehr raus. OK, wenn das der usecase ist, völlig legitim. Hab sowas ähnliches mit einem alten Nexus 6 mit neuer Firmware, weils da nichts "aktuelles" gibt, darf das auch nicht wirklich ins Netz, sondern spielt quasi nur inhouse Fernbedienung, Sonos Controller und Tasmota Steuerpult :)
@fireodo said in Internet Zugang für Amazon Kindle blockieren:
Ja, das kann ich JETZT verstehen ... Aber zum Lernen ist bekanntlich niemand zu alt
Nö nie, darum auch mein "bitte nicht falsch verstehen", denn ich wollte nur versuchen den langlebigen Irrtum zu kontern, der sich immer wieder einschleicht
Und euch auch allen ein gutes Neues
@nocling said in Internet Zugang für Amazon Kindle blockieren:
Nein, das geht mit eine einzigen Regel, indem man eine Deny Regel mit der Quell IP auf !Lan-Netz anlegt.
Nope, das behandle ich immer wieder in meinen Workshops. Sowas klappt in EINEM gezielten Ausnahmefall gerne. Sobald das Szenario aber ein klein wenig zur Seite abweicht, ist mit dem "NOT" (also !LAN_address) ganz schnell Feierabend und man verleitet die Leute dazu zu denken, dass man mehrere dieser Reglen stacken kann, was natürlich NIE funktioniert!
Mit einem NOT und damit indirekt mit einem logischen ODER zu arbeiten ist immer wesentlich schwerer und undurchsichtiger als einfach eine Regel mehr zu erstellen und SICHER zu sein, dass GENAU das gemacht wird, was da steht.
Zugleich ist aber alles intern erlaubt, wenn man das sauber mit RFC1918 aufbaut, kann das Ding dann auch mit anderen privaten IPs in anderen VLANs sprechen, sollte man diese haben.
Ich kann dann aber ebenfalls nicht den Zugriff auf die Sense auf DNS o.ä. begrenzen, sonst gilt das nämlich dank dem NOT und OR für alle Geräte im LAN was ich nicht will. Und nicht nur für den Kindle.
Aber warum simpel wenn man es doch auch kompliziert aufbauen kann.
Im Gegenteil, dein NOT Beispiel ist das volle Gegenteil von simpel.
Nein, das geht mit eine einzigen Regel, indem man eine Deny Regel mit der Quell IP auf !Lan-Netz anlegt.
Das würde aber eine völlig andere Konstellation ergeben: Ein Deny mit Quelle !LAN_network würde hier gar nichts auslösen. Nicht LAN Netzwerk wären alle IPs außer dem LAN Netz, in dem auch der Kindle ist. Somit wird gar nichts geblockt.
Wenn das schlecht formuliert und du Quelle Kindle IP auf !lan_netzwerk gemeint hattest, wird damit alles was nicht LAN ist geblockt. OK schön, damit ist aber dann die pfSense auch komplett offen. Will man aber vielleicht nicht, sondern ggf. nur DNS, NTP und sonst nix. Soll ja nicht jeder auf die UI. Wenn man zudem mal später noch andere Netze auf der pfSense bekommt gehen die auch nicht mehr. Auch doof.
Nur weil es jetzt gerade im Augenblick vielleicht mit einer "not" Regel funktioniert, heißt das IMHO nicht, dass das a) einfacher und b) simpler ist. Simpel ist an Not/Or/XOr/And Logik für den normalen User nämlich gar nichts. Und da genügt schon wieder eine zweite Regel mit einem NOT, die dann eben NICHT einfach dazu"addiert" wird, sondern die eine die andere Regel aussticht. Das verstehen aber ganz viele nicht. Das ist genauso wie mit Floating Regeln. Ihr könnt das wenn ihr 100% wisst was ihr tut gern nutzen, ich werde es weder empfehlen noch sagen "es ist einfacher". Weil es eben einfach ganz spezifische Anwendungsfälle gibt, wo das passen kann/gut ist, aber in allen anderen Fällen mag es vielleicht eine Regel oder zwei mehr kosten, es "normal" zu machen, dafür ist es effektiv wirklich einfacher und lesbarer, denn man kann 1:1 runterlesen was erlaubt ist und wann. Keine komischen Überraschungen, dass plötzlich Traffic erlaubt ist, weil da eine "Not Destinaton X" Regel drin ist und da plötzlich ganz anderer Traffic drauf matcht.
Nee sorry, schon viel zu oft bei Kunden gesehen, dass genau DAS voll nach hinten losgehen kann!
Cheers
\jensEdit: und ja, wie @mike69 schreibt, ich hab genug Beispiele wo diese NOT Nutzung nach hinten losging, weil die Leute ganz schnell vergessen, dass das nicht funktioniert wie gesprochenes Wort, sondern nach Ablauf- und Programmlogik. Und nicht jeder kennt sich toll mit Logik-Gates oder entsprechenden Softwarekonstrukten so super aus, um alle Auswirkungen im Griff zu haben. Es funktioniert dann einfach irgendwie und hinterher findet man plötzlich raus, dass man durch doofe Kombination von 2-3 NOTs oder Floatings dann quasi alles freigegeben hat.
-
Nein, ich meinte in meiner Erklärung ganz obendrüber (über den Block) noch eine Regel mit
- erlaube TCP/UDP, 172.16.1.77 Port * nach LAN_address (pfSense) Port DNS (53)
- dann den Block (aber mit block any, nicht nur tcp/udp)
Ich habe jetzt die in meinem letzten Post gezeigt Konfiguration gelassen. Der Internet Zugang für den Kindle ist nicht mehr möglich (habe ich getestet) und alle anderen LAN Zugriffe kann er durchführen.
Alternativ statt nur DNS erlauben zu "LAN Address" eben alle Ports erlauben, dann kannst du vom Kindle Tablet auch noch die Sense UI aufrufen oder auch NTP machen statt nur DNS. Und wenn man mal ggf. mit HAproxy spielt, klappt auch das. :)
Das problem daran ist, dass der Kindle nicht nur auf den NextCloud Server zugreifen muss, sondern auch auf andere "Server" und "Dienste" welche (derzeit) alle im LAN Segment stehen. Das würde bedeuten, dass ich für jeden Dienst eine Regel erstellen müsste. Da diese ganze Konfiguration noch maximal dieses Jahr halten muss, ist mir diese Quick-and-Dirty Lösung ganz recht. Wenn wir dann im neuen Haus sind, wird sowieso richtig umgebaut und alle Server in eine DMZ verschoben.
Ah verstehe, den Kindle ggf. sogar mit Ads billig gekauft, gerootet oder neu geflasht und soll jetzt nicht mehr raus. OK, wenn das der usecase ist, völlig legitim. Hab sowas ähnliches mit einem alten Nexus 6 mit neuer Firmware, weils da nichts "aktuelles" gibt, darf das auch nicht wirklich ins Netz, sondern spielt quasi nur inhouse Fernbedienung, Sonos Controller und Tasmota Steuerpult :)
Nun ja, schuldig im Sinne der Anklage ;) ...
Aber vielen Dank für die guten Erläuterungen, hoffe das ich demnächst auch mal diese Wissenschaft der Layer begreifen werde :)
-
@sohei said in Internet Zugang für Amazon Kindle blockieren:
Alternativ statt nur DNS erlauben zu "LAN Address" eben alle Ports erlauben, dann kannst du vom Kindle Tablet auch noch die Sense UI aufrufen oder auch NTP machen statt nur DNS. Und wenn man mal ggf. mit HAproxy spielt, klappt auch das. :)
Das problem daran ist, dass der Kindle nicht nur auf den NextCloud Server zugreifen muss, sondern auch auf andere "Server" und "Dienste" welche (derzeit) alle im LAN Segment stehen. Das würde bedeuten, dass ich für jeden Dienst eine Regel erstellen müsste. Da diese ganze Konfiguration noch maximal dieses Jahr halten muss, ist mir diese Quick-and-Dirty Lösung ganz recht. Wenn wir dann im neuen Haus sind, wird sowieso richtig umgebaut und alle Server in eine DMZ verschoben.
Wie weiter oben schon mehrfach erwähnt: wenn der Kindle und 'die ganzen anderen Geräte im gleichen LAN' letzten Endes an einem Switch vor bzw. hinter der pfSense hängen dann sieht die pfSense das (an ihrem LAN) nicht und man braucht auch keine separaten Firewallregeln dafür. Das ist unnütz. Die Geräte reden über den Switch direkt miteinander.
Die Firewallregeln für den Kindle sind nur dazu da:
- um DNS, DHCP und NTP der pfSense zu nutzen
- den gesamten restlichen Traffic zur pfSense und ausserhalb des LAN (eben auch den kompletten Internetverkehr) zu blockieren
