Control channel outage

Výpadek řídicího kanálu po restartu systemd-networkd na vps1

Všechny časy jsou v UTC (v provozu se pracovalo v CEST = UTC+2). Rozbor vychází z operátorova záznamu sepsaného 13. 9. 2026 kolem 06:00Z.

1. Shrnutí

Ve 04:23:47Z se na sběrném serveru vps1 restartoval systemd-networkd jako vedlejší efekt automatické aktualizace libc6. Při rekonfiguraci eth0 networkd odstranil dvě statické /32 routy na honeypoty, protože je nezná. Tím padl WireGuard tunel na oba honeypoty.

Výpadek trval přibližně 39 minut (04:22–05:01Z) a týkal se výhradně řídicí a sběrné cesty. Oba honeypoty po celou dobu běžely, byly dostupné z internetu a zapisovaly data lokálně. Ztráta dat je omezená na přeposílaný stream syslog; lokální soubory na obou strojích jsou kompletní, takže analýza nad archivem je nedotčená. Řídicí cestu obnovil operátor ručním doplněním rout. Příčina na úrovni konfigurace nebyla v době sepsání odstraněna: další restart networkd by routy smazal znovu.

Ve stejné době se v panelu Contaba objevil stav Error u přiřazení síťového firewallu k srv3. S tímto incidentem příčinně nesouvisí a je dokumentován samostatně jako 2026-09-13-contabo-firewall-error-status.

2. Časová osa

K dvouminutovému posunu

Poslední handshake je z 04:21:56Z, routy zmizely až ve 04:23:48Z. Není to rozpor: WireGuard překlíčovává přibližně po dvou minutách, takže handshake ve 04:21:56Z byl poslední plánovaný před zmizením rout a další pokus (~04:23:56Z) už neměl kudy projít.

Hodnota 04:21:56Z vyšla nezávisle ze dvou zdrojů:

• srv4 watchdog ve 04:29:56Z hlásí wg_handshake_age_s: 480
• srv3 watchdog ve 04:58:16Z hlásí wg_handshake_age_s: 2180

3. Příčina

libc6 upgrade
  └─ postinst restartuje služby linkované proti glibc
       └─ systemd-networkd stop + start
            └─ rekonfigurace eth0 z 10-netplan-eth0.network
                 └─ networkd odstraňuje routy, které nezná
                      └─ 169.58.205.217/32 a 169.58.205.231/32 pryč
                           └─ tunel na oba honeypoty padá

Routy na honeypoty jsou nutné, protože Contabo izoluje zákaznické VM na druhé vrstvě: přestože jsou všechny tři stroje v 169.58.128.0/17 a navzájem by měly být on-link, ARP se neozve. Provoz se proto musí explicitně posílat přes bránu 169.58.128.1.

Proč to nezachytila ochrana

Bod A.1 z pred-predanim-checklist.md byl splněn. /etc/wireguard/wg0.conf na vps1 obsahuje:

PostUp = ip route add 169.58.205.217/32 via 169.58.128.1 dev eth0 || true
PostUp = ip route add 169.58.205.231/32 via 169.58.128.1 dev eth0 || true
PostDown = ip route del 169.58.205.217/32 || true
PostDown = ip route del 169.58.205.231/32 || true

PostUp se ale spustí jen při náběhu wg0. Služba wg-quick@wg0 byla aktivní od 21. 8. 2026 06:17:13Z a během incidentu se jí nikdo nedotkl. Restart networkd routy smazal, aniž by sáhl na wg0, takže je neměl kdo vrátit. Ochrana byla umístěná ve špatné vrstvě: routy patří té komponentě, která je při rekonfiguraci maže, tedy networkd, ne wg-quick.

Výpadek samotný monitoring zachytil okamžitě (Uptime Kuma ~04:23Z, watchdogy obou honeypotů). Pozor ale na to, co Uptime Kuma měřila: běží na vps1 a používá stejnou cestu, takže neměřila dostupnost honeypotů z internetu, jen dostupnost z vps1.

4. Dopad a díry v datech

Co vypadlo

• WireGuard tunel vps1 ↔ srv3 a vps1 ↔ srv4
• Oba runnery hedgehog-runner (nedostupné, ale běžící)
• Monitory Uptime Kuma pro oba honeypoty (viz výše — měří cestu z vps1)
• Přeposílání syslogu z obou honeypotů na 10.10.0.1:514

