Экспарт 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 дзеляць адну машыну. Правілы, што перасылаюць трафік, не кіруюць запытамі, накіраванымі на службу, якая працуе лакальна на тым жа хосце. Гэтая прага тлумачыць нечакана вялікую колькасць экспартаў, якія меркаваліся прыватнымі. Праверце лакальную палітыку ўваходу яўна, а не меркуйце, што правілы тунелю яе пакрываюць.
Праверце, што іншы інтэрфейс або шлюз з трансляцыяй крыніцы не можа нечакана задаволіць правіла, і лічыце гэта падставай устанавіць паходжанне, а не сцвярджэннем, што падробка адраса гарантуе працоўнае мантаванне.
Правядзіце тры прыёмачныя выпадкі, а не адзін. Пачніце з зацверджанага кліента ў ролі зацверджанага карыстальніка, потым паўтарыце з піра, які ніколі не быў зацверджаны, затым паспрабуйце тое, што зацверджанаму карыстальніку ўсё яшчэ не дазволена. Пасля спытайце, што зменіцца, калі аўтарызаваны кліент будзе скампраметаваны, бо аўтэнтыфікацыя транспарту не робіць кожны працэс на гэтай машыне надзейным. Украдзены сертыфікат і цікаўны лакальны ўліковы запіс — розныя праблемы з рознымі кантролямі.