Router/AP, WPA2 und Sicherheit im Heimnetzwerk

[smutbert]

Hi allerseits,

ich brauche euren Rat:
Für meinen (billigen Plastik-) Router mit eingebautem 3G-Modem gibt es (lange) keine Updates mehr und ganz abgesehen von den WPA2-Lücken vermisse ich ohnehin einige Funktionen, vor allem

• die Namensauflösung per DHCP im Netzwerk angemeldeter Geräte und
• irgendeine zusätzliche Absicherung des WLANs zu WPA2, zB mit einem VPN (??), wobei ich da noch etwas ratlos bin wie das gehen könnte ohne dass man Geräte, die nichts von dieser zusätzlichen Absicherung verstehen, komplett aussperrt (zB Netzwerkdrucker, Streamingclients).

Würdet ihr mir eher raten

1. einen neuen Router zu besorgen oder
2. den alten zu behalten.
   Ich würde dann sein WLAN deaktivieren, ihn an eine Netzwerkschnittstelle eines (bereits vorhandenen) kleinen lüfterlosen PC hängen und diesen als WLAN-AP/Router verwenden (den alten Router sozusagen zum Modem degradieren).
   Von der Zahl der Netzwerkschnittstellen wär das vorerst kein Problem, weil nur mein stationärer PC mit einem Netzwerkkabel am Router hängt und der lüfterlose PC zwei Schnittstellen hat. Klingt diese Konstellation nach einem Sicherheitsrisiko, wenn der PC weiterhin seine momentanen Aufgaben im Netz erfüllen soll - er dient mir momentan als apt-cacher-ng-Server und als kleines NAS.

lg smutbert

[DeletedUserReAsG]

So aus dem Bauch heraus: Letzteres. Wenn du dir einen neuen Plastikrouter holst, wirst du auf lange Sicht das gleiche Problem wieder haben, und mit einem eigenen Rechner für den Job hast du weit mehr Kontrolle und kannst auch erheblich mehr Komfort realisieren.

Bei mir hat den Job ein Cubie hinter Yodaphones Plastikrouter, der zusätzliche Stromverbrauch ist imho zu vernachlässigen. Sieht dann etwa so aus: Plastikrouter ↔ Cubie ↔ Switch ↔ LAN mit allen anderen Rechnern. Als zweite NIC ist ein USB-Ethernetstick angeklemmt, die zusätzliche Latenz ist kaum messbar, und die hier anliegenden 16MBit/s verarbeitet der problemlos. Das Onboard-WLAN ist auch gut als AP zu benutzen, sofern man keinen großen Wert auf den neusten Kram (5GHz und so) legt.

[BenutzerGa4gooPh]

Wuerde auch Methode b) waehlen. 3G-Modem brauchst du ja.
Wuerde dann analog wie bei keinem, aeh niemand aussehen: 3G-Modem - Mini-PC - Switch - PCs. (Oder PC ohne Switch.)

Klingt diese Konstellation nach einem Sicherheitsrisiko, wenn der PC weiterhin seine momentanen Aufgaben im Netz erfüllen soll - er dient mir momentan als apt-cacher-ng-Server und als kleines NAS.

Hier streiten sich die Geister. Eigentlich trennt man Firewall und NAS, aber einige professionelle Linux-Server-Distris (ClearOS) lassen Gateway mit vielen Diensten (Server) zu. Allerdings nicht "einfach so", Zusammenstellung von Paketen bleibt dem Kaeufer/Admin ueberlassen. Vielleicht das vorhandene Geraet doch zusaetzlich als NAT-Router nutzen? Aber so ohne Updates wieder unsicher. Wenn du allerdings auf dem Mini-PC zusaetzlich eine Firewall laufen laesst? Der Router ohne Updates zumindest bleibt unsicher, koennte Teil eines Botnetzes wie so viele IoTs werden. Also doch nur 3G-Modem und Firewall auf Mini-PC.

irgendeine zusätzliche Absicherung des WLANs zu WPA2, zB mit einem VPN (??), wobei ich da noch etwas ratlos bin wie das gehen könnte ohne dass man Geräte, die nichts von dieser zusätzlichen Absicherung verstehen, komplett aussperrt (zB Netzwerkdrucker, Streamingclients).

