Výpadok Cloudflare z 18. novembra 2025 spôsobil, že množstvo webov a služieb zostalo na niekoľko hodín nedostupných. V reakcii na to sa viacerí správcovia rozhodli pre rýchle riešenie – vypnúť proxy a publikovať origin servery priamo. Technicky to fungovalo. Z biznisového hľadiska to pomohlo. Z bezpečnostného pohľadu je to však rozhodnutie s dlhodobými dôsledkami.

Táto situácia otvára diskusiu, ktorá je v bezpečnostnej komunite známa, no často podceňovaná:

Čo je menšie riziko – dočasný výpadok, alebo trvalé odhalenie origin IP adries?

Keď sa origin raz odhalí, nie je to možné vrátiť späť

Origin IP je verejná IP adresa skutočného servera, na ktorom beží web alebo aplikácia – teda „zdrojový“ server, ku ktorému by inak priamo smeroval všetok traffic.

Pri používaní CDN alebo proxy služieb, ako je Cloudflare, sa origin IP schová za ich infraštruktúru, takže používatelia komunikujú s Cloudflare a nie priamo s týmto serverom.

Inak povedané: Cloudflare ťa chráni len dovtedy, kým nikto nevie, kam útočiť priamo.

Akonáhle je však origin IP adresa verejná:

  • uložená v DNS logoch resolverov
  • zachytená monitoringom veľkých poskytovateľov
  • zverejnená náhodnými ľuďmi
  • scrapnutá botmi, ktoré automaticky sledujú zmeny DNS
  • uložená v Shodane, Censuse, RiskIQ a podobných scaneroch
  • rozšírená screenshotmi a tweetmi

Cloudflare môže byť po čase opäť v prevádzke, ale origin IP zostáva uniknutá. Táto informácia sa nedá „odverejniť“ a pretrváva aj po návrate do bežného režimu.

Je to ako poslať e-mail: už ho nezmažeš.

Prečo je to problém aj po obnovení Cloudflare?

Ešte raz. Cloudflare dokáže chrániť origin len vtedy, keď útočník nepozná jeho adresu.

Ak má origin IP k dispozícii, môže spustiť:

  • priame L3/L4 DDoS útoky
  • zahltenie linky alebo firewallu na strane hostingu
  • útoky mimo siete Cloudflare, ktoré tento už nemá ako filtrovať

Inými slovami: poznať origin IP znamená mať alternatívnu útočnú cestu, ktorú Cloudflare nevie blokovať.

Dá sa tomu vyhnúť? Áno, ale v praxi to nie je bežné

Z technického hľadiska je správny postup jasný: po obnovení Cloudflare je možné znova obmedziť prístup na origin tak, aby ho prijímal len z IP rozsahov Cloudflare.

Organizácia, ktorá má:

  • správne nakonfigurovaný perimeter firewall
  • striktne nastavené allowlisty Cloudflare IP
  • kontrolovaný a auditovaný postup návratu do pôvodnej konfigurácie

…môže fallback zabezpečiť bez dlhodobých rizík.

Problém je, že takto nastavená infraštruktúra je skôr výnimkou než pravidlom.

Odhad podľa praxe

  • Enterprise, banky, telco – 60 až 80 percent správne nakonfigurovaných origin firewallov
  • Stredné firmy, e-shopy, SaaS – 15 až 30 percent
  • Malé projekty, VPS hostingy – 1 až 10 percent

Príčiny výpadku Cloudflare podľa oficiálneho reportu

Podľa Cloudflare začal incident 18. novembra 2025 o 11:20 UTC, keď interná zmena práv v databáze spôsobila, že systém pre Bot Management vygeneroval poškodený a veľmi rozsiahly „feature file“. Ten prekročil limity proxy infraštruktúry a vyvolal zlyhania, ktoré sa následne reťazili naprieč sieťou.

Následkom boli masívne 5xx chyby a narušená prevádzka veľkej časti služieb. Odstraňovanie problému začalo približne o 14:30 UTC a úplná normalizácia bola dosiahnutá o 17:06 UTC. Podľa Cloudflare išlo o ich najzávažnejší výpadok od 2019.

