Oporavak sajta Quantum Group kroz slojeve sanacije

Redosled koji je odredio oporavak sajta Quantum Group

Oporavak sajta Quantum Group morao je da poštuje jasan redosled, jer se sistem u početku uopšte nije učitavao. Kada javna prezentacija ne može da se otvori, optimizacija i fino podešavanje pretrage nisu prvi korak. Najpre se vraća upotrebljivo stanje i čiste potvrđeni problematični delovi, a tek onda dolaze brzina i vidljivost. Svaki od tih koraka rešavao je drugačiji sloj sistema.

Ovaj sled nije proizvoljan. Ako se preskoči, lako se dobija sajt koji je naizgled brz, ali i dalje nosi neželjeni kod, ili sajt sa doteranim SEO elementima koji povremeno pada. Zato sam poslove poredao prema stvarnom stanju, od najosnovnijeg problema ka onima koji imaju smisla tek kada je osnova uređena.

Nedostupnost kao prva prepreka

Prvo pitanje nije bilo kako sajt rangira, već da li se uopšte otvara. Izvor hakerski napad navodi kao potvrđen događaj, ali ne opisuje kako je izveden. Zbog toga incident ne pripisujem ukradenom nalogu, ranjivom dodatku, temi ili serveru. Potvrđeno je i prisustvo malware-a, ali bez naziva, ponašanja, lokacije i broja izmenjenih datoteka.

Takvo ograničenje nije nedostatak studije. Ono razdvaja dokumentovanu intervenciju od naknadnog nagađanja. Mogu da objasnim zašto je svaki izvedeni korak bio potreban, ali ne mogu opšti bezbednosni scenario da predstavim kao istoriju baš ovog incidenta.

Uklanjanje malware-a i čišćenje MySQL baze

Posle vraćanja osnovne funkcije, sanacija se odvijala na dva sloja. Uklanjanje malware-a rešavalo je problem u delu sa kodom, dok se čišćenje MySQL baze odnosilo na podatke. Ta dva sloja tretiram odvojeno, jer čišćenje jednog ne znači automatski da je drugi pregledan. WordPress i slični sistemi sadržaj i postavke čuvaju u bazi, a programski kod u datotekama.

Ne navodim koje su tabele ili zapisi bili pogođeni, jer izvor tu informaciju ne daje. Ne tvrdim da su menjani korisnički nalozi, objave ili opcije u određenoj tabeli. Potvrđena činjenica je da je baza očišćena u sklopu oporavka, a ne detaljan forenzički nalaz o svakom zapisu.

Zašto baza traži poseban tretman

Kod rada sa bazom cilj nije neselektivno brisanje. Baza nosi podatke koji su aplikaciji potrebni, pa intervencija mora da sačuva ono što je legitimno i funkcionalno. To je opšti kriterijum odgovornog rada sa podacima, a ne opis konkretnih procedura, rezervnih kopija ili alata korišćenih na ovom projektu, jer taj deo nije dokumentovan.

Stariji opis kaže da je čišćenje sprovedeno kako bi se eliminisali tragovi malicioznog koda i povratio integritet informacija. Ovde rezultat izražavam opreznije: baza je očišćena, a sajt je vraćen u funkciju. Bez izveštaja pre i posle intervencije ne tvrdim da je svaki mogući trag pronađen niti da je moguće dokazati apsolutnu potpunost.

Keširanje dolazi tek posle stabilizacije

Keširanje čuva prethodno pripremljen rezultat kako aplikacija za svaki zahtev ne bi iznova obavljala isti posao. Na ovom projektu uvedeno je radi bolje brzine odziva i stabilnijeg rada, i to tek kada je osnovna funkcionalnost bila vraćena, a potvrđeni problem očišćen. Keširanje neispravnog izlaza samo bi produžilo prikazivanje sadržaja koji ne treba čuvati.