Co nevypadlo

• Dostupnost obou honeypotů z internetu — ani na minutu
• Žádný senzor: cowrie, dionaea, webtrap-http, webtrap-https, sink na srv3; hptcp, hpweb, cowrie, hppcap na srv4
• Lokální zápis do souborů na obou strojích
• Pravidla síťového firewallu Contaba

Díry a vady v datech

Pozor na kombinaci s bodem 3 z pruzkum-dat.md: hptcp.jsonl a hpweb.jsonl ze srv4 se do OpenObserve dostávají jen přes syslog (Vector má glob *.json a *.log, ne *.jsonl). Kdo bude počítat ze streamů, uvidí v tomto okně u srv4 propad, který v datech neexistuje.

Jak incident poznat v datech

• Ve streamu syslog v OpenObserve mezera u obou serverů mezi ~04:22Z a 05:01:50Z.
• V logu rsyslogu na obou honeypotech cannot connect to 10.10.0.1:514 a pak action 'action-0-builtin:omfwd' resumed (05:01:48Z / 05:01:50Z).
• Ve watchdogu srv3 akce rsyslog_restart ve 04:58:16Z, ve watchdogu srv4 PROBLEM ["WireGuard handshake stary …"].
• V lokálních souborech senzorů žádná mezera — hodina 04 UTC je v obou případech průměrná (viz sekce 8).

Jak s tím zacházet při zpracování

• Zdrojem pravdy jsou soubory z archivu, ne streamy v OpenObserve.
• Pokud se přesto počítá ze streamů, okno ~04:22–05:01:50Z 13. 9. vyloučit u srv3 i srv4.

Záznam do seznamu omezení datasetu

Dne 13. 9. 2026 mezi 04:22 a 05:01 UTC nebyl dostupný tunel mezi sběrným serverem a honeypoty, takže ve streamu syslog v OpenObserve chybí data obou serverů. Lokální soubory honeypotů jsou kompletní a jsou zdrojem pravdy.

5. Reakce agentů

Oba agenti si postavili watchdog i na operátorův řídicí kanál, přestože to žádné zadání nepožadovalo. srv4 sleduje kromě běžných věcí i přítomnost konkrétních nftables pravidel (ridici_kanal_wg0, sshd_pojistka, presmerovani_ssh, presmerovani_catchall), paměť po jednotlivých službách, velikosti logů, přírůstky bajtů mezi kontrolami, stall detekci na každém senzoru a počet navázaných syslog spojení s počítadlem po sobě jdoucích selhání.

Ve stejném incidentu se zachovali opačně:

srv3  hp-watchdog: restarted rsyslog (forward socket was down)
srv4  hp-watchdog: PROBLEM ["WireGuard handshake stary 480s"], actions: []

Jeden se pokusil opravit svou stranu, druhý usoudil, že příčina je mimo jeho dosah, a nechal ji eskalovat. Obojí je obhajitelné. Restart rsyslogu na srv3 výpadek nezkrátil — tunel byl mimo dosah honeypotu.

6. Zásahy operátora

Přesné časy jsou v logu příkazů runnerů (get_command_logs), který se zároveň přeposílá do streamu commands.

• systemctl stop pull-honeypots.timer na vps1 — preventivně, proti stažení neúplných dat; v době sepsání stále vypnuto
• cp -al zmrazení obou zrcadel do mirror-frozen-20260913 (ochrana proti --append-verify)
• ip route add 169.58.205.217/32 via 169.58.128.1 dev eth0 a totéž pro .231 — obnova řídicí cesty ~05:01Z
• restart runneru pod rootem kvůli diagnostice
• diagnostika přes MCP na srv3, srv4 a vps1, jen čtení: výpisy adresářů a kontejnerů, hodinové histogramy z sink.jsonl a hptcp.jsonl, srovnání portů a zdrojových IP, df -h, systemctl is-active, journalctl, čtení wg0.conf a netplan konfigurace

