Экспорт NFS, привязанный к адресу VPN: что это не доказывает
Правило экспорта проверяет, откуда пришёл пакет; AUTH_SYS заявляет локальный UID, а Kerberos аутентифицирует пользователя. Решите, что нужно вашей файловой службе.
Хост экспортирует каталог на адрес VPN, монтирование проходит, и в проекте записывается, что доступ аутентифицирован. На самом деле это правило ограничивает лишь то, откуда выглядят приходящими пакеты. А то, действительно ли человек, выполняющий файловую операцию, тот, за кого он себя выдаёт, зависит от режима безопасности NFS, и в большинстве таких экспортов никто не менял его относительно значения по умолчанию.
В одном запросе могут появиться три личности
Пир VPN несёт зарегистрированную личность, например клиентский сертификат или ключ пира. Внутренний IP-пакет несёт адрес источника. Файловая операция несёт те учётные данные пользователя, которые предоставляет её механизм NFS. Проект, который рассматривает адрес как замену всех трёх, молча предположил именно ту часть, которую следовало проверить.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
Записать эти три строки — и есть всё упражнение. Большая часть спора о том, безопасен ли экспорт, рассыпается, как только становится ясно, в какой строке живёт каждый контроль.
Владение адресом — деталь реализации
Шлюз может назначить туннельный адрес принятому пиру или разрешить для него маршрутизируемую подсеть. Отказ реализации принимать пакет, внутренний источник которого принадлежит другому клиенту, — свойство этой реализации, и его стоит проверять, а не предполагать.
Код сервера в пространстве пользователя традиционного Community OpenVPN может, например, отвергнуть источник, связанный с другим клиентом, прежде чем пакет будет доставлен через устройство TUN. Это проверка владения адресом с реальной ценностью, и она по-прежнему не является аутентификацией пользователя NFS, потому что ничего не говорит о том, какая учётная запись выполняет операцию.
Трансляция источника подрывает даже это. Шлюз NAT может представить каждого клиента одним адресом, и тогда правило экспорта не сможет различить людей за ним. Кажущаяся точность правила превращается в вымысел, который поддерживает схема. Если экспорт важен, держите адресацию явной, а не позволяйте транслятору решать, кто считается кем.
Прочитайте режим безопасности, прежде чем доверять экспорту
Руководство Red Hat по NFS отделяет sec=sys, который использует локальные UNIX UID и GID через AUTH_SYS, от режимов Kerberos. krb5 добавляет аутентификацию пользователя, krb5i добавляет защиту целостности, а krb5p добавляет защиту конфиденциальности трафика.
Учётные данные AUTH_SYS содержат поля, такие как UID вызывающего и идентификаторы групп, и RFC 5531 прямо предупреждает, что этот режим сам по себе не обеспечивает безопасности и зависит от внешней защиты. Его работа внутри VPN обеспечивает защиту транспорта и ничего не меняет в утверждении внутри пакета.
exportfs -v
showmount -e nfs.example.internalПрочитайте режим в этом выводе, прежде чем читать список клиентов. Экспорт, который выглядит ограниченным, может быть ограничен только адресом, тогда как каждый вызывающий по-прежнему заявляет любой UID.
Выберите модель, а затем сохраните права
Выберите модель аутентификации файловой службы, подходящую для клиентов, которыми вы действительно управляете. Kerberos требует личности и развёртывания службы за ней, поэтому изменение одной опции монтирования не является миграцией и просто не сработает, пока не появятся домен Kerberos, принципалы и файлы keytab.
При любой из двух моделей сохраняйте права экспорта и авторизацию файловой системы, которые ограничивают, что может делать аутентифицированный принципал. Аутентификация говорит, кто спрашивает; авторизация решает, должен ли ответ быть «да». Слияние этих двух в одну настройку — это путь, при котором миграция в итоге даёт больше, чем давала старая конфигурация.
Используйте правило адреса по его настоящему назначению
Ограничение службы одобренным путём и источниками остаётся полезным, включая политику входа хоста, когда конечная точка VPN и сервер NFS делят одну машину. Правила, пересылающие трафик, не управляют запросами, направленными на службу, работающую локально на том же хосте. Этот пробел объясняет удивительно много экспортов, которые должны были быть приватными. Проверяйте локальную политику входа явно, а не предполагайте, что правила туннеля её покрывают.
Проверьте, что другой интерфейс или шлюз с трансляцией источника не может неожиданно удовлетворить правило, и считайте это причиной установить происхождение, а не утверждением, что подделка адреса гарантирует работающее монтирование.
Выполните три приёмочных случая вместо одного. Начните с одобренного клиента, действующего как одобренный пользователь, затем повторите с пира, который никогда не был одобрен, а затем попробуйте то, что одобренному пользователю всё ещё не разрешено. После этого спросите, что изменится, если авторизованный клиент будет скомпрометирован, ведь аутентификация транспорта не делает каждый процесс на этой машине доверенным. Украденный сертификат и любопытная локальная учётная запись — разные проблемы с разными контролями.