Защита WebDAV: SSL и двухфакторная аутентификация

Краткое определение

WebDAV — расширение HTTP для совместного чтения/записи и управления удалёнными файлами. Одной строкой: WebDAV делает удалённые ресурсы доступными как сетевые диски.

Преимущества использования WebDAV

WebDAV можно монтировать как локальный диск и работать с файлами как с локальными.
Поддерживает блокировки файлов (shared/exclusive), чтобы избежать конфликтных изменений.
Эффективнее FTP/SFTP при конвейеризации запросов через одно TCP‑соединение.
Работает по тем же портам, что и HTTP(S) — 80/443, что уменьшает проблемы с фаерволом.
Поддержка на разных платформах делает решение кросс‑платформенным.

Важно: без SSL и двухфакторной аутентификации WebDAV остаётся уязвимым для перехвата паролей и MITM‑атак.

DAV‑команды (одно предложение определения)

WebDAV добавляет к HTTP методы управления ресурсами и метаданными: PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK. Эти команды используются клиентами и серверами для навигации, изменения свойств и управления файлами.

Основные методы:

PROPFIND — получить свойства ресурса или структуру каталога.
PROPPATCH — изменить или удалить несколько свойств атомарно.
MKCOL — создать коллекцию (каталог).
COPY — скопировать ресурс между URI.
MOVE — переместить ресурс между URI.
LOCK — установить блокировку ресурса (shared или exclusive).
UNLOCK — снять блокировку.

Общая методология: как организовать защиту

Закройте хост и обновите ОС и Apache до поддерживаемых версий.
Настройте SSL/TLS с корректным сертификатом (не самоподписанный в проде).
Включите модули WebDAV (mod_dav, mod_dav_fs) и модуль для внешней аутентификации через RADIUS/PAM.
На сервере аутентификации (WiKID) добавьте веб‑сервер как RADIUS‑клиента.
Настройте PAM или модуль Apache для передачи учётных данных в WiKID RADIUS.
Ограничьте права файловой системы, настройте DavLockDB и права каталогов.
Протестируйте монтирование на клиентах Windows, macOS и Linux.
Внедрите мониторинг и регистрацию попыток аутентификации.

Настройка сервера — рекомендации по безопасности

Всегда держите систему и пакеты в актуальном состоянии.
Отключите неиспользуемые службы и порты.
Используйте непривилегированные пользователя/группу для файлов WebDAV (пример: root:apache в Fedora).
Установите строгие права: 750 или аналогичные, чтобы файлы были недоступны посторонним.
Настройте SELinux/AppArmor по необходимости.
Ведите аудит доступа и логи Apache, храните их на удалённом сервере логов.

Примечание: для продакшн‑окружений используйте сертификаты от доверенного CA и включите HSTS.

Создание директорий WebDAV

Создайте корневой каталог и подкаталоги для пользователей, затем установите владельца и права:

mkdir /var/www/webdav/

mkdir /var/www/webdav/USERNAME

chown -R root:apache /var/www/webdav

chmod -R 750 /var/www/webdav

Важно: пользователь Apache должен иметь права записи только в те каталоги, где это необходимо.

Конфигурация WiKID — кратко и по шагам

WiKID — решение для двухфакторной аутентификации, работающее через RADIUS и использующее публично‑ключевую криптографию для защиты одноразовых кодов.

Как подготовить WiKID для Apache:

