Záložné súbory vo webovom koreni: .zip, .sql a .bak

Stručne: Záložné súbory vo webovom koreni, teda výpisy databáz (.sql), archívy (.zip, .tar.gz) a záložné kópie (.bak, .old, ~), si môže stiahnuť každý, kto pozná alebo uhádne názov súboru. Takéto súbory pravidelne hľadajte pomocou find, zálohy presuňte mimo verejného priečinka, typické prípony zablokujte vo webservery a v prístupových protokoloch skontrolujte, či sa už sťahovali.

Záloha, ktorá sa stane únikom

Tesne pred aktualizáciou niekto ešte rýchlo vytvorí zálohu: backup.zip v hlavnom priečinku a vedľa datenbank.sql. Aktualizácia sa podarí, súbory zostanú ležať. O mesiace neskôr sú tam stále, s celým kódom, všetkými údajmi zákazníkov a prístupovými údajmi webu.

Tento vzor patrí k najčastejším nálezom pri kontrolách webserverov. Nepotrebuje exploit ani zraniteľnosť v PHP. Webserver doručuje z webového koreňa to, čo tam leží, a archívy alebo súbory SQL nevykonáva, ale ponúka ich na stiahnutie.

Archív webu pritom neobsahuje len údaje, ale aj kód s konfiguráciou. Kto ho stiahne, môže si v pokoji hľadať zraniteľnosti a pozná prístupové údaje k databáze.

Automatizované skenery cielene hľadajú typické názvy ako backup.zip, site.tar.gz alebo dump.sql, často v kombinácii s názvom domény alebo dátumom. Kto verí, že nezvyčajný názov súboru chráni, podceňuje, ako systematicky toto hľadanie prebieha.

O ktoré súbory ide

Záložné súbory vo webovom koreni sa vyskytujú vo viacerých podobách:

Obzvlášť citlivé sú kópie konfiguračných súborov. Pôvodný súbor config.php server vykoná a jeho obsah zostane skrytý. Kópiu config.php.bak doručí ako text, spolu s heslom databázy.

Nájdenie zálohy vo webovom koreni: hľadanie na serveri

Nasledujúce hľadanie vypíše podozrivé súbory pod webovými koreňmi s dátumom a veľkosťou. Cesty upravte podľa svojho servera:

find /var/www /srv/www -type f \( \
  -iname '*.sql' -o -iname '*.sql.gz' -o -iname '*.dump' -o \
  -iname '*.zip' -o -iname '*.tar' -o -iname '*.tar.gz' -o -iname '*.tgz' -o \
  -iname '*.rar' -o -iname '*.7z' -o \
  -iname '*.bak' -o -iname '*.old' -o -iname '*.orig' -o -iname '*.save' -o \
  -iname '*~' -o -iname '*.swp' \) \
  -printf '%TY-%Tm-%Td  %10s  %p\n' 2>/dev/null | sort

Nie každý nález je problém. Niektoré archívy sú vedome sprístupnené na stiahnutie, napríklad príručky. Každý súbor si však zaslúži vedomé rozhodnutie. Dávajte pozor najmä na veľké súbory a na priečinky pluginov pre zálohovanie. Pri zdieľanom hostingu bez prístupu do shellu pomôže prehľad súborov v hostingovom paneli alebo prístup cez SFTP.

Sťahoval sa súbor už?

Odpoveď je v prístupových protokoloch webservera. Hľadajú sa úspešné volania, teda stav 200, na nájdené súbory:

# Úspešné volania typických prípon záloh (formát protokolu Combined)
zgrep -hE '\.(sql|sql\.gz|zip|tar|tgz|gz|bak|old|7z|rar)[ ?]' /var/log/nginx/access.log* \
  | awk '$9 == 200 {print $4, $1, $7, $10}'

