TP5-Runbook: D3 entschieden (ICMP-Sweep = lanscan.app, gehoert in die JIT-Gruppe)

Der Dauersweep von .10.82 auf alle Shellys ist lanscan.app — ein Ad-hoc-Scan vom
Arbeitsplatz, kein Dienst. Also keine permanente MAIN->IOT-ICMP-Regel, sondern
Teil der selbstverfallenden JIT-Admin-Gruppe (deckt sich mit D4).

Hinweis fuer den Log-Lauf ergaenzt: der Scan erzeugt sonst Rauschen in Etappe 1.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-14 16:38:29 +02:00
parent 3113218212
commit f31172e4d9

View File

@@ -73,9 +73,11 @@ Beispiel: `INFRA→MEDIA` hat 178.142 Pakete auf dem Zähler, stand aber im Snap
1. 📱 **Ein iPhone sitzt in VLAN30 (IOT):** `10.40.30.201`, Hostname `iPhone`, und es spricht mit dem
Mac mini (`udp/3722`, Apple-Continuity-Muster). Entweder hat sich jemand bewusst ins `dirtyvader-iot`-SSID
gehängt, oder das ist ein Ausrutscher. **Ein IOT-Deny trennt dieses Gerät** — vorher klären, nicht danach.
2. 🔍 **`.10.82` („Mac") pingt im Dauerlauf alle ~30 Shellys** (223 offene ICMP-Conntrack-Einträge).
Sieht nach einem Monitoring-/Scan-Tool aus. Wenn das gewollt ist, braucht MAIN→IOT eine ICMP-Ausnahme;
wenn nicht, ist es der erste Kandidat zum Abdrehen.
2. ✅ **`.10.82` („Mac") pingt alle ~30 Shellys — GEKLÄRT (User 2026-08-14): das ist `lanscan.app`**, also
ein Ad-hoc-Scan vom eigenen Arbeitsplatz, kein Dauerdienst. **Konsequenz: keine permanente
MAIN→IOT-ICMP-Regel bauen** — der Scan gehört in die **JIT-Admin-Gruppe** (address-list mit
`timeout`, s. §3/D3). Beim Log-Lauf erzeugt er sonst viel Rauschen: entweder während Etappe 1
nicht scannen, oder die Treffer beim Auswerten bewusst ausfiltern.
3. 🔑 **VLAN99 ist Mitglied der `LAN`-Liste** → `TP10-seal-lan` erlaubt Mgmt-Input aus *jedem* VLAN.
„MGMT isolieren" (TP5-Ziel) heißt also: `seal-lan` verengen — das ist derselbe Griff, der die
5 mDNS-Regeln scharf schaltet. **Beides passiert zusammen oder gar nicht.**
@@ -88,7 +90,7 @@ Beispiel: `INFRA→MEDIA` hat 178.142 Pakete auf dem Zähler, stand aber im Snap
|---|---|---|
| **D1** | MAIN→INFRA: welche Dienste? | Beobachtet: NAS `6690`, pve-mcp `3000`, macmini `49152`, `3722`. Vorschlag: **erst mit dem Log-Lauf (Etappe 1) vervollständigen**, dann Whitelist — nicht jetzt raten. |
| **D2** | iPhone `.30.201` in IOT | Ins MAIN-SSID holen (sauber) **oder** bewusst als Ausnahme dulden. Empfehlung: umhängen. |
| **D3** | ICMP-Sweep `.10.82`→IOT | Zweck klären. Falls Monitoring: schmale Regel `vlan10 → vlan30 protocol=icmp`. |
| **D3** | ~~ICMP-Sweep `.10.82`→IOT~~ | ✅ **ENTSCHIEDEN (2026-08-14): `lanscan.app`, Ad-hoc vom Arbeitsplatz.** Keine Dauerregel — läuft über die **JIT-Admin-Gruppe** (selbstverfallend). Deckt sich mit D4. |
| **D4** | Wer darf auf VLAN99-Mgmt? | Vorschlag: nur MAIN (`vlan10`), Rest drop. `seal-lan` entsprechend verengen. |
| **D5** | IOT→INFRA-Whitelist | Doku nennt MQTT 1883/8883, HA-API, Influx 8086. Beobachtet real: **`8123` (HA), `5540/udp` (Matter)**. Vorschlag: die beobachteten + MQTT. |
| **D6** | UNTRUSTED/GUEST | Beide tragen **null** Inter-VLAN-Verkehr → Internet-only sofort und gefahrlos pinnbar. |