# Rezerves kopiju faili tīmekļa saknē: .zip, .sql un .bak

> Rezerves kopijas tīmekļa saknē var lejupielādēt ikviens. Kā atrast .zip, .sql un .bak failus, tos bloķēt un pārbaudīt, vai tie jau tika atvērti.

Avots: https://phpsos.de/lv/blog/backup-dateien-im-webroot/  
Aktuāls uz: 25.10.2026  
Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6

**Īsi sakot:** Rezerves kopijas tīmekļa saknē, tātad datubāzu izmetumus (`.sql`), arhīvus (`.zip`, `.tar.gz`) un rezerves kopijas (`.bak`, `.old`, `~`), var lejupielādēt ikviens, kas zina vai uzmin faila nosaukumu. Šādus failus regulāri meklējiet ar `find`, pārvietojiet rezerves kopijas ārpus publiskās direktorijas, tīmekļa serverī bloķējiet tipiskus paplašinājumus un piekļuves žurnālos pārbaudiet, vai tās jau ir atvērtas.

## Rezerves kopija, kas kļūst par noplūdi

Īsi pirms atjauninājuma kāds vēl ātri izveido rezerves kopiju: `backup.zip` galvenajā direktorijā, blakus `datenbank.sql`. Atjauninājums izdodas, faili paliek. Pēc mēnešiem tie joprojām ir tur, ar pilnu kodu, visiem klientu datiem un vietnes piekļuves datiem.

Šis paraugs pieder pie biežākajiem konstatējumiem tīmekļa serveru pārbaudēs. Tam nevajag ne exploit, ne ievainojamību PHP. Tīmekļa serveris no tīmekļa saknes piegādā to, kas tur atrodas, un arhīvus vai SQL failus tas neizpilda, bet piedāvā lejupielādei.

Vietnes arhīvs satur ne tikai datus, bet arī kodu kopā ar konfigurāciju. Kas to lejupielādē, var mierīgi meklēt vājās vietas un zina datubāzes piekļuves datus.

Automatizēti skeneri mērķtiecīgi meklē tipiskus nosaukumus, piemēram, `backup.zip`, `site.tar.gz` vai `dump.sql`, bieži kombinētus ar domēna nosaukumu vai datumu. Kas tic, ka neparasts faila nosaukums aizsargā, nenovērtē, cik sistemātiski šī meklēšana notiek.

## Kuri faili ir domāti

Rezerves kopiju faili tīmekļa saknē rodas vairākās formās:

| Veids | Tipiski paplašinājumi | Kas iekšā |
|---|---|---|
| Datubāzu izmetumi | `.sql`, `.sql.gz`, `.dump` | klientu dati, pasūtījumi, paroļu jaucējkodi, iestatījumi |
| Vietnes arhīvi | `.zip`, `.tar`, `.tar.gz`, `.tgz`, `.rar`, `.7z` | viss kods, konfigurācija, augšupielādes |
| Atsevišķu failu kopijas | `.bak`, `.old`, `.orig`, `.save`, `.php~`, `.copy` | bieži konfigurācijas faili ar piekļuves datiem |
| Redaktoru atliekas | `.swp`, `.swo`, `~` beigās | tikko rediģētu failu daļas |
| Spraudņu rezerves kopijas | savas apakšmapes CMS | pilnas rezerves kopijas, daļēji ar uzminamiem nosaukumiem |

Īpaši delikātas ir konfigurācijas failu kopijas. Oriģinālo failu `config.php` serveris izpilda, tā saturs paliek slēpts. Kopiju `config.php.bak` tas piegādā kā tekstu, kopā ar datubāzes paroli.

## Rezerves kopiju atrašana tīmekļa saknē: meklēšana serverī

Turpmākā meklēšana uzskaita aizdomīgus failus zem tīmekļa saknēm ar datumu un izmēru. Pielāgojiet ceļus savam serverim:

```bash
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
```

Ne katrs trāpījums ir problēma. Daži arhīvi ir apzināti nodrošināti lejupielādei, piemēram, rokasgrāmatas. Tomēr katram failam jāpieņem apzināts lēmums. Īpaši ņemiet vērā lielus failus un rezerves kopiju spraudņu mapes. Koplietošanas hostingā bez shell piekļuves palīdz failu pārskats hostinga panelī vai atvēršana ar SFTP.

> **Rīkoties nekavējoties:**
> Ja tīmekļa saknē atrodat datubāzes izmetumu ar klientu datiem, nekavējoties pārvietojiet to ārpus publiskās direktorijas un nodrošiniet piekļuves žurnālus, pirms tie tiek rotēti. Tikai pēc tam noskaidrojiet, vai fails tika atvērts.

## Vai fails jau ir lejupielādēts?

Atbilde ir tīmekļa servera piekļuves žurnālos. Meklējami ir sekmīgi atvērumi, tātad statuss 200, uz atrastajiem failiem:

```bash
# Sekmīgi tipisku rezerves kopiju paplašinājumu atvērumi (Combined žurnāla formāts)
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}'
```

