بررسی اصلاح امنیتی OpenSSL؛ کتابخانهٔ واقعی سرویس را پیدا کنید

انتشار جدید، دستور مهاجرت فوری نیست

خط زمانی رسمی OpenSSL اطلاعیهٔ امنیتی ۲۹ سپتامبر ۲۰۲۶ و انتشار نسخهٔ 4.1.0 در ۲۳ اکتبر را ثبت کرده است. این تاریخ‌ها دلیل خوبی برای بازبینی اجزای TLS هستند، اما به معنی جایگزینی فوری کتابخانهٔ توزیع با نسخهٔ اصلی دست‌ساز نیستند. اطلاعیه باید با بسته، قابلیت فعال و مسیر پشتیبانی واقعی سرور تطبیق داده شود.

پیش از تغییر، وضعیت را ثبت کنید

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

openssl version -a
# Debian / Ubuntu
dpkg-query -W openssl libssl3
# RHEL family
rpm -q openssl openssl-libs

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

مدرک سازنده را بخوانید

ردهات توضیح می‌دهد که اصلاح امنیتی می‌تواند به بستهٔ پشتیبانی‌شده بک‌پورت شود. بنابراین عدد قدیمی‌تر نسخهٔ بالادستی همیشه به معنی اصلاح‌نشده بودن نیست. اطلاعیهٔ مرتبط و شمارهٔ کامل بستهٔ نصب‌شده را با راهنمای فعلی سازنده تطبیق دهید. در جهت مقابل، نسخهٔ جدید خط فرمان، اصلاح یک Runtime جداگانه را ثابت نمی‌کند. راهنمای رسمی RHEL 9 روش بررسی اطلاعیه‌ها با DNF را توضیح داده است.

بسته را به سرویس واقعی وصل کنید

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

تغییر کنترل‌شده و آزمون نتیجه

1. دسترسی کنسول، پشتیبان قابل بازیابی و منبع معتبر بسته را تأیید کنید.
2. اصلاح سازنده را روی محیط آزمایشی یا نمونهٔ مشابه بررسی کنید.
3. راه‌اندازی مجدد سرویس مرتبط را برنامه‌ریزی کنید؛ اگر زیرساخت اجازه می‌دهد، نمونه‌ها را تدریجی جایگزین کنید.
4. مدرک بسته و شروع سرویس را بخوانید؛ سپس HTTPS، ورود، کار پس‌زمینه و اتصال خروجی واقعی برنامه را آزمایش کنید.
5. خروجی قبلی و معیار روشن بازگشت را نگه دارید؛ پیش از گسترش تغییر، خطای تازه را بررسی کنید.

مرز هر آزمایش را بشناسید

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