Кратко

  • Незащищённый DNS SRV может выбрать хост с настоящими собственными учётными данными. RFC 5178 требует аутентифицировать тройку «служба — обслуживаемый домен — конкретный хост», чтобы собственная идентичность машины не подменяла её полномочие.
  • RFC 6641 применяет эту тройку к корню пространства NFSv4. Ответ SRV, успешный GSS-контекст и правильное дерево файлов остаются отдельными квитанциями.

Клиент получил SRV-ответ, установил защищённый контекст и смонтировал файловую систему. В сводном индикаторе это выглядит как одна удачная операция. В действительности здесь последовательно действовали разные владельцы решений.

DNS сообщил, куда попробовать подключиться. Система учётных данных подтвердила, что выбранный сервер уполномочен представлять файловую службу домена. NFS разрешил конкретные операции. Только наблюдаемое дерево файлов показало, какой результат получил пользователь.

RFC 5178 нужен потому, что первый шаг может быть ложным, даже когда второй честно аутентифицирует неправильную машину.

Настоящая идентичность неправильного сервера

При подмене незащищённого SRV злоумышленнику не обязательно красть имя ожидаемого сервера. Он может направить клиента на собственный хост, у которого есть действительная учётная запись для собственного имени. Если клиент строит host-based имя из ответа DNS, GSS подтверждает именно тот хост, который был вписан в ложный ответ.

Не доказано другое: разрешил ли целевой домен этому хосту предоставлять искомую службу.

RFC 5178 вводит GSS_C_NT_DOMAINBASED_SERVICE с формой service [AT] domain [AT] hostname, где [AT] означает буквальный ASCII-символ at в синтаксисе RFC. Service обозначает функцию, domain — обслуживаемую организационную или ресурсную область, hostname — конкретный acceptor. IANA закрепила тип под номером 5.

Учётные данные для всей тройки воплощают разрешение. Их выдача — не нейтральная регистрация строки. Она позволяет хосту аутентифицироваться как поставщику данной службы для данного домена. Поэтому журнал выдачи и отзыва относится к плоскости управления службой.

RFC 6641 показывает композицию

RFC 6641 описывает глобальное пространство NFSv4, в котором клиент находит корневые серверы организации по DNS SRV. При наличии DNSSEC его следует использовать. Доменный service principal остаётся дополнительным механизмом: выбранный сервер должен подтвердить имя вроде nfs [AT] example.net [AT] nfs2.example.net.

Это не делает SRV защищённым задним числом. Оно не позволяет произвольному хосту из изменённого ответа пройти под обычной host-идентичностью. Администратор домена может выдать доменные credentials только разрешённым корневым серверам.

После этого NFS всё ещё согласовывает безопасность, применяет разрешения, следует referral и возвращает данные. Успешная аутентификация principal не доказывает, что корень содержит ожидаемое дерево, что права пользователя верны или что операция чтения завершилась.

Для расследования нужны четыре записи: запрос и ответ discovery; сконструированное типизированное имя и канонический principal; решение приложения; наблюдаемый mount и содержимое. Одна зелёная строка «NFS доступен» стирает место ошибки.

Два множества меняются независимо

Список SRV и набор активных доменных credentials обычно должны совпадать по хостам, но это не одна истина. При вводе нового узла DNS может быть опубликован раньше credential. Хост виден, но не готов доказать полномочие. При выводе запись SRV может исчезнуть раньше отзыва. Хост не находится обычным путём, но всё ещё способен аутентифицироваться при обращении через кэш, статическую конфигурацию или подменённый ответ.

Полезная проверка вычисляет разность множеств. Узел только в discovery — незавершённый ввод или устаревшая публикация. Узел только в credentials — остаточное полномочие. Совпадение подтверждает согласованность реестров, но не работоспособность NFS.

Если объединить всё в поле «активен», переходы исчезнут. Вместе с ними исчезнет и возможность понять, почему правильная криптография обслужила неправильный состав кластера.

Fallback меняет область утверждения

Не все GSS-механизмы и acceptor поддерживают доменный тип. В существующем LDAP или NFS могут быть только host-based credentials. Одностороннее включение нового имени ломает совместимость.

RFC 5178 допускает возврат к имени хоста, но требует отдельно проверить, что этот host уполномочен предоставлять службу для желаемого domain. Клиент без поддержки доменного типа несёт ту же обязанность.

Повторное подключение не является такой проверкой. Нужен независимый список или policy, связывающий host с service-domain. Если связь снова берётся из незащищённого SRV, discovery назначает само себя авторитетом.

Оператор должен различать успешное доменное имя, fallback с эквивалентной авторизацией, fallback без эквивалентной области и обычную несовместимость. Автоматическая библиотека не должна молча решать, что доступность важнее исходного вопроса.

Представление имени не равно его сравнению

RFC 5178 определяет импорт и отображение интернационализированных доменов. Обычный импорт принимает ACE. Рекомендованный UTF-8 импорт принимает UTF-8 и ACE. Обычный display выводит ASCII или ACE; UTF-8 display выдаёт UTF-8 и не должен выдавать ACE.

GSS-API при этом различает внутреннее имя, display-строку, mechanism name и exported name. RFC 2743 не обещает, что импортированная и затем отображённая строка совпадёт с исходной или сохранит идентификатор типа. Для авторизации предназначены GSS_Compare_name(), канонизация и механизм-специфичные формы, а не буквальное сравнение журналов.

RFC 5178 опирался на RFC 3490. Позже IDNA2008 ввёл различия A-label/U-label и иную рамку обработки. Современная реализация должна фиксировать выбранный профиль, но не приписывать поздние нормы старому документу. Аудиту нужны Unicode, ACE, тип ввода и конечный principal одновременно.

Kerberos не позволяет domain выбрать проверяющий realm

RFC 5179 отображает service в первый компонент Kerberos principal, hostname — во второй, domain — в третий. Рекомендуется NT-SRV-HST-DOMAIN со значением 12.

Realm остаётся отдельной частью. Из соображений безопасности его следует выводить из hostname, а не из domain-поля входной строки. Область, чьё полномочие заявлено, не должна одной строкой назначать собственный центр проверки.

Эксплуатационная квитанция поэтому включает входную тройку, полученный principal, realm, KDC и credential. Способность парсера принять синтаксис не подтверждает ожидаемое отображение.

Успешный контекст — сильный, но ограниченный факт

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

Минимальная общая структура RFC 5178 полезна тем, что не создаёт единого верховного реестра. Discovery выбирает путь. Локальный издатель credentials делегирует полномочие. Механизм проверяет. NFS принимает решение и выдаёт результат. Каждый участник может проверить свой слой и отвечать за него.

Когда эти слои сохранены, инцидент можно разложить: неверный SRV, неправильная выдача, неожиданное realm-mapping, отказ приложения или неверное содержимое. Когда сохранено только «mount success», все причины превращаются в одну неясную историю.

Источники