Ограничение доступа через .htaccess в Apache 2.4: IP, пароль и проверка защиты

Файл .htaccess позволяет задать правила доступа к каталогу сайта, когда нет возможности менять основной конфигурационный файл Apache. Типичные задачи — закрыть тестовую площадку, разрешить служебный раздел только из VPN и запретить выдачу файлов с конфигурацией или дампами. Рабочая защита зависит от того, какой сервер действительно обрабатывает запрос.

Ниже используются директивы Apache 2.4. Адреса 192.0.2.0/24 и 198.51.100.0/24 зарезервированы для документации: перед применением замените их адресами своего разрешённого выхода. Примеры предназначены для выбранного каталога, а не для безусловного закрытия всего сайта.

1. Убедитесь, что запрос проходит через Apache

Nginx не читает .htaccess. Если перед Apache стоит Nginx, а статические файлы выдаются непосредственно им, правило Apache может защитить PHP-страницу и оставить доступным соседний архив. CDN или другой кэширующий прокси также способен вернуть уже сохранённый ответ.

Нарисуйте путь: клиент, CDN, reverse proxy, Apache, приложение. Для проверяемого URL определите обработчик и место ограничения. При доступе к конфигурации сервера используйте вывод виртуальных хостов; команды зависят от дистрибутива.

# Debian/Ubuntu с пакетом Apache
sudo apache2ctl -S
sudo apache2ctl -M
# RHEL-подобная система: вместо apache2ctl используйте httpd

Проверяйте фактический DocumentRoot и правила выдачи статики. Заголовок Server сам по себе не доказывает, какой внутренний компонент обработал запрос. Для чувствительных данных предпочтительнее хранение вне web-root, а не единственное правило веб-сервера.

2. Проверьте AllowOverride до изменения файла

Руководство Apache по .htaccess определяет действие AllowOverride и AllowOverrideList. При AllowOverride None без разрешённых исключений файл игнорируется. Наличие файла на диске ещё не означает, что его правила применены.

Если основной конфигурацией управляете вы, ограничения удобнее задать непосредственно там. Для распределённой настройки разрешите только нужные категории в конкретном каталоге. Пример блока в конфигурации виртуального хоста, а не внутри .htaccess:

<Directory "/srv/www/example-site/private">
    AllowOverride AuthConfig
    Require all granted
</Directory>

Перед включением проверьте вложенные каталоги и существующие Location/Directory-блоки: объединение секций влияет на итоговые права. Применение AuthConfig позволяет использовать правила аутентификации и авторизации, но не разрешает произвольные RewriteRule или Options.

Сначала сохраните прежнюю конфигурацию вне публичного каталога. Не оставляйте config.bak или site.sql рядом с сайтом, рассчитывая скрыть их только названием.

3. Как запретить доступ к отдельному каталогу

Для полностью закрытого служебного каталога создайте или согласованно дополните его .htaccess:

Require all denied

После изменения запрос к известному файлу внутри каталога должен получить отказ. Проверяйте реальный существующий файл: HTTP 404 для несуществующего пути не подтверждает срабатывание ограничения.

Не заменяйте этим весь корневой .htaccess CMS. Там могут находиться маршрутизация, обработка ошибок и служебные исключения. Вносите минимальное изменение в выбранный каталог, учитывая его дочерние секции. Защита каталога приложения не отменяет доступа через другой virtual host, alias, origin-адрес или альтернативный путь.

4. Как разрешить доступ из офиса или VPN

В .htaccess защищаемого каталога разрешите конкретный адрес либо согласованную подсеть:

# Адреса документации: заменить перед применением
Require ip 192.0.2.25 198.51.100.0/24

Здесь несколько адресов в одной директиве работают как альтернативы. Из других источников доступ должен быть закрыт. Современный синтаксис описан в документации управления доступом Apache; старые Order, Allow и Deny из Apache 2.2 не стоит смешивать с Require.

Используйте адрес, который видит сервер. За NAT это может быть общий адрес офиса, а за VPN — адрес выхода VPN. Внутренний IP ноутбука не обязательно попадёт в запрос к внешнему сайту. Проверьте IPv4 и IPv6: разрешение только одного семейства может дать разный результат на одной машине.

5. Как объединить разрешение и исключение

Отрицательное правило требует положительной части. Если разрешена подсеть, но один её адрес нужно исключить, используйте RequireAll:

<RequireAll>
    Require ip 198.51.100.0/24
    Require not ip 198.51.100.42
</RequireAll>

Смысл: клиент должен принадлежать разрешённой сети и не совпадать с исключением. Одна директива Require not ip не является самостоятельным разрешением остальных клиентов. Порядок объединения правил объясняет mod_authz_core.

Проверьте минимум три случая: разрешённый адрес, исключённый адрес внутри подсети и адрес за её пределами. Для каждого сохраните время и HTTP-статус. Проверка только своего рабочего компьютера может пропустить ошибку в запретительной части.

