Файлы .env и .git на сервере: что ищут сканеры

В логах моего сервера я регулярно вижу запросы к адресам, которых на сайте нет: /.env, /.git/config, /backup.zip, /phpinfo.php. Это не клиенты и не поисковые системы, а автоматические сканеры. Они по очереди опрашивают тысячи сайтов компаний и проверяют, не оставил ли кто-нибудь на сервере файл с паролями или копию всего сайта.

Если такой файл доступен, достаточно одного скачивания: пароль к базе данных, ключ к почте или копия данных клиентов попадает к постороннему человеку. В этой статье я показываю, что ищут сканеры, как за 10 минут проверить собственный сайт и как заблокировать эти файлы.

Что ищут сканеры

Одни и те же адреса повторяются в логах многих серверов. За каждым из них стоит файл, который иногда остаётся в каталоге сайта после развёртывания или обновления.

Важное различие: файл wp-config.php сервер запускает как программу, поэтому снаружи его содержимое не видно. А вот его копия с другим окончанием (.bak, .old, .txt) уже является обычным текстовым файлом, который браузер просто покажет или скачает.

Откуда эти файлы берутся на сервере

Никто не оставляет их намеренно. Чаще всего я вижу пять сценариев:

1. Развёртывание путём копирования всей папки проекта. Вместе с файлами сайта на сервер попадают скрытый каталог .git и файл .env.
2. Копия «на минутку» перед обновлением. Кто-то упаковывает сайт в backup.zip в каталоге сайта и забывает удалить этот архив.
3. Копии из редактора. Редактор оставляет рядом с редактируемым файлом файлы с окончанием ~, .bak или .swp.
4. Старая версия сайта в подкаталоге. После смены сайта предыдущая версия попадает в /old/ или /test/ и продолжает работать, часто без обновлений.
5. Резервные копии в публичном каталоге. Некоторые инструменты резервного копирования сохраняют архивы в месте, до которого можно добраться из браузера.

Как проверить свой сайт за 10 минут

Проверяйте только собственный сайт или сайт, который Вы обслуживаете с разрешения владельца.

Шаг 1: введите адреса в браузере. Замените yourdomain.pl своим адресом и откройте по очереди:

https://yourdomain.pl/.env
https://yourdomain.pl/.git/config
https://yourdomain.pl/.git/HEAD
https://yourdomain.pl/backup.zip
https://yourdomain.pl/phpinfo.php

Хороший результат: ошибка 403 или 404. Плохой результат: показанное содержимое файла или начавшееся скачивание.

Шаг 2: просмотрите каталог сайта. Войдите в файловый менеджер в панели хостинга (или по FTP) и откройте каталог сайта, обычно public_html или www. Ищите файлы с окончаниями .zip, .sql, .tar.gz, .bak, .old и каталоги old, test, kopia.

Шаг 3: проверьте списки файлов в каталогах. Откройте адрес каталога, в котором лежат изображения, например https://yourdomain.pl/wp-content/uploads/ в WordPress. Если Вы видите список файлов вместо пустой страницы или ошибки, сервер показывает содержимое каталогов каждому посетителю.

Более широкую проверку сайта, не только на эти файлы, Вы найдёте в статье как проверить сайт компании бесплатно.

Что делать, если файл доступен

Если какой-то из адресов показал содержимое, действуйте в таком порядке:

1. Удалите файл или перенесите его за пределы каталога сайта. Резервные копии не должны лежать в месте, доступном из интернета.
2. Считайте пароли из этого файла раскрытыми. Смените пароль к базе данных, сгенерируйте новые ключи API и отзовите старые, смените пароль к почтовому ящику, которым пользуется сайт. В WordPress сгенерируйте также новые ключи аутентификации и соли, что завершит сеансы всех вошедших пользователей.
3. Запросите у хостинга логи. Спросите, скачивал ли кто-нибудь этот адрес (ответ сервера 200). Это покажет, утёк ли файл или просто лежал.
4. Оцените, не утекли ли персональные данные. Если в копии была база с данными клиентов, это может быть нарушением защиты данных. Статья 33 GDPR (RODO) требует сообщить Председателю UODO (Urząd Ochrony Danych Osobowych, польского органа по защите персональных данных) без неоправданной задержки и по возможности не позднее 72 часов после обнаружения нарушения, если только маловероятно, что оно повлечёт риск для прав и свобод физических лиц. Информация и форма есть на сайте uodo.gov.pl.

Полный план первых суток после обнаружения проблемы я описываю в статье уязвимость на сайте компании: что делать в первые 24 часа.

Блокировка в конфигурации сервера

Удаление файлов является основой, но стоит также навсегда заблокировать такие адреса. Тогда случайно загруженный файл не будет доступен.

Apache (многие виртуальные хостинги), файл .htaccess в каталоге сайта:

# Без списка файлов в каталогах
Options -Indexes

# Файлы и каталоги, начинающиеся с точки (.env, .git), кроме .well-known
RedirectMatch 404 /\.(?!well-known)

# Копии и дампы, которых не должно быть в каталоге сайта
<FilesMatch "(\.(sql|bak|old|swp)|~)$">
  Require all denied
</FilesMatch>

Три замечания перед вставкой:

• Сделайте копию текущего .htaccess и сразу после изменения откройте сайт. Часть хостингов не разрешает строку Options, и тогда сайт покажет ошибку 500. Удалите эту строку и спросите хостинг, как отключить список файлов.
• Require all denied работает в Apache 2.4, то есть на подавляющем большинстве современных серверов.
• Исключение для .well-known нужно, потому что через него работает, в частности, продление SSL-сертификата.

Nginx (серверы VPS, изменение вносит администратор):

location ~ /\.(?!well-known) {
    deny all;
}

location ~* \.(sql|bak|old|swp)$ {
    deny all;
}

После изменения и удаления лишних файлов повторите шаг 1 проверки: все адреса должны вернуть 403 или 404.

Как не допустить этого в будущем

• Загружайте на сервер только файлы сайта, без каталога .git, файлов проекта и заметок. У инструментов развёртывания для этого есть список исключений.
• Храните .env вне публичного каталога. У фреймворков вроде Laravel есть отдельный каталог public, и только он должен быть виден из интернета, а файл .env лежит уровнем выше.
• Храните резервные копии вне каталога сайта и вне сервера. Как это организовать, я описываю в статье о резервной копии сайта и правиле 3-2-1.
• Наводите порядок после каждого обновления: удаляйте тестовые файлы, архивы и старые версии сайта.
• Раз в квартал повторяйте проверку из этой статьи. Это 10 минут, а сканеры не делают перерывов.

Итог

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