Sari la conținut
UpTrust Cyber Security Defence
Din practică

Patru incidente, fără nume și fără cifre. Cu tot restul

Aproape toate paginile de securitate promit protecție „de cel mai înalt nivel". Noi am preferat să povestim ce s-a întâmplat, la clienți reali, în situații reale. Fără nume, fără cifre de trafic, fără date. Nu pentru că nu le avem, ci pentru că sunt ale clienților: cât trafic ostil primește o firmă este treaba acelei firme. Cifrele exacte le primește fiecare client în raportul lui lunar.

Ce rămâne după ce scoți numele și cifrele este partea care contează: ce am văzut, ce am crezut prima dată, unde ne-am înșelat și ce am avut grijă să nu blocăm. Aia nu se poate copia de pe alt site.

Cum sunt scrise cazurile de mai jos

Fiecare are aceeași structură: ce a văzut clientul, ce am văzut noi, ce a fost greu, ce am făcut și ce a rămas să funcționeze. Rândul „ce a fost greu" este acolo intenționat. Un caz în care totul a mers din prima este rar, iar dacă îl citești pe un site, de obicei înseamnă că cineva a tăiat partea incomodă.

Nu vei găsi aici nici reguli scrise în clar, nici adrese, nici lista excepțiilor. Dacă am publica regulile după care filtrăm un site, am publica instrucțiunile de ocolire a lor. Îți spunem ce am făcut, nu cum e configurat.

Clienții nu sunt numiți, iar din fiecare caz am scos tot ce i-ar putea identifica: cifrele de trafic, datele, numele integrărilor lor, locurile. Fiecare este descris printr-un singur detaliu, cât să te recunoști tu în el, nu cât să îl recunoască altcineva pe el.

Cazul 1Atac în etape

O după-amiază în care platforma nu a avut voie să cadă

O platformă financiară online, cu conturi de client

Ce a văzut clientul

Într-o după-amiază obișnuită, platforma a intrat sub un val de trafic. Pentru clienții ei, fiecare minut în care nu răspunde este un minut în care cineva nu își poate urmări banii sau nu poate închide o operațiune.

Ce am văzut noi

Nu era un vârf de trafic și nici un scaner rătăcit. Era o campanie, cu etape. Întâi cineva a măsurat cât duce platforma, dintr-o singură direcție. Apoi a forțat pagina de autentificare. Apoi a venit inundarea propriu-zisă: din zeci de țări deodată, fără pauză, îndreptată pe o singură adresă, exact cea la care clienții își deschid conturile. Nimic din ce cereau nu putea fi servit din memorie. Fiecare cerere era construită anume ca să ajungă până la server. Iar sursele nu erau operatori de internet pentru populație. Erau centre de date de unde închiriezi servere cu ora.

Ce a fost greu

Atacul semăna cu trafic normal: browsere obișnuite, sistem de operare obișnuit, protocol modern. Semnele erau în detalii. Câteva identități de browser, aproape identice, aduceau fiecare exact aceeași cantitate de trafic, iar oamenii nu se împart niciodată atât de egal. Și raportul dintre desktop și telefon era pe dos față de cum arată clienții reali ai platformei, care intră de pe mobil. Prima regulă scrisă nu a fost de ajuns: un filtru prea larg ar fi dat afară și clienții adevărați, deci fiecare variantă a trebuit strânsă, în timp ce atacul rula. În timpul vârfului au fost momente în care serverul din spate nu a mai răspuns. Nu vindem povestea unei apărări perfecte.

Cum s-a desfășurat, fără volume

  1. 1. În timpul atacului

    Prima regulă, scrisă cu valul în desfășurare.

  2. 2. Tot atunci

    Cel puțin trei variante, până când filtrul a separat atacul de clienți fără să îi dea afară.

  3. 3. Trei luni mai târziu

    Al doilea atac. Nu a intervenit nimeni. Au ținut regulile scrise atunci.

  4. 4. În aceeași perioadă

    Audit la rece. A găsit ce încă trecea, din alte rețele decât cele blocate la început. Un set de reguli scris o dată nu ține la nesfârșit.