Naziv rešenja, njegov nivo i konfiguraciju ne navodim. Ne tvrdim da je korišćen određeni WordPress dodatak, serverski keš ili mreža za isporuku sadržaja. Ne navodim ni vreme učitavanja pre i posle rada. Stariji tekst kaže da je odziv drastično ubrzan, ali bez merenja taj pridev ne pretvaram u rezultat. Proverljivo je jedino da je keširanje uvedeno kao poseban deo oporavka.

Vredi razdvojiti i dva pogrešna zaključka koja se lako provuku. Prvo, brži odziv posle keširanja ne dokazuje da je sajt bezbedan, kao što ni bezbednosno čišćenje samo po sebi ne znači da je isporuka sadržaja optimalna. Drugo, keširanje ne popravlja lošu strukturu stranice, već samo brže isporučuje ono što već postoji. Na ovom projektu oba sloja su bila deo rada, ali svaki ima sopstvenu svrhu i sopstvene granice, pa ih ne predstavljam kao jedan potez koji istovremeno rešava i sigurnost i vidljivost.

Popravka on-page SEO elemenata

On-page SEO obuhvata elemente na samom sajtu koji pretraživaču pomažu da razume stranice i njihovu temu. Prema starom opisu, ti elementi bili su narušeni tokom napada, pa su nakon stabilizacije popravljeni. Ne nabrajam pojedinačne delove, jer izvor to ne čini. Ne tvrdim da su menjani naslovi, meta opisi, kanonske oznake, interne veze ili sitemap.

Sve su to mogući on-page elementi u opštem smislu, ali mogućnost nije isto što i projektna činjenica. Dovoljno je precizno reći da je on-page sloj popravljen nakon vraćanja sajta. Postepenu stabilizaciju i povratak Google pozicija na prvobitni nivo prenosim kao kvalitativan ishod, bez broja pozicija, procenta rasta ili količine saobraćaja, jer nedostaju ključne reči i datumi poređenja. Rangiranje ostaje odluka pretraživača, pa ga ne obećavam unapred svakom drugom sajtu.

Vremenski okvir i šta ostaje nepoznato

Izvor navodi period od 2019. do 2025. godine. Taj okvir ne koristim da bih izračunao broj intervencija, trajanje incidenta ili dužinu oporavka. On potvrđuje godine povezane sa projektom, ali ne daje precizan dnevnik rada. Ne dodajem ni tehnologije izvan potvrđenog MySQL sistema, jer kompletan stek, verzije softvera i hosting okruženje nisu opisani.

Isto važi za posledice napada. Potvrđeno je da se sajt nije učitavao i da su on-page elementi bili narušeni. Nisu potvrđeni gubitak podataka, krađa informacija, poslovni gubitak, preusmeravanja ili upozorenja pregledača, pa ostaju van ove studije. Time izbegavam da opšte rizike predstavim kao posledice baš ovog slučaja.

Sledeći korak ako tvoj sajt ne radi

Sličan pristup ima smisla kada sajt nije funkcionalan, postoji potvrđen bezbednosni problem i treba rešiti više slojeva. Redosled zavisi od stvarnog nalaza, ali funkcionalnost i integritet imaju prednost nad optimizacijom. Tek kada je osnova uređena, keširanje i SEO popravke mogu da se procenjuju na smislen način, a ne kao prvi potez.

To ne znači da će svaki slučaj tražiti čišćenje baze ili isti tip optimizacije. Quantum Group je imao potvrđen rad na MySQL bazi i keširanju, dok drugi sajt može biti u sasvim drugom stanju, pa obim ne treba kopirati bez pregleda. Zbog toga svaki novi slučaj počinjem procenom zatečenog stanja, a ne unapred pripremljenim spiskom radova.

Ako tvoj sajt ne može da se učita posle kompromitovanja ili sumnjaš da su pogođeni različiti slojevi sistema, pošalji mi URL i dostupne informacije. U okviru čišćenja sajta od virusa proceniću šta je moguće potvrditi i predložiću redosled provere, sanacije i vraćanja funkcije, bez izmišljanja uzroka i bez neproverljivih obećanja.