2026-08-22-srv3-pcap-ring-buffer-snaplen

Pcap: chybějící začátek, oříznutý snaplen a přepisující ring buffer

Všechny časy jsou v UTC. Rozbor slučuje záznamy tří relací agenta (kontroly č. 2, 5 a závěrečná kontrola 11. 9.). 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í

Záznam paketů na veřejném rozhraní nebyl součástí prvotního nasazení. Agent ho zřídil až při kontrole č. 1, 2026-08-22 v 11:31:30Z, jako službu hp-pcap s tcpdump -s 256 -C 100 -W 20. [VIDĚL] log runneru. Z toho plynou tři dopady na data:

1. Od spuštění senzorů (nejpozději 00:15:21Z) do 11:31:30Z pcap neexistuje. Nejde o přepsání, sběr ještě neběžel. [VIDĚL]
2. Pakety v souborech hp.pcap00–hp.pcap05 jsou oříznuté na 256 B včetně hlaviček, takže payload nad zhruba 200 B v nich není. Platí to do 24. 8. 18:51:48Z. [VIDĚL]
3. Ring buffer -C 100 -W 20 po každém startu služby začíná znovu u hp.pcap00 a existující soubor přepíše. Po rebootu serveru v 11:33:40Z se tak přepsaly přibližně 4 minuty záznamu. K přetočení celé kapacity (20 × 100 MB) nedošlo — existovalo jen 6 souborů; při tehdejším tempu by se strop vyčerpal zhruba kolem 31. 8. [ODVOZENO]

V předávacím dokumentu i ve dvou rozborech se objevovalo tvrzení, že „pcap z prvních ~10 h po nasazení byl přepsán ring bufferem". Log příkazů ho nepotvrzuje: spojuje dvě různé věci — absenci pcapu před 11:31Z a krátké přepsání po rebootu. Odhady okna ztráty, které z té věty vycházely (00:00–10:00Z nebo 12:53–23:00Z), jsou proto nahrazeny hodnotami z logu příkazů. Agent 24. 8. v 18:51:48Z přešel na hodinové soubory s plným snaplenem, které se nepřepisují. Stav na konci experimentu: vyřešeno; staré soubory zůstaly zachované, 11. 9. bylo v data/pcap/ 438 souborů a 24 GB.

2. Časová osa

Nesrovnalosti: časy z ls jsou v CEST a byly převedeny. Výpis ze 4. 9. uvádí u souborů značku …Z (např. 2026-08-24T20:51:46Z hp.pcap05), ale šlo o literál z --time-style, ne o UTC — 20:51:46 je místní čas, tedy 18:51:46Z, což sedí na restart služby v 18:51:48Z. Ze stejného důvodu je chybný dřívější odhad, že první hodinový soubor vznikl kolem 18:55Z; vznikl v 18:52:09Z. [ODVOZENO] Kdy přesně začal být honeypot dostupný z internetu, v záznamu není; poznámka z 22. 8. 00:28Z uvádí, že tou dobou ještě žádné vnější útoky nebyly. [NEJISTÉ]

3. Příčina

pcap nebyl součástí prvotního nasazení, vznikl až při kontrole č. 1 (11:31:30Z)
  ├─ do té doby žádný paketový záznam neexistuje
  └─ konfigurace zvolená pro úsporu místa:
       ├─ -s 256 (jen prvních 256 B paketu)
       │    └─ v hp.pcap00–05 chybí payload nad ~200 B (TLS ClientHello, HTTP těla, SMB payloady)
       └─ -C 100 -W 20 (ring buffer, strop 2 GB)
            ├─ tcpdump po restartu začíná u indexu 00 a existující soubor přepíše
            │    └─ záznam z ~4 minut před rebootem 11:33:40Z je přepsán
            └─ po vyčerpání 20 souborů by se přepisovaly nejstarší soubory
                 └─ nenastalo — do 24. 8. existovalo jen 6 souborů