Ein Accesspoint mit WPA2-Enterprise (802.1X und RADIUS)? Hast ja einen kleinen Server (NAS) laufen. Die Clients interessiert nur WPA2 und eventuell Zertifikate. Letzteres nicht unbedingt erforderlich, Passworte genuegen auch. WPA2-Enterprise wuerde nur Authentifizierung sicherer machen, keine zusaetzliche Verschluesselung wie ueber WPA2 "aufgestuelptes" VPN. Kannst ja im LAN und WLAN wenigstens verschluesselte Protokolle wie ftps sftp etc. einsetzen. Druckertraffic ist wohl nicht so kritisch. Streaming ueber VPN koennte an geringer WLAN-Bandbreite zu sehr "knabbern". Oder Jitter durch rechenaufwaendige Verschluesselung.

Edit: Den "Knackpunkt" bei der Entscheidung "neuer Router oder nicht" sehe ich in den Diensten, die auf dem Mini-PC zusatzlich zur Firewall laufen. Bei kritischen Diesten sollte man Server und Firewall trennen. M. E. machen LTE-Provider Carrier Grade NAT, vielleicht alles halb so wild bei 3G-Zugang?
https://de.m.wikipedia.org/wiki/Carrier-grade_NAT
Bei Univention kann man auch viel (falsch) zusammenstellen: https://www.univention.de/produkte/univ ... p-katalog/
Server und Firewall (UTM) kann man zumindest auch getrennt erwerben: https://www.clearcenter.com/pages/products
Mit den letzten Links ging es mir nur darum, zu schauen, wie Profis Dienstetrennung auf Gateways handhaben. Also um's Spicken. )

[smutbert]

Ob ich Carrier-grade NAT will, konnte ich mir aussuchen (zumindest glaube ich, dass es das war) – mein Router erhält jedenfalls eine öffentliche IP, aber ich glaube die Wahlmöglichkeit wird, spätestens, wenn ich meinen Tarif ändere, gemeinsam mit der öffentlichen IP wegfallen, aber

Vielleicht das vorhandene Geraet doch zusaetzlich als NAT-Router nutzen?

NAT macht mein Plastikrouter zwangsweise, aber wie du bereits schreibst, würde ich den Router gerne als unsicher betrachten, auch wenn ich insgeheim hoffe, dass er ohne DHCP und WLAN nicht besonders viel Angriffsfläche bietet.

Edit: Den "Knackpunkt" bei der Entscheidung "neuer Router oder nicht" sehe ich in den Diensten, die auf dem Mini-PC zusatzlich zur Firewall laufen. Bei kritischen Diesten sollte man Server und Firewall trennen.

In welcher Hinsicht kritisch? Wahrscheinlich stelle ich mich gerade saublöd an, aber ich kann das schlecht einschätzen.

Auf dem MiniPC laufen jetzt jedenfalls ssh, apt-cacher-ng, mpd und minidlna, als Datenquelle für den Streamingclient.

Zum ssh-Server existiert auf dem Plastikrouter ein Portforwarding, das ich bei Bedarf aktiviere, damit hilfesuchende Freunde einen ssh-Tunnel aufbauen können.
Spielt es bei der Sicherheit (Trennung von Firewall und Server) überhaupt eine Rolle ob die Dienste von außen erreichbar sein sollen oder nicht?
und wie läuft die Verbindung im Heimnetz mit VPN mit VPN-unfähige Geräten: über den VPN-Server oder komplett am VPN vorbei (hätte dann ein VPN überhaupt noch einen Sinn)?

[BenutzerGa4gooPh]

Ob ich Carrier-grade NAT will, konnte ich mir aussuchen (zumindest glaube ich, dass es das war) – mein Router erhält jedenfalls eine öffentliche IP ...

Mit CGN wuerdest du eine IP aus 100.64.0.0 bis 100.127.255.255 erhalten. Mehrfach benutzt so wie die privaten IPs nach RFC1918 und wegen NAT auf Providerseite nicht oeffentlich erreichbar. Hast bestimmt was anderes/besseres, wenn du eine oeffentliche IP bekommst.

In welcher Hinsicht kritisch?

Das geht um Angriffsflaechen, GUIs auf Servern sind im Forum zumindest "unbeliebt". (Unbekannte) Exploits in zusaetzlichen, auf einer Firewall unnoetigen Diensten und deren eventuelle Konfigurationsfehler (offene Ports) vergroessern Angriffsflaeche.
Hier mal ein Beispiel, was Profis auf einer Firewall (moeglicherweise mit gutem Gewissen ) noch laufen lassen: https://doc.pfsense.org/index.php/Package_list
mini-dlna auf Firewall "gefällt" mir nicht.

