Initial import from bf-network-r6.opencode — opencode migration

This commit is contained in:
2026-08-26 12:44:21 +02:00
commit 5ee0716dda
297 changed files with 72324 additions and 0 deletions

View File

@@ -0,0 +1,100 @@
# TP5 Etappe 2 — Whitelists auf crs326-core.
#
# Quelle: NICHT geraten, sondern aus 43.027 Zeilen Log-Lauf abgeleitet
# (Kollektor 10.40.20.18, Fenster 2026-08-16T17:21 .. 2026-08-17T14:05).
# Beobachtete Matrix (in -> out):
# 20682 vlan20->vlan99 8082 vlan10->vlan20 7123 vlan20->vlan10
# 6238 vlan20->vlan30 306 vlan30->vlan20 237 vlan10->vlan30
# 214 vlan10->vlan99 17 vlan10->vlan10 2 vlan30->vlan10
# 137 cf-mesh->{vlan20,vlan99}
# vlan40/50/90: NULL Inter-VLAN -> Internet-only ist risikofrei (D6).
#
# Entscheidungen (User 2026-08-17):
# D1 = MAIN->INFRA pauschal accept (MAIN ist das Trusted-VLAN, INFRA die
# eigene Serverzone; Least-Privilege bleibt bei IOT/UNTRUSTED/GUEST/MGMT).
# D4 = MGMT named sources: HA:8728 + Nautobot:22 + vlan10 + cf-mesh, Rest drop.
# D5 = IOT->INFRA: beobachtet ist nur 8123; MQTT 1883/8883 als dokumentierte
# Absicht mit aufgenommen (Shelly-Push kann jederzeit dazukommen).
#
# BLOCKIERT NICHTS: ausschliesslich action=accept. Der Drop kommt in Etappe 3.
#
# Push: python3 nautobot/gc-manual-plan.py --device crs326-core \
# --commands-file routeros/tp5-etappe2-whitelists.rsc \
# --change-id TP5-Etappe2-Whitelists --deploy
# Backup davor: core-pre-tp5-etappe2-20260817.backup
#
# ABNAHMEKRITERIUM: der Zaehler der Log-Regel muss danach (nahezu) stehen
# bleiben. Solange sie Nutzverkehr sieht, ist die Whitelist unvollstaendig —
# das ist das Gate fuer Etappe 3.
#
# ---------------------------------------------------------------------------
# WICHTIG — place-before: alle Zeilen muessen VOR die Log-Regel. Sonst laeuft
# die Log-Regel weiter voll und das Abnahmekriterium oben ist nicht messbar
# (action=log ist nicht-terminierend, funktional waere es egal - messbar nicht).
# Alle Adds sind per :if [:len [find comment=...]]=0 idempotent, ein zweiter
# Lauf legt also nichts doppelt an. Jede Zeile eigenes on-error (Lehre aus
# Etappe 1: ein gescheiterter Netmiko-Deploy hinterlaesst Teil-Zustand).
# ---------------------------------------------------------------------------
# 1) LAN -> WAN. Ohne diese Zeile nimmt der spaetere Drop das ganze Haus vom
# Netz, inklusive der "Internet-only"-VLANs 50/90. Bekannt, braucht keinen
# Logbeleg, und aus demselben Grund stand schon die Log-Regel auf "!WAN".
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: LAN->WAN"]] = 0) do={ /ip firewall filter add chain=forward action=accept out-interface-list=WAN comment="TP5-E2: LAN->WAN" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 01 LAN->WAN warf" }
# 2) Cloudflare Mesh (TP16.1/TP16.3). 137 Logtreffer belegen den Pfad.
# Ohne diese beiden Zeilen sperrt der Drop den kompletten Fernzugang aus —
# und zwar genau den, mit dem man den Fehler zuruecknehmen wollte.
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: mesh->LAN"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=cf-mesh comment="TP5-E2: mesh->LAN" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 02 mesh->LAN warf" }
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: LAN->mesh"]] = 0) do={ /ip firewall filter add chain=forward action=accept out-interface=cf-mesh comment="TP5-E2: LAN->mesh" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 03 LAN->mesh warf" }
# 3) D1 — MAIN <-> INFRA pauschal. Beobachtet waren 13 Dienste (macmini
# udp/3722 Continuity 6234x, NAS 6690 1578x, Nautobot 8080, AirPlay 7000,
# pve-mcp 3000, ssh auf pve/NAS/macmini, Ollama 11434, ...). Die
# Rueckrichtung braucht eine eigene Zeile, weil Continuity je Richtung
# eigene Flows oeffnet (7123 "new" aus vlan20).
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: MAIN->INFRA"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=vlan10 out-interface=vlan20 comment="TP5-E2: MAIN->INFRA" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 04 MAIN->INFRA warf" }
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: INFRA->MAIN"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=vlan20 out-interface=vlan10 comment="TP5-E2: INFRA->MAIN" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 05 INFRA->MAIN warf" }
# 4) INFRA -> IOT. HA (10.40.20.105) pollt ~22 Shellys auf tcp/80, 6238 Zeilen.
# Richtungsasymmetrisch gewollt: INFRA darf IOT anfassen, nicht umgekehrt.
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: INFRA->IOT"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=vlan20 out-interface=vlan30 comment="TP5-E2: INFRA->IOT" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 06 INFRA->IOT warf" }
# 5) D5 — IOT -> INFRA, nur Dienste. Beobachtet: 10.40.30.249 -> HA:8123 (203x).
# MQTT mit drin, weil die Doku es als Absicht nennt und ein Shelly-Push
# jederzeit dazukommen kann. Influx 8086 NICHT: nie beobachtet, und der
# Weg dorthin laeuft ueber HA.
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: IOT->INFRA Dienste"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=vlan30 out-interface=vlan20 protocol=tcp dst-port=8123,1883,8883 comment="TP5-E2: IOT->INFRA Dienste" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 07 IOT->INFRA warf" }
# 6) D4 — MGMT (vlan99). Drei named sources, sonst nichts:
# a) MAIN komplett = Arbeitsplatz (.10.82 -> ssh/80/443 auf branch/ap1/ap2)
# b) HA .20.105:8728 = mikrotik-Integration, 20.667 Polls. Ohne diese Zeile
# brechen die HA-Integrationen.
# c) Nautobot .20.30:22 = Netmiko-Deploy der Golden Config. Ohne diese Zeile
# sperrt sich TP22 selbst aus — der Weg, ueber den dieser Push laeuft.
# cf-mesh ist bereits durch Zeile 2 gedeckt.
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: MAIN->MGMT"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=vlan10 out-interface=vlan99 comment="TP5-E2: MAIN->MGMT" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 08 MAIN->MGMT warf" }
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: HA->MGMT api"]] = 0) do={ /ip firewall filter add chain=forward action=accept src-address=10.40.20.105 out-interface=vlan99 protocol=tcp dst-port=8728 comment="TP5-E2: HA->MGMT api" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 09 HA->MGMT warf" }
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: Nautobot->MGMT ssh"]] = 0) do={ /ip firewall filter add chain=forward action=accept src-address=10.40.20.30 out-interface=vlan99 protocol=tcp dst-port=22 comment="TP5-E2: Nautobot->MGMT ssh" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 10 Nautobot->MGMT warf" }
# 7) Same-VLAN mDNS. vlan10 -> vlan10 udp/5353, erzeugt vom mDNS-Repeater auf
# dem Core selbst (17 Zeilen). Erreicht die forward-Kette und wuerde von
# einem blanken Drop getroffen -> Discovery INNERHALB von MAIN kaputt.
:do { :if ([:len [/ip firewall filter find comment="TP5-E2: same-VLAN mDNS"]] = 0) do={ /ip firewall filter add chain=forward action=accept in-interface=vlan10 out-interface=vlan10 protocol=udp dst-port=5353 comment="TP5-E2: same-VLAN mDNS" place-before=[/ip firewall filter find comment="TP5: log-only, Vorstufe zum deny-by-default"] } } on-error={ :log info "tp5e2: 11 same-VLAN mDNS warf" }
# ---------------------------------------------------------------------------
# BEWUSST NICHT AUFGENOMMEN:
#
# vlan10 -> vlan30 (237x udp/3722) und vlan30 -> vlan10 (2x): das ist das
# iPhone 10.40.30.201, das im IOT-SSID haengt. D2 ist entschieden — es wird
# ins MAIN-SSID umgehaengt (Hands-on bei Christoph), dann verschwindet die
# Richtung von selbst. Eine Whitelist auf .30.201 waere ausserdem instabil:
# iOS vergibt pro SSID eine eigene Private Address.
# => Vor Etappe 3 pruefen, ob die Zeilen aus dem Log verschwunden sind.
#
# MAIN -> IOT ICMP (lanscan.app, D3): keine Dauerregel. Gehoert in die
# JIT-Admin-Gruppe (address-list mit timeout), Etappe 4.
# ---------------------------------------------------------------------------
# Zaehlzeile: 11 Whitelist-Regeln erwartet. Per get_log zeilengenau auslesen —
# der Deploy-Job zeigt den Geraete-Output nicht (Lehre aus Etappe 1).
:log info ("tp5e2: ENDE whitelist-regeln=" . [:tostr [:len [/ip firewall filter find comment~"TP5-E2:"]]] . " logregel-disabled=" . [:tostr [/ip firewall filter get [find comment="TP5: log-only, Vorstufe zum deny-by-default"] disabled]])