Накратко: Резервни файлове в уеб корена, тоест дъмпове на бази данни (.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 той доставя като текст, заедно с паролата за базата данни.
Откриване на резервни копия в уеб корена: търсене на сървъра
Следващото търсене изброява подозрителни файлове под уеб корените с дата и размер. Съобразете пътищата с Вашия сървър:
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, на намерените файлове:
# Успешни извиквания на типични разширения на резервни копия (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}'
Изходът показва момент, адрес, път и размер на отговора. Ако предаденият размер съответства на размера на файла, файлът е бил зареден изцяло. Докъде назад стигат журналите, зависи от ротацията. Ако не стигат до датата на създаване на файла, по-ранно изтегляне не може да се изключи. Подробно това описва Анализ на журналите на уеб сървъра след атака. Без достъп до суровите журнали, например при споделен хостинг, поискайте от хостинг доставчика журналите за съответния период.
Ако е бил изтеглен дъмп с лични данни или това не може да се изключи, започва проверката за задължение за уведомяване. Основите обобщава Задължение за уведомяване по ОРЗД: 72 часа след инцидента; оценката в конкретния случай принадлежи на Вашето длъжностно лице по защита на данните. Данните за достъп от изтеглени файлове сменяте във всеки случай.
Добавки за резервни копия, панели и преместване
Много находки се дължат на добавки за резервни копия на CMS и магазини. Те често записват копията в подпапка на уеб корена, понякога с имена от дата и домейн, които могат да се налучкат. Проверете във всяка добавка три настройки: къде се архивира? Изтриват ли се локалните копия след качване към външна цел? Защитена ли е локалната папка срещу директно извикване?
Резервните копия от хостинг панели по правило стоят извън уеб корена, например в домашната директория. Проблем възниква, когато някой копира такова копие в уеб корена, защото изтеглянето в браузъра е по-удобно от SFTP. За преместванията затова важи: прехвърляне по SFTP или директно между сървърите, никога чрез публична връзка.
Ако агенции или доставчици на услуги поддържат Вашите уебсайтове, това правило трябва да стои и в договора, заедно със задължението за почистване след дейности по поддръжка. Насоки дава Договори с ИТ доставчици: ясно уреждане на задълженията за сигурност.
Превенция за постоянно: място за съхранение и блокиране
За да не се повтори проблемът, са нужни две нива. Първото е организационно: резервните копия имат определено място извън уеб корена и допълнително извън сървъра. Как изглежда надеждно резервно копие, описва наръчникът Резервни копия по правилото 3-2-1.
Второто ниво е техническо: уеб сървърът по принцип отказва типичните разширения на резервни копия, дори и някой файл все пак да остане.
location ~* \.(sql|sql\.gz|dump|bak|old|orig|save|swp|swo)$ {
return 404;
}
location ~ ~$ {
return 404;
}
Архиви като .zip блокирате само ако Вашият уебсайт не предлага изтегляния в този формат, или целенасочено в директориите, в които няма изтегляния. Допълнително помагат редовно автоматично търсене с известяване и кратко правило в екипа: без резервни копия и копия в уеб корена, дори за пет минути. Сродни случаи като скрити конфигурационни файлове разглежда Правилна защита на данните за достъп и .env файловете.
Как помага PHP SOS конкретно?
- Претърсваме Вашите уеб корени за дъмпове, архиви, копия и резервни копия от добавки и оценяваме всяка находка.
- Проверяваме по журналите за достъп дали файлове са били изтегляни и документираме резултата за Вашата оценка във връзка със защитата на данните.
- Въвеждаме блокирания в уеб сървъра и редовно автоматично търсене.
- Преместваме резервните копия на защитено място извън уеб корена.
Тези дейности са част от нашето заздравяване на сървъри за PHP уеб сървъри.
Често задавани въпроси
Защо резервните копия изобщо попадат в уеб корена?
Най-често от удобство: дъмп се създава за преместване, добавка записва копия в собствената си папка или преди промяна бързо се създава копие на файл с разширение .bak. След това файлът бива забравен.
Колко опасен е файл като config.php.bak?
Много. Файл с разширение .php се изпълнява от сървъра, а съдържанието му остава скрито. Копие с друго разширение сървърът обикновено доставя като текст, заедно с паролата за базата данни и ключовете.
Нарушение на сигурността на данните ли е публично достъпен дъмп на база данни?
Ако съдържа лични данни и е бил изтеглен или изтегляне не може да се изключи, идва предвид задължение за уведомяване по ОРЗД. Оценката в конкретния случай поемат Вашето длъжностно лице по защита на данните или Вашият правен съветник.
Къде трябва да са резервните копия вместо това?
Извън уеб корена и допълнително извън сървъра, по правилото 3-2-1. Поне едно копие трябва да се съхранява така, че самият уеб сървър да не може да го изтрие или промени.