Offene Netzwerk-Härtungsmaßnahmen¶

Stand: 24. August 2026.

Diese Seite sammelt bewusst noch nicht umgesetzte Maßnahmen zur weiteren Härtung und Bereinigung des produktiven MikroTik-/Smart-Home-Netzes. Sie trennt offene Arbeiten vom aktuell produktiven Stand in MikroTik Router und Firewall.

Priorität 1 – alte RouterOS-Standardkonfiguration entfernen¶

Auf der Bridge existiert noch die RouterOS-Defaultadresse:

192.168.88.1/24

Dazu gehören noch:

deaktivierter DHCP-Server defconf auf der Bridge;
DHCP-Pool default-dhcp mit 192.168.88.10-192.168.88.254;
DHCP-Network 192.168.88.0/24 mit Gateway/DNS 192.168.88.1;
zwei Firewallregeln, die IoT beziehungsweise Gäste gegenüber 192.168.88.0/24 sperren.

Das Netz wird produktiv nicht mehr verwendet. Die Komponenten bleiben vorerst bewusst bestehen, weil noch nicht abschließend geklärt ist, ob eine Management- oder Recovery-Abhängigkeit daran hängt. Vor einer Entfernung noch einmal prüfen, dass kein Gerät oder Wartungsweg das Netz benötigt. Danach Adresse, deaktivierten DHCP-Server, Pool, DHCP-Network und die beiden überflüssigen Firewallregeln gemeinsam entfernen.

Priorität 2 – IPv6 und Matter/Thread sauber absichern¶

IPv6 darf nicht pauschal deaktiviert werden, da es für Matter/Thread verwendet wird.

Aktuell vorhanden:

fd7a:3c91:5e2b:30::1/64 auf vlan30

Der Präfix wird auf VLAN30 per Router Advertisement beworben.

Zusätzlich existieren statische Thread-Routen über Home Assistant:

fd3c:f900:72a2:fbea::/64 -> Home Assistant via VLAN10
fd9b:67ec:18c0:1::/64    -> Home Assistant via VLAN10

Außerdem besteht eine dynamische IPv6-Default-Route über pppoe-wobcom.

Die IPv6-Firewall entspricht derzeit weitgehend der RouterOS-Standardkonfiguration und besitzt noch nicht das gleiche explizite Segmentierungs-/Default-Deny-Modell wie IPv4.

Vorgehen:

tatsächliche IPv6-/Matter-/Thread-Verbindungen beobachten;
benötigte ICMPv6-, Thread- und Routing-Flows bestimmen;
explizite Allow-Regeln vorbereiten;
erst danach eine kontrollierte IPv6-Default-Deny-Policy aufbauen;
Matter/Thread nach jeder Änderung praktisch testen.

Priorität 3 – IPv4-Firewall weiter präzisieren¶

Die IPv4-Firewall arbeitet inzwischen mit aktivem Default-Deny. Deaktivierte Altregeln wurden am 24. August 2026 entfernt; ebenso die letzte verwaiste VLAN20 -> ether1-Regel.

Nach erfolgreichem Audit können noch folgende Punkte verbessert werden:

DNS-, NTP- und mDNS-INPUT-Regeln zusätzlich an interne Interfaces beziehungsweise die Interface-Liste LAN binden;
die derzeit bewusst breiten Regeln Home Assistant -> Home VLAN und Home Assistant -> IoT später anhand realer Ziele und Ports enger fassen, falls sich dafür ein klarer Nutzen ergibt;
Audit-Regeln nach ausreichender Beobachtungszeit entfernen, wenn sie dauerhaft keine unerwarteten Flows zeigen.

Für AUDIT Home -> internal unmatched ist derzeit gezieltes Logging mit Präfix AUDIT-HOME aktiv. Dabei wurden bereits bewusst blockierte Wartungszugriffe eines Admin-Geräts aus VLAN20 auf IoT-Weboberflächen identifiziert. Diese werden nicht pauschal freigegeben; für direkte IoT-Wartung kann in das IoT-WLAN gewechselt werden.

Priorität 4 – zentrale RouterOS-Backups weiter automatisieren¶

Ein lesbarer RouterOS-Export kann mit den bestehenden MCP-Rechten erfolgreich direkt per SSH gestreamt werden:

ssh mcp@10.10.10.1 '/export' > "router-$(date +%F-%H%M).rsc"

Das wurde am 23. August 2026 erfolgreich getestet. Ein Router-seitiger /export file=... ist dafür nicht nötig.

Weiter offen ist die vollständige Automatisierung der zentralen Sicherung:

