Preskoči na sadržaj

Blog

Zaraženi sajtovi na istom hostingu: kako sam očistio svih 31

Na jednom hosting nalogu bilo je 31 zaraženih sajtova. Zaraza nije pogodila svaki domen odvojeno i slučajno. Krenula je sa jednog sajta, a zatim se proširila kroz zajednički nalog na ostale. Zadatak nije bio da „obrišem virus” na jednoj početnoj strani, već da zaustavim lanac, očistim svaku instalaciju i pomerim klijenta na reseller hosting gde sajtovi više ne dele isti rizik kao na jednoj zajedničkoj kutiji.

Apstraktan prikaz širenja i izolacije zaraze na hostingu sa više sajtova

Zaraženi sajtovi na istom hostingu nisu 31 odvojenih incidenta

Zaraženi sajtovi na istom hostingu često izgledaju kao lista odvojenih problema, a zapravo su jedan sistemski incident sa više simptoma. Vlasnik vidi da jedan domen preusmerava, drugi šalje spam, treći ima čudne fajlove, pa traži čišćenje „tog sajta”. Na deljenom nalogu to je pogrešan okvir. Ako skripte više domena rade pod istim sistemskim korisnikom, kompromitovanje jednog direktorijuma može otvoriti put ka drugima.

U ovom slučaju tačno to se desilo. Jedan sajt je bio ulaz. Ostalih trideset nije moralo da ima isti početni propust da bi kasnije postali zaraženi. Dovoljno je bilo da dele nalog, dozvole i prostor u kojem jedan proces može da piše tamo gde ne bi smeo.

Jedan zaražen sajt koji širi kompromitovanje ka drugim domenima na istom hosting nalogu

Zato sam odmah razdvojio tri nivoa problema:

  1. aktivna šteta na pojedinačnim sajtovima
  2. zajednički hosting nalog kao kanal širenja
  3. dugoročna izolacija, da se isti scenario ne ponovi

Bez trećeg nivoa, čišćenje 31 sajta može da bude privremeno. Očistiš jedan, a drugi, još uvek kompromitovan, ponovo ubaci kod.

Zašto „očisti ovaj jedan” ovde nije imalo smisla

Prirodna reakcija je da se prvo sredi sajt koji najviše smeta poslovanju. To ponekad mora da bude prvi hitni korak, ali ne sme da bude cela strategija. Na nalogu sa trideset jednom instalacijom, sajt koji trenutno izgleda „mirno” može već da nosi backdoor, izmenjen fajl ili zakazani zadatak.

Ako očistiš samo vidljiv domen:

  • ostali zaraženi sajtovi ostaju izvor ponovne infekcije
  • isti nalozi i lozinke mogu ostati kompromitovani
  • napadač zadržava položaj u zajedničkom prostoru
  • sutra se problem vraća na očišćen sajt

Zato sam radio inventar cele površine: svi domeni, poddomene, stare kopije, razvojni folderi i sve što deli isti nalog. Tek sa spiskom možeš da znaš šta čistiš, šta izoluješ i šta više ne sme da ostane na starom mestu.

Inventar svih domena i instalacija pre čišćenja celog hosting naloga

Kako sam pristupio čišćenju 31 zaraženih sajtova

Čišćenje 31 zaraženih sajtova nije linearno „otvori fajl, obriši virus, gotovo”. Vodim ga kao kontrolisanu sanaciju niza sistema koji međusobno utiču jedni na druge.

1. Zaustavi aktivnu štetu, sačuvaj tragove

Pre neselektivnog brisanja treba sačuvati dovoljno stanja za proveru: fajlove, baze i dostupne logove gde postoje. Bez toga lako uništiš dokaz o ulazu, a kasnije nagađaš zašto se zaraza vratila. Istovremeno, ako neki sajt aktivno šteti posetiocima, prioritet je da se ta šteta ograniči.

2. Utvrdi da je nalog, a ne samo jedan folder, kompromitovan