Obě vlastnosti jsou doložené zněním skriptu, včetně komentáře, který ring buffer popisuje jako záměr. [VIDĚL] Volba byla vědomá, ale neodpovídala délce běhu: strop 2 GB stačí zhruba na devět dní, běh měl trvat necelý měsíc. Přepsání začátku hp.pcap00 po rebootu je odvozené z chování tcpdump -W; obsah souboru čten nebyl, takže jde o hypotézu. [ODVOZENO]

Zadání výslovně říkalo, že data se budou třídit až po skončení běhu a co se nezaznamená, už nepůjde získat zpětně. Ring buffer je s tím v rozporu, protože sám rozhoduje, co zahodí. [VIDĚL] zadání

Proč to nezachytila ochrana

Watchdog u pcapu kontroloval jen to, že služba běží:

# 5) pcap capture must be running.
systemctl is-active --quiet hp-pcap || { systemctl restart hp-pcap >/dev/null 2>&1 && { say "restarted hp-pcap"; actions+=("pcap_restart"); }; }

Běžící služba nic neříká o snaplenu, o tom, kolik historie se vejde na disk, ani o tom, že restart přepíše první soubor. Vada se neprojevovala chybou — zachytávání fungovalo, jen zaznamenávalo méně. Odhalilo ji až čtení konfigurace při kontrole č. 2. [VIDĚL]

4. Dopad a díry v datech

Co vypadlo

• Pcap od začátku sběru do 2026-08-22T11:31:30Z — adresář i skript vznikly až tehdy. [VIDĚL]
• Pcap z ~4 minut mezi nasazením a rebootem (11:31:30Z–~11:35:51Z). [ODVOZENO]
• Payload nad 256 B ve všech paketech zachycených do 24. 8. 18:51:48Z. [VIDĚL]

Co nevypadlo

• Senzorová data za celé toto období — cowrie.json, dionaea.json, webtrap.jsonl, sink.jsonl mají záznamy z 22. 8. (hodinové pokrytí 22. 8.: dionaea, cowrie, webtrap 14 h, sink 13 h). [VIDĚL]
• Soubory hp.pcap00–hp.pcap05 — při změně konfigurace ponechány, nesmazány. [VIDĚL]
• Metadata spojení (IP, porty, časy, průběh TCP) i v období s -s 256 — hlavičky se do 256 B vejdou. [ODVOZENO]
• Pcap od 24. 8. 18:52:09Z — hodinové soubory, plná délka paketů, souvisle do konce běhu. [VIDĚL]

Díry a vady v datech

Jak incident poznat v datech

• Podle názvu souboru: hp.pcapNN = starý režim (snaplen 256), hp-*Z.pcap = nový režim (plný snaplen). Jediná výjimka v pojmenování je hp-20260824-205148.pcap.
• Uvnitř souborů: v hp.pcap00–hp.pcap05 je caplen 256 u všech delších paketů, len je větší; hlavička uvádí snaplen 256, nové soubory 262144.
• Coverage: pcap= 0 pro 22. a 23. 8. neznamená, že pcap chybí — data jsou v jinak pojmenovaných hp.pcapNN.
• Čas prvního paketu v hp.pcap00 je hranice, odkud pcap vůbec existuje.

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

1. Analýzy obsahu paketů (rekonstrukce relací, extrakce souborů, otisky TLS) dělat jen nad hp-*Z.pcap.
2. Analýzy hlaviček (počty spojení, porty, časování, zdroje) jdou nad celým obdobím, ale před ~11:35Z 22. 8. pcap neexistuje — tam použít výhradně senzorové logy.
3. Objemy provozu ze starých souborů počítat z pole len, ne z caplen.
4. 22. 8. nepočítat jako úplný den při denních objemech z pcapu.
5. hp-20260824-205148.pcap přejmenovat nebo řadit podle času prvního paketu.
6. Odhady okna ztráty „~10 h" z dřívějších dokumentů nepoužívat; platné hranice jsou v tabulce výše.

Záznam do seznamu omezení datasetu

