Открытые файлы .env и .git: как найти, заблокировать и сменить секреты

Как эти файлы становятся публичными

Причины будничные. Скрипт развёртывания копирует весь репозиторий, включая .git, в каталог, который отдаёт веб-сервер. Фреймворк хранит файл конфигурации в корне проекта, который совпадает с корнем сайта. Разработчик правит файл на месте, и редактор оставляет резервную копию. В руководстве OWASP по тестированию веб-безопасности общая проблема описана так: резервные архивы могут содержать копии всех файлов внутри корня веб-сервера (и даже вне его), а резервные файлы могут раскрывать исходный код страниц, предназначенных для выполнения на сервере. Рекомендация: хранить файлы данных, журналов и конфигурации в каталогах, недоступных веб-серверу.

Последствия зависят от содержимого файла. Sysdig сообщила, что операторы EMERALDWHALE проверяли путь /.git/config, проверяли найденные токены и затем использовали их, чтобы клонировать закрытые репозитории и извлекать облачные учётные данные из исходного кода. В одном запуске нашлось более 67 000 URL с открытым путём /.git/config. Украденные учётные записи, по сообщениям, применялись для фишинга и спама, а также продавались. Утёкший .env обычно содержит пароль к базе данных, ключ API и секрет приложения, что напрямую связано с проблемой открытых баз данных.

Проверьте свой сервер

Проверяйте теми же запросами, которые делает сканер. Замените домен и выполните это со своей машины:

for p in /.env /.git/config /.git/HEAD /.env.backup /config.php.bak; do
  printf '%s  ' "$p"
  curl -s -o /dev/null -w '%{http_code}\n' "https://your-domain$p"
done

Нужный ответ 404. Ответ 403 означает, что файл есть, но заблокирован: это приемлемо, хотя подтверждает сканеру наличие пути, поэтому лучше 404. Ответ 200 требует взглянуть на тело: многие приложения возвращают главную страницу со статусом 200 для любого неизвестного пути, и это безвредно, но если вы видите строки вроде DB_PASSWORD= или [core] с repositoryformatversion, это утечка. Проверяйте каждый виртуальный хост, включая тестовые поддомены и забытые старые сайты, потому что именно их чаще всего оставляют без защиты. Помогут и журналы: найдите запросы к этим путям командой grep -E '/\.(env|git)' /var/log/nginx/access.log, чтобы увидеть, как часто сканеры уже пытаются и какой статус получали. Как читать журналы, объясняет руководство по анализу журналов.

Блокировка в nginx

Правило такое: запретить все пути с точкой, кроме того, который нужен Let's Encrypt. Проверка HTTP-01 размещает токен по адресу http://your-domain/.well-known/acme-challenge/ и, как сказано в документации Let's Encrypt, может выполняться только на порту 80, поэтому полная блокировка путей с точкой сломает продление сертификата, если не сделать исключение для этого пути. Внутри блока server:

location ^~ /.well-known/acme-challenge/ {
    allow all;
}

location ~ /\.(?!well-known/) {
    return 404;
}

Это опирается на описанный в документации порядок выбора location в nginx: сначала выбирается самый длинный совпавший префикс, и если у него есть модификатор ^~, регулярные выражения не проверяются. Поэтому путь ACME обслуживается как обычно, а регулярное выражение ловит всё остальное, что начинается с точки, включая /.env, /.git/ и /.htpasswd. Если путь ACME у вас обслуживается из отдельного root, оставьте эту настройку в первом блоке. Добавьте блок в каждый server и проверьте командой sudo nginx -t перед перезагрузкой. Если вы используете Let's Encrypt с более короткими сроками сертификатов, после этого выполните пробное продление (sudo certbot renew --dry-run), чтобы убедиться, что ничего не сломалось.

Чтобы закрыть и типичные остатки, добавьте правило для расширений резервных копий: location ~* \.(bak|old|orig|swp|sql)$ { return 404; }. Не добавляйте расширения вроде zip или gz, если вы законно отдаёте такие файлы.

Блокировка в Apache

В документации mod_alias Apache указан синтаксис RedirectMatch [status] regex URL и сказано, что для статуса вне диапазона 300-399 аргумент URL должен быть опущен, поэтому для 404 цель не нужна. В конфигурации сервера или виртуального хоста:

RedirectMatch 404 "/\.(?!well-known/)"

Это возвращает 404 для любого пути с каталогом или файлом, начинающимся с точки, кроме /.well-known/, который использует проверка Let's Encrypt. Перезагрузите командой sudo apachectl configtest && sudo systemctl reload apache2. Если приложение использует файлы .htaccess, помните, что их учёт определяется настройкой AllowOverride, и что правила в основной конфигурации проверять проще, чем разбросанные по каталогам файлы.

Устраните причину: храните секреты вне корня сайта

Блокировка URL это страховка. Долгосрочное решение: чтобы файлов вообще не было в корне сайта.

• Отдавайте подкаталог. Направьте веб-сервер на папку public/, как задумано в Laravel и многих фреймворках, чтобы корень проекта с .env и .git никогда не отдавался.
• Развёртывайте артефакты, а не репозитории. Используйте git archive, этап сборки или rsync с --exclude=.git вместо клонирования на сервер.
• Храните конфигурацию вне репозитория. Методика twelve-factor хранит конфигурацию в окружении, потому что вероятность случайно закоммитить её в репозиторий мала, и предлагает хороший тест: можно ли в любой момент открыть исходный код, не раскрыв никаких учётных данных?
• Не редактируйте файлы на месте на продакшене. OWASP называет это особенно плохой привычкой, потому что редакторы оставляют резервные копии.
• Применяйте минимальные привилегии к самим секретам. Пользователь базы данных только с теми правами, что нужны приложению, ограничивает ущерб от утёкшего файла. См. минимальные привилегии на Linux-сервере.

Если файл был открыт, меняйте всё

Блокировка пути останавливает будущие чтения, но не те, что уже произошли. Если .env или .git был доступен хоть на какое-то время, считайте, что его скопировали, и действуйте в таком порядке:

1. Заблокируйте путь (разделы выше), чтобы остановить утечку.
2. Составьте список всех секретов, которые были в файле или истории репозитория: пароли баз данных, ключи API, облачные токены, учётные данные SMTP, ключи приложения и секреты подписи.
3. Смените каждый у его источника, а не только в своей конфигурации. Отзовите старое значение; не ждите, пока его используют.
4. Проверьте, к чему давали доступ эти учётные данные, и просмотрите их журналы на предмет незнакомой активности. Sysdig отметила, что одного управления секретами недостаточно, и рекомендует следить за поведением идентификаторов, связанных с учётными данными.
5. Удалите секрет из истории Git, если репозиторий публичный или общий, но считайте это только уборкой. Переписывание истории не вернёт утёкшее значение, которое уже скопировали, поэтому настоящее решение это смена.

Если вы видите признаки того, что утёкшими учётными данными воспользовались на самом сервере, переходите к процедуре реагирования на взлом.