Kod više sajtova na jednom nalogu gledam šire od jednog public_html foldera. Tražim obrasce koji se ponavljaju na više domena, sumnjive fajlove van očekivanih direktorijuma, nepoznate naloge, izmenjene konfiguracije i znakove da jedan sajt može da piše u prostor drugog.

3. Očisti svaki sajt kao zaseban sistem, ali u zajedničkom planu

Svaki od 31 sajta dobio je sopstveni prolaz: potvrđene zlonamerne komponente, legitimne fajlove koji su izmenjeni, bazu gde je to bilo potrebno, administratorske naloge i završnu proveru osnovnih funkcija. Paralelno sam držao listu šta je završeno, šta čeka i gde postoji rizik od povratka.

Ne predstavljam to kao magično dugme. Radi se o disciplini: ne proglasiti nalog čistim dok trideset prvi sajt nije prošao istu proveru.

Redosled čišćenja više sajtova uz kontrolu rizika od ponovne infekcije

4. Promeni pristupe kada okruženje više nije otvorena rana

Nova lozinka na još uvek kompromitovanom nalogu često nema trajnu vrednost. Zato relevantne pristupe menjam u trenutku kada čišćenje i izolacija daju smisla: panel, FTP ili SSH gde postoji, CMS administracije, baze i povezani servisi. Ako se administracija radi sa zaraženog računara, i to mora da se reši, jer inače nova lozinka može odmah ponovo da procuri.

Reseller hosting: zašto sam ga predložio i zakupio

Ključna odluka posle čišćenja bila je promena arhitekture. Klijentu sam zakupio reseller hosting. Cilj nije bio „skuplji paket radi imena”, već izolacija. Na reseller modelu svaki sajt može da dobije sopstveni nalog, sopstvenog korisnika i jasniju granicu prema drugim sajtovima.

Na starom modelu, jedan propust i jedan nalog nosili su svih 31. Na novom, kompromitovanje jednog sajta ne sme automatski da znači da napadač ima isti nivo pristupa ka ostalim. To ne čini sajt neuništivim. Čini štetu lokalnijom.

Prelazak sa jednog deljenog naloga na reseller sa odvojenim nalozima po sajtu

Zašto sam insistirao na tome posle ovog incidenta:

  • čišćenje bez izolacije ostavlja isti kanal širenja
  • 31 sajt na jednom nalogu znači 31 puta veću površinu za jednu grešku
  • održavanje, lozinke i prava pristupa lakše se kontrolišu po nalogu
  • kada se problem ipak desi, sanacija može da ostane na jednom sistemu

Reseller nije lek za loše lozinke, zastarele dodatke ili odsutno održavanje. On rešava drugi sloj: da greška na jednom domenu ne kupi napadaču ceo portfolio.

Šta sam naučio iz ovog slučaja

Ovaj projekat je potvrdio nekoliko pravila koja sada još direktnije kažem klijentima sa više sajtova.

Broj sajtova na nalogu jeste bezbednosna odluka

Ljudi broj domena gledaju kao pogodnost paketa. Napadač ga vidi kao mapu susednih meta. Što više produkcijskih i napuštenih instalacija deli isti nalog, to je veći rizik da jedan slab sajt povuče zdrave.

Stari i zaboravljeni sajtovi često koštaju više od aktivnih

Na velikom nalogu skoro uvek postoji nešto što „samo stoji”: stari redizajn, test poddomena, kopija od pre dve godine, sajt koji više nije u upotrebi. Takve instalacije retko dobijaju ažuriranja, a i dalje mogu biti ulaz. U inventaru ih tretiram ozbiljno, ne kao šum.

Čišćenje i selidba moraju da idu zajedno kada je nalog truo

Ako ostaneš na istom kompromitovanom modelu i samo „prođeš skenerom”, rizik ostaje ugrađen u način rada. U ovom slučaju čišćenje plus prelazak na reseller bili su jedan plan, ne dve nepovezane usluge.

Transparentnost prema klijentu štedi vreme