regelmäßiger lesbarer .rsc-Export;
verschlüsseltes binäres .backup für schnelle Wiederherstellung;
Ablage auf dem separaten Proxmox-Backup-Speicher;
sinnvolle Aufbewahrungsfrist und Bereinigung alter Sicherungen;
minimale, getrennte Berechtigungen für den Transfer des binären Backups.

Details: Router-Backup

Maßnahmen außerhalb der Firewall¶

RouterOS- und Firmware-Pflege¶

Router und Access Points auf dem Stable-Kanal halten;
RouterOS- und RouterBOARD-Firmware gemeinsam pflegen;
vor größeren Updates Backup/Export erstellen;
nach Updates WAN, CAPsMAN, VLANs und zentrale Smart-Home-Verbindungen prüfen.

Administrationskonten und Zugang¶

keine ungenutzten RouterOS-Benutzer behalten;
administrative Konten nur mit notwendigen Gruppen/Rechten betreiben;
SSH bevorzugt mit Schlüsseln statt Passwort verwenden;
regelmäßige Kontrolle, ob alte Schlüssel oder Benutzer entfernt werden können.

Konfigurations- und Recovery-Backups¶

RouterOS-Backup und .rsc-Export regelmäßig extern sichern;
Proxmox-Backups und Home-Assistant-Backups getrennt betrachten;
Wiederherstellungsweg dokumentieren und gelegentlich praktisch prüfen;
wichtige Zugangsdaten/Providerparameter so dokumentieren, dass ein Neuaufbau ohne Altgerät möglich ist.

Logging und Monitoring¶

Sinnvoll wäre eine zentrale Überwachung von mindestens:

WAN/PPPoE-Verbindung;
Router-/AP-Erreichbarkeit;
CPU, RAM und Temperatur der MikroTik-Geräte;
Interface-Linkstatus und Fehlerzähler;
auffälligen Firewall-Drops;
RouterOS-/Firmware-Versionen;
Ausfall zentraler Infrastruktur wie HA, Cloudflare und MCP.

Optional kann RouterOS-Logging an einen zentralen Syslog-Empfänger gesendet werden, damit relevante Ereignisse auch nach einem Router-Neustart erhalten bleiben.

Layer-2- und VLAN-Härtung¶

Nach Entfernung des alten 192.168.88.0/24-Netzes kann geprüft werden, ob VLAN 1 vollständig ungenutzt ist und Bridge-/Port-Einstellungen weiter eingeschränkt werden können.

Dabei insbesondere prüfen:

PVIDs aller Bridge-Ports;
Tagged/Untagged-Zuordnungen;
ingress-filtering;
passende frame-types je Port;
keine unerwarteten untagged Management-Pfade.

Änderungen an Bridge/VLAN-Konfiguration nur mit lokalem Fallback und schrittweise durchführen, da Fehler dort das gesamte Netz trennen können.

WLAN-Härtung¶

Regelmäßig prüfen:

WPA2/WPA3-Konfiguration und Transition-Mode;
PMF/Management Frame Protection;
Fast-Transition-Konfiguration;
keine veralteten oder ungenutzten SSIDs;
IoT- und Gäste-SSIDs weiterhin korrekt den vorgesehenen VLANs zugeordnet;
keine Clients dauerhaft im falschen VLAN.

DNS und Zeitversorgung¶

Router-DNS und NTP als zentrale interne Dienste beibehalten und überwachen;
externe DNS-/NTP-Abhängigkeiten dokumentieren;
bei späterem Bedarf prüfen, ob IoT-Geräte auf die vorgesehenen Resolver/NTP-Server festgelegt werden sollen;
Änderungen nicht nur nach Konfigurationswerten, sondern mit realen Clienttests prüfen.

Regelmäßige Inventur¶

In festen Abständen Router-DHCP-Leases, Wiki-IP-Adressplan und tatsächlich vorhandene Geräte vergleichen. Entfernte Geräte, alte Reservierungen und nicht mehr benötigte Integrationen zeitnah aus Router und Dokumentation entfernen.

Empfohlene Reihenfolge¶

Firewall-Audit nach der Default-Deny-Umstellung weiter auswerten.
Altes 192.168.88.0/24 nur nach abschließender Abhängigkeitsprüfung vollständig entfernen.
Zentrale RouterOS-Backups automatisieren.
IPv6-/Matter-/Thread-Flows beobachten und dokumentieren.
IPv6 kontrolliert segmentieren.
Danach erst weitere Bridge-/VLAN-Feinhärtung vornehmen.
Logging/Monitoring und regelmäßige Inventur als Daueraufgabe etablieren.