Zum Inhalt springen

Honeypot-Experiment

2026-08-22-srv3-sshd-move-broke-operator-backup

Innerhalb eines Monats Betrieb sind mehrere Dinge kaputtgegangen – einiges wurde vom Agenten, einiges vom Anbieter und einiges vom Betreiber beschädigt. Zu jedem Vorfall gibt es eine eigene Analyse mit einer Zeitleiste, der Ursache und einer Auflistung der verlorenen Gegenstände.

Analyse aktualisiert: 02.10.2026 20:00:00 UTC+02:00

Problem melden
Zurück zur Übersicht der Vorfälle

Übersicht über den Vorfall #


Die Daten sind vorhanden Schweregrad: winzig Verursacht: Agent gelöst
Bezeichnung
2026-08-22-srv3-sshd-move-broke-operator-backup
Anfang
22.08.2026 00:01:00 UTC
Festgestellt
Ich füge hinzu
Man begann, sich damit zu befassen
Ich füge hinzu
Gelöst
22.08.2026 00:15:00 UTC
Länge
14 min
Ursache
sshd_bind_change belegt
Wer hat das bemerkt?
Betreiber
Betroffene Server
srv3
Auswirkung
Steuerkanal
Eingriffe des Bedieners
1
Offene Fragen
3
  • bis zur Klärung
Beginn 00:01Gelöst 00:15

Auswirkungen auf Honeypots und Daten #


Reaktionen der Agenten

Server Reaktion
srv3 nicht vermerkt

Lücken in den Daten

Der Vorfall hat keine Datenlücken verursacht.

Änderungshistorie der Analyse #


Die Analyse wird nicht stillschweigend überschrieben: Jede Änderung wird im Abschnitt Änderungen

Die Analyse hat sich seit der Veröffentlichung nicht geändert.

Analyse #


Die Analyse ist in der Sprache dieser Seite nicht verfügbar. Es wird die Version in der Sprache Tschechisch angezeigt – es handelt sich nicht um eine Übersetzung.

Verfügbare Sprachen für die Analyse: Tschechisch

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)KomponentaCo se staloZdroj
2026-08-22T00:00:00Z – 01:00:00ZnasazeníOkno nasazení honeypotu: docker, hpnet, cowrie, dionaea, webtrap, rsyslog 95-honeypot.conf, přesun sshd[VIDĚL]
2026-08-22T00:01:00ZsshdPřesun sshd na 10.10.0.2:62222 rozbil zálohovou cestu operátora[VIDĚL]
2026-08-22T00:02:00Z – 00:17:00ZcowrieTestovací loginy root/hunter2, admin/test123 z 10.222.0.1 — senzor už v tu dobu běžel[VIDĚL]
2026-08-22T00:15:00Zsshd / zálohaKonec okna, ve kterém byla záloha rozbitá[VIDĚL]
neznámo (po 00:15Z)operátorOperátor si zálohu přenastavil na novou adresu a port[VIDĚL]
2026-08-22T11:20:00Z – 12:53:00Zssh.servicePři kontrole č. 1 přidán drop-in, aby ssh.service čekal na wg0[VIDĚL]
2026-09-11T06:00:12Z, 18:00:12ZsshdPř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-runner poslouchá na portu 26412 přes WireGuard, nezávisle na vazbě sshd. [ODVOZENO]
  • Přeposílání syslogu — běží přes rsyslog omfwd 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 / streamPoleOdDoCharakterNenávratné?Kde jsou data kompletní
————žádná díra ani vadaneVš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 na wg0 — 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 Accepted jako 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ázkaKde 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+R20jiJtvMRHwq04bNRSs40QtP7oc3bXY4

9. 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á na wg0 (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.