بیشتر نفوذهای موفق به سرورهای لینوکسی از طریق آسیب‌پذیری‌هایی انجام میشود که وصلهٔ آن‌ها هفته‌ها یا ماه‌ها قبل منتشر شده بود. بهروزرسانی خودکار امنیتی با unattended-upgrades این فاصله را از هفته‌ها به کمتر از یک روز می‌رساند، بدون آن‌که مجبور باشید هر شب روی چند سرور apt upgrade بزنید. اما همین ابزار اگر بدون پیکربندی رها شود، میتواند نیمه‌شب MySQL را ریاستارت کند یا سرور را بدون اطلاع شما ریبوت کند. در این راهنما سازوکار unattended-upgrades در Ubuntu 24.04 را توضیح می‌دهیم، فایل 50unattended-upgrades را خط‌به‌خط پیکربندی می‌کنیم، ریبوت و ریاستارت سرویسها را تحت کنترل درمی‌آوریم و می‌گوییم چه زمانی نباید به آن اعتماد کرد.
چرا بهروزرسانی خودکار و چرا فقط بستههای امنیتی
پنجرهٔ آسیب‌پذیری
از لحظهٔ انتشار یک CVE تا شروع اسکن گستردهٔ اینترنت توسط ربات‌ها معمولاً کمتر از 48 ساعت می‌گذرد. مدیری که هفته‌ای یک‌بار به سرور سر می‌زند، بهطور میانگین چند روز سرور را در معرض سوءاستفاده می‌گذارد. وصلههای امنیتی Ubuntu (مخزن -security) با حداقل تغییر رفتار منتشر می‌شوند و دقیقاً برای نصب خودکار طراحی شده‌اند.
چرا همهٔ بستهها را خودکار نمی‌کنیم
مخزن -updates شامل رفع باگ و به‌روزرسانی‌های نسخه است که ممکن است رفتار PHP، Nginx یا MariaDB را تغییر دهد و پیکربندی شما را بشکند. قاعده این است: امنیتی خودکار، سایر بستهها دستی و پس از تست. اگر سایت روی هاست لینوکس اشتراکی است، این وظیفه با ارائهدهنده است؛ این مقاله برای کسانی است که سرور مجازی یا اختصاصی خود را مدیریت میکنند.
unattended-upgrades چگونه کار میکند
در Ubuntu Server بستهٔ unattended-upgrades بهطور پیشفرض نصب و فعال است؛ اما پیکربندی پیشفرض فقط حداقل کار را انجام می‌دهد: وصلههای امنیتی را نصب میکند، ریبوت نمی‌کند و به کسی خبر نمی‌دهد. سازوکار آن دو مرحله دارد که هر کدام با یک تایمر systemd اجرا میشود.
دو تایمر systemd
تایمر apt-daily.timer دو بار در روز (ساعت 6 و 18 با تأخیر تصادفی تا 12 ساعت) فهرست بستهها را به‌روز و بستههای جدید را دانلود میکند. تایمر apt-daily-upgrade.timer ساعت 6 صبح (با تأخیر تصادفی تا 60 دقیقه) اسکریپت unattended-upgrade را اجرا میکند که نصب واقعی را انجام می‌دهد. تأخیر تصادفی عمدی است تا هزاران سرور همزمان به مخازن فشار نیاورند. با systemctl list-timers apt-daily* می‌توانید زمان اجرای بعدی را ببینید.
فایل‌های پیکربندی
دو فایل همه چیز را تعیین میکنند. /etc/apt/apt.conf.d/20auto-upgrades سوئیچ روشن/خاموش است و /etc/apt/apt.conf.d/50unattended-upgrades جزئیات رفتار را مشخص میکند: کدام مخازن، کدام استثناها، ریبوت و اعلان. فایل اول معمولاً این دو خط را دارد:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";نصب و فعال‌سازی در Ubuntu 24.04
- اطمینان از نصب بسته و فعال بودن تایمرها.
- ساخت یا بررسی فایل 20auto-upgrades (دستور dpkg-reconfigure این کار را تعاملی انجام می‌دهد).
- ویرایش 50unattended-upgrades مطابق بخش بعد.
- اجرای آزمایشی با dry-run و بررسی لاگ.
apt install unattended-upgrades apt-listchanges
dpkg-reconfigure -plow unattended-upgrades
systemctl status apt-daily-upgrade.timer
unattended-upgrade --dry-run --debugتوجه کنید نام بسته unattended-upgrades (جمع) و نام دستور unattended-upgrade (مفرد) است؛ این تفاوت کوچک، منبع بسیاری از خطاهای «command not found» است. خروجی dry-run نشان می‌دهد کدام بستهها نصب می‌شدند و کدام به دلیل blacklist یا وابستگی کنار گذاشته شده‌اند.
پیکربندی 50unattended-upgrades خط‌به‌خط
Allowed-Origins: فقط مخزن امنیتی
بخش Unattended-Upgrade::Allowed-Origins تعیین میکند بستهها از کدام مخازن می‌توانند خودکار نصب شوند. در Ubuntu 24.04 سه خط فعال پیشفرض عبارت‌اند از ${distro_id}:${distro_codename}-security و دو خط مربوط به ESM که فقط با Ubuntu Pro فعال می‌شوند. خط -updates به‌صورت کامنت است و باید همان‌طور بماند، مگر آن‌که آگاهانه بخواهید همهٔ به‌روزرسانی‌ها خودکار شوند. مخازن شخص ثالث (مثلاً PPA یا مخزن رسمی Nginx) بهطور پیشفرض شامل نمی‌شوند؛ برای افزودن آن‌ها باید origin و suite دقیق را از خروجی apt-cache policy بردارید.
Package-Blacklist: استثناهای حیاتی
اینجا بسته‌هایی را فهرست می‌کنید که حتی وصلهٔ امنیتی آن‌ها هم باید دستی و با نظارت نصب شود. برای سرور وب معمولاً سرور دیتابیس (چون بهروزرسانی آن ریاستارت و چند دقیقه قطعی به همراه دارد) و گاهی کرنل در این فهرست قرار می‌گیرند. فهرست از عبارت منظم پشتیبانی میکند، پس «linux-» همهٔ بستههای کرنل را می‌پوشاند. نگه داشتن کرنل در blacklist به معنای پذیرش ریسک است؛ جایگزین بهتر، فعال کردن Livepatch در Ubuntu Pro (رایگان تا پنج ماشین) است که وصلههای کرنل را بدون ریبوت اعمال میکند.
Unattended-Upgrade::Package-Blacklist {
"mariadb-server";
"mysql-server";
"linux-";
};
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";
Unattended-Upgrade::Mail "admin@example.com";
Unattended-Upgrade::MailReport "on-change";ریبوت خودکار و فایل reboot-required
وقتی وصله‌ای به کرنل یا کتابخانه‌های پایه‌ای مانند glibc اعمال میشود، بسته فایل /var/run/reboot-required را می‌سازد. با Automatic-Reboot "true" سرور در ساعت تعیین‌شده ریبوت میشود و با Automatic-Reboot-WithUsers "false" اگر کاربری login کرده باشد، ریبوت به تعویق می‌افتد. برای سروری که چند سایت پرترافیک دارد، ریبوت ساعت 3:30 بامداد معمولاً کم‌هزینه‌ترین زمان است، اما فقط در صورتی آن را فعال کنید که همهٔ سرویسها با systemd به‌درستی بالا می‌آیند. Remove-Unused-Dependencies نیز کرنل‌های قدیمی را پاک میکند و از پر شدن /boot جلوگیری میکند.
اعلان، لاگ و تست: چگونه بفهمیم چه اتفاقی افتاده
بهروزرسانی خودکاری که هیچ‌کس نتیجهٔ آن را نمی‌بیند، نصف ارزش خود را از دست می‌دهد. برای ایمیل باید یک MTA ساده مانند postfix در حالت satellite یا msmtp نصب باشد؛ MailReport با مقدار on-change فقط وقتی چیزی نصب شده ایمیل می‌فرستد و only-on-error فقط هنگام خطا.
| فایل یا دستور | کاربرد |
|---|---|
| /var/log/unattended-upgrades/unattended-upgrades.log | تصمیم‌ها: چه بسته‌ای نصب یا رد شد و چرا |
| /var/log/unattended-upgrades/unattended-upgrades-dpkg.log | خروجی خام dpkg برای عیب‌یابی خطای نصب |
| /var/log/apt/history.log | تاریخچهٔ همهٔ عملیات apt، دستی و خودکار |
| journalctl -u apt-daily-upgrade | خطاهای اجرای خود تایمر و سرویس |
| /var/run/reboot-required.pkgs | فهرست بسته‌هایی که ریبوت می‌خواهند |
یک بررسی هفتگی لاگ اول، یا بهتر از آن ارسال این لاگ به سامانهٔ مانیتورینگ، برای اطمینان از سلامت فرایند کافی است. اگر تعداد سرورها زیاد است، سرویس مدیریت سرور میتواند پایش و واکنش به خطاهای بهروزرسانی را بر عهده بگیرد.
ریاستارت سرویسها پس از وصله: needrestart
نصب نسخهٔ جدید OpenSSL یا glibc به‌تنهایی کافی نیست؛ پروسه‌هایی که کتابخانهٔ قدیمی را در حافظه دارند (Nginx، PHP-FPM، sshd) تا ریاستارت نشوند همچنان آسیب‌پذیرند. ابزار needrestart که در Ubuntu Server 22.04 به بعد پیشفرض نصب است، پس از هر اجرای apt این پروسه‌ها را شناسایی میکند. در حالت تعاملی سؤال می‌پرسد، اما در اجرای خودکار رفتار آن را فایل /etc/needrestart/conf.d/ تعیین میکند: مقدار $nrconf{restart} = 'a' یعنی ریاستارت خودکار همهٔ سرویس‌های نیازمند و 'l' یعنی فقط فهرست کردن. ریاستارت خودکار Nginx و PHP-FPM قابل قبول است؛ اما دیتابیس را می‌توانید با $nrconf{override_rc} از این فهرست خارج کنید.
زمان‌بندی و هماهنگی در چند سرور
اگر چند سرور پشت یک Load Balancer دارید، ریبوت همزمان همهٔ آن‌ها در 3:30 بامداد دقیقاً همان قطعی‌ای است که می‌خواستید از آن جلوگیری کنید. زمان ریبوت هر سرور را متفاوت تنظیم کنید (3:30، 4:00، 4:30) و با systemctl edit apt-daily-upgrade.timer مقدار OnCalendar را نیز برای هر سرور جابه‌جا کنید؛ در فایل override ابتدا یک خط خالی OnCalendar= بگذارید تا مقدار قبلی پاک شود و سپس زمان جدید را بنویسید. در AlmaLinux و Rocky Linux بستهٔ dnf-automatic با تنظیم upgrade_type = security و apply_updates = yes همان نقش را دارد.
چه زمانی نباید به بهروزرسانی خودکار اعتماد کرد
- سرورهای cPanel یا DirectAdmin: این پنل‌ها فرایند بهروزرسانی خود را دارند و نصب موازی بستهها میتواند PHP یا Apache ساخته‌شده توسط پنل را بشکند.
- بستههای hold شده: اگر نسخهٔ خاصی از PHP یا Node را با apt-mark hold نگه داشته‌اید، unattended-upgrades به آن احترام می‌گذارد؛ اما مطمئن شوید وصلههای امنیتی آن را از مسیر دیگری دریافت می‌کنید.
- بدون اسنپ‌شات یا بکاپ: ریبوت خودکار روی سروری که هیچ بکاپ قابل بازیابی ندارد، قمار است.
- دیسک رمزنگاری‌شده که هنگام بوت رمز می‌خواهد؛ ریبوت خودکار یعنی سرور تا صبح خاموش می‌ماند.
جمع‌بندی
بهروزرسانی خودکار امنیتی با unattended-upgrades یکی از کم‌هزینه‌ترین اقدامات امنیتی برای هر سرور Ubuntu است: مخزن -security را فعال نگه دارید، دیتابیس و در صورت نیاز کرنل را در blacklist بگذارید، ریبوت را به ساعت کم‌ترافیک و فقط با وجود بکاپ محدود کنید، needrestart را روی ریاستارت خودکار سرویس‌های کم‌خطر تنظیم کنید و لاگ‌ها یا ایمیل گزارش را واقعاً بخوانید. به‌روزرسانی‌های غیرامنیتی را همچنان دستی و پس از تست انجام دهید.
سوالات متداول
آیا unattended-upgrades در Ubuntu Server بهطور پیشفرض فعال است؟
بله، در نصب استاندارد و ایمیجهای ابری Ubuntu Server بسته نصب و تایمرها فعال هستند و وصلههای امنیتی را نصب میکنند. اما ریبوت، اعلان ایمیل و استثناها پیکربندی نشدهاند و باید خودتان فایل 50unattended-upgrades را ویرایش کنید.
چگونه بهروزرسانی خودکار را موقتاً متوقف کنیم؟
سادهترین راه، اجرای systemctl disable --now apt-daily-upgrade.timer است. راه دیگر تغییر مقدار APT::Periodic::Unattended-Upgrade به "0" در فایل 20auto-upgrades است. برای یک بستهٔ خاص از apt-mark hold استفاده کنید.
آیا بهروزرسانی خودکار میتواند سایت را از کار بیندازد؟
با پیکربندی پیشفرض (فقط امنیتی، بدون ریبوت) احتمال آن بسیار کم است، چون وصلههای امنیتی Ubuntu تغییر رفتار ندارند. ریسک اصلی از ریاستارت سرویسها یا ریبوت خودکار است که با blacklist و تنظیم needrestart کنترل میشود.
چطور بفهمم سرور به ریبوت نیاز دارد؟
وجود فایل /var/run/reboot-required نشانهٔ نیاز به ریبوت است و /var/run/reboot-required.pkgs می‌گوید کدام بستهها عامل آن هستند.
آیا بهروزرسانی خودکار روی سرور مجازی OpenVZ هم کار میکند؟
بله، نصب بستهها مستقل از نوع مجازیسازی است. فقط در OpenVZ و LXC کرنل متعلق به میزبان است و بستههای linux-* روی کانتینر اثری ندارند؛ بهروزرسانی کرنل بر عهدهٔ ارائهدهنده است.