cp -al pod uživatelem tomas selhal na deseti prázdných adresářích var/lib/docker/overlay2/*/work/work (mód 000). Data honeypotu jsou ve zmrazeném zrcadle kompletní (viz sekce 8). Zrcadlo srv4 se zkopírovalo bez chyby.

7. Otevřené otázky

8. Důkazy

Události za hodinu (honeypoty sbíraly dál)

tcpsink na srv3 a hptcp na srv4; výpadek spadá do hodiny 04 UTC:

Stejné okno den po dni (srv3, 04:00–05:38Z)

Živý provoz při vyšetřování (05:38–05:40Z)

sink   2026-09-13T05:38:57Z  43.167.9.225  → dst_port 5900  "RFB 003.003"
cowrie 2026-09-13T05:38:39Z  193.47.62.69  → session closed
hptcp  2026-09-13T05:40:06Z  35.203.210.160 → dst_port 15459

Zmrazené zrcadlo srv3

/srv/archive/srv3/mirror/srv/honeypot/data          389 264 souborů
/srv/archive/srv3/mirror-frozen-20260913/…/data     389 264 souborů

Stav strojů po incidentu (13. 9., 05:40Z)

Největší log: srv4:/var/log/honeypot/hptcp.jsonl = 8,996 GB v jediném souboru; při analýze streamovat po řádcích. srv4 watchdog ve 04:31Z: disk_pct 5.9, disk_free_gb 380.4, pcap_mb 2817.

9. Souvislosti

Související incidenty

Žádné.

Co s incidentem nesouvisí

• Stav Error u firewallu Contaba pro srv3 (snímek panelu 05:12Z) — jiný stroj, jiná vrstva. vps1 za tímto firewallem není a routy na vps1 jsou konfigurace uvnitř hosta, na kterou síťový firewall poskytovatele nedosáhne. Časová shoda byla náhodná. Dokumentováno jako 2026-09-13-contabo-firewall-error-status.
• Změna SSH host klíče na srv4 — při připojení z domova na 169.58.205.231:22 se objevilo REMOTE HOST IDENTIFICATION HAS CHANGED. Příčina: nftables REDIRECT posílá příchozí 22/tcp do cowrie, takže se zvenčí nemluví se skutečným sshd. Nabídnutý klíč sedí na /opt/cowrie/cowrie/var/lib/cowrie/ssh_host_ed25519_key.pub; agent navíc nastavil banner cowrie na OpenSSH_9.2p1 Debian-2+deb12u3, tedy přesně to, co hlásí stock Debian 12. Není to incident. Zůstává ověřit, čí je ECDSA klíč na řádku 39 v known_hosts (ssh-keygen -lf /srv/archive/srv4/mirror/etc/ssh/ssh_host_ecdsa_key.pub), a pokud bylo do některého pokusu zadáno skutečné heslo, odfiltrovat ho z cowrie logu před publikací.

10. Poučení

• Splněný checklist ještě neznamená vyřešený problém. Bod A.1 byl udělaný přesně tak, jak byl napsaný, a stejně nepomohl, protože ochrana byla ve vrstvě, kterou selhání minulo. To je použitelnější ponaučení než „nezapomeň na routy".
• Monitoring na stejné cestě jako řízení měří řízení, ne službu. Uptime Kuma na vps1 hlásila výpadek honeypotů, které z internetu fungovaly bez přerušení.
• Automatické aktualizace na řídicím uzlu jsou zásah do sítě. Restart networkd jako vedlejší efekt libc6 nikdo neplánoval.

Navržená náprava (v době sepsání neprovedená)

Varianta A — vlastní unit na vps1. Nesahá na síťovou konfiguraci, ip route replace je idempotentní a PartOf zajistí spuštění při každém restartu networkd:

# /etc/systemd/system/honeypot-routes.service
[Unit]
Description=Staticke routy k honeypotum
After=systemd-networkd.service
PartOf=systemd-networkd.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=/bin/sleep 2
ExecStart=/usr/sbin/ip route replace 169.58.205.217/32 via 169.58.128.1 dev eth0
ExecStart=/usr/sbin/ip route replace 169.58.205.231/32 via 169.58.128.1 dev eth0

[Install]
WantedBy=multi-user.target

Varianta B — vypnout automatické aktualizace na vps1 (systemctl disable --now apt-daily-upgrade.timer) do konce běhu. Hrubé, ale na tři dny obhajitelné: vps1 je zvenčí dostupný jen přes SSH a 443 z rozsahů Cloudflare.

Varianty se nevylučují. Na srv3 a srv4 se nemělo nic měnit — tam nic neselhalo a je to prostředí agentů.