# Резервни файлове в уеб корена: .zip, .sql и .bak

> Резервни файлове в уеб корена може да изтегли всеки. Как да откриете .zip, .sql и .bak файлове, да ги блокирате и да проверите дали са били изтегляни.

Източник: https://phpsos.de/bg/blog/backup-dateien-im-webroot/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** Резервни файлове в уеб корена, тоест дъмпове на бази данни (`.sql`), архиви (`.zip`, `.tar.gz`) и резервни копия (`.bak`, `.old`, `~`), може да изтегли всеки, който знае или налучка името на файла. Търсете редовно такива файлове с `find`, преместете резервните копия извън публичната директория, блокирайте типичните разширения в уеб сървъра и проверете в журналите за достъп дали вече са били изтегляни.

## Резервното копие, което става теч

Малко преди актуализация някой бързо създава резервно копие: `backup.zip` в главната директория, до него `datenbank.sql`. Актуализацията минава, файловете остават. Месеци по-късно те още са там, с целия код, всички данни на клиенти и данните за достъп на уебсайта.

Този образец е сред най-честите констатации при проверки на уеб сървъри. Не е нужен експлойт, нито уязвимост в PHP. Уеб сървърът доставя от уеб корена това, което е там, а архиви или SQL файлове не изпълнява, а предлага за изтегляне.

Архив на уебсайта не съдържа само данни, а и кода заедно с конфигурацията. Който го изтегли, може на спокойствие да търси слабости и познава данните за достъп до базата данни.

Автоматизирани скенери търсят целенасочено типични имена като `backup.zip`, `site.tar.gz` или `dump.sql`, често комбинирани с името на домейна или дата. Който вярва, че необичайно име на файл го защитава, подценява колко систематично върви това търсене.

## Кои файлове имаме предвид

Резервните файлове в уеб корена се срещат в няколко форми:

| Вид | Типични разширения | Какво съдържат |
|---|---|---|
| Дъмпове на бази данни | `.sql`, `.sql.gz`, `.dump` | Данни на клиенти, поръчки, хешове на пароли, настройки |
| Архиви на уебсайта | `.zip`, `.tar`, `.tar.gz`, `.tgz`, `.rar`, `.7z` | Целия код, конфигурация, качени файлове |
| Копия на отделни файлове | `.bak`, `.old`, `.orig`, `.save`, `.php~`, `.copy` | Често конфигурационни файлове с данни за достъп |
| Останки от редактори | `.swp`, `.swo`, `~` в края | Части от файлове, редактирани в момента |
| Резервни копия от добавки | отделни подпапки в CMS | Пълни резервни копия, понякога с налучкваеми имена |

Особено деликатни са копията на конфигурационни файлове. Оригиналният файл `config.php` сървърът изпълнява, а съдържанието му остава скрито. Копието `config.php.bak` той доставя като текст, заедно с паролата за базата данни.

## Откриване на резервни копия в уеб корена: търсене на сървъра

Следващото търсене изброява подозрителни файлове под уеб корените с дата и размер. Съобразете пътищата с Вашия сървър:

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

Не всяко попадение е проблем. Някои архиви са предоставени съзнателно за изтегляне, например ръководства. Всеки файл заслужава обаче съзнателно решение. Обърнете особено внимание на големите файлове и на папките на добавки за резервни копия. При споделен хостинг без достъп до shell помага прегледът на файловете в хостинг панела или извличане през SFTP.

> **Действайте веднага:**
> Ако намерите дъмп на база данни с данни на клиенти в уеб корена, преместете го веднага от публичната директория и запазете журналите за достъп, преди да бъдат ротирани. Едва след това изяснете дали файлът е бил изтеглян.

## Изтеглен ли е файлът вече?

Отговорът е в журналите за достъп на уеб сървъра. Търсят се успешни извиквания, тоест статус 200, на намерените файлове:

```bash
# Успешни извиквания на типични разширения на резервни копия (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}'
```

