Turvalisus Drupal Hooldus

Drupal turvaintsidendi plaan – mida teha, kui sait kompromiteeritakse

🎧 Kuula kõiki artikleid järjest

Kui veebisait on kompromiteeritud, loeb iga minut. Sel hetkel ei ole aega protsessi välja mõelda. Hästi koostatud turvaintsidendi plaan aitab vähendada kahju, taastada teenuse kiiremini ja vältida paanikat.

Miks peab plaan olemas olema enne intsidenti?

Turvaintsidendid juhtuvad harva sobival ajal.

Tüüpiline olukord on järgmine:

  • klient või partner märkab probleemi;
  • Google kuvab turvahoiatuse;
  • hosting saadab teavituse;
  • veeb ei tööta ootuspäraselt;
  • logides ilmub kahtlane tegevus.

Sellises olukorras suureneb surve kiiresti ning iga minut loeb.

Kui tegevusplaan on eelnevalt kokku lepitud, saab keskenduda probleemi lahendamisele, mitte otsustada kriitilisel hetkel, mida järgmisena teha.

Turvaintsidendi plaan ei pea olema pikk. See peab olema arusaadav, ajakohane ja kättesaadav ka siis, kui veebiserver ise ei ole enam usaldusväärne.

Kuidas ära tunda, et sait võib olla kompromiteeritud?

Mõnikord on rünnaku tunnused ilmsed, mõnikord mitte.

Levinumad märgid on:

  • Google kuvab hoiatust „See sait võib olla ohtlik”;
  • hosting pakkuja saadab teavituse pahavara või kahtlase liikluse kohta;
  • veebilehele ilmuvad võõrad lehed;
  • külastajad suunatakse ümber tundmatutele veebidele;
  • administraatori konto ei tööta enam;
  • süsteemis tekivad tundmatud kasutajad;
  • failid muutuvad ilma selge põhjuseta;
  • serveri koormus kasvab ootamatult.

Oluline on mõista, et kompromiteeritud süsteem ei pruugi alati nähtavaid sümptomeid näidata. Mõned ründajad tegutsevad teadlikult vaikselt.

Samm 1: Dokumenteeri olukord

Esimene reaktsioon ei tohiks olla failide kustutamine.

Kirjuta üles:

  • millal probleem avastati;
  • kes selle avastas;
  • millised sümptomid ilmnesid;
  • milliseid samme on juba tehtud.

See info aitab hiljem analüüsida juhtunu ulatust ja võimalikke põhjuseid.

Samm 2: Piira ligipääs süsteemile

Kui on põhjust arvata, et süsteem on kompromiteeritud, tuleb piirata edasist kahju.

Võimalikud variandid:

  • aktiveerida maintenance mode;
  • piirata ligipääs IP-aadresside järgi;
  • blokeerida veeb ajutiselt tulemüüris;
  • suunata külastajad hooldusteatele.

Näiteks Drupalis:

bash
drush state:set system.maintenance_mode 1 --input-format=integer
drush cr

Eesmärk on peatada:

  • ründaja tegevus;
  • pahavara levik;
  • andmete edasine lekkimine.

Samm 3: Säilita tõendid

Levinud viga on kohe puhastamise alustamine.

Enne muudatuste tegemist tasub luua:

  • serveri koopia;
  • failisüsteemi koopia;
  • andmebaasi varukoopia;
  • logide eksport.

Need andmed võivad hiljem aidata:

  • ründevektori tuvastamisel;
  • kahju ulatuse hindamisel;
  • kordumise vältimisel.

Samm 4: Kontrolli logisid

Logid annavad sageli kõige väärtuslikuma info.

Kontrollida tasub:

Veebiserveri logisid

text
/var/log/apache2/access.log
/var/log/apache2/error.log

või Nginxi puhul vastavaid logifaile.

Drupal logisid

Kui ligipääs on võimalik:

text
/admin/reports/dblog

Mida otsida?

  • tundmatud POST päringud;
  • failide üleslaadimised;
  • administraatori sisselogimised;
  • kahtlased IP-aadressid;
  • ootamatud URL-id;
  • skriptide käivitamised üleslaadimiskataloogidest.

Samm 5: Tuvasta sisenemispunkt

Turvaintsidendi lahendamine ei tähenda ainult pahavara eemaldamist.

Levinumad põhjused on:

  • uuendamata Drupal Core või moodul;
  • nõrk administraatori parool;
  • ebaturvaline kolmanda osapoole moodul;
  • aegunud PHP või serveritarkvara;
  • kompromiteeritud kasutajakonto.

Kui algpõhjus jääb leidmata, võib sama probleem korduda ka pärast taastamist.

Samm 6: Taasta puhtast varukoopiast

