چگونه بررسی کنیم کلید اضطراری روی یک میزبان آلوده چه چیزهایی را پوشش می‌دهد

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

کلید اضطراری را روشن کنید، سرور تونل را از شبکه خارج کنید و ببینید ماشین هنوز چه کار می‌کند. این آزمون ارزش اجرا دارد، چون آنچه فایروال واقعاً اعمال می‌کند را از آنچه تصور می‌کردید جدا می‌کند، و نتایج از آنچه بیشتر صفحه‌های محصول القا می‌کنند باریک‌تر است. کلید اضطراری مسیرهای شبکه را کنترل می‌کند؛ نرم‌افزاری را که از قبل روی دستگاه اجرا می‌شود کنترل نمی‌کند. من این توالی را روی هر ماشینی که کلاینتش ادعا می‌کند fail-closed است اجرا می‌کنم و حدود ده دقیقه طول می‌کشد.

از کلاینت شروع کنید، نه از سرور

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

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

گام یک: بلوک را روی مسیرهایی که فکر می‌کنید پوشش می‌دهد تأیید کنید

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

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

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

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

گام دو: DNS و IPv6 را به‌عنوان مسیرهای جداگانه بررسی کنید

تفکیک نام همان شکافی است که از بیشتر پیاده‌سازی‌ها جان سالم می‌برد، چون پرس‌وجو می‌تواند از چیزی جز resolver سیستم بیرون برود. با ابزاری بپرسید که پیکربندی resolver شما را نادیده می‌گیرد و همان‌جا سمت v6 را هم بررسی کنید:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

پاسخ‌های خالی برای هر دو پرس‌وجوی نام با تونل قطع، همان نتیجه‌ای است که می‌خواهید. اگر پرس‌وجوی دوم پاسخ دهد، یک نشانی resolver سخت‌کدشده در دسترس است و تونل تنها راه خروج از ماشین نیست. اگر فقط درخواست v6 موفق شود، سیاست IPv4 را پوشش می‌دهد و IPv6 را نادیده می‌گیرد، که همان نشت در خانواده‌ای دیگر از نشانی‌هاست.

مرورگرها خواندن این را از بیرون سخت‌تر می‌کنند، چون مرورگری که برای DNS روی HTTPS تنظیم شده پرس‌وجو را با یک درخواست HTTPS حل می‌کند: پرس‌وجو تنها تا اندازه‌ای که درگاه 443 به آن نقطه بسته باشد بسته است. روی میزبانی که سیاستش زیرشبکهٔ محلی را مجاز می‌کند، آن درخواست هنوز می‌تواند به resolver در LAN برسد.

گام سه: مواجههٔ شبکه را از مواجههٔ نقطهٔ پایانی جدا کنید

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

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

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

گام چهار: ادعایی را بنویسید که آزمونتان پشتیبانی می‌کند

پس از آزمون قطع می‌توانید واقعیت‌های مشخصی بگویید: کدام برنامه‌ها شکست خوردند، کدام مسیرها ایستادند، DNS و IPv6 چگونه رفتار کردند و آیا بلوک وقتی تونل افتاد دوام آورد. نمی‌توانید بگویید سیستم‌عامل پاک است و نمی‌توانید بگویید سرویسی در انتهای دور ورود شما را خصوصی نگه می‌دارد.

دو مسئله را جدا نگه دارید و به هرکدام کنترل خودش را بدهید:

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

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

مقالات مرتبط