Ce am făcut

  • Blocare pe tipar de comportament, nu pe adresă. Traficul era prea împrăștiat ca să existe câteva adrese pe care să le blochezi și să se termine povestea.
  • Blocare pe rețelele de găzduire de unde venea grosul, odată ce a fost limpede că sursele erau furnizori de cloud, nu operatori de internet.
  • Limitare separată pentru API și pentru zona de client, ca presiunea pe una să nu o omoare pe cealaltă.
  • Problema inversă, găsită la auditul de la trei luni: un filtru antifraudă oprea o funcție reală din panoul de administrare al clientului. Excepția a fost făcută cât se poate de îngustă, doar pentru acea operațiune.

Ce a rămas să funcționeze

Excepțiile pentru operațiunile clienților și pentru verificarea de identitate au rămas active tot timpul, ca blocările să nu prindă exact ce aduce bani. La finalul acelei după-amiezi, platforma își servea clienții normal, de pe telefon, din câteva țări, ca într-o zi obișnuită.

Ce ar trebui să înțelegi de aici

La volumul ăsta nu mai contează cât de bun e serverul tău

Un asemenea val se oprește doar într-o rețea care are capacitate în mai multe puncte ale lumii în același timp, pentru că exact de acolo vine. Partea pe care o face omul e prima oră: cine se uită la trafic, cine observă că niște identități aproape identice aduc exact același volum, cine scrie regula care separă atacatorul de client fără să dea clientul afară. Cât valorează ora aia se vede la al doilea atac, când nu mai e nevoie de ea.

Cazul 2Atac, într-o noapte

Cineva a încercat să scoată lista de clienți a unui magazin

Un magazin online

Ce a văzut clientul

Nimic, și ăsta e tot rostul. În noaptea aia nu a fost nevoie de nimeni. Clientul a aflat din raport că se întâmplase ceva.

Ce am văzut noi

Târziu în noapte, traficul blocat a sărit de la aproape zero la un platou care a ținut până spre ora unu. Nu era zgomot de fond. Era o rulare automată de injecție SQL și de tentative de execuție de cod, îndreptată exact spre acele adrese ale magazinului care, dacă răspund, întorc lista de clienți sau spun ce versiuni rulează în spate. Nimeni nu încerca să dea magazinul jos. Încerca să scoată ceva din el.

Ce a fost greu

Regulile care prind injecția SQL prind uneori și lucruri legitime. Notificările semnate ale procesatorului de plăți pot arăta, pentru un filtru, ca un atac. A trebuit o singură excepție, punctuală, doar pentru acele notificări. Partea grea a fost să o facem punctuală: destul de îngustă cât să lase notificările să treacă, fără să slăbească filtrul în rest.

Ce am făcut

  • Regulile care au prins valul existau dinainte. Blocarea rețelelor de unde veniseră sondările anterioare fusese deja scrisă.
  • Blocare permanentă pe căutarea de fișiere de configurare și de căi tipice de administrare, care rulează mereu, nu doar în timpul unui atac.
  • Blocare pe semnătura uneltelor de scanare automată, recunoscute după felul în care se prezintă.
  • Limitare pe autentificare și pe formularele publice de contact și de abonare.
  • În noaptea aia, nimeni nu a avut nimic de făcut. Asta e tot ce contează la un incident de noapte.

Ce a rămas să funcționeze

Excepțiile pentru notificările automate de plată, pentru motoarele de căutare verificate și pentru platforma de marketing a clientului au rămas active prin tot valul. Partea de trafic servită în noaptea aia conținea clienți reali ai magazinului.

Ce ar trebui să înțelegi de aici

Ținta nu era site-ul. Erau clienții din el

Dacă una dintre adresele alea ar fi răspuns, nu am fi avut un incident tehnic, ci o scurgere de date personale, cu tot ce înseamnă asta în fața autorității de protecție a datelor. Nu contează dacă adresele mai există sau nu în spate. Cererile nu au ajuns până acolo ca să afle.

Cazul 3Magazin online

Cele mai multe reguli de aici există ca să nu blocăm clienții

Un magazin online care își aduce clienții din reclame

Ce a văzut clientul

Nimic rău. Aici nu a existat un incident, a existat un risc. Traficul magazinului vine în cea mai mare parte de pe telefon, din reclame, prin browserul din interiorul aplicației Facebook sau Instagram. Ce risca să vadă clientul era o campanie plătită care duce oamenii într-un ecran de verificare în loc de produs.