Kõige usaldusväärsem taastamismeetod on puhta varukoopia kasutamine.

Soovitatav tegevuskava:

  1. leia kompromiteerimisele eelnev varukoopia;
  2. taasta failid;
  3. taasta andmebaas;
  4. kontrolli süsteemi terviklikkust;
  5. eemalda kompromiteeritud keskkond.

Pahatahtlike failide käsitsi kustutamine võib jätta alles peidetud tagauksed.

Samm 7: Uuenda süsteem enne taasavamist

Enne veebi taasavamist tuleb eemaldada kompromiteerimise põhjus.

bash
composer update
drush updb
drush cr

Lisaks vaheta kõik olulised ligipääsud:

  • administraatorite paroolid;
  • andmebaasi paroolid;
  • SSH võtmed;
  • FTP kasutajad;
  • hostingu juhtpaneeli paroolid.

Samm 8: Ava sait ja jälgi

bash
drush state:set system.maintenance_mode 0 --input-format=integer
drush cr

Järgmise 24–48 tunni jooksul jälgi:

  • logisid;
  • serveri koormust;
  • kasutajakontosid;
  • väljuvat liiklust;
  • veateateid.

Kui kahtlane tegevus jätkub, pole kompromiteerimise põhjus tõenäoliselt täielikult eemaldatud.

Kas GDPR nõuab teavitamist?

Kui kompromiteerimise käigus võisid lekkida isikuandmed, ei ole tegemist ainult tehnilise probleemiga.

Näiteks võivad riskis olla:

  • kontaktivormide andmed;
  • kliendikontod;
  • e-posti aadressid;
  • telefoninumbrid;
  • kasutajate autentimisandmed.

GDPR nõuab teatud juhtudel isikuandmete rikkumisest teavitamist Andmekaitse Inspektsioonile 72 tunni jooksul pärast rikkumise avastamist.

Kui rikkumine võib põhjustada olulist mõju ka andmesubjektidele, tuleb teavitada ka mõjutatud kasutajaid.

Seetõttu tasub turvaintsidendi ajal dokumenteerida:

  • millised andmed võisid lekkida;
  • kui kaua ligipääs võis kesta;
  • milliseid süsteeme ründaja puudutas;
  • milliseid samme kahju piiramiseks tehti.

Kahtluse korral tasub kaasata andmekaitse spetsialist või jurist.

Mida peaks turvaintsidendi plaan sisaldama?

Hoia eraldi dokumendis vähemalt järgmist infot.

Kontaktid

  • hostingu tehniline tugi;
  • veebiarendaja;
  • süsteemiadministraator;
  • organisatsiooni võtmeisikud.

Ligipääsud

  • hostingu juhtpaneel;
  • DNS haldus;
  • varundussüsteem;
  • monitooringulahendus.

Varukoopiate info

  • kus varukoopiad asuvad;
  • kui tihti neid tehakse;
  • kuidas taastamine toimub;
  • millal taastamist viimati testiti.

Vastutajad

Kui veebi haldab meeskond, peab olema selge:

  • kes juhib intsidenti;
  • kes suhtleb klientidega;
  • kes teeb tehnilised otsused;
  • kes kinnitab teenuse taastamise.

Ennetamine on alati odavam

Turvaintsidendi plaan on viimane kaitseliin.

Palju olulisem on:

  • rakendada Drupal turvauuendused kiiresti;
  • hoida PHP ja server tarkvara ajakohasena;
  • teha regulaarseid varukoopiaid;
  • testida taastamisprotsessi;
  • kasutada mitmefaktorilist autentimist;
  • jälgida süsteemi monitooringuga.

Enamik reaalseid kompromiteerimisi kasutab teadaolevaid haavatavusi, mille parandused on olnud saadaval juba nädalaid või kuid.

Kokkuvõte

Turvaintsidendi ajal on kõige olulisem tegutseda süsteemselt.

Hea tegevusplaan aitab:

  1. piirata kahju;
  2. säilitada tõendid;
  3. taastada teenus kiiremini;
  4. vältida sama probleemi kordumist.

Kui Drupal-sait on organisatsiooni jaoks oluline töövahend, tasub turvaintsidendi plaan koostada enne, kui seda vaja läheb. Kriitilisel hetkel on ettevalmistus sageli olulisem kui tehnoloogia ise.

Telli RSS
Kaido Toomingas, WebPro tehniline juhtWebPro Company OÜ Tehniline juht: Kaido Toomingas

Vajad Drupal abi?

Kui artikkel puudutab sinu olukorda, ei pea kõike lõpuni lugema. Sinuga suhtleb päris inimene ja aitab järgmise sammuni jõuda.

Võta ühendust