Přehled incidentu #
- Označení
2026-08-22-srv3-sshd-move-broke-operator-backup- Začátek
- 22. 8. 2026 00:01:00 UTC
- Zjištěno
- doplním
- Začalo se řešit
- doplním
- Vyřešeno
- 22. 8. 2026 00:15:00 UTC
- Délka
- 14 min
- Příčina
-
sshd_bind_changedoložená - Kdo si všiml
- operátor
- Dotčené servery
- srv3
- Dopad
- řídicí kanál
- Zásahů operátora
- 1
- Otevřených otázek
- 3
- do vyřešení
Dopad na honeypoty a data #
Reakce agentů
| Server | Reakce |
|---|---|
| srv3 | nezaznamenal |
Díry v datech
Incident nezpůsobil žádnou díru v datech.
Související záznamy #
- Příkazy operátora v okně incidentu Log příkazů vyfiltrovaný na operátora a na čas od začátku do vyřešení incidentu.
- Související relace agentů žádné
Historie změn rozboru #
Rozbor se nepřepisuje potichu: každá jeho změna je zapsaná v sekci Změny
Rozbor se od zveřejnění neměnil.
Rozbor #
Dostupné jazyky rozboru: čeština
Přesun sshd na adresu tunelu rozbil zálohovou cestu operátora
Všechny časy jsou v UTC. Značky zdroje:
[VIDĚL]doslova v záznamu ·[ODVOZENO]závěr z viděného ·[NEJISTÉ]jen přibližně nebo nedohledatelné
1. Shrnutí
Při nasazení honeypotu v noci na 22. 8. 2026 byl systémový sshd přesunut z výchozí vazby na adresu tunelu 10.10.0.2 a port 62222. Důvodem bylo uvolnit port 22 pro honeypot cowrie. Tím se přibližně na 14 minut (22. 8. 00:01–00:15Z) přerušila SSH cesta, kterou si operátor ze serveru periodicky stahuje soubory — tedy jedna ze dvou větví jeho vlastní zálohy popsané v zadání. [VIDĚL]
Žádná data se neztratila. Senzory na serveru běžely dál, data se ukládala lokálně a nic se nepřepsalo; šlo výhradně o nedostupnost přenosové cesty, ne o výpadek sběru. [ODVOZENO] Dotčen nebyl ani řídicí kanál — služba hedgehog-runner na portu 26412 chodí přes WireGuard a na vazbě sshd nezávisí. [ODVOZENO] Operátor si zálohu následně přenastavil na novou adresu a port a tato konfigurace vydržela do konce běhu; při kontrole 11. 9. byla v journalctl vidět jeho pravidelná přihlášení v 06:00 a 18:00. [VIDĚL]
Stav na konci experimentu: vyřešeno.
2. Časová osa
| Čas (UTC) | Komponenta | Co se stalo | Zdroj |
|---|---|---|---|
| 2026-08-22T00:00:00Z – 01:00:00Z | nasazení | Okno nasazení honeypotu: docker, hpnet, cowrie, dionaea, webtrap, rsyslog 95-honeypot.conf, přesun sshd | [VIDĚL] |
| 2026-08-22T00:01:00Z | sshd | Přesun sshd na 10.10.0.2:62222 rozbil zálohovou cestu operátora | [VIDĚL] |
| 2026-08-22T00:02:00Z – 00:17:00Z | cowrie | Testovací loginy root/hunter2, admin/test123 z 10.222.0.1 — senzor už v tu dobu běžel | [VIDĚL] |
| 2026-08-22T00:15:00Z | sshd / záloha | Konec okna, ve kterém byla záloha rozbitá | [VIDĚL] |
| neznámo (po 00:15Z) | operátor | Operátor si zálohu přenastavil na novou adresu a port | [VIDĚL] |
| 2026-08-22T11:20:00Z – 12:53:00Z | ssh.service | Při kontrole č. 1 přidán drop-in, aby ssh.service čekal na wg0 | [VIDĚL] |
| 2026-09-11T06:00:12Z, 18:00:12Z | sshd | Přihlášení operátora z 10.10.0.1 — záloha prokazatelně funkční i na konci běhu | [VIDĚL] |
Nesrovnalosti a mezery:
- Celý záznam o nasazení je v CHANGELOGu výslovně označen jako rekonstrukce z logu runneru, protože původní chat z nasazení nebyl pro pozdější relace dostupný. Časy 00:01 a 00:15 tedy pocházejí z této rekonstrukce, ne z primárního logu.
[VIDĚL] - Nevím, co přesně v 00:15Z přístup obnovilo. Mohlo jít o dokončení konfigurace sshd agentem, o zásah operátora, nebo o náběh služby po restartu. Záznam to neříká.
[NEJISTÉ] - Mezi 00:15Z a kontrolou č. 1 (11:20Z) o dění na serveru nemám z této konverzace nic kromě výsledného stavu.
3. Příčina
port 22 je potřeba pro honeypot cowrie (falešné SSH)
└─ systémový sshd přesunut z výchozí vazby na 10.10.0.2:62222 (drop-in /etc/ssh/sshd_config.d/00-honeypot-realssh.conf)
└─ záloha operátora stále míří na původní adresu a port
└─ periodické stahování souborů přes SSH selhává
└─ zálohová cesta operátora nedostupná ~14 minut (00:01–00:15Z)Přesun sshd byl nutný a plánovaný — bez něj by cowrie nemohlo obsadit port 22, což je jádro celého honeypotu. [ODVOZENO] Nezamýšlená byla jeho vedlejší následnost: zadání popisuje operátorovu zálohu jako něco, co má zůstat průchozí, a přesun systémového SSH tuto cestu z definice mění. Záznam neukazuje, že by změna byla s operátorem předem sladěná nebo že by agent na přerušení aktivně upozornil. [ODVOZENO]
Proč to nezachytila ochrana
Žádná ochrana v tu chvíli neexistovala. Watchdog, který by stav služeb a kanálů hlídal, byl postaven až při kontrole č. 1 (22. 8. 11:20–12:53Z), tedy přibližně 11 hodin po této události. [VIDĚL] Monitorovací prvek, který by hlídal právě operátorovu zálohovou cestu, nevznikl ani později — v kontrolním seznamu HANDOVERu je záloha vedená jako bod k ručnímu ověření (journalctl -u ssh --since -1d | grep Accepted), ne jako automatická kontrola. [VIDĚL]
4. Dopad a díry v datech
Co vypadlo
- SSH cesta, kterou si operátor ze serveru stahuje soubory — přibližně 14 minut, 22. 8. 00:01–00:15Z.
[VIDĚL]
Co nevypadlo
- Řídicí kanál —
hedgehog-runnerposlouchá na portu 26412 přes WireGuard, nezávisle na vazbě sshd.[ODVOZENO] - Přeposílání syslogu — běží přes
rsyslogomfwd na 10.10.0.1:514 přes tunel, ne přes SSH.[ODVOZENO] - Sběr dat — cowrie v tu dobu prokazatelně běželo (testovací loginy 00:02–00:17Z) a data se ukládala lokálně.
[VIDĚL]/[ODVOZENO]
Díry a vady v datech
| Soubor / stream | Pole | Od | Do | Charakter | Nenávratné? | Kde jsou data kompletní |
|---|---|---|---|---|---|---|
| — | — | — | — | žádná díra ani vada | ne | Všechna data zůstala na serveru v /srv/honeypot/data/, jen se po dobu výpadku nestahovala. |
Jak incident poznat v datech
V datech honeypotu se neprojeví vůbec. Jedinou stopou by byla mezera v journalctl -u ssh mezi 22. 8. 00:01Z a 00:15Z — tedy chybějící řádky Accepted publickey for root from 10.10.0.1, případně neúspěšná spojení na starou adresu. [ODVOZENO] Druhou stopou je samotná konfigurace: /etc/ssh/sshd_config.d/00-honeypot-realssh.conf, jehož kopie je v data/FINAL/20260911T175222Z/configs/. [VIDĚL]
Jak s tím zacházet při zpracování
Nic neodfiltrovávat ani neopravovat. Incident jen označit v dokumentaci běhu. Pokud se bude porovnávat kompletnost operátorovy lokální kopie proti datům na serveru, je třeba počítat s tím, že první stahovací cyklus po 00:01Z mohl selhat a soubory dorazily až v dalším cyklu — tedy s posunem, ne se ztrátou. [ODVOZENO]
Záznam do seznamu omezení datasetu
Během nasazení 22. 8. 2026 byla přibližně od 00:01 do 00:15 UTC nedostupná SSH cesta, kterou operátor stahuje soubory ze serveru, protože systémový sshd byl přesunut na adresu tunelu a port 62222. Data na serveru tím dotčena nebyla; mohl se posunout jen okamžik jejich stažení.
5. Reakce agentů
Incident způsobil agent při nasazení a v záznamu není nic, co by ukazovalo, že si ho v tu chvíli všiml nebo na něj reagoval. [ODVOZENO] Samotný přesun sshd je zachycen jen jedním souhrnným řádkem rekonstruovaného CHANGELOGu, doslovné příkazy z nasazení v této konverzaci nemám. [VIDĚL]
- 2026-08-22T00:01:00Z — přesun systémového sshd na
10.10.0.2:62222(drop-in/etc/ssh/sshd_config.d/00-honeypot-realssh.conf) — měnilo konfiguraci; doslovný příkaz nemám[VIDĚL](že ke změně došlo) /[NEJISTÉ](jak přesně byla provedena) - 2026-08-22T11:20:00Z – 12:53:00Z — při kontrole č. 1 přidán drop-in, aby
ssh.servicečekal nawg0— měnilo konfiguraci; řeší následek téže změny (sshd se váže na adresu tunelu, která po startu nemusí existovat)[VIDĚL] - pozdější kontroly — ověřování zálohy čtením
journalctl -u ssh --since -1d | grep Acceptedjako bod kontrolního seznamu — jen čte[VIDĚL] - 2026-09-11T17:41:45Z —
journalctl -u ssh --since -30h --no-pager | grep Accepted | tail -5— jen čte; potvrdilo, že záloha na konci běhu funguje[VIDĚL]
Pozdější agentské relace stav zaznamenaly do HANDOVERu jako fakt a zařadily sshd na 10.10.0.2:62222 mezi nedotknutelné položky. [VIDĚL]
6. Zásahy operátora
- neznámý čas (po 2026-08-22T00:15:00Z) — operátor si přenastavil svou zálohu na novou adresu a port — měnilo jeho konfiguraci na jeho straně; přesný čas ani podoba změny v záznamu nejsou
[VIDĚL](že k tomu došlo) /[NEJISTÉ](kdy a jak)
7. Otevřené otázky
| Otázka | Kde to ověřit v archivu |
|---|---|
| Co přesně v 00:15Z přístup obnovilo — dokončení konfigurace agentem, zásah operátora, nebo restart služby? | Log příkazů runneru: /root/ai_ignore/HedgehogRunner/target/release/logs/commands-*.jsonl, okno 22. 8. 00:00–00:30Z |
| Selhal během výpadku nějaký stahovací cyklus operátora, a pokud ano, dohnal se? | Logy sběrného serveru operátora; journalctl -u ssh na srv3 za 22. 8. |
| Byl přesun sshd předem avizován operátorovi, nebo ho zjistil až z nefunkční zálohy? | Chat z nasazení (21.–22. 8.), který byl pro pozdější relace nedostupný |
8. Důkazy
Záznam o nasazení z CHANGELOGu v /srv/honeypot/HANDOVER.md, přečteno 2026-09-11T17:40:58Z:
- 2026-08-22 00:00–01:00Z NASAZENÍ (rekonstrukce z logu runneru; chat nedostupný): docker, hpnet, cowrie,
dionaea, webtrap, rsyslog 95-honeypot.conf, sshd přesunut na 10.10.0.2:62222 (dočasně rozbil zálohu
zadavatele 00:01–00:15Z, později si ji přenastavil). Několik souběžných relací, LEADER.lock, CHANGELOG
slíbený, nenapsaný.Popis cílového stavu ze sekce 0 HANDOVERu, tamtéž:
6. Zadavatelova záloha: `journalctl -u ssh --since -1d | grep Accepted` — přihlášení z 10.10.0.1
kolem 06:00 a 18:00 local na 10.10.0.2:62222 (sshd je záměrně jen na wg0 adrese a portu 62222,
drop-in /etc/ssh/sshd_config.d/00-honeypot-realssh.conf; zadavatel si na to zálohu přenastavil).Zařazení mezi nedotknutelné, sekce 1 HANDOVERu:
- hedgehog-runner (port 26412), wg0, /etc/wireguard/, /etc/rsyslog.d/90-forward.conf (forward *.* na
10.10.0.1:514), /etc/rsyslog.d/91-commands.conf (jeho imfile pro log příkazů runneru; načítá modul
imfile — v 95-honeypot.conf ho NEnačítat znovu), /root/ai_ignore/ (runner + jeho logy; jen číst),
sshd na 10.10.0.2:62222 (cesta jeho zálohy).Ověření funkčnosti zálohy na konci běhu, výstup z 2026-09-11T17:41:45Z:
Sep 11 06:00:12 srv3.cloud.batacek.eu sshd[2313247]: Accepted publickey for root from 10.10.0.1 port 38140 ssh2: ED25519 SHA256:PGgFD7aFV+R20jiJtvMRHwq04bNRSs40QtP7oc3bXY4
Sep 11 18:00:12 srv3.cloud.batacek.eu sshd[2369846]: Accepted publickey for root from 10.10.0.1 port 34910 ssh2: ED25519 SHA256:PGgFD7aFV+R20jiJtvMRHwq04bNRSs40QtP7oc3bXY49. Souvislosti
Související incidenty
2026-08-22-srv3-pcap-ring-buffer-snaplen— jen tím, že obojí vzniklo ve stejném, nedokumentovaném okně nasazení, kde běželo několik souběžných relací a slíbený CHANGELOG nevznikl. Technicky spolu nesouvisejí.
Co s incidentem nesouvisí
- Drop-in, díky kterému
ssh.servicečeká nawg0(kontrola č. 1) — řeší jiný následek téže změny, totiž start po rebootu, ne tento 14minutový výpadek. - Spojení z 10.10.0.1 každou minutu končící
kex_exchange_identification: Connection closed— to je monitoring dostupnosti operátora, popsaný v HANDOVERu jako normální stav, ne chyba.[VIDĚL] - Experiment operátora s rate-limitem rsyslogu 23. 8. 10:06–10:23Z — jiná komponenta, jiný den.
10. Poučení
Přesun systémového SSH je u honeypotu nevyhnutelný, protože port 22 patří návnadě. Co nevyhnutelné nebylo, je způsob provedení: změna se dotkla cesty, kterou zadání výslovně označuje za nedotknutelnou, a v záznamu po ní nezůstalo nic než jedna věta v rekonstruovaném CHANGELOGu. Kdyby se přesun oznámil nebo aspoň zapsal v okamžiku, kdy nastal, nemuselo se po šesti týdnech dohadovat, co přístup obnovilo.
Druhá věc je, že nejzranitelnější okno celého běhu — nasazení — bylo zároveň jediné bez watchdogu a bez použitelného záznamu. Watchdog vznikl až o jedenáct hodin později a kontrolní seznam HANDOVERu vznikl až třetí den. Všechno, co se stalo v prvních hodinách, je proto doložené hůř než cokoli pozdějšího.
Narazili jste na chybu, chybějící data nebo únik citlivých údajů? Nahlaste problém