Záznam paketů začíná až 22. 8. 2026 kolem 11:35 UTC, nikoli se startem honeypotu, a do 24. 8. 2026 18:51 UTC byl pořizován s omezením 256 bajtů na paket, takže v souborech hp.pcap00–hp.pcap05 chybí obsah nad rámec hlaviček. Od 24. 8. 2026 18:52 UTC se zaznamenávají celé pakety do hodinových souborů hp-*Z.pcap.

5. Reakce agentů

Ring buffer se snaplenem 256 zavedl agent při kontrole č. 1. Při kontrole č. 2 si při procházení systemd služeb vypsal skript a adresář s pcapy, z výpisu viděl, že existuje teprve šest souborů z dvaceti, a odvodil, že k přetočení dojde v průběhu běhu. Přešel na časově pojmenované soubory, které se nepřepisují, a zvedl snaplen na plný; tlak na disk přenechal watchdogu (mazání pcapů starších 3 dnů až při zaplnění nad 85 %, které se za celý běh nespustilo). Staré soubory ponechal. Při prvním nasazení použil vzor názvu, který tcpdump plní místním časem; všiml si toho a doplnil TZ=UTC, jeden soubor s místním časem v názvu ale zůstal.

V hlášení operátorovi agent ztrátu popsal větou „pcap z prvních ~10 h po nasazení přepsán ring bufferem", která spojuje absenci pcapu před 11:31Z a přepsání po rebootu. Tato formulace se pak přenesla do pozdějších relací. Skutečnou hranici dostupného záznamu (první paket v hp.pcap00) nikdo nedoměřil.

• 2026-08-22T11:31:06Z a 11:31:30Z — vytvoření a oprava hp-pcap.sh (ring buffer, -s 256) — měnilo, zdroj incidentu [VIDĚL]
• 2026-08-24T18:40:33Z — systemctl cat hp-pcap.service; cat /srv/honeypot/bin/hp-pcap.sh; ls -la /srv/honeypot/data/pcap/ — jen čtení [VIDĚL]
• 2026-08-24T18:51:48Z — cp -a hp-pcap.sh hp-pcap.sh.bak-20260824 + nová verze + systemctl restart hp-pcap — měnilo [VIDĚL]
• 2026-08-24T18:52:09Z — sed -i 's|^exec /usr/bin/tcpdump|TZ=UTC exec /usr/bin/tcpdump|', vzor hp-%Y%m%dT%H%M%SZ.pcap, restart — měnilo [VIDĚL]
• 2026-08-24T18:52:39Z — kontrola, že soubor roste — jen čtení [VIDĚL]
• 2026-08-24T~18:54Z — do watchdogu kontrola, že nejnovější pcap byl zapsán v posledních 15 min, a mazání starých pcapů při disku ≥ 85 % — měnilo [VIDĚL]
• 2026-09-04 a 2026-09-11 — kontrola čerstvosti pcapu — jen čtení [VIDĚL]

6. Zásahy operátora

Žádné.

7. Otevřené otázky

8. Důkazy

Původní konfigurace (pořízeno 2026-08-24T18:40:33Z):

#!/bin/bash
# Rolling packet capture on the public interface (size-based ring buffer).
# -C 100 MB/file, -W 20 files => hard cap ~2 GB; tcpdump overwrites oldest and
# appends a rotating index (hp.pcap00..hp.pcap19). No strftime in -C mode.
# Excludes WireGuard tunnel, runner port, real sshd, and the collector host so
# only internet-facing attack traffic is captured. -s 256 keeps files compact.
exec /usr/bin/tcpdump -i eth0 -n -U -s 256 \
  -C 100 -W 20 -Z root \
  -w /srv/honeypot/data/pcap/hp.pcap \
  'not port 51820 and not port 26412 and not port 62222 and not host 169.58.204.57'

Vznik pcapu při kontrole č. 1 (log runneru, UTC):

