SSD Nodes Learn Hosting plans →
راهنماها Matt Connorتوسط Matt Connor

آیا unattended-upgrades در Ubuntu 24.04 فعال است؟

در Ubuntu 24.04 بسته unattended-upgrades نصب است اما تنظیمات 20auto-upgrades وضعیت فعال‌سازی را تعیین می‌کند. در این مطلب نحوه بررسی وضعیت و اجرای dry-run را می‌آموزید.

چرا راه‌اندازی به‌روزرسانی‌های امنیتی خودکار ارزشمند است

سروری که وصله (patch) نشده باشد، ساده‌ترین هدف در اینترنت است. اکثر نفوذها به سرورهای کوچک هوشمندانه نیستند؛ بلکه ناشی از یک باگ شناخته‌شده در بسته‌ای قدیمی هستند که مالک سرور هرگز آن را به‌روزرسانی نکرده است. اوبونتو ابزاری دارد که این شکاف را به‌طور خودکار می‌بندد: unattended-upgrades به‌روزرسانی‌های امنیتی را طبق یک زمان‌بندی و بدون نیاز به ورود شما به سیستم، به‌طور خودکار نصب می‌کند. این ارزان‌ترین دستاورد امنیتی ممکن در یک VPS است و در اوبونتو تنها چند دقیقه زمان برای راه‌اندازی نیاز دارد.

این ابزار به‌صورت پیش‌فرض محافظه‌کارانه عمل می‌کند. به‌طور پیش‌فرض، فقط به‌روزرسانی‌های امنیتی اعمال می‌شوند، نه هر ارتقای بسته‌ای؛ زیرا یک وصله امنیتی ریسک کمی دارد و بدون بررسی ارزش نصب دارد، در حالی که ارتقای قابلیت‌ها ممکن است رفتاری را که به آن وابسته بودید تغییر دهد. این تنظیم پیش‌فرض برای اکثر سرورها مناسب است و این راهنما ضمن حفظ آن، تنظیمات معدودی را که ارزش تغییر دارند به شما نشان می‌دهد.

گام 1: نصب و فعال‌سازی

در Ubuntu Server 24.04، این بسته به‌صورت پیش‌فرض نصب و فعال است. مستندات سرور Ubuntu بیان می‌کند که unattended-upgrades به‌طور پیش‌فرض نصب شده و نصب خودکار به‌روزرسانی‌های امنیتی بلافاصله پس از نصب فعال می‌شود. پاسخ پیش‌فرض به پرسش فعال‌سازی در حین نصب، مثبت (yes) است؛ بنابراین مگر اینکه شخصی صراحتاً پاسخ منفی داده باشد، وظیفه (job) روزانه از قبل فعال است. با این حال، ممکن است imageهای سفارشی یا سبک ارائه‌دهنده متفاوت باشند، پس به‌جای فرض کردن، آن را تأیید کنید. این دستورات در هر صورت ایمن هستند: آن‌ها بسته را در صورت نبودن نصب کرده و تنها پرسشی که آن را فعال می‌کند، دوباره می‌پرسند:

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

اعلان dpkg-reconfigure یک پرسش بله/خیر ساده می‌پرسد که آیا به‌روزرسانی‌های پایدار به‌طور خودکار دانلود و نصب شوند یا خیر. پاسخ مثبت (yes) بدهید. این کار فایلی را می‌نویسد که وظیفه روزانه را فعال می‌کند:

cat /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

خط اول لیست بسته‌ها را به‌صورت روزانه به‌روزرسانی می‌کند؛ خط دوم، ارتقای خودکار (unattended upgrade) را به‌صورت روزانه اجرا می‌کند. تنظیم هر دو روی 1 به این معناست که سیستم هر روز از طریق یک systemd timer، به‌روزرسانی‌های امنیتی را بررسی و اعمال می‌کند، بدون اینکه نیاز به اقدام دیگری از سوی شما باشد.

گام 2: تصمیم‌گیری درباره آنچه به‌طور خودکار اعمال می‌شود