Najgore je obećati da će „jedan sajt biti gotov sutra”, a prećutati da postoji još trideset tačaka rizika. Bolje je rano reći: ovo je incident celog naloga, evo šta čistimo, evo zašto selimo, evo šta ti dobijaš na kraju.

Pouke posle incidenta: inventar, izolacija, čišćenje i promena modela hostinga

Preporuke ako i ti držiš više sajtova na jednom hostingu

Ne moraš da imaš 31 sajt da bi isti princip važio. Već tri ili pet produkcijskih domena na jednom nalogu zaslužuju proveru.

Uradi bar ovo:

  1. Napravi spisak svih domena, poddomena i folder instalacija na nalogu.
  2. Obriši ili strogo izoluj sajtove koji više nisu u upotrebi.
  3. Proveri da li više sajtova radi pod istim sistemskim korisnikom i istim setom pristupa.
  4. Ako vodiš ozbiljan portfolio sajtova, razmotri reseller ili drugi model sa odvojenim nalozima.
  5. Drži odvojene jake lozinke i, gde je moguće, dvofaktorsku autentifikaciju.
  6. Ažuriranja, rezervne kopije i monitoring tretiraj kao obavezu po sajtu, ne kao jednu zajedničku sreću.
  7. Ako jedan sajt pokaže zarazu, pretpostavi da treba proveriti i susede na istom nalogu.

Ako već vidiš simptome, ne kreći od nasumičnog brisanja fajlova. Bolji prvi korak je čišćenje sajtova od virusa kao kontrolisana intervencija, a zatim plan da se ulaz i model hostinga zatvore. Za razumevanje kako zaraza uopšte nastaje, koristan je i tekst kako se zapravo stvara zaražen WordPress sajt.

Šta ovaj slučaj nije i šta ne obećavam

Ne tvrdim da je svaki shared hosting po definiciji neupotrebljiv. Za jedan jednostavan sajt često bude dovoljan. Problem nastaje kada se na isti nalog natače portfolio sajtova, starih kopija i različitih nivoa održavanja.

Ne tvrdim ni da reseller uklanja potrebu za održavanjem. Isolacija smanjuje širenje. Održavanje sajta smanjuje šansu da do incidenta uopšte dođe. To su različiti slojevi.

Takođe ne izmišljam da je svaki od 31 sajta imao isti simptom ili istu težinu štete. Bitna činjenica je zajednička: bili su zaraženi, bili su na istom hostingu, zaraza je krenula od jednog, a rešenje je zahtevalo čišćenje svakog i prelazak na reseller model.

Razlika između deljenog naloga sa više sajtova i izolovanih naloga posle reseller prelaska

Kada da zoveš pomoć umesto da čistiš naslepo

Ako imaš više domena na jednom nalogu i jedan pokaže upozorenje, preusmeravanje, spam ili poruku hostinga, treperi crvena lampica za ceo nalog. Posebno ako:

  • ne znaš tačno koliko instalacija živi na nalogu
  • postoje stari sajtovi koje nisi dirao godinama
  • već si „očistio” jedan sajt, a problem se vratio
  • nemaš pouzdane rezervne kopije
  • isti pristupi važe za više sajtova i više ljudi

U takvoj situaciji brzina ima vrednost, ali redosled ima veću. Prvo inventar i ograničenje štete, zatim čišćenje, zatim izolacija i promena pristupa.

Ako vodiš više sajtova, proveri nalog pre nego što napadač uradi inventar umesto tebe

Ovaj slučaj sa 31 sajtom je ekstremniji po broju, ali ne i po logici. Isti mehanizam radi i na manjim nalozima. Ako želiš da proverimo da li ti je rizik lokalni ili sistemski, pošalji mi spisak domena i opis simptoma. Mogu da procenim da li treba čišćenje jednog sajta, pregled celog naloga ili plan selidbe na izolovaniji model.

Za trošak incidenta šire, ne samo tehnički deo, vidi i koliko zaista košta hakovan sajt.