Ce am văzut noi

Browserul din interiorul acelor aplicații nu arată ca un browser obișnuit, iar un filtru pus pe agresiv îl tratează ca pe un robot. Traficul ostil real era, prin comparație, mărunt: scanări din rețele de găzduire și din noduri Tor.

Ce a fost greu

Aici partea grea nu a fost oprirea atacurilor. A fost să nu oprim cumpărătorii. Fiecare regulă a trebuit verificată în două direcții, nu doar dacă blochează ce trebuie, ci și pe cine lasă să treacă. Un magazin care blochează un atac și odată cu el comenzile a pierdut, nu a câștigat.

Ce am făcut

  • Întâi excepțiile, apoi blocările. Excepții pentru finalizarea comenzii, pentru procesatorul de plăți și pentru notificările lui automate, ca o plată să nu poată fi prinsă niciodată de filtru.
  • Excepție pentru browserul din aplicațiile de socializare, ca traficul plătit să intre direct în magazin.
  • Excepție pentru motoarele de căutare verificate, ca poziția în Google să nu aibă de suferit.
  • Abia apoi blocare pe rețelele de găzduire de unde vin scanările și pe căile tipice de exploatare, plus limitare pe autentificare.

Ce a rămas să funcționeze

Plățile, pixelul de conversie, indexarea în Google și traficul plătit. Adică toate lucrurile pentru care clientul plătește deja altcuiva.

Ce ar trebui să înțelegi de aici

Un firewall prost configurat costă mai mult decât lipsa lui

Oricine poate apăsa butonul care pune protecția pe maxim. Cinci minute mai târziu, plățile nu mai trec, pixelul nu mai raportează, iar Google primește o eroare în loc de pagină. Munca adevărată nu e în regulile care blochează. E în cele care se asigură că omul cu cardul în mână ajunge la casă. Un panou nu face partea asta singur.

Cazul 4Site de prezentare

Un site fără nimic de furat, unde cea mai mare parte din trafic nu era om

Un site de prezentare

Ce a văzut clientul

„La mine nu are cine să intre. Nu am ce pierde." Un site de prezentare pentru o firmă mică, fără magazin, fără conturi de client, fără nimic de furat, cel puțin la prima vedere.

Ce am văzut noi

Într-o singură zi, cea mai mare parte din tot ce a bătut la ușă nu era om. Scanere care trec prin tot internetul și încearcă aceleași câteva zeci de căi pe fiecare adresă pe care o găsesc: fișierul de configurare cu parole al aplicației, setările de email, panourile de administrare ale serverului. Un singur server dintr-un cloud public a trimis cereri în rafală, în aceeași secundă. Nu îl căuta pe client. Căuta pe oricine a lăsat o ușă deschisă.

Ce a fost greu

Să deosebim roboții de indexare agresivi de cei legitimi. Motoarele de căutare trebuie să treacă, altfel firma dispare din Google. Restul primesc o verificare în plus. Excepția pentru cei legitimi este explicită, nu lăsată la voia filtrului.

Ce am făcut

  • Blocare pe căile pe care le caută scanerele: fișiere de configurare, setări de email, panouri de administrare ale serverului.
  • Blocare pe rețelele de găzduire și pe nodurile Tor de unde pleacă scanările în masă.
  • Verificare suplimentară pentru roboții agresivi, cu excepție explicită pentru cei legitimi.

Ce a rămas să funcționeze

Site-ul, indexarea lui și liniștea serverului, care a fost deranjat de puține ori într-o zi întreagă de trafic.

Ce ar trebui să înțelegi de aici

„Nu am ce pierde" nu e o poziție de apărare

Scanerele nu te caută pe tine. Nu contează cât de mic ești sau ce vinzi. Contează dacă ai lăsat undeva un fișier cu parole în el. Pentru un site fără autentificare, fără coș și fără plăți, protecția de bază este o alegere onestă, și așa i-am spus și clientului. Din ziua în care apare o autentificare, un coș sau o plată, nu mai este.

Ca să fim corecți

Ce nu demonstrează cazurile de mai sus

Fără secțiunea asta, pagina ar fi doar încă un material de marketing. Pe bună dreptate, nu ar crede-o nimeni.

O cerere oprită nu înseamnă un atac evitat