6. Как добавить пароль к служебному разделу

Для Basic Auth используйте HTTPS и файл паролей вне web-root. Утилита htpasswd создаёт хеши, а не файл с открытым паролем. На сервере должен быть доступен соответствующий пакет Apache tools и модуль проверки файла пользователей.

# Только при первоначальном создании НОВОГО файла
sudo htpasswd -cB /etc/apache2/private-site.htpasswd support_admin
# При добавлении следующего пользователя: без -c
sudo htpasswd -B /etc/apache2/private-site.htpasswd another_admin

Ключ -c создаёт файл заново: его нельзя применять к существующему файлу, если нужно сохранить остальных пользователей. Пароль вводится интерактивно; не помещайте его в командную строку. Проверьте владельца и разрешения так, чтобы процесс Apache мог читать файл, а обычные пользователи сайта не могли его менять. Поведение ключей описано в htpasswd.

Конфигурация каталога:

AuthType Basic
AuthName "Service area"
AuthUserFile /etc/apache2/private-site.htpasswd
Require valid-user

Basic Auth не заменяет права приложения и MFA для административной панели. Для дополнительных требований следуйте руководству Apache по аутентификации.

7. Как потребовать одновременно VPN и пароль

Если нужно выполнить оба условия, задайте явное RequireAll. Два независимых разрешающих Require на одном уровне могут дать более широкий доступ, чем ожидалось.

AuthType Basic
AuthName "Restricted service"
AuthUserFile /etc/apache2/private-site.htpasswd
<RequireAll>
    Require ip 198.51.100.0/24
    Require valid-user
</RequireAll>

Проверьте четыре комбинации: разрешённая сеть с правильной авторизацией, она же без авторизации, чужая сеть с правильной авторизацией, чужая сеть без неё. Успешной должна быть только первая. Сохраняйте именно наблюдаемые статусы: детали 401/403 зависят от того, на каком этапе произошёл отказ.

За reverse proxy не доверяйте произвольному X-Forwarded-For от клиента. Восстановление адреса допустимо только через настроенный доверенный прокси и проверенный механизм, например mod_remoteip. Иначе клиент сможет подставить разрешённый адрес в заголовок.

8. Как защитить отдельные имена файлов

Пример запрещает выдачу .env, его вариантов и SQL/backup-файлов, если запрос действительно обрабатывает Apache:

<FilesMatch "^(?:\.env(?:\..*)?|.*\.(?:sql|bak))$">
    Require all denied
</FilesMatch>

Это дополнительная мера. Репозитории, ключи и резервные копии должны находиться вне публичного дерева. FilesMatch сопоставляет имена файлов и не является универсальным запретом всех каталогов с похожими именами. Для каталогов используйте соответствующее ограничение и проверяйте реальный URL.

Учитывайте исключения сайта: механическое закрытие всех скрытых путей способно сломать ACME-проверку в .well-known. Добавляйте исключения только для действительно необходимых ресурсов. Если Nginx обслуживает файлы отдельно, запрет требуется и в его конфигурации либо файлы нужно убрать из web-root.

9. Как проверить правило и разобраться с HTTP 500

Изменение основного конфигурационного файла требует его проверки и согласованного reload. Изменение .htaccess читается при запросе; отдельный reload обычно не требуется. Проверка apache2ctl configtest не заменяет запросы ко всем затронутым .htaccess.

sudo apache2ctl configtest
curl --max-time 10 -sS -o /dev/null -w '%{http_code}\n' \
  https://site.example/private/existing-test.txt

Домен и путь замените своим тестовым ресурсом. Для Basic Auth передайте только имя: curl --user support_admin ... запросит пароль интерактивно. Не используйте отключение проверки TLS как стандартную проверку защищённого раздела.

HTTP 500 после правки часто означает недопустимую директиву, синтаксис или запрещённую категорию override. Прочитайте error log соответствующего virtual host. Если ограничения не сработали, проверьте обработчик, AllowOverride, дочерние правила и кэш. Нельзя подтверждать защиту только отсутствием ошибки в журнале.

10. Как вернуть конфигурацию и подтвердить результат

Верните точную сохранённую версию изменённого файла. Если менялась основная конфигурация, повторите её проверку и reload штатным способом. Если менялся только .htaccess, повторите HTTP-проверки после восстановления.

Итоговая проверка должна включать разрешённого и запрещённого клиента, существующую PHP-страницу и статический файл, IPv6 при его наличии, а также альтернативный путь доступа к origin. Проверьте необходимые функции приложения и выпуск сертификатов.

Сохраните выбранный каталог, адреса доверенного выхода, правило, результаты тестов и место резервной копии. Рабочее ограничение — это подтверждённое поведение запросов через всю инфраструктуру сайта, а не просто наличие файла с красивыми директивами.