From 7cd31df1ee56c48327011fc9d020c4448cf8387a Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Tue, 18 Aug 2026 04:53:35 +0200 Subject: [PATCH] TP5 Etappe 4 vorbereitet (input haerten, MGMT isolieren, JIT-Gruppe) Vorbereitet, NICHT ausgerollt: 0 TP5-E4-Regeln am Geraet, seal-lan weiter aktiv, kein input-Drop. Der riskantere Teil, riskanter als der forward-Drop: der Core ist DNS- und DHCP-Server fuer alle sieben VLANs, und beides ist input-Verkehr, der heute allein von TP10-seal-lan durchgewunken wird. seal-lan naiv auf vlan10 zu verengen nimmt in derselben Sekunde jedem anderen VLAN DHCP und DNS. Das Skript geht deshalb strikt: Ersatzregeln (dns udp+tcp, dhcp, MAIN, HA:8728, Nautobot-ssh, cf-mesh) zuerst, dann seal-lan disabled, dann Log, dann Drop. Auto-Revert steht als Schritt 0 und setzt BEIDE Schnitte zurueck. Zwei am Geraet gepruefte Voraussetzungen sind darin festgehalten: /system ntp server ist disabled, es braucht also keine udp/123-Regel; und HA pollt den Core selbst auf 8728 als INPUT -- die forward-Regel aus Etappe 2 deckt das nicht ab. Dazu die JIT-Admin-Gruppe aus D3: Dauerregel mit leerer Liste, die nichts oeffnet, bis sich jemand mit timeout eintraegt. Nachtrag zum vorigen Commit da452ce: der dort als "vorbereitet" beschriebene Etappe-3-Drop ist inzwischen ausgerollt und greift (5 Pakete). Der tp5autorevert-Scheduler laeuft und wuerde ihn um 05:02:29 wieder abschalten -- wer ihn behalten will, muss den Scheduler vorher entfernen. Co-Authored-By: Claude Opus 5 --- routeros/tp5-etappe4-input-mgmt.rsc | 77 +++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 routeros/tp5-etappe4-input-mgmt.rsc diff --git a/routeros/tp5-etappe4-input-mgmt.rsc b/routeros/tp5-etappe4-input-mgmt.rsc new file mode 100644 index 0000000..415fd82 --- /dev/null +++ b/routeros/tp5-etappe4-input-mgmt.rsc @@ -0,0 +1,77 @@ +# TP5 Etappe 4 — input-Kette haerten, MGMT isolieren, JIT-Admin-Gruppe. +# +# WARUM DAS DER RISKANTERE TEIL IST (riskanter als der Drop in forward) +# -------------------------------------------------------------------- +# Der Core ist DNS- UND DHCP-Server fuer alle sieben VLANs. Beides ist +# input-Verkehr und wird heute allein von `TP10-seal-lan` +# (in-interface-list=LAN, accept) durchgewunken. Wer seal-lan naiv auf vlan10 +# verengt, nimmt in derselben Sekunde jedem anderen VLAN DHCP und DNS. +# Deshalb strikt: erst die Ersatzregeln, dann seal-lan abschalten, dann Drop. +# +# GEPRUEFTE VORAUSSETZUNGEN (2026-08-18, live am Geraet): +# - /system ntp server = enabled:no -> die Clients nutzen den Core NICHT als +# Zeitquelle, es braucht also KEINE udp/123-Regel. +# - /ip service ist bereits auf 10.40.0.0/16 + 100.96.0.0/12 eingegrenzt; +# diese Kette ist die zweite, grobkoernigere Schranke davor. +# - Die 5 `TP5: mDNS in vlanXX`-Regeln stehen hinter seal-lan und zaehlen +# deshalb 0. Sobald seal-lan faellt, werden sie scharf — das ist Absicht +# und war beim Bau 2026-08-14 schon so vorgesehen. +# +# ⚠️ Wie in Etappe 3 gilt: erst Sicherung, dann Schnitt. Und die Log-Regel steht +# VOR dem Drop, damit der Kollektor zeigt, was der Drop frisst. +# +# Push: python3 nautobot/gc-manual-plan.py --device crs326-core \ +# --commands-file routeros/tp5-etappe4-input-mgmt.rsc \ +# --change-id TP5-Etappe4-Input --deploy +# Backup davor: core-pre-tp5-etappe4-20260818.backup +# +# Rollback sofort: /ip firewall filter set [find comment="TP10-seal-lan"] disabled=no +# /ip firewall filter set [find comment="TP5: input deny-by-default"] disabled=yes +# --------------------------------------------------------------------------- + +# 0) Sicherung zuerst — schaltet BEIDE Schnitte zurueck, nicht nur einen. +:do { :if ([:len [/system scheduler find name="tp5e4autorevert"]] = 0) do={ /system scheduler add name="tp5e4autorevert" interval=10m on-event="/ip firewall filter set [find comment=\"TP5: input deny-by-default\"] disabled=yes; /ip firewall filter set [find comment=\"TP10-seal-lan\"] disabled=no; /system scheduler remove [find name=\"tp5e4autorevert\"]; :log warning \"tp5e4: AUTO-REVERT hat input-Drop und seal-lan zurueckgesetzt\"" } } on-error={ :log info "tp5e4: 00 scheduler warf" } + +# 1) DNS. Der Core ist Resolver fuer jedes VLAN (dhcp-server network liefert +# ueberall 10.40.X.1 aus). Ohne diese zwei Zeilen ist nach dem Drop das +# ganze Haus ohne Namensaufloesung. +:do { :if ([:len [/ip firewall filter find comment="TP5-E4: dns udp"]] = 0) do={ /ip firewall filter add chain=input action=accept in-interface-list=LAN protocol=udp dst-port=53 comment="TP5-E4: dns udp" place-before=[/ip firewall filter find comment="TP10-seal-lan"] } } on-error={ :log info "tp5e4: 01a dns-udp warf" } +:do { :if ([:len [/ip firewall filter find comment="TP5-E4: dns tcp"]] = 0) do={ /ip firewall filter add chain=input action=accept in-interface-list=LAN protocol=tcp dst-port=53 comment="TP5-E4: dns tcp" place-before=[/ip firewall filter find comment="TP10-seal-lan"] } } on-error={ :log info "tp5e4: 01b dns-tcp warf" } + +# 2) DHCP. 7 Server, 54 Reservierungen — alle haengen an udp/67 auf dem Core. +:do { :if ([:len [/ip firewall filter find comment="TP5-E4: dhcp"]] = 0) do={ /ip firewall filter add chain=input action=accept in-interface-list=LAN protocol=udp dst-port=67 comment="TP5-E4: dhcp" place-before=[/ip firewall filter find comment="TP10-seal-lan"] } } on-error={ :log info "tp5e4: 02 dhcp warf" } + +# 3) MAIN = die Admin-Zone. Das ist das verengte seal-lan: ssh/www/winbox/api +# kommen ab jetzt nur noch aus vlan10 (plus Mesh, s. 6). +:do { :if ([:len [/ip firewall filter find comment="TP5-E4: MAIN->core admin"]] = 0) do={ /ip firewall filter add chain=input action=accept in-interface=vlan10 comment="TP5-E4: MAIN->core admin" place-before=[/ip firewall filter find comment="TP10-seal-lan"] } } on-error={ :log info "tp5e4: 03 main warf" } + +# 4) HA pollt den Core selbst auf 8728. Live belegt: /ip service zeigt offene +# api-Verbindungen local=10.40.99.1 remote=10.40.20.105. Das ist input, nicht +# forward — die forward-Regel aus Etappe 2 deckt es NICHT ab. +:do { :if ([:len [/ip firewall filter find comment="TP5-E4: HA->core api"]] = 0) do={ /ip firewall filter add chain=input action=accept src-address=10.40.20.105 protocol=tcp dst-port=8728 comment="TP5-E4: HA->core api" place-before=[/ip firewall filter find comment="TP10-seal-lan"] } } on-error={ :log info "tp5e4: 04 ha warf" } + +# 5) Nautobot deployt auch auf den Core selbst -> ssh als input. Address-List +# aus dem Etappe-2-Nachtrag (.20.30/.31/.32). +:do { :if ([:len [/ip firewall filter find comment="TP5-E4: Nautobot->core ssh"]] = 0) do={ /ip firewall filter add chain=input action=accept src-address-list=nautobot protocol=tcp dst-port=22 comment="TP5-E4: Nautobot->core ssh" place-before=[/ip firewall filter find comment="TP10-seal-lan"] } } on-error={ :log info "tp5e4: 05 nautobot warf" } + +# 6) Der Fernzugang. Ohne diese Zeile sperrt der input-Drop den Mesh aus — also +# genau den Weg, ueber den man von auswaerts korrigieren wuerde. +:do { :if ([:len [/ip firewall filter find comment="TP5-E4: mesh->core admin"]] = 0) do={ /ip firewall filter add chain=input action=accept in-interface=cf-mesh comment="TP5-E4: mesh->core admin" place-before=[/ip firewall filter find comment="TP10-seal-lan"] } } on-error={ :log info "tp5e4: 06 mesh warf" } + +# 7) Jetzt erst der Schnitt: seal-lan ausschalten (nicht loeschen — disabled ist +# der schnellere Rueckweg und der Auto-Revert greift genau hier an). +:do { /ip firewall filter set [find comment="TP10-seal-lan"] disabled=yes } on-error={ :log info "tp5e4: 07 seal-lan warf" } + +# 8) Log VOR Drop, gleiche Doktrin wie in forward: der Kollektor zeigt weiter, +# was der Drop frisst. Ohne diese Zeile ist jede spaetere Fehlersuche Raten. +:do { :if ([:len [/ip firewall filter find comment="TP5: input log-only"]] = 0) do={ /ip firewall filter add chain=input action=log log-prefix="TP5-INPUT-WOULD-DROP" comment="TP5: input log-only" } } on-error={ :log info "tp5e4: 08 log warf" } +:do { :if ([:len [/ip firewall filter find comment="TP5: input deny-by-default"]] = 0) do={ /ip firewall filter add chain=input action=drop comment="TP5: input deny-by-default" } } on-error={ :log info "tp5e4: 09 drop warf" } + +# 9) JIT-Admin-Gruppe (D3 aus dem Runbook). Dauerregel, LEERE Liste: solange +# niemand drinsteht, oeffnet sie nichts. Wer scannen oder ein IoT-Geraet +# anlernen will, traegt sich selbst mit timeout ein: +# /ip firewall address-list add list=jit-admin address=10.40.10.183 timeout=1h +# Das ersetzt die Dauerregel MAIN->IOT, die lanscan.app sonst braeuchte. +:do { :if ([:len [/ip firewall filter find comment="TP5-E4: JIT-Admin aus MAIN"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=vlan10 src-address-list=jit-admin comment="TP5-E4: JIT-Admin aus MAIN" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e4: 10 jit warf" } + +:log info ("tp5e4: ENDE input-regeln=" . [:tostr [:len [/ip firewall filter find chain=input]]] . " seal-lan-disabled=" . [:tostr [/ip firewall filter get [find comment="TP10-seal-lan"] disabled]] . " input-drop=" . [:tostr [:len [/ip firewall filter find comment="TP5: input deny-by-default"]]] . " jit=" . [:tostr [:len [/ip firewall filter find comment="TP5-E4: JIT-Admin aus MAIN"]]])