این یافته آسیب‌پذیری کدام فرایند VPN را هدف می‌گیرد؟

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

ترتیب مهم است: اول مؤلفه، دوم هشدار، سوم رفع.

گزارش درگاه را نام می‌برد، نه برنامه را

از نقطه پایانی که واقعاً ارزیابی شده شروع کنید. یک کاوش علیه درگاه مدیریت HTTPS سرویس وب، پشته TLS آن و هر پراکسی که جلوی آن باشد را اندازه گرفت؛ درباره شنونده OpenVPN یا WireGuard روی درگاهی دیگر چیزی نیاموخت. پراکسی‌های معکوس و عامل‌های مدیریت این را بدتر می‌کنند، چون گواهی و بنر می‌توانند به بخش جلویی تعلق داشته باشند در حالی که کتابخانه آسیب‌پذیر پشت آن در یک فرایند پشتی نشسته است.

مقصد، انتقال، درگاه و نام سرویس را همراه با نتیجه ثبت کنید تا دامنه همراه یافته سفر کند.

ساخت در حال اجرا واقعاً چیست

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

systemctl status openvpn-server@server --no-pager
ps -o pid,lstart,args -C openvpn
ss -lntup | grep -E '1194|443'
dpkg -l | grep -i -E 'openvpn|libssl'
ldd "$(command -v openvpn)" | grep -i ssl

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

تطبیق ساخت با دامنه یک هشدار

هشدارها محصولات، نسخه‌ها و گاهی شرایط لازم را توصیف می‌کنند، و این سه میدان همیشه با نسخه یک بسته هم‌راستا نیستند. هشدار Heartbleed اوپن‌وی‌پی‌ان از آوریل 2014 نمونه تاریخی سودمندی است، چون نسخه‌های آسیب‌دیده Access Server را از سرویس‌های وب و دیمن‌های VPN جدا می‌کند که میزان مواجهه متفاوتی داشتند. درس این است که بخوانید متن کدام مؤلفه را پوشش می‌دهد، نه اینکه واژه OpenSSL را الگووار تطبیق دهید.

آن هشدار هم تاریخ‌گذشته است. شماره‌های نسخه وصله‌شده‌اش اکنون توصیه نصب نیستند، و نقصی که در 2014 وصله شد چیزی درباره مسائل بعدی در شاخه‌ای که امروز اجرا می‌کنید نمی‌گوید.

رفع اختلاف، سپس بستن مواجهه

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

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

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