Изходът показва момент, адрес, път и размер на отговора. Ако предаденият размер съответства на размера на файла, файлът е бил зареден изцяло. Докъде назад стигат журналите, зависи от ротацията. Ако не стигат до датата на създаване на файла, по-ранно изтегляне не може да се изключи. Подробно това описва [Анализ на журналите на уеб сървъра след атака](https://phpsos.de/bg/ratgeber/logfiles-auswerten/). Без достъп до суровите журнали, например при споделен хостинг, поискайте от хостинг доставчика журналите за съответния период.

Ако е бил изтеглен дъмп с лични данни или това не може да се изключи, започва проверката за задължение за уведомяване. Основите обобщава [Задължение за уведомяване по ОРЗД: 72 часа след инцидента](https://phpsos.de/bg/compliance/dsgvo-meldepflicht-72-stunden/); оценката в конкретния случай принадлежи на Вашето длъжностно лице по защита на данните. Данните за достъп от изтеглени файлове сменяте във всеки случай.

## Добавки за резервни копия, панели и преместване

Много находки се дължат на добавки за резервни копия на CMS и магазини. Те често записват копията в подпапка на уеб корена, понякога с имена от дата и домейн, които могат да се налучкат. Проверете във всяка добавка три настройки: къде се архивира? Изтриват ли се локалните копия след качване към външна цел? Защитена ли е локалната папка срещу директно извикване?

Резервните копия от хостинг панели по правило стоят извън уеб корена, например в домашната директория. Проблем възниква, когато някой копира такова копие в уеб корена, защото изтеглянето в браузъра е по-удобно от SFTP. За преместванията затова важи: прехвърляне по SFTP или директно между сървърите, никога чрез публична връзка.

Ако агенции или доставчици на услуги поддържат Вашите уебсайтове, това правило трябва да стои и в договора, заедно със задължението за почистване след дейности по поддръжка. Насоки дава [Договори с ИТ доставчици: ясно уреждане на задълженията за сигурност](https://phpsos.de/bg/blog/dienstleistervertrag-sicherheit/).

## Превенция за постоянно: място за съхранение и блокиране

За да не се повтори проблемът, са нужни две нива. Първото е организационно: резервните копия имат определено място извън уеб корена и допълнително извън сървъра. Как изглежда надеждно резервно копие, описва наръчникът [Резервни копия по правилото 3-2-1](https://phpsos.de/bg/ratgeber/backups-3-2-1/).

Второто ниво е техническо: уеб сървърът по принцип отказва типичните разширения на резервни копия, дори и някой файл все пак да остане.

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

Архиви като `.zip` блокирате само ако Вашият уебсайт не предлага изтегляния в този формат, или целенасочено в директориите, в които няма изтегляния. Допълнително помагат редовно автоматично търсене с известяване и кратко правило в екипа: без резервни копия и копия в уеб корена, дори за пет минути. Сродни случаи като скрити конфигурационни файлове разглежда [Правилна защита на данните за достъп и .env файловете](https://phpsos.de/bg/blog/env-dateien-schuetzen/).

## Как помага PHP SOS конкретно?

- Претърсваме Вашите уеб корени за дъмпове, архиви, копия и резервни копия от добавки и оценяваме всяка находка.
- Проверяваме по журналите за достъп дали файлове са били изтегляни и документираме резултата за Вашата оценка във връзка със защитата на данните.
- Въвеждаме блокирания в уеб сървъра и редовно автоматично търсене.
- Преместваме резервните копия на защитено място извън уеб корена.

Тези дейности са част от нашето [заздравяване на сървъри за PHP уеб сървъри](https://phpsos.de/bg/leistungen/server-haertung/).


## Често задавани въпроси

**Защо резервните копия изобщо попадат в уеб корена?**  
Най-често от удобство: дъмп се създава за преместване, добавка записва копия в собствената си папка или преди промяна бързо се създава копие на файл с разширение .bak. След това файлът бива забравен.

**Колко опасен е файл като config.php.bak?**  
Много. Файл с разширение .php се изпълнява от сървъра, а съдържанието му остава скрито. Копие с друго разширение сървърът обикновено доставя като текст, заедно с паролата за базата данни и ключовете.

**Нарушение на сигурността на данните ли е публично достъпен дъмп на база данни?**  
Ако съдържа лични данни и е бил изтеглен или изтегляне не може да се изключи, идва предвид задължение за уведомяване по ОРЗД. Оценката в конкретния случай поемат Вашето длъжностно лице по защита на данните или Вашият правен съветник.

**Къде трябва да са резервните копия вместо това?**  
Извън уеб корена и допълнително извън сървъра, по правилото 3-2-1. Поне едно копие трябва да се съхранява така, че самият уеб сървър да не може да го изтрие или промени.

## Източници

- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [ОРЗД, чл. 33: уведомяване на надзорния орган](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Документация на Nginx](https://nginx.org/en/docs/)