سیاست (policy) در /etc/apt/apt.conf.d/50unattended-upgrades قرار دارد. آن را باز کنید و به بلوک Allowed-Origins در نزدیکی ابتدای فایل نگاه کنید:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

خطوط -security همان مواردی هستند که اهمیت دارند و به‌صورت پیش‌فرض فعال هستند. این یک سیاست محافظه‌کارانه است: به‌روزرسانی‌های امنیتی اعمال می‌شوند، اما به‌روزرسانی‌های عادیِ ویژگی‌ها برای زمانی که خودتان انتخاب کنید، باقی می‌مانند. شما می‌توانید علامت کامنت را از ابتدای خط "${distro_id}:${distro_codename}-updates" در همان بلوک بردارید تا به‌روزرسانی‌های پایدار و عادی Ubuntu نیز به‌طور خودکار اعمال شوند. این کار سیاست را فقط به آرشیو -updates در Ubuntu گسترش می‌دهد، نه به تمام مخازن یا PPAهای موجود در سیستم. بررسی‌های معمول همچنان اعمال می‌شوند: این ابزار هر بسته‌ای را که باعث ایجاد اعلان برای فایل پیکربندی شود متوقف می‌کند و هیچ بسته‌ای را که وابستگی‌هایش از منبع مجاز تأمین نشود، نصب نخواهد کرد. برای سروری که میزبان سرویس‌های حساس شماست، اعمال خودکار فقط وصله‌های امنیتی، پیش‌فرض امن‌تری است. مگر اینکه دلیل خاصی برای تغییر آن داشته باشید، آن را به همان شکلی که ارائه شده است، رها کنید.

گام 3: مدیریت راه‌اندازی مجدد (Reboot)

برخی به‌روزرسانی‌ها، مانند هسته (kernel) یا کتابخانه‌های اصلی، تنها پس از راه‌اندازی مجدد سیستم به‌طور کامل اعمال می‌شوند. unattended-upgrades تا زمانی که به آن دستور ندهید، سرور شما را ری‌بوت نمی‌کند؛ این یعنی یک هسته وصله‌شده ممکن است تا زمانی که خودتان سرور را ری‌بوت کنید، بدون استفاده باقی بماند. تصمیم بگیرید که چگونه می‌خواهید این مورد را مدیریت کنید و آن را به‌صراحت در 50unattended-upgrades تنظیم کنید:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

این دستور سرور را در ساعت چهار صبح، تنها در صورتی که به‌روزرسانی نیاز به ری‌بوت داشته باشد، راه‌اندازی مجدد می‌کند. در یک VPS تکی که کلاستری برای failover ندارد، یک ری‌بوت کوتاه در اوایل صبح معمولاً بهترین معامله برای به‌روز ماندن وصله‌های هسته است. اگر سرور شما سرویسی را اجرا می‌کند که نباید به‌طور غیرمنتظره ری‌بوت شود، ری‌بوت خودکار را غیرفعال بگذارید و عادت کنید پس از بررسی /var/run/reboot-required، خودتان سرور را ری‌بوت کنید.

گام 4: اثبات عملکرد

یک روز صبر نکنید تا ببینید آیا این وظیفه اجرا می‌شود یا خیر. یک اجرای آزمایشی (dry run) را فعال کنید که دقیقاً نشان می‌دهد چه چیزی اعمال خواهد شد، بدون اینکه تغییری ایجاد شود:

sudo unattended-upgrade --dry-run --debug

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

cat /var/log/unattended-upgrades/unattended-upgrades.log

این لاگ پاسخ این پرسش است که «آیا سرور من واقعاً خودش را وصله می‌کند؟». اگر نشان می‌دهد که بسته‌های امنیتی طبق زمان‌بندی نصب می‌شوند، یعنی وظیفه به‌درستی کار می‌کند.

این ابزار در کجا قرار می‌گیرد

