2026-09-13-contabo-firewall-error-status

Stav Error u přiřazení síťového firewallu Contaba

Všechny časy jsou v UTC. Časy z panelu a ticketu Contaba jsou zobrazené v CEST (UTC+2) a byly převedeny.

1. Shrnutí

Dne 13. 9. 2026 ráno si operátor při vyšetřování jiného incidentu všiml, že v panelu Contaba ukazuje firewall Honeypot_prod_srv3 (ID 69f39c0f-db2e-45ec-ac8c-dbeb8544d1ed, Active, 49 inbound pravidel) u instance vmi3520686 / 169.58.205.217 stav Error. Stejný stav měla ve stejnou dobu i instance srv4 (vmi3520717 / 169.58.205.231) u svého firewallu. U srv4 pomohl první Retry, u srv3 Retry opakovaně selhával a odebrání a opětovné přiřazení selhalo také.

Na sběr dat to nemělo žádný doložený vliv. Externí test výchozího deny na portu 26412 i nezměněná množina portů s provozem ukazovaly, že filtrace funguje dál. Contabo 16. 9. přiřazení opravilo a uvedlo, že v tomto případě šlo o problém se synchronizací zobrazení v panelu. Jak dlouho byl stav Error zobrazený před 13. 9. ráno, nelze zjistit, protože panel nikdo nemonitoroval. Stav na konci: vyřešeno poskytovatelem, ticket uzavřen 18. 9.

2. Časová osa

Nesrovnalosti: přesné časy Retry, odebrání a opětovného přiřazení nejsou zaznamenané, víme jen, že proběhly před odesláním ticketu. Okamžik, kdy Contabo přiřazení skutečně opravilo, v odpovědi není; 16. 9. 08:27Z je horní hranice.

3. Příčina

chyba synchronizace stavu v administraci firewallu Contaba (podle poskytovatele)
  └─ panel zobrazuje u přiřazení instance stav Error
       └─ Retry ani znovupřiřazení z panelu stav neopraví (u srv3)
            └─ datová rovina (filtrace provozu) podle externích testů nedotčena

Příčinu uvádí poskytovatel; zevnitř platformy ji ověřit nelze. Je ale v souladu se vším, co šlo změřit zvenčí (sekce 4 a 8). Proč se stav objevil současně u obou instancí a proč u srv4 stačil Retry a u srv3 ne, poskytovatel nevysvětlil.

Proč to nezachytila ochrana

Žádný monitoring stav panelu poskytovatele nesledoval — ani operátorův, ani watchdogy agentů, které do panelu nemají přístup. Na stav se přišlo náhodou při vyšetřování jiného incidentu. Watchdogy by naopak zachytily skutečný výpadek filtrace jen nepřímo (počet veřejných listenerů pub_listeners sleduje porty na hostu, ne pravidla firewallu).

4. Dopad a díry v datech

Co vypadlo

• Nic prokazatelně. Nefunkční byla jen správa přiřazení firewallu z panelu u srv3 (Retry, znovupřiřazení).

Co nevypadlo

• Filtrace na srv3 — port 26412/tcp nemá záměrně žádné ACCEPT pravidlo a spoléhá na výchozí deny. Zvenčí spojení vypršelo v timeoutu bez odpovědi, tedy drop, ne reject — ruleset se uplatňoval.
• Množina portů s provozem — proti předchozím dnům nezměněná (20 vs. 21 unikátních dst_port), žádné pravidlo tedy zjevně nepřestalo platit.
• Senzory a jejich porty — watchdog na srv3 hlásil konstantně pub_listeners: 43.
• Sběr dat na obou honeypotech.

Díry a vady v datech

Jak incident poznat v datech

V datech honeypotů se neprojeví. Jedinou stopou jsou snímek panelu a ticket u poskytovatele. Externí testy operátora na port 26412 se do dat nedostaly — na tom portu neposlouchá žádný senzor a pcap ho filtrem vynechává.

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

