Röviden: A webrootban lévő mentésfájlokat, vagyis az adatbázis-dumpokat (.sql), az archívumokat (.zip, .tar.gz) és a biztonsági másolatokat (.bak, .old, ~) bárki letöltheti, aki ismeri vagy kitalálja a fájlnevet. Az ilyen fájlokat rendszeresen keresse a find paranccsal, a mentéseket helyezze át a nyilvános könyvtáron kívülre, a tipikus végződéseket tiltsa le a webszerverben, és a hozzáférési naplókban ellenőrizze, hogy lekérték-e már őket.
A mentés, amely szivárgássá válik
Egy frissítés előtt valaki még gyorsan készít egy mentést: backup.zip a főkönyvtárban, mellette datenbank.sql. A frissítés sikerül, a fájlok ott maradnak. Hónapokkal később még mindig ott vannak, a teljes kóddal, az összes ügyféladattal és a weboldal hozzáférési adataival.
Ez a minta a webszerverek ellenőrzéseinek leggyakoribb megállapításai közé tartozik. Nem kell hozzá exploit, sem a PHP-ban lévő rés. A webszerver a webrootból kiszolgálja, ami ott van, az archívumokat vagy SQL-fájlokat pedig nem hajtja végre, hanem letöltésre kínálja.
A weboldal archívuma ráadásul nem csak adatokat tartalmaz, hanem a kódot is a konfigurációval együtt. Aki letölti, nyugodtan kereshet sebezhetőségeket, és ismeri az adatbázis hozzáférési adatait.
Az automatizált szkennerek célzottan keresik a tipikus neveket, mint a backup.zip, a site.tar.gz vagy a dump.sql, gyakran a domainnévvel vagy egy dátummal kombinálva. Aki azt hiszi, hogy egy szokatlan fájlnév véd, alábecsüli, milyen szisztematikusan megy ez a keresés.
Mely fájlokról van szó
A webrootban lévő mentésfájlok többféle formában fordulnak elő:
| Fajta | Tipikus végződések | Mi van bennük |
|---|---|---|
| Adatbázis-dumpok | .sql, .sql.gz, .dump |
ügyféladatok, rendelések, jelszó-hashek, beállítások |
| A weboldal archívumai | .zip, .tar, .tar.gz, .tgz, .rar, .7z |
a teljes kód, konfiguráció, feltöltések |
| Egyes fájlok másolatai | .bak, .old, .orig, .save, .php~, .copy |
gyakran hozzáférési adatokat tartalmazó konfigurációs fájlok |
| Szerkesztőmaradványok | .swp, .swo, ~ a végén |
éppen szerkesztett fájlok részei |
| Bővítmény-mentések | saját almappák a CMS-ben | teljes mentések, részben kitalálható nevekkel |
Különösen kényesek a konfigurációs fájlok másolatai. Az eredeti config.php fájlt a szerver végrehajtja, a tartalma rejtve marad. A config.php.bak másolatot szövegként szolgálja ki, az adatbázis-jelszóval együtt.
Mentés a webrootban megtalálása: keresés a szerveren
A következő keresés felsorolja a webrootok alatti gyanús fájlokat dátummal és mérettel. Az útvonalakat igazítsa a szerveréhez:
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
Nem minden találat probléma. Egyes archívumokat szándékosan letöltésre bocsátottak, például kézikönyveket. Minden fájl megérdemel azonban egy tudatos döntést. Különösen a nagy fájlokra és a mentő bővítmények mappáira ügyeljen. Shell-hozzáférés nélküli megosztott tárhelynél a tárhelypanel fájláttekintése vagy egy SFTP-lekérés segít.
Ha egy ügyféladatokat tartalmazó adatbázis-dumpot talál a webrootban, azonnal helyezze át a nyilvános könyvtárból, és mentse a hozzáférési naplókat, mielőtt azokat rotálják. Csak ezután tisztázza, hogy lekérték-e a fájlt.
Letöltötték már a fájlt?
A válasz a webszerver hozzáférési naplóiban van. A sikeres lekéréseket keresi, vagyis a 200-as állapotúakat a megtalált fájlokra:
# A tipikus mentési végződések sikeres lekérései (Combined naplóformátum)
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}'
A kimenet megmutatja az időpontot, a címet, az útvonalat és a válasz méretét. Ha az átvitt méret megfelel a fájlméretnek, a fájlt teljes egészében letöltötték. Hogy a naplók meddig nyúlnak vissza, a rotációtól függ. Ha nem érnek el a fájl létrehozásának dátumáig, egy korábbi lekérés nem zárható ki. Részletesen ezt a Webszerver-naplók kiértékelése egy támadás után írja le. A nyers naplókhoz való hozzáférés nélkül, például megosztott tárhelynél, kérje el a tárhelyszolgáltatótól az érintett időszak naplóit.
Ha személyes adatokat tartalmazó dumpot kértek le, vagy ez nem zárható ki, megkezdődik a bejelentési kötelezettség vizsgálata. Az alapokat a GDPR-bejelentési kötelezettség: 72 óra az incidens után foglalja össze; az egyedi esetben az értékelés az adatvédelmi tisztviselőjére tartozik. A lekért fájlokból származó hozzáférési adatokat minden esetben cserélje ki.
Mentő bővítmények, panelek és költözések
Sok találat a CMS-ek és webshopok mentő bővítményeire vezethető vissza. A mentéseket gyakran a webroot egy almappájában tárolják, részben dátumból és domainből álló, kitalálható nevekkel. Minden bővítményben három beállítást ellenőrizzen: hová ment? Törlik-e a helyi másolatokat egy külső célra való feltöltés után? Védett-e a helyi mappa a közvetlen lekérés ellen?
A tárhelypanelek mentései általában a webrooton kívül vannak, például a saját könyvtárban. Problémás, ha valaki ilyen mentést átmásol a webrootba, mert a böngészőből való letöltés kényelmesebb, mint SFTP-vel. Költözéseknél ezért ez érvényes: átvitel SFTP-vel vagy közvetlenül a szerverek között, soha nem nyilvános linken keresztül.
Ha ügynökségek vagy szolgáltatók gondozzák a weboldalait, ennek a szabálynak a szerződésben is szerepelnie kell, a karbantartási munkák utáni takarítási kötelezettséggel együtt. Útmutatást ad az IT-szolgáltatói szerződések: a biztonsági kötelezettségek egyértelmű szabályozása.
Tartós megelőzés: tárolási hely és tiltások
Hogy a probléma ne ismétlődjön, két szint kell. Az első szervezési: a mentéseknek rögzített helyük van a webrooton kívül, és ezenkívül a szerveren kívül is. Hogyan néz ki egy terhelhető mentés, azt a Mentések a 3-2-1 szabály szerint útmutató írja le.
A második szint technikai: a webszerver alapvetően megtagadja a tipikus mentési végződéseket, még ha egyszer mégis ottmarad egy fájl.
location ~* \.(sql|sql\.gz|dump|bak|old|orig|save|swp|swo)$ {
return 404;
}
location ~ ~$ {
return 404;
}
Az olyan archívumokat, mint a .zip, csak akkor tiltsa, ha a weboldala nem kínál ilyen formátumú letöltéseket, vagy célzottan azokban a könyvtárakban, ahol nincsenek letöltések. Kiegészítésként segít a rendszeres automatikus keresés értesítéssel, és egy rövid szabály a csapatban: nincsenek mentések és másolatok a webrootban, ötpercre sem. A rokon eseteket, mint a rejtett konfigurációs fájlok, a Hozzáférési adatok és .env fájlok helyes védelme tárgyalja.
Hogyan segít konkrétan a PHP SOS?
- Átvizsgáljuk a webrootjait dumpok, archívumok, másolatok és bővítmény-mentések után, és minden találatot értékelünk.
- A hozzáférési naplók alapján ellenőrizzük, hogy lekértek-e fájlokat, és az eredményt dokumentáljuk az Ön adatvédelmi értékeléséhez.
- Tiltásokat és rendszeres automatikus keresést állítunk be a webszerverben.
- A mentéseket védett helyre helyezzük át a webrooton kívül.
Ezek a munkák a PHP-webszerverek keményítésének részei.
Gyakori kérdések
Miért kerülnek egyáltalán mentések a webrootba?
Többnyire kényelemből: egy dump egy költözéshez készül, egy bővítmény a saját mappájában tárolja a mentéseket, vagy egy módosítás előtt gyorsan másolatot készítenek egy fájlról .bak végződéssel. Utána a fájl feledésbe merül.
Mennyire veszélyes egy olyan fájl, mint a config.php.bak?
Nagyon. A .php végződésű fájlt a szerver végrehajtja, a tartalma rejtve marad. A más végződésű másolatot viszont a szerver többnyire szövegként szolgálja ki, az adatbázis-jelszóval és a kulcsokkal együtt.
Egy nyilvánosan lekérhető adatbázis-dump adatvédelmi incidens?
Ha személyes adatokat tartalmaz, és lekérték, vagy a lekérés nem zárható ki, a GDPR szerinti bejelentési kötelezettség jöhet szóba. Az egyedi esetben az értékelést az adatvédelmi tisztviselője vagy a jogi tanácsadója végzi.
Hol legyenek helyette a mentések?
A webrooton kívül, és ezenkívül a szerveren kívül is, a 3-2-1 szabály szerint. Legalább egy másolatot úgy kell tárolni, hogy a webszerver maga ne törölhesse vagy módosíthassa.