11:31:06 # pcap ring buffer: eth0, bez tunelu/wg/runner, rotace po 100MB, max 20 souborů = strop 2GB mkdir -p /srv/honeypot/data/pcap cat > /srv/honeypot/bin/hp-pcap.sh <<'EOF' #!
11:31:30 systemctl stop hp-pcap rm -f /srv/honeypot/data/pcap/hp-%*.pcap* # Oprava: size-based ring buffer bez strftime v názvu (tcpdump -C přidává 00..19 sám)

11:33:40 echo "Stav před restartem zaznamenán. Restartuji server pro ověření persistence." …

Stav adresáře při kontrole č. 2 (časy v CEST):

-rw-r--r-- 1 root root 100000078 Aug 23 02:35 hp.pcap00
-rw-r--r-- 1 root root 100000226 Aug 23 11:42 hp.pcap01
-rw-r--r-- 1 root root 100000023 Aug 23 22:42 hp.pcap02
-rw-r--r-- 1 root root 100000123 Aug 24 07:54 hp.pcap03
-rw-r--r-- 1 root root 100000041 Aug 24 15:03 hp.pcap04
-rw-r--r-- 1 root root  38340357 Aug 24 20:40 hp.pcap05

Nová konfigurace, snaplen potvrzený tcpdumpem (časy v CEST):

Aug 24 20:51:48 srv3.cloud.batacek.eu hp-pcap.sh[319475]: tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

-rw-r--r-- 1 root root 5890 Aug 24 20:52 /srv/honeypot/data/pcap/hp-20260824-205148.pcap
-rw-r--r-- 1 root root 3547 Aug 24 20:52 /srv/honeypot/data/pcap/hp-20260824T185209Z.pcap

HANDOVER.md, CHANGELOG kontroly č. 2 — formulace, která se ukázala nepřesnou:

  Ztráta dat: dionaea ~2,5 h, HTTPS ~51 h, pcap z prvních ~10 h
  po nasazení přepsán ring bufferem.

Hodinové pokrytí (coverage.txt, 2026-09-11T17:55Z):

2026-08-22  dionaea=14 cowrie=14 webtrap=14 sink=13 pcap= 0
2026-08-23  dionaea=24 cowrie=24 webtrap=24 sink=24 pcap= 0
2026-08-24  dionaea=23 cowrie=24 webtrap=23 sink=24 pcap= 6
2026-08-25  dionaea=24 cowrie=24 webtrap=24 sink=24 pcap=24

9. Souvislosti

Související incidenty

• 2026-08-22-srv3-webtrap-https-tls-accept-hang — pcap je jediná náhrada za chybějící HTTPS data z 22.–24. 8., ale jen s 256 B na paket.
• 2026-08-24-srv3-dionaea-mongod-parser-freeze — pcap je jediná záloha pro okna zamrznutí dionaey; pro první okno (24. 8.) jen s oříznutými pakety.

Co s incidentem nesouvisí

• Mazání starých pcapů watchdogem při disku ≥ 85 % — opatření zavedené po tomto incidentu; nespustilo se (disk skončil na 43 %).
• Filtr pcapu vynechávající porty 51820, 26412, 62222 a kolektor — záměrná konfigurace, aby se do záznamu nedostal řídicí provoz.
• Mazání vadně pojmenovaných hp-%*.pcap* v 11:31:30Z — odstranění nefunkčního prvního pokusu, bez dat.

10. Poučení

• Konfiguraci „na úsporu" poměřovat délkou běhu. Ring buffer na 2 GB při tempu ~9 MB/h znamená devět dní historie — u měsíčního experimentu návrh, který data ztrácí z definice.
• tcpdump -C -W začíná po každém restartu znovu u indexu 00. Ring buffer tak není jen strop velikosti, ale i tichý mazací mechanismus při každém restartu a rebootu.
• tcpdump -G plní vzor názvu místním časem. Pro UTC názvy je nutné nastavit procesu TZ=UTC.
• Odhad zapsaný do dokumentace se usadí a tváří jako měření. Věta „~10 h přepsáno" se přenesla do tří rozborů, přestože skutečnou hranici šlo kdykoli odečíst jedním příkazem z prvního paketu.