Зайдите в веб‑интерфейс WiKID (http://yourwikidserver/WiKIDAdim).
Выберите вкладку «Сетевые клиенты».
Нажмите «Создать нового сетевого клиента».
Заполните форму: в поле IP‑адрес укажите IP вашего веб‑сервера.
В качестве протокола выберите RADIUS.
Нажмите «Добавить», затем на следующей странице задайте общий секрет (shared secret).
Поле «Return Attribute» оставьте пустым.
На сервере WiKID выполните ‘stop’ и затем ‘start’ для применения нового клиента в встроенном RADIUS.

Это настраивает WiKID как RADIUS‑сервер для Apache. Далее — связать Apache и PAM/RADIUS.

Интеграция Apache + RADIUS (варианты)

Ниже приведены три рабочих подхода — выберите тот, который подходит вашей ОС и политике поддержки модулей.

Вариант A — PAM + pam_radius_auth (универсальный)

Установите пакет pam_radius (название пакета может отличаться: pam_radius, pam_radius_auth и т.п.).
Создайте PAM‑сервис для Apache: /etc/pam.d/httpd с содержимым, например:

# /etc/pam.d/httpd
auth required pam_radius_auth.so
account required pam_permit.so

В файле /etc/raddb/server или /etc/pam_radius.conf добавьте строку с IP RADIUS‑сервера и shared secret (формат зависит от реализации).
Установите и включите модуль Apache для аутентификации через PAM (например, mod_authnz_pam или mod_auth_pam).
Конфигурация виртуального хоста: (пример с WebDAV и Basic Auth)


  ServerName webdav.example.com

  SSLEngine on
  SSLCertificateFile /etc/pki/tls/certs/webdav.crt
  SSLCertificateKeyFile /etc/pki/tls/private/webdav.key

  DavLockDB /var/lock/davlock
  Alias /webdav /var/www/webdav

  
    Dav On
    Options Indexes
    AuthType Basic
    AuthName "WebDAV — защищённый доступ"
    # В зависимости от модуля: AuthBasicProvider PAM или другой провайдер
    AuthBasicProvider PAM
    Require valid-user

Примечание: точные директивы AuthBasicProvider зависят от установленного модуля (PAM, radius, external). Проверьте документацию вашего модуля.

Вариант B — модуль Apache для RADIUS (mod_auth_radius)

Установите модуль mod_auth_radius, укажите RADIUS‑сервер и секрет в конфигурации. Этот метод позволяет пропускать Basic Auth напрямую в RADIUS без PAM.

Вариант C — внешняя прокси‑аутентификация

Используйте nginx или отдельный аутентификационный шлюз, который выполняет RADIUS‑запросы и проксирует валидные соединения к Apache. Подходит для унификации аутентификации в крупной инфраструктуре.

Важно: тестируйте локально и в стендовой среде до переноса в прод.

Что вводит пользователь (поведение токена)

При обращении к WebDAV клиент запрашивает имя пользователя и пароль.
Пользователь генерирует одноразовый код в WiKID‑токене и вводит его в поле пароля (или комбинацию PIN+OTP в зависимости от настроек WiKID).
Apache передаёт эти данные в RADIUS (через PAM или модуль), WiKID проверяет и возвращает ответ об успешной аутентификации.

Совет: в документации WiKID уточните формат пароля (OTP отдельно или PIN+OTP), чтобы клиенты знали, что вводить.

Клиенты: как монтировать WebDAV

Windows: «Подключить сетевой диск» → URL вида https://webdav.example.com/webdav/USERNAME. При запросе учётных данных вводите логин и OTP.
macOS: Finder → Go → Connect to Server → введите https://webdav.example.com/webdav/USERNAME.
Linux: используйте davfs2: добавить в /etc/fstab строку вида

https://webdav.example.com/webdav/USERNAME /mnt/webdav davfs _netdev,uid=1000,gid=1000 0 0

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

Управление сертификатами и SSL‑лучшие практики

Используйте сертификаты от доверенного CA (Let’s Encrypt подходит для многих случаев).
Поддерживайте современные шифровальные наборы и включайте TLS 1.2/1.3.
Включите HSTS и отключите слабые протоколы/шифры.
Регулярно обновляйте сертификаты и проверяйте цепочку доверия.

Когда это решение не подойдёт (контрпримеры)

Если клиенты требуют старых протоколов TLS или специфичных устаревших браузеров — SSL‑требования могут ломать совместимость.
Если у вас строгая политика BYOD и вы не хотите выдавать токены внешним подрядчикам — управление токенами станет проблемой.
Если требуется аудит на уровне файловой системы на стороне клиента — WebDAV не даёт встроённую детальную поведенческую телеметрию пользователей.

Альтернатива для таких случаев: VPN с мандатной аутентификацией, SFTP с ключами или корпоративный файловый шлюз с интеграцией SAML/OAuth.

Ролевые чек‑листы

Администратор сети:

Обновления ОС и Apache выполнены.
Открыты только нужные порты (443).
SSL настроен корректно.

DevOps / Системный инженер:

DAVLockDB задан и доступен.
Права на каталоги установлены (750).
Логи собираются централизованно.

Информационная безопасность:

Настроена двухфакторная аутентификация (WiKID), тест на уязвимости пройден.
Правила отказа доступа и блокировки учётных записей при подозрении на компрометацию.

Пользователь поддержки:

Инструкции для восстановления токена и сброса PIN готовы.
Документированы шаги по монтированию на Windows/macOS/Linux.

Мини‑методология развертывания (шаги)

Подготовка сервера: обновления, бэкап, firewall.
Настройка директорий WebDAV и прав доступа.
Установка модулей Apache: mod_dav, mod_dav_fs, mod_ssl и модуль для RADIUS/PAM.
Настройка WiKID: добавить сетевой клиент, задать shared secret.
Настройка PAM или mod_auth_radius и конфигурация виртуального хоста HTTPS.
Тестирование на стенде: монтирование, аутентификация, отказ при неверном OTP.
Мониторинг и переход в прод.

Диаграмма принятия решения

flowchart TD
  A[Нужно ли защищать WebDAV?] -->|Да| B[Есть WiKID/RADIUS?]
  B -->|Да| C[Использовать PAM или mod_auth_radius]
  B -->|Нет| D[Рассмотреть VPN или SAML/TLS]
  C --> E[Настроить SSL и DAV]
  E --> F[Протестировать клиенты]
  F --> G[Деплой]
  D --> H[Использовать альтернативный метод]

Критерии приёмки

Доступ по HTTPS к WebDAV работает на тестовом клиенте.
Аутентификация через WiKID RADIUS проходит успешно для пары логин+OTP.
Отказ при вводе неверного OTP или при отсутствии токена.
Логи аутентификации записываются и доступны для аудита.

Советы по отладке

Проверьте соединение до RADIUS‑сервера (udp/1812 по умолчанию).
Включите подробные логи PAM/RADIUS и Apache временно для диагностики.
Убедитесь, что часовые пояса и синхронизация времени корректны (OTP может зависеть от времени).

Резюме

Защита WebDAV наиболее надёжна при комбинировании HTTPS и двухфакторной аутентификации через RADIUS (например, WiKID). Подход даёт сильную защиту от кражи статических паролей и подходит для совместной работы с подрядчиками без раздачи аппаратных токенов. Выбор между интеграцией через PAM, модуль RADIUS или внешний шлюз зависит от вашей инфраструктуры и политики поддержки модулей.

Важно: тестируйте каждую часть в стендовом окружении и документируйте поведение клиентов при вводе OTP.

Если нужно, могу прислать пример полной конфигурации Apache + PAM для конкретного дистрибутива (CentOS/RHEL или Debian/Ubuntu) и шаблон инструкций для пользователей по монтированию на Windows/macOS/Linux.

Защита WebDAV через SSL и двухфакторную аутентификацию