Izvade rāda laiku, adresi, ceļu un atbildes izmēru. Ja pārsūtītais izmērs atbilst faila izmēram, fails ir lejupielādēts pilnībā. Cik tālu žurnāli sniedzas atpakaļ, atkarīgs no rotācijas. Ja tie nesniedzas līdz faila izveides datumam, agrāku atvēršanu nevar izslēgt. Plaši to apraksta [Tīmekļa servera žurnālu izvērtēšana pēc uzbrukuma](https://phpsos.de/lv/ratgeber/logfiles-auswerten/). Ja nav piekļuves neapstrādātajiem žurnāliem, piemēram, koplietošanas hostingā, pajautājiet hostinga sniedzējam žurnālus par attiecīgo laika posmu.

Ja izmetums ar personas datiem tika atvērts vai to nevar izslēgt, sākas ziņošanas pienākuma izvērtēšana. Pamatus apkopo [VDAR ziņošanas pienākums: 72 stundas pēc incidenta](https://phpsos.de/lv/compliance/dsgvo-meldepflicht-72-stunden/); novērtējums atsevišķā gadījumā pieder jūsu datu aizsardzības speciālistam. Piekļuves datus no atvērtiem failiem nomainiet jebkurā gadījumā.

## Rezerves kopiju spraudņi, paneļi un pārcelšanās

Daudzi atradumi izriet no CMS un veikalu rezerves kopiju spraudņiem. Tie rezerves kopijas bieži glabā tīmekļa saknes apakšmapē, daļēji ar nosaukumiem no datuma un domēna, kurus var uzminēt. Katrā spraudnī pārbaudiet trīs iestatījumus: kurp tiek veidota rezerves kopija? Vai lokālās kopijas pēc augšupielādes ārējā mērķī tiek dzēstas? Vai lokālā mape ir aizsargāta pret tiešu atvēršanu?

Hostinga paneļu rezerves kopijas parasti atrodas ārpus tīmekļa saknes, piemēram, mājas direktorijā. Problēmas rodas, ja kāds šādu kopiju iekopē tīmekļa saknē, jo lejupielāde pārlūkā ir ērtāka nekā ar SFTP. Pārcelšanai tāpēc ir spēkā: pārsūtīšana ar SFTP vai tieši starp serveriem, nekad ne pa publisku saiti.

Ja jūsu vietnes uztur aģentūras vai pakalpojumu sniedzēji, šim noteikumam jābūt arī līgumā, kopā ar pienākumu sakopt pēc apkopes darbiem. Norādes dod [IT pakalpojumu sniedzēju līgumi: skaidri noteikt drošības pienākumus](https://phpsos.de/lv/blog/dienstleistervertrag-sicherheit/).

## Ilgtermiņā novērst: glabāšanas vieta un bloķēšana

Lai problēma neatkārtotos, vajadzīgi divi līmeņi. Pirmais ir organizatorisks: rezerves kopijām ir fiksēta vieta ārpus tīmekļa saknes un papildus ārpus servera. Kā izskatās noturīga rezerves kopija, apraksta ceļvedis [Rezerves kopijas pēc 3-2-1 noteikuma](https://phpsos.de/lv/ratgeber/backups-3-2-1/).

Otrais līmenis ir tehnisks: tīmekļa serveris principā atsaka tipiskus rezerves kopiju paplašinājumus, arī ja kāds fails tomēr paliek.

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

Arhīvus, piemēram, `.zip`, bloķējiet tikai tad, ja jūsu vietne nepiedāvā lejupielādes šajā formātā, vai mērķtiecīgi direktorijās, kur lejupielāžu nav. Papildus palīdz regulāra automātiska meklēšana ar paziņojumu un īss noteikums komandā: nekādu rezerves kopiju un kopiju tīmekļa saknē, arī ne uz piecām minūtēm. Radniecīgus gadījumus, piemēram, slēptos konfigurācijas failus, aplūko [Piekļuves datu un .env failu pareiza aizsardzība](https://phpsos.de/lv/blog/env-dateien-schuetzen/).

## Kā PHP SOS palīdz konkrēti?

- Mēs pārmeklējam jūsu tīmekļa saknes uz izmetumiem, arhīviem, kopijām un spraudņu rezerves kopijām un novērtējam katru atradumu.
- Mēs pēc piekļuves žurnāliem pārbaudām, vai faili tika atvērti, un dokumentējam rezultātu jūsu datu aizsardzības novērtējumam.
- Mēs iestatām bloķēšanu tīmekļa serverī un regulāru automātisku meklēšanu.
- Mēs pārvietojam rezerves kopijas uz aizsargātu vietu ārpus tīmekļa saknes.

Šie darbi ir daļa no mūsu [PHP tīmekļa serveru nostiprināšanas](https://phpsos.de/lv/leistungen/server-haertung/).


## Biežāk uzdotie jautājumi

**Kāpēc rezerves kopijas vispār nonāk tīmekļa saknē?**  
Parasti ērtības dēļ: izmetums tiek izveidots pārcelšanai, spraudnis rezerves kopijas glabā savā mapē, vai pirms izmaiņas ātri tiek izveidota faila kopija ar paplašinājumu .bak. Pēc tam fails tiek aizmirsts.

**Cik bīstams ir tāds fails kā config.php.bak?**  
Ļoti. Failu ar paplašinājumu .php serveris izpilda, tā saturs paliek slēpts. Kopiju ar citu paplašinājumu serveris turpretī parasti piegādā kā tekstu, kopā ar datubāzes paroli un atslēgām.

**Vai publiski atverams datubāzes izmetums ir datu aizsardzības pārkāpums?**  
Ja tas satur personas datus un tika atvērts vai atvēršanu nevar izslēgt, pēc VDAR var iestāties ziņošanas pienākums. Novērtējumu atsevišķā gadījumā veic jūsu datu aizsardzības speciālists vai juridiskais konsultants.

**Kur tā vietā jāglabā rezerves kopijas?**  
Ārpus tīmekļa saknes un papildus ārpus servera, pēc 3-2-1 noteikuma. Vismaz vienai kopijai jābūt glabātai tā, lai tīmekļa serveris pats to nevarētu dzēst vai mainīt.

## Avoti

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [VDAR 33. pants: ziņošana uzraudzības iestādei](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Nginx dokumentācija](https://nginx.org/en/docs/)