Експорт 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 ділять одну машину. Правила, що пересилають трафік, не керують запитами, скерованими до служби, що працює локально на тому ж хості. Ця прогалина пояснює напрочуд багато експортів, які мали бути приватними. Перевіряйте локальну політику входу явно, а не припускайте, що правила тунелю її покривають.
Перевірте, що інший інтерфейс або шлюз із трансляцією джерела не може несподівано задовольнити правило, і вважайте це причиною встановити походження, а не твердженням, що підробка адреси гарантує робоче монтування.
Виконайте три приймальні випадки замість одного. Почніть зі схваленого клієнта, що діє як схвалений користувач, потім повторіть із піра, якого ніколи не схвалювали, а потім спробуйте те, що схваленому користувачеві все ще не дозволено. Після цього запитайте, що зміниться, якщо авторизованого клієнта буде скомпрометовано, адже автентифікація транспорту не робить кожен процес на цій машині довіреним. Викрадений сертифікат і цікавий локальний обліковий запис — різні проблеми з різними контролями.