ProtectHome در برابر دانه TOTP: چرا ورود به VPN شکست می‌خورد

برنامه احراز هویت یک کد شش‌رقمی تازه نشان می‌دهد، VPN آن را رد می‌کند، و همان کد وقتی از پوسته خودتان آزمایش می‌کنید بی‌عیب تأیید می‌شود. همین شکاف تمام ماجراست. ماژول PAM که نمی‌تواند راز ثبت‌نام را باز کند، شکستی برمی‌گرداند که با کد اشتباه یکسان به نظر می‌رسد، و محیط سرویسی که پوشه‌های خانه را پنهان می‌کند دلیل رایج آن است. پیش از هرگونه آسان‌سازی مجوز، تصمیم بگیرید در کدام یک از سه وضعیت هستید.

کدام یک از این سه شکست است؟

اولی رازی است که ماژول اصلاً نمی‌تواند بخواند. دومی رازی است که می‌تواند بخواند اما نمی‌تواند به‌روز کند. سومی کدی است که واقعاً اشتباه است، معمولاً به‌دلیل انحراف ساعت یا مقدار بازپخش‌شده.

آن‌ها را با خواندن وقایع‌نگاری سرویس و گزارش احراز هویت سیستم برای یک تلاش ناموفق جدا کنید، سپس تأیید کنید افزونه کدام سرویس PAM را بارگذاری می‌کند و آن سرویس از کدام خط ماژول استفاده می‌کند. پیام عمومی شکست احراز هویت آن‌ها را از هم جدا نمی‌کند، و آزمون دستی موفق هم جدا نمی‌کند، زیرا پوسته شما محیط سرویس نیست.

نمای سیستم فایل واحد معمولاً مقصر است وقتی فقط سرویس شکست می‌خورد.

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

گزینه A: راز را از پوشه خانه بیرون ببرید

وقتی سرویس /home را پنهان می‌کند و ترجیح می‌دهید آن حفاظت را نگه دارید، راز را جایی ذخیره کنید که بتواند ببیند. ماژول مسیر secret= و حساب user= را می‌پذیرد که عملیات فایل را انجام می‌دهد، و این به یک انبار مرکزی اجازه می‌دهد به هویت‌های زیادی خدمت کند.

این گزینه مرتب است و بیشترین دقت را می‌طلبد، زیرا انبار مشترک یک پوشه را مرز امنیتی هر حساب می‌کند.

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

پیش از اعتماد سه چیز را بررسی کنید: حساب وجود دارد، فرایند کار ماژول می‌تواند به آن سوئیچ کند، و فایل‌ها با حالت‌های محدودکننده متعلق به آن هستند. از ~ یا مسیر متغیر خانه همراه با user= استفاده نکنید، و بررسی‌های مالکیت ماژول را برای کار کردن یک مسیر غیرفعال نکنید. مرحله گذرواژه و بقیه پشته را دست‌نخورده نگه دارید.

گزینه B: فایل را بگذارید و مسیری باز کنید

اگر راز باید در پوشه خانه کاربر بماند، واحد به نمایی نیاز دارد که همان یک پوشه را شامل شود بدون آشکار کردن همه پوشه‌های خانه روی میزبان. یک drop-in می‌تواند یک اتصال bind بسیار محدود زیر یک خانه سندباکس‌شده اضافه کند.

این مالکیت به‌ازای هر کاربر را به‌عنوان مدل نگه می‌دارد، به بهای تغییری در واحد که هر بار سندباکس تغییر می‌کند باید بازبینی شود.

دو محدودیت آسان فراموش می‌شوند. مسیر فقط‌خواندنی که زیر پوشه‌ای که سندباکس پنهان می‌کند افزوده شود آن را آشکار نمی‌کند، زیرا پوشه والد به‌سادگی آنجا نیست. و اتصال باید نوشتنی باشد اگر ماژول باید وضعیت را به‌روز کند، که گزینه بعدی را وارد بازی می‌کند. drop-in را به‌عنوان فایل جداگانه بنویسید نه با ویرایش واحد بسته‌بندی‌شده زیر /usr/lib، تا ارتقای بسته آن را بی‌صدا خنثی نکند.

گزینه C: سندباکس را نگه دارید و نوشتن‌های وضعیت را درست کنید

خواندن راز فقط نیمی از احراز هویت است. ماژول ممکن است اطلاعات انحراف زمانی، محافظت در برابر بازپخش یا یک شمارنده را بازنویسی کند، و فایلی که بررسی خواندن را می‌گذراند باز هم می‌تواند در نوشتن شکست بخورد.

آن شکست در تلاش بعدی مانند کد بد به نظر می‌رسد نه در این تلاش، و به همین دلیل با انحراف ساعت اشتباه گرفته می‌شود.

پوشه نوشتنی مخصوص خودش را به آن بدهید و مسیر راز را به آنجا ببرید، نه اینکه کل پوشه خانه را نوشتنی کنید. مالک پوشه، فضای آزاد سیستم فایل و اینکه واحد نوشتن‌ها را جای دیگری محدود می‌کند تأیید کنید. سپس دو ورود پیاپی را آزمایش کنید، زیرا دومی مسیر نوشتن را اثبات می‌کند و اولی فقط خواندن را.

به‌عنوان سرویس تأیید کنید، نه به‌عنوان خودتان

هر بررسی مهم باید درون سندباکس واحد و با هویت واحد اجرا شود.

فرمانی که با root موفق می‌شود فقط می‌گوید فایل وجود دارد و دیگر هیچ. ورود از طریق سرویس واقعی می‌گوید آیا ماژول می‌تواند راز را بخواند، استفاده کند و آنچه لازم دارد را بازنویسی کند.

در پایان، الزام را دست‌نخورده نگه دارید. افزودن گزینه گذرواژه تهی، پذیرش شکست‌های فقط‌خواندنی یا حذف سندباکس همه نشانه را با تغییر سیاست از میان می‌بردند. کاربری که باید کد ارائه کند همچنان باید وقتی راز در دسترس نیست رد شود.