O bună parte din ce oprim este zgomot de fond: scanere care trec prin tot internetul și încearcă aceleași căi peste tot. Excepție fac cazurile în care volumul și tiparele arată limpede o acțiune țintită. În rest, nu spunem că fiecare cerere blocată ar fi dat site-ul jos. Spunem doar că nu a ajuns la server.

Nu îți spunem câte ore de nefuncționare am salvat

Pentru că nu avem de unde să știm. Ar însemna să comparăm cu un scenariu care nu s-a întâmplat. La fel, nu putem demonstra că o cerere blocată ar fi reușit dacă trecea. Cine îți dă cifre de genul ăsta le inventează.

Rețeaua singură ar fi oprit o parte din trafic

E adevărat și nu ascundem asta. Diferența nu stă în rețea, care e aceeași pentru toată lumea, ci în regulile scrise peste ea și în cine se uită la ele când ceva iese din tipar. La un atac ca primul de mai sus, diferența aia decide dacă platforma rămâne în picioare.

De ce nu apar cifre, când le avem

Pentru că sunt ale clienților. Cât trafic ostil primește o firmă, când a fost atacată și de unde, sunt informații despre firma aceea, nu despre noi. Le primește ea, în raportul lunar. Noi îți spunem cum am gândit, nu cât a primit altcineva.

Înainte să ne scrii

Trei lucruri care ne ajută să îți răspundem repede

Contactul se face doar pe email, iar formularul de pe site ajunge tot acolo. Motivul e practic: primim des mesaje care conțin doar „atac DDoS”, fără adresa site-ului și, de multe ori, fără o adresă la care să putem răspunde. Înțelegem că e un moment neplăcut și că vrei un răspuns imediat. Spunem cinstit cum stau lucrurile: la volumul de cereri pe care îl avem, un mesaj fără detalii nu poate primi un răspuns util și riscă să se piardă printre celelalte. Nu vrem să sărim peste nimeni, așa că te rugăm să ne dai trei lucruri.

  1. 1

    O adresă de email la care revenim

    Scrie-ne direct la office@uptrust.eu sau completează adresa ta în formular. Fără o adresă de contact nu îți putem trimite nicio ofertă, oricât de urgent ar fi.

  2. 2

    Domeniul și ce se întâmplă concret

    Adresa site-ului, de când durează, ce vezi (site căzut, încărcare lentă, erori), ce spune furnizorul de găzduire și dacă ai deja ceva în față, de exemplu Cloudflare sau protecția inclusă la hosting.

  3. 3

    Dacă atacul este chiar acum

    Dacă site-ul este căzut în acest moment, nu vorbim despre o ofertă, ci despre o intervenție de urgență, cu alt regim și alt preț. Scrie-ne cu URGENT în subiect și cu domeniul în prima linie, ca să sară peste coadă. Răspundem de regulă sub o oră în programul de lucru, iar pentru urgențe avem gardă non-stop.

Prețul este cel de pe site, dacă nu ai cerințe speciale

Ca să nu pierdem timpul niciunuia: pentru un site obișnuit, oferta noastră este exact grila de pe pagina de prețuri. Nu ținem un preț mai bun, ascuns, pe care îl dăm doar pe email. O ofertă diferită are sens doar dacă ai cerințe care nu intră în planurile standard, de exemplu:

  • Mai multe domenii sau subdomenii sub același contract
  • Trafic sau vârfuri de trafic peste ce acoperă un plan obișnuit
  • Magazin online cu checkout propriu sau API-uri care trebuie protejate separat
  • Acces de tip Zero Trust pentru o echipă, cu un număr concret de utilizatori
  • Timp de răspuns garantat prin contract
  • Cerințe de conformitate: NIS2, ISO 27001 sau reguli specifice domeniului tău
  • Infrastructură nestandard: mai multe origini, echilibrare de trafic, servere proprii
  • Integrare cu ce ai deja: furnizorul de găzduire, echipa ta de IT, uneltele de monitorizare

Dacă te regăsești mai sus, trimite-ne detaliile și îți facem o ofertă pe cazul tău, adică planul Fortress. Dacă nu, cel mai rapid drum este să alegi direct un plan de pe pagina de prețuri. Protecția devine activă imediat ce comuți nameserverele.

Scrie-ne