به‌روزرسانی‌های خودکار یک لایه از امنیت سرور هستند، نه تمام آن. آن‌ها از باقی ماندن باگ‌های شناخته‌شده جلوگیری می‌کنند، اما هیچ کاری در مورد اینکه چه کسی می‌تواند وارد شود یا چه چیزی در معرض دید است، انجام نمی‌دهند. آن‌ها را با سخت‌سازی SSH (فقط با کلید) ترکیب کنید تا درب ورودی در برابر حملات brute-force مقاوم شود، از یک فایروال UFW با سیاست پیش‌فرض deny استفاده کنید تا فقط موارد انتخابی شما در دسترس باشند، و از کاربران سرویس بدون دسترسی ریشه استفاده کنید تا یک برنامه نفوذپذیر نتواند کل سیستم را در اختیار بگیرد. برنامه‌هایی که میزبانی می‌کنید، علاوه بر این‌ها، اسرار خاص خود را دارند؛ بنابراین اگر این سرور یک Vaultwarden شخصی‌سازی‌شده را اجرا می‌کند، یک مرحله سخت‌سازی Vaultwarden توکن مدیریت و فایل پشتیبان را پوشش می‌دهد که هیچ مقدار وصله apt نمی‌تواند از آن‌ها محافظت کند. وصله‌کردن، حفره‌هایی را که می‌شناسید می‌بندد؛ لایه‌های دیگر، خسارت ناشی از حفره‌هایی را که نمی‌شناسید محدود می‌کنند.

FAQ

آیا unattended-upgrades همه به‌روزرسانی‌ها را اعمال می‌کند یا فقط موارد امنیتی را؟

به‌طور پیش‌فرض، فقط به‌روزرسانی‌های امنیتی. بلوک Allowed-Origins در /etc/apt/apt.conf.d/50unattended-upgrades مبدأهای -security را فعال می‌کند و ارتقاهای عادی قابلیت‌ها را برای اعمال دستی توسط شما باقی می‌گذارد. این یک تصمیم عمدی است: وصله‌های امنیتی ریسک کمی دارند و ارزش اعمال خودکار را دارند، در حالی که ارتقای قابلیت‌ها ممکن است رفتار سیستم را تغییر دهد، بنابراین اکثر سرورها باید تنظیمات پیش‌فرض محافظه‌کارانه را حفظ کنند.

آیا به‌روزرسانی‌های خودکار سرور من را ری‌بوت می‌کنند؟

فقط اگر به آن‌ها دستور دهید. Unattended-Upgrade::Automatic-Reboot "true" و یک Automatic-Reboot-Time را در فایل پیکربندی تنظیم کنید تا سرور در آن زمان، در صورتی که به‌روزرسانی نیاز به ری‌بوت داشته باشد (مثلاً پس از وصله هسته)، ری‌بوت شود. اگر غیرفعال باشد، هسته وصله‌شده تا زمانی که خودتان ری‌بوت کنید منتظر می‌ماند؛ برای اطلاع از زمان نیاز به ری‌بوت، /var/run/reboot-required را بررسی کنید.

چگونه بررسی کنم که به‌روزرسانی‌های خودکار واقعاً در حال اجرا هستند؟

دستور sudo unattended-upgrade --dry-run --debug را اجرا کنید تا ببینید در حال حاضر چه چیزی اعمال می‌شود (بدون تغییر در سیستم)، و /var/log/unattended-upgrades/unattended-upgrades.log را برای مشاهده سوابق اجراهای گذشته بخوانید؛ هر نصب خودکار در /var/log/apt/history.log نیز ثبت می‌شود. اگر لاگ نشان می‌دهد که بسته‌های امنیتی طبق زمان‌بندی روزانه نصب شده‌اند، تایمر به‌درستی کار می‌کند. اگر اجرای آزمایشی عبارت No packages found that can be upgraded unattended را چاپ کرد، یا همه چیز به‌روز است یا مبدأهای مجاز شما برای تطبیق با مخزن امنیتی بیش از حد محدود هستند.

آیا unattended-upgrades برای امن نگه داشتن سرور کافی است؟

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