Incident ukazuje, že aj veľmi robustné infraštruktúry môžu zlyhať na zdanlivo vnútornej, neškodnej zmene. A že je dôležité mať plán B – ale zároveň musí ísť o plán B, ktorý neoslabí bezpečnosť.

Dôležitý faktor: trvanie výpadku nikdy nie je možné poznať dopredu

Správcovia v čase výpadku nevedeli, či potrvá:

  • niekoľko minút
  • hodinu
  • niekoľko hodín
  • alebo viac než deň

Táto neistota je prirodzená. Cloudflare a iní veľkí provideri síce komunikujú situáciu, ale interné technické príčiny a odhad doby obnovy nie je možné okamžite sprístupniť verejnosti.

V tejto neistote robia organizácie rozhodnutia, ktoré majú okamžitý pozitívny efekt – no ich dlhodobé dôsledky sú často horšie než samotný výpadok.

Aj preto je dôležité mať pripravený bezpečný fallback vopred, nie až počas incidentu.

Legislatíva a smernice: kde môže vzniknúť problém

Samotné zverejnenie IP adresy zväčša nie je porušením zákona. Avšak v regulovaných sektoroch, ako sú banky, zdravotníctvo alebo kritická infraštruktúra, môže byť:

  • vypnutie DDoS ochrany
  • publikovanie infraštruktúrnych údajov
  • zmena v DNS mimo schváleného procesu
  • zásah bez analýzy rizík

posúdené ako porušenie interných bezpečnostných smerníc, NIS2 povinností alebo napríklad PCI-DSS pravidiel.

Mnohé organizácie majú priamo zakázané:

  • vypínať bezpečnostné vrstvy počas incidentov
  • meniť DNS bez schváleného procesu
  • odhaľovať interné IP rozsahy
  • obchádzať perimeter firewall

Z tohto pohľadu môže byť reakcia typu „prepni to na origin“ v rozpore s auditnými požiadavkami.

Výpadok vs. bezpečnostné riziko: ktorý problém je väčší?

Krátkodobý výpadok

– nepríjemný

– zasiahne používateľov

– poškodenie trvá len počas incidentu

Odhalený origin

– posúva riziko do budúcnosti

– mení útočný model natrvalo

– môže vyústiť do DDoS útoku o mesiac, o rok alebo kedykoľvek

– oprava si vyžaduje zmenu IP alebo migráciu originu

Najväčší rozdiel je v charaktere rizika: Výpadok je dočasný. Odhalenie IP je trvalé.

Po výpadku: Bez nápravy

Samozrejme, takáto situácia sa nedeje každý deň. Pre ilustráciu - počas výpadku som si uložil origin IP viacerých spravodajských webov, komerčných projektov a veľkých ecommerce hráčov. Všetci už opäť fungujú za Cloudflare a ich origin IP sú napriek tomu stále dostupné priamo z internetu.

Okrem toho sa počas incidentu objavilo aj niekoľko administrátorských a DevOps spoločností, ktoré tento postup propagovali ako „sofistikované záložné riešenie“ a prezentovali ho s istou dávkou hrdosti.

Odporúčania pre správcov

  1. Overte, či váš origin neprijíma priame požiadavky mimo Cloudflare.
  2. Nastavte perimeter firewall tak, aby povoľoval len Cloudflare IP rozsahy.
  3. Vypracujte plán fallbacku a plán následného návratu do pôvodného režimu.
  4. Po incidente vykonajte kontrolu DNS a firewallu, aby origin nezostal nechtiac otvorený.
  5. V regulovaných sektoroch posúďte dopad na compliance.
  6. Pravidelne auditujte architektúru a testujte incident response scenáre.

Záver

Výpadky infraštruktúry veľkých poskytovateľov sa budú opakovať. Je rozumné byť na ne pripravený. Rovnako dôležité je však mať architektúru, ktorá umožní reagovať bez toho, aby sme sa stali budúcim cieľom útoku.