OpenConnect csd-wrapper: پیش از ورود، اسکریپت را بررسی کنید

افزودن --csd-wrapper به یک نمایه، اسکریپت محلی را به دیمونی می‌سپارد که آن را هنگام ورود اجرا می‌کند، پس تصمیم پیش روی شما بازبینی کد است، نه یک کلید ترجیح. این گزینه وجود دارد تا مؤلفهٔ بررسی میزبان در دروازه قابل جایگزینی باشد، و مسیری به اسکریپتی می‌گیرد که خودتان فراهم می‌کنید. همهٔ موارد زیر فرض می‌کنند که مالک استقرار پیش‌تر گفته است کدام بررسی وضعیت لازم است؛ اگر آن بخش هنوز باز است، نخست آن را روشن کنید. راهنما چهار گام دارد: مرحلهٔ ناموفق را پیدا کنید، اسکریپت را بخوانید، هویتی را که با آن اجرا می‌شود انتخاب کنید و نتیجه را اثبات کنید.

گام 1: مرحلهٔ ناموفق را پیدا کنید

پیام نهایی کلاینت معمولاً دربارهٔ یک کوکی است، که پایان یک زنجیره است نه آغاز آن. ورود HTTPS، بررسی گواهی سرور، تبادل احراز هویت و یک مؤلفهٔ وضعیت همه پیش از آن پیام قرار دارند.

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

openconnect --version
openconnect --verbose --user="$VPN_USER" vpn.example.com </dev/null

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

گام 2: اسکریپت را پیش از ورود به نمایه بخوانید

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

sha256sum ./vpn-csd-wrapper.sh
bash -n ./vpn-csd-wrapper.sh

کل فایل را با چهار پرسش در ذهن بخوانید: آیا فراخوانی‌های HTTP خروجی انجام می‌دهد، آیا فایل‌های اعتبارنامه یا متغیرهای محیطی را می‌خواند، آیا بیرون از پوشهٔ موقت می‌نویسد، و آیا شاخه‌ای وضعیت قبولی را بدون اندازه‌گیری چیزی گزارش می‌کند. آن الگوی آخر یک دور زدن سیاست است که یک خط گزارش به آن چسبیده. پوشش‌های کپی‌شده معمولاً آن را پشت بررسی‌ای که باورپذیر به نظر می‌رسد قاچاق می‌کنند. اگر اسکریپت پیش از نگاه کردن به دستگاه تصمیم بگیرد که دستگاه خوب است، همان‌جا متوقف شوید.

بارهای بسته‌بندی‌شده را هم بررسی کنید، زیرا یک سرآیند خوانا هیچ چیزی دربارهٔ بقیهٔ فایل اثبات نمی‌کند. دانلود یک اسکریپت از یک انجمن، آن را تنها به این دلیل که نامش مؤلفهٔ واقعی بررسی میزبان را بازتاب می‌دهد قابل اعتماد نمی‌کند. ثبت کنید چه کسی آن را نصب کرد، از کجا آمد و چگونه به‌روزرسانی خواهد شد.

grep -nE 'base64 -d|xxd -r|eval |curl |wget ' ./vpn-csd-wrapper.sh

گام 3: هویتی را انتخاب کنید که پوشش با آن اجرا می‌شود

--csd-user هنگام اجرای برنامهٔ CSD، TNCC یا HIP امتیازها را کاهش می‌دهد. آن حساب بخشی از ترتیب اجرای محلی است، نه نام کاربری‌ای که به دروازه ارائه می‌شود.

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

sudo -u vpn-csd /usr/local/libexec/vpn-csd-wrapper.sh

کاهش امتیازها آسیب‌هایی را که یک اسکریپت بد می‌تواند وارد کند محدود می‌کند. اما کد را بازبینی نمی‌کند، گزارش را صادق نمی‌کند و ثابت نمی‌کند که سرپرست دروازه این پیاده‌سازی را به‌عنوان برآورده کردن سیاست دستگاه می‌پذیرد.

گام 4: تغییر را برگشت‌پذیر نگه دارید

پیش از ویرایش، از نمایه نسخهٔ پشتیبان بگیرید و پوشش را در کنترل نسخه نگه دارید تا بازگردانی یک هش شناخته‌شده را بازیابی کند نه جست‌وجوی یک کپی. مسیر اسکریپت، هش، کاربر اجرا و تأییدکننده را در یک جا بنویسید.

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

پس از استقرار موفق، دو چیز را بررسی کنید نه یکی: تونل بالا می‌آید، و دستگاهی که باید در بررسی وضعیت رد شود همچنان رد می‌شود. اتصالی که برای همه کار می‌کند شاهد آن نیست که ارزیابی از تغییر شما جان سالم به در برده است.

میان‌برهایی که مشکل دومی می‌سازند

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

غیرفعال کردن بررسی سرور، پخش دوبارهٔ یک کوکی کهنه و انبار کردن اسکریپت‌های بازبینی‌نشده همه یک شکست دیدنی را با یک شکست نادیدنی معاوضه می‌کنند. اگر کلاینت نصب‌شده نمی‌تواند جریان پشتیبانی‌شده را کامل کند، به‌جای خم کردن جریانی که دارید یک جایگزین تأییدشده بخواهید.

راهنمای OpenConnect هر یک از --csd-wrapper و --csd-user را جداگانه مستند می‌کند، و این همان سرنخی است که مهم است: اسکریپت و هویت دو تصمیم‌اند. آنها را جداگانه بازبینی کنید و هر دو را بنویسید. آنگاه اعلان ورود دیگر معمایی نیست که با چسباندن کد حلش کنید.