هل التحديثات التلقائية مفعّلة افتراضياً في Ubuntu 24.04؟
تأتي Ubuntu Server 24.04 مع unattended-upgrades، لكن الملف 20auto-upgrades هو الذي يفعّلها. تعرّف إلى Automatic-Reboot والوضع التجريبي قبل التثبيت.
لماذا تستحق التحديثات الأمنية التلقائية الإعداد
الخادم الذي لا تُثبَّت تحديثاته هو أسهل هدف على الإنترنت. معظم حالات اختراق الخوادم الصغيرة ليست نتيجة أساليب معقدة؛ بل تنتج عن ثغرة معروفة في حزمة قديمة لم يحدّثها المالك. توفّر Ubuntu أداة تسد هذه الفجوة تلقائياً: تثبّت unattended-upgrades التحديثات الأمنية تلقائياً وفق جدول زمني، من دون الحاجة إلى تسجيل الدخول. وهي أبسط إجراء أمني فعّال يمكن تطبيقه على VPS، ولا يتطلب إعدادها على Ubuntu سوى بضع دقائق.
تتبع الأداة نهجاً محافظاً عمداً. فهي تطبّق افتراضياً التحديثات الأمنية فقط، وليس ترقية كل الحزم، لأن التصحيح الأمني منخفض المخاطر ويستحق التثبيت من دون مراجعة، بينما يمكن لترقية الميزات أن تغيّر سلوكاً تعتمد عليه. هذا الإعداد الافتراضي مناسب لمعظم الخوادم، ويحافظ عليه هذا الدليل مع توضيح الإعدادات القليلة التي تستحق التغيير.
الخطوة 1: تثبيتها وتفعيلها
في Ubuntu 24.04 تكون الحزمة موجودة غالباً، لكنها ليست مفعّلة دائماً. ثبّتها وفعّلها:
sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgradesيسأل موجّه dpkg-reconfigure سؤالاً واحداً بنعم أو لا: هل تريد تنزيل التحديثات المستقرة وتثبيتها تلقائياً؟ أجب بنعم. يؤدي ذلك إلى كتابة الملف الذي يفعّل المهمة اليومية:
cat /etc/apt/apt.conf.d/20auto-upgradesAPT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";يحدّث السطر الأول قائمة الحزم يومياً؛ بينما يشغّل السطر الثاني الترقية غير التفاعلية يومياً. ويعني ضبط كليهما على 1 أن الجهاز يتحقق من التحديثات الأمنية ويطبّقها كل يوم، باستخدام مؤقت systemd، من دون أي إجراء آخر منك.
الخطوة 2: تحديد ما يُطبَّق تلقائياً
توجد السياسة في /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" لتطبيق جميع التحديثات تلقائياً، لكن الاقتصار على تطبيق التصحيحات الأمنية تلقائياً هو الإعداد الأكثر أماناً للخادم الذي يستضيف شيئاً مهماً لك. اترك الإعداد كما جاء مع الحزمة، ما لم يكن لديك سبب محدد لتغييره.
الخطوة 3: التعامل مع عمليات إعادة التشغيل
لا تصبح بعض التحديثات، مثل تحديث kernel أو مكتبة أساسية، نافذة بالكامل إلا بعد إعادة التشغيل. لن تعيد unattended-upgrades تشغيل خادمك ما لم تطلب منها ذلك، ما يعني أن kernel المصحّح قد يبقى غير مستخدم حتى تعيد التشغيل لاحقاً. حدّد الطريقة التي تريد التعامل بها مع ذلك، واضبطها صراحةً في 50unattended-upgrades:
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";يعيد ذلك تشغيل الخادم عند الساعة الرابعة صباحاً، وفقط عندما يتطلب أحد التحديثات ذلك. في VPS واحد لا توجد له عنقود لتجاوز الأعطال إليه، تكون إعادة التشغيل القصيرة في الصباح الباكر عادةً المقايضة المناسبة للحفاظ على تحديث إصلاحات kernel. إذا كان خادمك يشغّل شيئاً يجب ألا يُعاد تشغيله بشكل مفاجئ، فاترك إعادة التشغيل معطّلة، واعتد على إعادة التشغيل بنفسك بعد التحقق من /var/run/reboot-required.
الخطوة 4: إثبات عملها
لا تنتظر يوماً لمعرفة ما إذا كانت المهمة تعمل. شغّل اختباراً جافاً يعرض بالضبط ما سيُطبَّق، من دون إجراء أي تغيير:
sudo unattended-upgrade --dry-run --debugيسرد الخرج الحزم التي تفحصها الأداة والأصول التي تأتي منها، حتى تتمكن من رؤية السياسة قيد التنفيذ. بعد تشغيل المهمة الفعلية مرة واحدة على الأقل، يوجد سجلها هنا:
cat /var/log/unattended-upgrades/unattended-upgrades.logيجيب هذا السجل عن السؤال: «هل يطبّق خادمي التحديثات على نفسه فعلاً؟». إذا أظهر تثبيت حزم أمنية وفق جدول زمني، فالمهمة تعمل.
موضع ذلك ضمن الخطة
التحديثات التلقائية طبقة واحدة من طبقات تأمين الخادم، وليست الحل الكامل. فهي تمنع بقاء الأخطاء المعروفة من دون معالجة، لكنها لا تتعامل مع من يمكنه تسجيل الدخول أو ما هو مكشوف. اقرنها بـتأمين SSH الذي يقتصر على المفاتيح، حتى لا يمكن تنفيذ تخمين كثيف على نقطة الدخول، وبـجدار UFW الناري بسياسة المنع الافتراضي حتى لا يكون قابلاً للوصول إلا ما تختاره، وبـمستخدمي الخدمات غير ذوي الصلاحيات حتى لا يتمكن تطبيق مخترق من السيطرة على الخادم بالكامل. تحمل التطبيقات التي تستضيفها أسرارها الخاصة فوق كل ذلك، لذلك إذا كان هذا الخادم يشغّل خزنة كلمات مرور مستضافة ذاتياً، فإن إجراءات تأمين Vaultwarden تغطي رمز المسؤول وملف النسخ الاحتياطي اللذين لن تحميهما أي كمية من تصحيحات apt. تغلق التحديثات الثغرات التي تعرفها؛ أما الطبقات الأخرى فتحد من الأضرار التي قد تسببها الثغرات التي لا تعرفها.
FAQ
هل تطبّق unattended-upgrades كل تحديث أم التحديثات الأمنية فقط؟
التحديثات الأمنية فقط، افتراضياً. تفعّل كتلة Allowed-Origins في /etc/apt/apt.conf.d/50unattended-upgrades الأصول -security وتترك تحديثات الميزات العادية لتطبّقها يدوياً. هذا مقصود: التصحيحات الأمنية منخفضة المخاطر وتستحق التطبيق تلقائياً، بينما يمكن لترقيات الميزات أن تغيّر السلوك، لذلك ينبغي لمعظم الخوادم الإبقاء على الإعداد المحافظ الافتراضي.
هل ستعيد التحديثات التلقائية تشغيل خادمي؟
فقط إذا طلبت منها ذلك. اضبط Unattended-Upgrade::Automatic-Reboot "true" وAutomatic-Reboot-Time في الإعدادات، وعندها يعيد الخادم التشغيل في ذلك الوقت عندما يتطلب أحد التحديثات ذلك، مثلاً بعد تصحيح kernel. إذا بقي الإعداد معطّلاً، ينتظر kernel المصحّح حتى تعيد تشغيل الخادم بنفسك؛ افحص /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، وجدار ناري بسياسة المنع الافتراضي، ومستخدمي خدمات بأقل قدر من الصلاحيات، لتحصل على خادم يصعب اختراقه فعلاً.