Nic neodfiltrovávat ani neopravovat; incident jen uvést v dokumentaci běhu. Protože nelze zjistit, od kdy stav Error trval, a vyjádření poskytovatele se týká jen tohoto případu, je vhodné u srv3 i srv4 jednou ověřit, že se rozložení cílových portů v průběhu běhu neměnilo skokově (to by ukazovalo na změnu filtrace).

Záznam do seznamu omezení datasetu

Dne 13. 9. 2026 ukazoval panel poskytovatele u přiřazení síťového firewallu k honeypotům stav Error; podle poskytovatele šlo o problém se synchronizací zobrazení a externí testy potvrdily, že filtrace fungovala. Vliv na sběr dat nebyl zjištěn, od kdy stav trval, ale nelze určit.

5. Reakce agentů

Netýká se — agenti do panelu poskytovatele přístup neměli a stav firewallu nemohli vidět. Watchdog na srv3 po celou dobu hlásil nezměněný počet veřejných listenerů.

6. Zásahy operátora

• Retry u přiřazení obou firewallů v panelu — u srv4 úspěšný napoprvé, u srv3 opakovaně neúspěšný
• odebrání vmi3520686 z firewallu Honeypot_prod_srv3 (dlouho ve stavu deleting, pak prošlo)
• opětovné přiřazení vmi3520686 ke stejnému firewallu — selhalo
• externí test portu 26412/tcp z cizí sítě (curl, PowerShell) — jen ověření, nic neměnilo
• ticket INT-12499788 na podporu Contaba s dotazem, co Error znamená pro filtraci

7. Otevřené otázky

8. Důkazy

Stav v panelu (z ticketu, 2026-09-13T05:59Z):

Firewall: Honeypot_prod_srv3
Firewall ID: 69f39c0f-db2e-45ec-ac8c-dbeb8544d1ed
Status: Active, 49 inbound rules, last rule change 21 August 2026
Instance: vmi3520686 / 169.58.205.217 (European Union)
Instance Status in Firewall: Error

Externí ověření filtrace (operátorův záznam): spojení na 169.58.205.217:26412 z cizí sítě vyprší v timeoutu bez jakékoli odpovědi; port nemá ACCEPT pravidlo, takže jde o uplatněný výchozí deny.

Watchdog srv3 během 13. 9.: konstantně pub_listeners: 43.

Odpověď Contaba (2026-09-16T08:27Z), shrnutí: přiřazení firewallu u vmi3520686 je opravené a stav Error byl v tomto konkrétním případě problémem se synchronizací zobrazení v panelu.

9. Souvislosti

Související incidenty

Žádné.

Co s incidentem nesouvisí

• Výpadek řídicího kanálu téhož rána (2026-09-13-control-channel) — stav Error byl objeven při jeho vyšetřování, ale jde o jiný stroj a jinou vrstvu: vps1 není za tímto firewallem a smazané routy byly konfigurace uvnitř hosta. Časová shoda byla náhodná.

10. Poučení

• Stav v panelu poskytovatele není údaj o datové rovině. Rozhodující byl externí test výchozího deny na portu, který nic nepropouští — levný, opakovatelný a nezávislý na tom, co panel tvrdí.
• Mít připravený „kanárkový" port. Port bez ACCEPT pravidla, na kterém se dá kdykoli ověřit, že filtrace platí, se ukázal jako nejrychlejší důkaz.
• Panel poskytovatele nikdo nemonitoroval, takže doba trvání stavu zůstane neznámá. U experimentu, kde firewall poskytovatele chrání izolaci, patří kontrola stavu přiřazení do pravidelného checklistu.
• Odpověď poskytovatele platí pro konkrétní případ. Obecná otázka, co Error znamená pro provoz, zůstala bez odpovědi; nelze z ní tedy vyvodit, že stav Error je vždy jen kosmetický.