Īsi: vai tas ir DDoS vai uzlaušana, parāda pēdas. DDoS rada ļoti daudz pieprasījumu un padara vietni lēnu vai nepieejamu, taču neko nemaina. Exploit bieži vajag tikai dažus pieprasījumus, un tas atstāj jaunus failus, kontus, procesus vai savienojumus. Pareizā klasifikācija nosaka, vai jums jāatvairā slodze vai jāierobežo incidents.
Atšķirība vienkāršos vārdos
DDoS uzbrukums (Distributed Denial of Service) ir kā ļaužu pūlis, kas bloķē veikala ieeju. Neviens netiek iekšā, bet veikalā nekas netiek zagts. Mērķis ir pārslogot jūsu vietni vai serveri, lai īstie klienti vairs netiktu cauri.
Exploit turpretī ir ielaušanās pa atvērtām durvīm. Uzbrucējs izmanto ievainojamību, piemēram, PHP, CMS vai kādā paplašinājumā, lai jūsu serverī izpildītu kodu. Tas var notikt klusi, vietnei nekļūstot lēnākai. Sekas sniedzas no surogātlapām līdz datu zādzībai un servera pārņemšanai.
Vadībai atšķirība ir izšķiroša: DDoS ir pieejamības problēma, kas beidzas ar uzbrukumu. Sekmīgs exploit ir drošības incidents, kas paliek, kamēr nav atrasts, attīrīts un dokumentēts.
DDoS vai uzlaušana: pazīmes salīdzinājumā
Turpmākā tabula palīdz pirmajā klasifikācijā. Tā neaizstāj analīzi, bet parāda, kur vispirms skatīties.
| Pazīme | Drīzāk DDoS | Drīzāk exploit vai ielaušanās |
|---|---|---|
| Pieejamība | lēna vai izkritusi | bieži normāla |
| Pieprasījumi žurnālā | ļoti daudz, bieži vienveidīgi | daži, mērķtiecīgi pieprasījumi |
| Faili | nemainīti | jauni vai mainīti PHP faili |
| Konti | nemainīti | jauni administratori, mainītas paroles |
| Procesi | tīmekļa serveris un PHP pie pilnas slodzes | nezināmi procesi, ieguve (mining), surogātpasta sūtīšana |
| Tīkls | daudz ienākošās satiksmes | neparasti izejoši savienojumi |
| Pēc beigām | viss kā iepriekš | pēdas paliek |
Uzmanību pie pārklāšanās: masveida skenēšana pēc ievainojamības var izskatīties kā neliels DDoS. Tieši tas ap PHP2Shell bija gaidāms, kad uzbrucēji meklēja ievainojamus serverus. Augsta slodze tātad var nozīmēt arī to, ka kāds tieši tagad mēģina ielauzties.
Pirmās pārbaudes serverī
Turpmākās komandas sistēmā neko nemaina un ātri dod pārskatu. Aizdomu gadījumā par ielaušanos pirms lielākām iejaukšanās saglabājiet žurnālus.
# Slodze un darbības laiks
uptime
# Savienojumi apkopoti un biežākās pretējās puses
ss -s
ss -tn state established | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
# Biežākās klientu adreses piekļuves žurnālā (pielāgojiet ceļu)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# PHP faili, kas mainīti pēdējās 7 dienās
find /var/www -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Procesi ar augstāko CPU slodzi
ps aux --sort=-%cpu | head -15
Savienojumu pārskatā ceturtā kolonna rāda pretējo pusi. Daudzi savienojumi no nedaudzām adresēm vai kāpums līdz normālās vērtības daudzkāršam norāda uz pārslodzi. Jauni PHP faili augšupielāžu vai kešatmiņas direktorijos, procesi zem tīmekļa servera lietotāja ar svešiem nosaukumiem vai izejoši savienojumi uz nezināmiem mērķiem drīzāk norāda uz ielaušanos. Detalizētu sarakstu atradīsiet rakstā Kompromitācijas pazīmes pēc PHP2Shell.
Kāpēc augsta slodze var būt arī novēršanas manevrs
Gadās, ka uzbrucēji rada pārslodzi, vienlaikus mērķtiecīgi ielaužoties. Komanda tad ir aizņemta ar pieejamību, un īstās pēdas noslīkst žurnālu troksnī. Tāpēc spēkā ir: arī ja DDoS ir acīmredzams, pēc tā beigām pārbaudiet failus, kontus un izejošos savienojumus.
PHP2Shell gadījumā klāt nāk tas, ka saskaņā ar php.net un drošības uzņēmumiem nav publicētu, apstiprinātu Indicators of Compromise. Atklāšana balstās uz uzvedības analīzi. Serveris, kas skenēšanas periodā no oktobra vidus bija neielāpots, tāpēc jāpārbauda neatkarīgi no novērotās slodzes.
Vēl viens variants ir izspiešanas e-pasti, kuros tiek draudēts ar DDoS uzbrukumu, ja netiks samaksāts. Saglabājiet šādus ziņojumus, nemaksājiet bez saskaņošanas ar speciālistiem un apsveriet iesniegumu Centrālajā kibernoziegumu kontaktpunktā (Zentrale Ansprechstelle Cybercrime). Paralēli informējiet savu hostinga sniedzēju, lai varētu sagatavot aizsardzības pasākumus. Kā šim nolūkam izvērtēt žurnālus, rakstīts ceļvedī Tīmekļa servera žurnālu izvērtēšana pēc uzbrukuma.
Ko darīt pirmajās stundās
Aizdomu gadījumā par DDoS:
- Informēt hostinga sniedzēju vai datu centru; tur bieži ir filtri pirms servera.
- Aktivizēt vai pastiprināt pirms servera novietotu aizsardzības pakalpojumu vai WAF ar virtuālo ielāpošanu.
- Iestatīt Rate Limit tīmekļa serverī un sevišķi aizsargāt dārgas lapas, piemēram, meklēšanu vai grozu.
- Saglabāt žurnālus, lai uzbrukumu vēlāk varētu izsekot.
Aizdomu gadījumā par ielaušanos:
- Neko nedzēst un serveri neuzstādīt no jauna, pirms nav saglabāti žurnāli un skartie faili.
- PHP atjaunināt uz izlabotu versiju un pārstartēt visus darbprocesus, ja tas vēl nav izdarīts.
- Ja atjauninājums nav iespējams nekavējoties, vietni uz laiku atvienot no tīkla, kā iesaka BSI.
- Piekļuves datus atjaunot no tīras ierīces, nevis no iespējami skartā servera.
- Ļaut pārbaudīt, vai varētu būt skarti personas dati; tad var tecēt ziņošanas termiņi.
Abos gadījumos palīdz īsa, lietišķa piezīme hostinga sniedzējam un pakalpojumu sniedzējiem: kopš kura laika problēma pastāv, kuras vietnes ir skartas, ko esat novērojis un kas jau ir mainīts. Fiksējiet arī to, kurš kādu lēmumu pieņēmis. Šī laika līnija ietaupa laiku analīzē un vēlāk ir vērtīga apdrošināšanai, datu aizsardzībai un iekšējai pēcapstrādei. Ja nav skaidrs, vai uzbrukums vispār ir, situāciju piesardzības labad uzskatiet par incidentu, kamēr nav pierādīts pretējais.
Kā PHP SOS palīdz konkrēti?
- Situāciju klasificējam attālināti pēc slodzes, žurnāliem, failiem un savienojumiem un sakām, ar ko jums, visticamāk, ir darīšana.
- Pārslodzes gadījumā iestatām filtrus, Rate Limit un pirms servera novietotus aizsardzības noteikumus, līdz uzbrukums norimst.
- Aizdomu gadījumā par ielaušanos uzņemamies strukturētu Incident Response: saglabāt, ierobežot, atrast cēloni, attīrīt.
- Beigās dokumentējam, kas noticis un kādi pasākumi īstenoti, līdz incidents ir noslēgts.
Biežāk uzdotie jautājumi
Vai DDoS uzbrukums var nozagt datus?
Tīrs DDoS uzbrukums vērsts uz pieejamību, nevis uz datiem. Tas nemaina failus un nelasa datubāzes. Tomēr tas var notikt vienlaikus ar ielaušanās mēģinājumu, tāpēc tik un tā ir vērts paskatīties uz failiem un kontiem.
Kā atpazīt, ka mana vietne ir uzlauzta?
Tipiskas norādes ir jauni vai mainīti PHP faili, nezināmi administratoru konti, pāradresācijas uz svešām lapām, negaidīti izejoši savienojumi un procesi, kas neatbilst jūsu lietojumprogrammai. Atsevišķa pazīme nav pierādījums, vairākas kopā ir nopietns signāls.
Vai CDN vai WAF palīdz pret abiem uzbrukumu veidiem?
Pret apjoma uzbrukumiem pirms servera novietots pakalpojums parasti palīdz labi. Pret exploit noteikumi darbojas tikai tad, ja atpazīst paraugu. PHP2Shell gadījumā Cloudflare pats norāda, ka noteikumi, kas balstās tikai uz pieprasījuma datiem, nav pietiekami.
Vai DDoS uzbrukums jāpaziņo?
Tas atkarīgs no konkrētā gadījuma un jūsu nozares. Bez piekļuves personas datiem VDAR ziņošanas pienākums parasti nav spēkā, taču var pastāvēt nozarei specifiski pienākumi. Noskaidrojiet to ar savu datu aizsardzības speciālistu vai advokātu.