صادرات 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 می‌تواند هر کلاینت را به‌صورت یک نشانی نشان دهد و آن‌گاه قاعده صادرات نمی‌تواند میان افراد پشت آن تمایز بگذارد. دقت ظاهری قاعده سپس به افسانه‌ای تبدیل می‌شود که نمودار آن را نگه می‌دارد. اگر صادرات مهم است، نشانی‌دهی را صریح نگه دارید نه اینکه به مترجم اجازه دهید تعیین کند چه کسی به‌جای چه کسی شمرده می‌شود.
پیش از اعتماد به صادرات، حالت امنیتی را بخوانید
راهنمای NFS شرکت Red Hat میان sec=sys، که از UID و GID محلی UNIX از طریق AUTH_SYS استفاده می‌کند، و حالت‌های Kerberos تفکیک می‌کند. krb5 احراز هویت کاربر را اضافه می‌کند، krb5i حفاظت یکپارچگی را اضافه می‌کند و krb5p حفاظت حریم خصوصی را برای ترافیک اضافه می‌کند.
اعتبارنامه AUTH_SYS فیلدهایی مانند UID فراخوان و شناسه‌های گروه را دارد و RFC 5531 آشکارا هشدار می‌دهد که این حالت به‌خودی‌خود امنیتی فراهم نمی‌کند و به حفاظت بیرونی وابسته است. اجرای آن درون VPN حفاظت انتقال را فراهم می‌کند و چیزی را در ادعای درون بسته تغییر نمی‌دهد.
exportfs -v
showmount -e nfs.example.internalحالت را در آن خروجی بخوانید پیش از آنکه فهرست کلاینت‌ها را بخوانید. صادراتی که محدود به نظر می‌رسد ممکن است تنها با نشانی محدود شده باشد در حالی که هر فراخوان همچنان هر UIDی را که بخواهد اعلام می‌کند.
مدل را انتخاب کنید و سپس مجوزها را نگه دارید
مدل احراز هویت سرویس فایل مناسب کلاینت‌هایی را که واقعاً مدیریت می‌کنید انتخاب کنید. Kerberos به هویت و استقرار سرویس در پشت آن نیاز دارد، بنابراین تغییر یک گزینه سوار کردن مهاجرت نیست و تا زمانی که دامنه Kerberos و principalها و keytabها وجود نداشته باشند صرفاً شکست می‌خورد.
در هر یک از دو مدل، مجوزهای صادرات و اجازه‌دهی فایل‌سیستم را که محدود می‌کند principal احراز هویت‌شده چه می‌تواند بکند نگه دارید. احراز هویت می‌گوید چه کسی می‌پرسد؛ اجازه‌دهی تعیین می‌کند آیا پاسخ باید بله باشد. یکی کردن این دو در یک تنظیم همان راهی است که مهاجرت سرانجام بیشتر از پیکربندی قدیمی اعطا می‌کند.
قاعده نشانی را برای هدف واقعی‌اش به کار ببرید
محدود کردن سرویس به مسیر و منابع تأییدشده همچنان ارزشمند است، از جمله سیاست ورودی میزبان هنگامی که نقطه پایانی VPN و کارساز NFS یک ماشین را شریک‌اند. قواعدی که ترافیک را هدایت می‌کنند درخواست‌های معطوف به سرویسی که به‌صورت محلی روی همان میزبان اجرا می‌شود را اداره نمی‌کنند. این شکاف شمار شگفت‌آوری از صادرات‌هایی را توضیح می‌دهد که قرار بود خصوصی باشند. سیاست ورودی محلی را صریحاً بررسی کنید نه اینکه فرض کنید قواعد تونل آن را پوشش می‌دهند.
بررسی کنید که یک رابط دیگر یا دروازه با ترجمه مبدأ نتواند به‌طور غیرمنتظره قاعده را برآورده کند و آن را دلیلی برای اثبات منشأ بدانید نه ادعایی که جعل یک نشانی سوار کردن کارآمد را تضمین می‌کند.
سه مورد پذیرش اجرا کنید نه یک مورد. با کلاینت تأییدشده‌ای که به‌عنوان کاربر تأییدشده عمل می‌کند آغاز کنید، سپس از همتایی که هرگز تأیید نشده تکرار کنید، سپس چیزی را امتحان کنید که کاربر تأییدشده هنوز مجاز به انجامش نیست. پس از آن بپرسید اگر کلاینت مجاز به خطر بیفتد چه تغییر می‌کند، زیرا احراز هویت انتقال هر فرایند روی آن ماشین را قابل اعتماد نمی‌کند. گواهی دزدیده‌شده و حساب محلی کنجکاو دو مسئله متفاوت با کنترل‌های متفاوت‌اند.