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 сървърът споделят една машина. Правилата, които препращат трафик, не управляват заявки, насочени към услуга, работеща локално на същия хост. Тази празнина обяснява изненадващ брой експорти, които е трябвало да бъдат частни. Проверете локалната политика за вход изрично, вместо да предполагате, че правилата на тунела я покриват.
Проверете дали друг интерфейс или шлюз с транслация на източника не може неочаквано да удовлетвори правилото, и приемете това като причина да установите произход, а не като твърдение, че подправянето на адрес гарантира работещо монтиране.
Изпълнете три приемателни случая, а не един. Започнете с одобрен клиент, действащ като одобрен потребител, после повторете от партньор, който никога не е бил одобрен, сетне опитайте нещо, което одобреният потребител все още няма право да прави. Попитайте след това какво се променя, ако оторизиран клиент бъде компрометиран, защото удостоверяването на транспорта не прави всеки процес на тази машина надежден. Откраднат сертификат и любопитен локален акаунт са различни проблеми с различни защити.