DDoS napad ne zaustavlja se jednim vatrozidom. Organizaciji trebaju kapacitet na rubu mreže, ugovorena pomoć pružatelja, nadzor aplikacije i uvježban odgovor. Za kategorizirane ključne i važne subjekte to je dio šire obveze upravljanja rizicima i dostupnošću, ali NIS2 ne propisuje određeni proizvod niti je svaki DDoS napad automatski značajan incident.
Ovaj vodič pomaže odabrati razmjerne mjere, pripremiti dokaze za nadzor i pravilno procijeniti treba li incident prijaviti nadležnom CSIRT-u.
Ključne poruke
- DDoS cilja dostupnost mreže, usluge ili aplikacije; volumetrijski, protokolski i aplikacijski napadi traže različite obrane.
- Zaštita mora početi prije veze s organizacijom: kod ISP-a, CDN-a ili pružatelja usluge ublažavanja napada.
- Hrvatski Zakon i Uredba traže odgovarajuće i razmjerne mjere, a ne određenu marku ili paket usluge.
- Rokovi 24 sata, 72 sata i 30 dana vrijede za značajan incident nakon što je kategorizirani subjekt za njega saznao.
- Zapis vremena, metrika dostupnosti, odluka i komunikacije jednako je važan kao tehnička konfiguracija.
Što je DDoS napad
Kod distribuiranog uskraćivanja usluge velik broj izvora istodobno opterećuje cilj. Napadač može iscrpiti internetsku vezu, stanje na mrežnoj opremi ili resurse same aplikacije. Izvor prometa često je botnet kompromitiranih računala, poslužitelja ili IoT uređaja.
| Vrsta napada | Što se iscrpljuje | Tipičan signal | Primarni sloj obrane |
|---|---|---|---|
| Volumetrijski | Propusnost internetske veze | Nagli rast bitova ili paketa | ISP, anycast, usluga čišćenja prometa |
| Protokolski | Tablice stanja i mrežna oprema | Velik broj nepotpunih ili neuobičajenih veza | Rubna mreža, zaštita od lažiranih izvora, ograničenja |
| Aplikacijski | CPU, baza, API ili poslovna funkcija | Naizgled valjani zahtjevi prema skupim rutama | WAF, zaštita botova, ograničenje zahtjeva, optimizacija aplikacije |
Napad može kombinirati sva tri sloja i mijenjati obrazac tijekom događaja. Zbog toga statična lista blokiranih IP adresa rijetko predstavlja cjelovitu zaštitu.
Koliki je poslovni rizik
ENISA je u pregledu prijetnji za 2025. DDoS izdvojila kao najčešći tip incidenta u analiziranom skupu, uz važnu ogradu: velik dio činile su kratke haktivističke kampanje bez mjerljivog prekida usluge. Broj napada zato nije zamjena za procjenu učinka.
Za organizaciju su važnija ova pitanja:
- Koje javne usluge imaju najveću dopuštenu nedostupnost?
- Gdje je stvarno usko grlo: internetska veza, DNS, CDN, vatrozid, autentikacija, API ili baza?
- Koliko brzo pružatelj može aktivirati ublažavanje i tko ga smije zatražiti?
- Može li organizacija nastaviti kritičnu uslugu kroz alternativni kanal?
- Može li se iz zapisa dokazati početak, trajanje, učinak i poduzete radnje?
Procjena rizika treba obuhvatiti ovisnosti koje se lako previde: autoritativni DNS, identitetsku uslugu, mrežnu opremu, telekomunikacijskog operatora, CDN, vanjski kontaktni centar i aplikacijske integracije.
Zaštita koja se može braniti pred upravom i regulatorom
1. Definirajte cilj dostupnosti
Za svaku kritičnu uslugu odredite vlasnika, korisnike, najveće prihvatljivo vrijeme prekida i minimalnu funkcionalnost u kriznom načinu rada. Bez tih odluka tehnički tim ne zna što mora štititi prvo.
2. Zaustavite promet što dalje od izvorišta
Volumetrijski napad koji je već zasitio pristupnu vezu ne može popraviti lokalni uređaj. S ISP-om i pružateljem zaštite unaprijed dogovorite:
- kontakte dostupne izvan radnog vremena
- način autentikacije zahtjeva za hitnu promjenu
- uvjete automatskog ili ručnog preusmjeravanja prometa
- zaštitu DNS-a i izvornih IP adresa
- postupak povratka u redovno stanje.
3. Odvojite mrežnu i aplikacijsku obranu
CDN ili usluga čišćenja prometa ublažava velik dio mrežnog opterećenja, ali ne poznaje nužno poslovnu logiku. Na aplikacijskoj razini uvedite ograničenja prema korisniku, tokenu i funkciji, zaštitu skupih API ruta, predmemoriranje, redove čekanja te kontrolirano smanjenje funkcionalnosti.
Ograničenja treba testirati na legitimnim vršnim opterećenjima. Prestrogo pravilo može samo proizvesti prekid koji izgleda kao uspješan napad.
4. Pratite učinak, ne samo količinu prometa
Operativna ploča treba povezati mrežne pokazatelje s poslovnom uslugom:
- dostupnost i vrijeme odziva iz više lokacija
- stopu uspješnih prijava i transakcija
- zasićenje veze i resursa
- broj odbijenih i propuštenih zahtjeva
- stanje DNS-a i ovisnih pružatelja
- vrijeme aktivacije i djelotvornost ublažavanja.
5. Vježbajte odluke
Stolna vježba treba obuhvatiti tehničku eskalaciju, proglašenje incidenta, komunikaciju s korisnicima, čuvanje dokaza i regulatornu procjenu. Destruktivno testiranje produkcije bez odobrenja i koordinacije nije primjerena zamjena za vježbu.
Za pomoć pri procjeni arhitekture i pripremi odgovora pogledajte uslugu kibernetičke sigurnosti.
DDoS i hrvatski NIS2 okvir
Članak 21. Direktive NIS2 prenesen je u hrvatski okvir kroz Zakon o kibernetičkoj sigurnosti. Zakon traži odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere. Među područjima su postupanje s incidentima, kontinuitet poslovanja, sigurnost lanca opskrbe, sigurnost nabave i održavanja, procjena djelotvornosti te osposobljavanje.
Uredba o kibernetičkoj sigurnosti razrađuje obvezujuće razine mjera. Iz toga ne slijedi da svaki subjekt mora kupiti isti DDoS paket. Subjekt treba moći pokazati da je:
- procijenio DDoS scenarije za svoje stvarne usluge
- odabrao mjere razmjerne riziku i utvrđenoj razini
- uredio odgovornosti i dobavljače
- testirao postupak i pratio njegovu djelotvornost
- ispravio utvrđene nedostatke.
Kada se DDoS prijavljuje
Prijavljuje se značajan incident, a ne naziv tehnike napada. Uredba propisuje opće i sektorske kriterije, uključujući ozbiljan operativni poremećaj, financijski gubitak, štetu drugim osobama te pragove nedostupnosti za pojedine usluge. Procjena se zato provodi prema stvarnom ili mogućem učinku konkretnog događaja.
Za kategorizirani subjekt slijed je:
| Faza | Rok | Svrha |
|---|---|---|
| Rano upozorenje | bez odgode, najkasnije 24 sata od saznanja | Osnovne značajke i mogući zlonamjerni, prekogranični ili međusektorski učinak |
| Početna obavijest | bez odgode, najkasnije 72 sata od saznanja | Ažurirana procjena, pogođeni sustavi i dostupni pokazatelji |
| Završno izvješće | najkasnije 30 dana od početne obavijesti | Uzrok, tijek, učinak i provedene mjere |
Za pružatelje usluga povjerenja vrijedi posebnost iz Uredbe: početna obavijest dostavlja se u roku od 24 sata. Nadležni CSIRT ovisi o sektoru; nije ispravno svaki slučaj automatski usmjeriti CERT.hr-u.
Ako kriterij još nije jasan, tim treba odmah prikupiti činjenice i uključiti pravnu ili regulatornu funkciju. Ne treba čekati potpunu forenziku da bi se donijela odluka o ranom upozorenju.
Operativni plan za prvih 60 minuta
- Potvrdite je li riječ o napadu, kvaru, pogrešnoj konfiguraciji ili legitimnom porastu prometa.
- Otvorite zapis incidenta i zabilježite vrijeme saznanja, vlasnika odluke i pogođene usluge.
- Aktivirajte unaprijed ugovoreno ublažavanje kod ISP-a ili pružatelja.
- Zaštitite upravljačke kanale i provjerite postoje li paralelni pokušaji upada.
- Uvedite privremena aplikacijska ograničenja prema odobrenom planu.
- Procijenite učinak prema kriterijima značajnog incidenta.
- Pripremite jasnu internu i korisničku poruku bez nagađanja o uzroku.
Nakon stabilizacije slijede analiza uzroka, potvrda cjelovitosti sustava, pregled učinkovitosti dobavljača i korektivni plan s vlasnicima i rokovima.
Dokazi koje treba čuvati
| Dokaz | Zašto je važan |
|---|---|
| Procjena rizika i popis kritičnih usluga | Povezuje mjeru s poslovnim učinkom |
| Arhitektura i ugovori s pružateljima | Pokazuje gdje se promet ublažava i tko reagira |
| Konfiguracije, odobrenja i rezultati testova | Dokazuje da mjera nije samo deklarativna |
| Vremenska crta incidenta i metrike | Podupire klasifikaciju i regulatorne rokove |
| Odluke uprave i izvješća nakon incidenta | Dokazuje nadzor i kontinuirano poboljšanje |
Česta pitanja
Je li svaki DDoS napad značajan incident?
Ne. Odlučuju učinak i kriteriji iz Uredbe, a ne sama oznaka „DDoS“. Apsorbiran napad bez relevantnog učinka može ostati sigurnosni događaj, dok prekid kritične usluge može ispuniti prag značajnog incidenta.
Je li WAF dovoljan?
Ne uvijek. WAF pomaže na aplikacijskoj razini, ali ne može sam riješiti zasićenje pristupne veze ili probleme DNS-a. Zaštita treba pokriti mrežu, protokole, aplikaciju i ovisne pružatelje.
Mora li se kupiti određena usluga radi NIS2 usklađenosti?
Ne. Propisi su tehnološki neutralni. Organizacija mora odabrati i dokazati razmjerne mjere prema riziku i obvezujućoj razini utvrđenoj u postupku kategorizacije.
Gdje se prijavljuje incident?
Kategorizirani subjekt prijavljuje putem kanala i nadležnog CSIRT-a navedenih u svojoj obavijesti i službenim uputama. Ako trebate uspostaviti postupak, pogledajte odgovor na incidente.
Izvori i pregled
Pregledano 8. kolovoza 2026. Pravne tvrdnje provjerene su prema važećem hrvatskom Zakonu i Uredbi; tehničke preporuke oslanjaju se na javne, vendor-neutralne smjernice. Konačna klasifikacija incidenta ovisi o sektoru i okolnostima konkretnog subjekta.
Robert Lozo, mag. iur., partner je u Vision Complianceu specijaliziran za usklađenost s EU regulativom. Savjetuje organizacije o GDPR-u, NIS2, AI Actu i financijskoj regulativi te izrađuje dokumentaciju spremnu za reviziju i planove usklađenosti u reguliranim industrijama.