Spielt es bei der Sicherheit (Trennung von Firewall und Server) überhaupt eine Rolle ob die Dienste von außen erreichbar sein sollen oder nicht?

Theoretisch nicht von aussen erreichbare Dienste können auch momentan unbekannte Exploits und eigene Fehlkonfigurationen bergen.

...und wie läuft die Verbindung im Heimnetz mit VPN mit VPN-unfähige Geräten...

VPN beidseitig im Heimnetz terminiert ist schon sehr "aluhütig". WPA2-PSK-Traffic ist verschlüsselt und "Krack" hoffentlich gefixt. Für Dateitransfers per WLAN kann man ja ftps/sftp mal nutzen, Management mit SSH und Passwort macht kaum zusätzliche Arbeit, Web-GUIs nutzen https. Und ein kastriertes, VPN-unfähiges Gerät kann's halt nicht. Vielleicht aber https.

An deiner Stelle (Streaming-, NAS-Server) wuerde ich wohl doch einen Router mit Firewall vor den Mini-PC setzen, den Mini-PC als reinen Server im LAN verwenden. Vielleicht eine stromsparende APU3b4 von PCEngines, wo man entsprechende Mobilfunk-Karte UND WLAN-Karte einbauen und PFSense, OPNSense, IPFire, Debian als Router/Firewall nutzen kann?
https://pcengines.ch/apu3a2.htm
(Wer hat's erfunden? Die Schweizer. Gibt es auch als Bundle, Fertiggeraet mit Gehaeuse.)

Edit: Text erweitert.

[smutbert]

Danke niemand und vor allem Jana.


Jetzt, habe ich einen ungefähren Plan. Ich werde auf dem MiniPC testweise alle Dienste bis auf ssh lahmlegen und ausprobieren ob ich es bis zu einer funktionierenden Firewall-, Router- und Accesspoint-konfiguration schaffe. Wenn ja, werde ich schon merken, ob ich das dann auf so einem System von pcengines oder etwas ähnlichem laufen lassen will.

Eine Frage habe ich vorläufig noch:
Die Trennung von Firewall und Server könnte ich doch auch mit einer Virtualisierung machen – lxc wollte ich eh schon einmal kennenlernen oder wäre dafür eine vollständige Virtualisierung à la VirtualBox/qemu/kvm sinnvoller oder wär das sowieso nichts gescheites?
und wenn doch, würde ich zwei virtuelle Maschinen laufen lassen, eine für Router/Firewall und eine für den Server oder lasse ich eines von beiden direkt auf dem Host laufen?

[BenutzerGa4gooPh]

Die Trennung von Firewall und Server könnte ich doch auch mit einer Virtualisierung machen – lxc wollte ich eh schon einmal kennenlernen oder wäre dafür eine vollständige Virtualisierung à la VirtualBox/qemu/kvm sinnvoller oder wär das sowieso nichts gescheites?
und wenn doch, würde ich zwei virtuelle Maschinen laufen lassen, eine für Router/Firewall und eine für den Server oder lasse ich eines von beiden direkt auf dem Host laufen?

Eine Virtualisierung der Firewall wird allgemein abgelehnt. Man hätte eine vergrößerte Angriffsfläche durch das Virtualisierungssystem und das Hostsystem und müsste letzteres zusätzlich härten, was nicht jeder kann.

Mit etwas Vertrauen zu den Virtualisierungslösungen würde ich an deiner Stelle die Firewall auf Blech laufen lassen und den Server für das LAN (Streming, NAS etc) virtualisieren. Z. B. mit Virtualbox und die virtuelle Schnittstelle des Gastsystems an die LAN-Schnittstelle der Blech-Firewall (Mini-PC) bridgen. Wegen Erreichbarkeit des virtuellen Servers aus dem gesamten LAN.
https://www.thomas-krenn.com/de/wiki/Ne ... VirtualBox
Die Firewall-Regeln für das LAN wären mit Bridging für das virtuelle Gastsystem 1:1 gültig. Kannst aber wegen Bridging auch nicht unterschiedlich per Firewall einschränken, müsstest du dann im Gastsystem mit iptables oder so tun. (Ausprobiert habe ich das alles nicht, erscheint mir jedoch logisch.)

Da ich mir persönlich nicht zutraue, ein Debian zu härten (bisher kein Bedarf, also kein Wissen angeeignet), würde ich einfach auf das Wissen und die Erfahrung und die Arbeit anderer zurückgreifen und IPFIRE als fertige Firewall-Distribution und einigermaßen vertrautes Linuxsystem verwenden (PFSense, OPNSense basieren auf FreeBSD) und wie im vorhergehenden Absatz beschrieben, virtualisieren. Andere Virtualisierungslösungen als VBOX habe ich nocht nicht ausprobiert, bin mit VBOX zufrieden.

Mit entsprechendem Wissen (oder Ambitionen) kannst du sicher auch ein gehärtetes Debian als Hostsystem, d. h. als Router-Firewall-Kombination auf Blech verwenden und einen anderen Virtualisierer als VBOX für deinen Heimserver.

Für andere Mitleser:
In einer Firma würde ich immer Firewall und (virtuelle) LAN-Server gerätetechnisch trennen - wegen kleinerer Angriffsflächen, einfacherer Backups, direkte Angriffe nur durch Exploits und Fehlkonfigurationen des Firewall-System möglich.

[ingo2]

Da ich mir persönlich nicht zutraue, ein Debian zu härten (bisher kein Bedarf, also kein Wissen angeeignet), würde ich einfach auf das Wissen und die Erfahrung und die Arbeit anderer zurückgreifen und IPFIRE als fertige Firewall-Distribution und einigermaßen vertrautes Linuxsystem verwenden (PFSense, OPNSense basieren auf FreeBSD) und wie im vorhergehenden Absatz beschrieben, virtualisieren.

Bin auch noch immer auf der Suche nach einer gescheiten Firewall, die mehr kann als meine FB7430..
Nur zu deiner Information:
IPFire (auch mein Favorit aus genannten Gründen) beherrscht leider kein IPv6: https://forum.ipfire.org/viewtopic.php? ... v6#p110887 und ist damit momentan noch aus dem Rennen. Wann v3.x kommt, steht in den Sternen - leider.

Ingo

[BenutzerGa4gooPh]

Nur zu deiner Information:
IPFire (auch mein Favorit aus genannten Gründen) beherrscht leider kein IPv6 ... Wann v3.x kommt, steht in den Sternen.

Danke, Kenntnis genommen.

[gugus]

Servus,
Nebenbei zur Virtualsierung, ich habe einen Xen Server am Start (Dom0) und darauf eine Ipfire Firewall (DomU).
Weitere DomU's als NFS etc.
In die Firewall habe ich eine Netzwerkkarte durchgereicht, die Dom0 sieht diese Karte nicht.
Dies hat bis anhin alle Tests bestanden.

Gruss
Gugus

[smutbert]

Danke, das klingt auch ganz gut, aber nachdem ich nun die ersten paar Minuten (oder waren es Stunden – ich glaube es nicht wieviel Zeit man mit einer falschen wlan-Passphrase verplempern kann) in das Projekt investiert habe, bin ich zum Schluss gekommen, dass ich das ganze so einfach wie möglich halten will


hostapd und dnsmasq funktionieren jedenfalls schon einmal, auch wenn ich viele Optionen noch nicht verstehe.
Die WLAN-Signalqualität hat sich freundlicherweise gegenüber dem Plastikrouter verbessert.

Zumindest rudimentäres Routing (samt Firewall) habe ich auch (glaube ich) – zumindest verwehren mir die iptables-Regeln erfolgreich den Zugriff auf den mpd-Server und sie verhageln mir auch die avahi-Dienste.

Eigentlich würde mich interessieren, was ihr von der Konfiguration hier als Ausgangspunkt haltet (ich seh nix verdächtiges, aber ich habe ungefähr soviel Erfahrung mit iptables wie mit dem Legen von Eiern):
https://arstechnica.com/gadgets/2016/04 ... m-scratch/
Nur das Portforwarding habe ich vorerst weggelassen. Mein Testsetup sieht so aus, dass der Plastikrouter ganz normal weiterläuft und mein MiniPC mit einem WLAN-Adapter (wl0) im WLAN des Routers hängt und mit einem weiterem WLAN-Adapter (wl1) selbst mit hostapd ein Netz aufspannt.
(Das heißt das WAN in der Konfiguration ist eigentlich noch gar nicht das WAN.)

edit:
ich freu mich grad wie ein kleines Kind, dass meine erste eigene iptables-Zeile auf Anhieb funktioniert und ich mpd wieder bedienen kann:

Code: Alles auswählen

-A INPUT -i wl1 -p tcp --dport 6600 -j ACCEPT

komplett sieht es so 40047 aus.

[smutbert]

Gleich noch eine Frage hinterher, wenn ich darf. Nun habe ich analog zur Regel für mpd eine Regel für apt-cacher-ng hinzugefügt

Code: Alles auswählen

-A INPUT -i wl1 -p tcp --dport 3142 -j ACCEPT

und es hat auch den erwünschten Effekt, bis auf die Tatsache, dass der Mini-PC/Router/Firewall, auf dem (noch) apt-cacher-ng läuft, selbst nicht darauf zugreifen kann. Woran kann denn das schon wieder liegen?

Vergesst meine Fragen (vorläufig) – früher oder später muss ich für iptables einen eigenen Thread eröffnen, da gibt es zu viele Dinge, die ich nicht verstehe, aber vorläufig versuche ich es noch alleine.

In diesem Thread werde ich mich auf grundsätzliche Fragen beschränken, davon kommen bestimmt auch noch einige...

[smutbert]

Hallo wieder einmal in diesem Thread

nun läuft schon einige Zeit das meiste so wie ich es mir vorstelle, aber es haben sich auch noch zwei grundsätzliche Fragen aufgetan. Ich versuche mich kurz zu fassen:

1. Bei deaktiviertem Bonjour muss ich den Netzwerkdrucker/-multifunktionsgerät bei Cups und in der sane Konfigurationsdatei mit dem FQDN eintragen.
   
   Die Frage ist nun, wie verhindere ich, dass versucht wird eine Verbindung zu diesem möglicherweise im Internet existierenden FQND aufzubauen, nur weil ich irrtümlich eine Scananwendung starte während ich in einem fremden Netzwerk bin?
   Genügt es im Heimnetz einen Domainnamen zu verwenden, der im Internet als Top Level Domain nicht existiert oder soll ich mehr/etwas anderes dagegen unternehmen?
   .
2. Kann ich bestimmten (WLAN-)Clients auf einfache Weise zuverlässiger als über die MAC-Adresse den Zugang zum Internet verweigern?
   
   Konkret meine ich damit zum Beispiel Nutzungsstatistiken, die das Gerät an den Hersteller schicken möchte. Das habe ich zwar in den Einstellungen deaktiviert, aber wer weiß was ich übersehen habe…
   Oder meint ihr dass alles was über das Blockieren anhand der MAC-Adresse hinausgeht für so einen Fall Overkill ist?

[BenutzerGa4gooPh]

Die Frage ist nun, wie verhindere ich, dass versucht wird eine Verbindung zu diesem möglicherweise im Internet existierenden FQND aufzubauen ...

Das sollte ein DNS-Server verhindern, in dem er autoritativ für lokale/interne Domain antwortet. Und das zuerst prüft. Des Weiteren kann man speziell reservierte Top-/Second-Level-Domains nutzen, die von öffentlichen Servern nicht aufgelöst/beantwortet werden:
.test, .example, example.com ...
https://tools.ietf.org/html/rfc2606
https://tools.ietf.org/html/rfc6761
Schneller Überblick:
https://en.m.wikipedia.org/wiki/.test
https://en.m.wikipedia.org/wiki/Example.com
(Ich benutze derzeit "<meinedomain>.test".)

Kann ich bestimmten (WLAN-)Clients auf einfache Weise zuverlässiger als über die MAC-Adresse den Zugang zum Internet verweigern?
Konkret meine ich damit zum Beispiel Nutzungsstatistiken, die das Gerät an den Hersteller schicken möchte.

Also ich gestatte per Paketfilter (Basis IP-Adressen) den Androiden nur http, https und ntp. (Als DNS-Server wird denen per DHCP mein eigener zugewiesen.) Die Filterung kann durch DNS-Reservierung (MAC-> "statische" IP-Adresse) für Smartphones und Prüfung der somit bekannten Quelladresse oder/und ein WLAN-Gastnetz (Prüfung des entsprechenden Quell-Subnetzes bei Mapping Gast-SSID -> Gast-VLAN -> Gast-IP-Subnetz) erfolgen.

Was über http/https gesendet wird, hat man so nicht eingeschränkt. Man kann eventuell noch bestimmte Zieladressen verbieten. Dazu Firewall / iptables loggen lassen und Ziel-IPs mit whois vergleichen. Beim Logging lernt man viel. Die Einschränkung der http-/https-Zieldressen mit Firewall/Paketfilter ist nach meinen Erfahrungen unnötig und unpraktikabel, Traffic wird m. E. nur vom Browser erzeugt, heisst also, besser Adblocker verwenden. Oder DNS-Server mit PiHole oder etc/hosts-Blacklists (Umleitung auf 0.0.0.0). /etc/hosts wird von dnsmasq zuerst geprüft, auch Antwort auf obige Frage. Block-Listen findet man im Netz, mal uBlockOrigin-Einstellungen (Filterlisten) durchsehen.

Edit: Text "nachgeschminkt".

[smutbert]

Danke liebe Jana, aber du vergrößerst meine Verwirrung nur noch mehr...

Das sollte ein DNS-Server verhindern, in dem er autoritativ für lokale/interne Domain antwortet. Und das zuerst prüft. […]

Im Heimnetz ist es ja kein Problem, da sehe ich allein schon an der Antwortgeschwindigkeit, dass gar nicht erst versucht wird einen Namen, der „meine“ Domain hintendran hat im Internet aufzulösen.

Außerhalb aber schon – ein fremder DNS-Server kann sich nicht nach dem Domainnamen richten, den ich zu Hause verwende, selbst wenn er ihn kennen würde. Genaugenommen stört mich in fremden WLANs schon, dass überhaupt eine DNS-Anfrage à la „wie lautet die IP-Adresse von drucker.zuhause“ hinausgeht und ich habe nicht den Eindruck, dass ich das verhindern kann indem ich .example statt .zuhause verwende.


Immerhin habe ich aus dem 2. Teil herausgelesen, dass Blockieren anhand von IP oder MAC vollkommen ok ist?

[BenutzerGa4gooPh]

Danke liebe Jana ...

Unserem hilfsbereiten (und wohl auch lieben) Audio-/Video-/Foto-Bert hilft man doch gern.

Außerhalb aber schon – ein fremder DNS-Server kann sich nicht nach dem Domainnamen richten, den ich zu Hause verwende, selbst wenn er ihn kennen würde. Genaugenommen stört mich in fremden WLANs schon, dass überhaupt eine DNS-Anfrage à la „wie lautet die IP-Adresse von drucker.zuhause“ hinausgeht und ich habe nicht den Eindruck, dass ich das verhindern kann indem ich .example statt .zuhause verwende.

Bei Anfrage eines lokalen FQDNs von dir privat im Fremdnetz (und auch zuhause mit fehlerhaftem DNS-Server) wird durch die reservierten (und standardisierten) Domains zumindest nicht auf eine falsche IP aufgelöst. Ansonsten für Fremdnetze eine unter Linuxern ach so unbeliebte Desktop-Firewall / iptables aufsetzen, Filter outbound/egress, nur HTTP, HTTPS, NTP, DNS und was du sonst noch brauchst (ICMP, traceroute, whois, SSH, ...) abgehend zulassen und Ruhe ist. Rechner als DHCP-Client im Fremdnetz? UDP Port 67 outbound und 68 inbound bei Bedarf auch zulassen, sonst zu viel Ruhe.

Immerhin habe ich aus dem 2. Teil herausgelesen, dass Blockieren anhand von IP oder MAC vollkommen ok ist?

M. E. kann man nicht viel mehr im Heimnetz tun, hochwertige Switches haben u. a. noch DHCP-Tricks (Pruefung richtige MAC vs. richtiger dynam. IP-Adresse am richtigem Port). MACs kann man ja leicht spoofen, denen dynamisch zugeordnete IPs somit auch. Dazu müssten dann aber andere und von dir zugelassene, vorhandene MACs/IPs/Subnetze verwendet werden. Aber die Systeme selber tun das wohl nicht, mein Androide will nur nach Hause telefonieren, das weitgehende Unterbinden trotz Internetzugang habe ich oben genannt. Zu "best practices" gehört, an allen LAN-/WLAN-Ports nur gewollte IP-Subnetze per Paketfilter zuzulassen. Das Wichtigste zuletzt: Du willst blocken? Falsch! Erlaube nur das, was gewollt! Meist genügen Quell-IPs oder/und Subnetze und Zielports/Dienste. Dazu sind Subnetze sinnvoll, die entsprechend verschiedener Sicherheitsanforderungen gebildet werden (Gast,- WLAN-, LAN-, Server-Segment, ...)

Nur MAC-Filter für WLAN? M. E. nur weitere Sicherheitsschicht zum Paketfilter, alleine nicht so sinnvoll wegen Spoofing. Wie gesagt, mein Androide tut's nicht von selber. Nachbarn vielleicht.

Falls ich zu umständlich antworte, einfach weiter bohren, gibt noch mehr hier.