Перейти к содержанию

Эксперимент с «медовой ловушкой»

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

За месяц работы сломалось несколько вещей — кое-что сломал агент, кое-что — поставщик, а кое-что — оператор. По каждому инциденту составлен отдельный отчет с хронологией событий, причиной и перечнем утраченного.

Анализ обновлен: 2. 10. 2026 20:00:00 UTC+02:00

Сообщить о проблеме
Вернуться к списку инцидентов

Обзор инцидента #


Данные присутствуют Серьезность: мелкая Причинил: агент решено
Обозначение
2026-08-22-srv3-sshd-move-broke-operator-backup
Начало
22. 8. 2026 00:01:00 UTC
Установлено
добавлю
Началось обсуждение
добавлю
Решено
22. 8. 2026 00:15:00 UTC
Длина
14 min
Причина
sshd_bind_change подтвержденная
Кто заметил
оператор
Затронутые серверы
srv3
Последствия
канал управления
Вмешательства оператора
1
Открытые вопросы
3
  • до разрешения
Начало 00:01Решено 00:15

Влияние на ханипоты и данные #


Реакция агентов

Сервер Реакция
srv3 не заметил

Пробелы в данных

Этот инцидент не привёл к утечке данных.

История изменений в анализе #


Анализ не редактируется незаметно: каждое его изменение фиксируется в разделе Изменения

Анализ не изменился с момента публикации.

Анализ #


Анализ недоступен на языке данного сайта. Отображается версия на языке: чешский язык — это не перевод.

Доступные языки анализа: чешский язык

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.