Výstup ukazuje čas, adresu, cestu a veľkosť odpovede. Ak prenesená veľkosť zodpovedá veľkosti súboru, súbor sa stiahol celý. Ako ďaleko protokoly siahajú, závisí od rotácie. Ak nesiahajú až k dátumu vytvorenia súboru, skoršie stiahnutie sa nedá vylúčiť. Podrobne to opisuje Vyhodnotenie protokolov webservera po útoku. Ak nemáte prístup k surovým protokolom, napríklad pri zdieľanom hostingu, vypýtajte si od hostera protokoly za príslušné obdobie.

Ak sa výpis s osobnými údajmi stiahol alebo sa to nedá vylúčiť, začína posúdenie oznamovacej povinnosti. Základy zhŕňa Oznamovacia povinnosť podľa GDPR: 72 hodín po incidente; posúdenie v jednotlivom prípade patrí vášmu zodpovednému pracovníkovi pre ochranu údajov. Prístupové údaje zo stiahnutých súborov vymeňte v každom prípade.

Pluginy pre zálohovanie, panely a sťahovania

Mnohé nálezy pochádzajú z pluginov pre zálohovanie CMS a obchodov. Zálohy ukladajú často do podpriečinka webového koreňa, niekedy s názvami z dátumu a domény, ktoré sa dajú uhádnuť. V každom plugine skontrolujte tri nastavenia: kam sa zálohuje? Mažú sa lokálne kópie po nahraní na externý cieľ? Je lokálny priečinok chránený pred priamym volaním?

Zálohy z hostingových panelov ležia spravidla mimo webového koreňa, napríklad v domovskom priečinku. Problematické to je, keď niekto takú zálohu skopíruje do webového koreňa, pretože stiahnutie v prehliadači je pohodlnejšie než cez SFTP. Pre sťahovania preto platí: prenos cez SFTP alebo priamo medzi servermi, nikdy cez verejný odkaz.

Ak sa o vaše weby starajú agentúry alebo dodávatelia, malo by toto pravidlo stáť aj v zmluve, spolu s povinnosťou upratať po údržbe. Pokyny dáva Zmluvy s IT dodávateľmi: jasne upraviť bezpečnostné povinnosti.

Trvalo predchádzať: miesto uloženia a blokovanie

Aby sa problém neopakoval, potrebujete dve úrovne. Prvá je organizačná: zálohy majú pevné miesto mimo webového koreňa a navyše mimo servera. Ako vyzerá spoľahlivá záloha, opisuje sprievodca Zálohy podľa pravidla 3-2-1.

Druhá úroveň je technická: webserver zásadne odmieta typické prípony záloh, aj keď niekde predsa len zostane súbor ležať.

location ~* \.(sql|sql\.gz|dump|bak|old|orig|save|swp|swo)$ {
    return 404;
}
location ~ ~$ {
    return 404;
}

Archívy ako .zip blokujte len vtedy, ak váš web neponúka sťahovanie v tomto formáte, alebo cielene v priečinkoch, v ktorých nie sú žiadne súbory na stiahnutie. Doplnkovo pomáhajú pravidelné automatické hľadanie s upozornením a krátke pravidlo v tíme: žiadne zálohy ani kópie vo webovom koreni, ani na päť minút. Príbuzné prípady ako skryté konfiguračné súbory rieši Správna ochrana prístupových údajov a súborov .env.

Ako konkrétne pomáha PHP SOS?

• Prehľadáme vaše webové korene na výpisy, archívy, kópie a zálohy pluginov a každý nález vyhodnotíme.
• Na základe prístupových protokolov preveríme, či sa súbory sťahovali, a výsledok zdokumentujeme pre vaše posúdenie ochrany údajov.
• Zavedieme blokovanie vo webservery a pravidelné automatické hľadanie.
• Zálohy presunieme na chránené miesto mimo webového koreňa.

Tieto práce sú súčasťou nášho spevnenia servera (hardening) pre webservery PHP.

Časté otázky

Zdroje

• OWASP Top 10
• GDPR čl. 33: oznámenie dozornému orgánu
• Dokumentácia Nginx