لماذا أتمتة تصحيحات الأمان
دورة حياة الثغرة قصيرة. بين نشر CVE حرج وأولى محاولات الاستغلال الجماعي، لا تتجاوز النافذة الزمنية بضع ساعات. بالنسبة لوكالة تدير عشرة أو عشرين أو خمسين خادم VPS، انتظار تدخل يدوي مجدول أسبوعيًا يعني إتاحة أيام من التعرض على كل جهاز.
تعزز اللوائح هذا المطلب. يلزم قانون المرونة السيبرانية الأوروبي المشغّلين بإثبات سياسة تصحيح موثقة ومُطبَّقة. بالنسبة للوكالات التي تستضيف تطبيقات العملاء، قد يُعرّض غياب إمكانية تتبع التصحيحات مسؤوليتها التعاقدية للخطر في حالة وقوع حادث.
الحجة التقنية بسيطة: غالبية اختراقات خوادم Linux تستغل ثغرات توفر تصحيح لها منذ أكثر من 30 يومًا. أداة unattended-upgrades، المضمّنة في مستودعات Debian وUbuntu، تثبّت تصحيحات الأمان تلقائيًا من المستودعات الرسمية دون المساس بترقيات الإصدارات الرئيسية أو الحزم التي استثنيتها صراحةً.
فوائد ملموسة للوكالات التي تدير أسطول عملاء
- تقليص وقت المعالجة: تُطبَّق تصحيحات الأمان في غضون ساعات من نشرها في المستودعات المستقرة، دون تذكرة صيانة.
- تتبع تلقائي: كل عملية تثبيت مسجّلة في
/var/log/unattended-upgrades/، قابلة للاطلاع في أي وقت للتدقيق أو التقارير. - نطاق محكوم: يُطبَّق افتراضيًا فقط التحديثات المصنّفة
security— تبقى ترقيات الإصدار تحت السيطرة اليدوية. - تخفيف العبء التشغيلي: لا يحتاج أسطول من 50 VPS بعد الآن إلى 50 اتصال SSH أسبوعي لتنفيذ
apt upgrade. - امتثال قابل للتوثيق: السياسة محددة في ملف تكوين قابل للإصدار ولإعادة الإنتاج عبر Ansible أو أي أداة إدارة تكوين.
- إشعارات موجهة: يمكن أن تطلق أخطاء التثبيت أو عمليات إعادة التشغيل المطلوبة بريدًا إلكترونيًا، دون إغراق الفريق بتقارير روتينية.
كيف يعمل unattended-upgrades
unattended-upgrades هو خدمة Debian/Ubuntu تعمل عبر مؤقت systemd (أو cron على الأنظمة الأقدم). يستعلم عن مستودعات APT المكوّنة، يصفّي الحزم وفق الأصول المسموح بها المحددة في تكوينه، ثم يثبّت التحديثات دون تفاعل المستخدم.
تعتمد منطق التصفية على ملفات APT Release. كل مستودع يكشف بيانات وصفية (Origin وSuite وCodename) يقارنها unattended-upgrades بقائمته البيضاء. افتراضيًا على Ubuntu، لا تُفعَّل إلا أصول ${distro_id}:${distro_codename}-security — وهو ما يتوافق تمامًا مع أرشيفات الأمان الرسمية لـ Canonical، دون تضمين تحديثات backport أو حزم طرف ثالث.
تسير العملية في ثلاث مراحل: تحديث ذاكرة التخزين المؤقت لـ APT، حل التبعيات للحزم المؤهلة، التثبيت مع تسجيل مفصل. في حالة خطأ (تعارض تبعية، حزمة مقفلة، مساحة قرص غير كافية)، تتوقف عملية التثبيت ويمكن إرسال إشعار حسب التكوين.
المتطلبات الأساسية
التكوين الموصوف في هذا المقال ينطبق على Debian 11/12 وUbuntu 22.04/24.04 LTS. الأنظمة الأقدم (Debian 10، Ubuntu 20.04) متوافقة لكن دعمها ينتهي — يُنصح بالترحيل قبل الاستثمار في تكوينها.
الوصول المطلوب: اتصال SSH بصلاحيات root أو حساب sudo. لا توجد تبعيات خارجية للتشغيل الأساسي؛ تكوين SMTP اختياري ولا يتدخل إلا في إشعارات البريد الإلكتروني.
إذا كنت تدير أسطولك من Ansible، يمكن إعادة إنتاج الخطوات الموضحة أدناه مباشرة في دور مخصص — بنية ملفات التكوين مستقرة عبر الإصدارات الرئيسية لـ Debian وUbuntu.
تثبيت وتكوين unattended-upgrades
تثبيت الحزمة
على Debian وUbuntu، الحزمة متاحة في المستودعات القياسية:
apt-get update apt-get install -y unattended-upgrades apt-listchangesحزمة
apt-listchangesاختيارية لكن موصى بها: تتيح تضمين ملخص التغييرات في إشعارات البريد الإلكتروني.تكوين الأصول المسموح بها
عدّل
/etc/apt/apt.conf.d/50unattended-upgrades. يتحكم القسمUnattended-Upgrade::Allowed-Originsفي المستودعات المؤهلة. على Ubuntu 22.04، التكوين الأدنى الموصى به:Unattended-Upgrade::Allowed-Origins { "${distro_id}:${distro_codename}-security"; "${distro_id}ESMApps:${distro_codename}-apps-security"; "${distro_id}ESM:${distro_codename}-infra-security"; };على Debian 12، استبدل بـ:
Unattended-Upgrade::Allowed-Origins { "Debian:${distro_codename}-security"; };لاستثناء حزم حساسة (مثل نواة مخصصة أو إصدار PHP مثبّت):
Unattended-Upgrade::Package-Blacklist { "linux-image"; "php8.2-fpm"; };تفعيل المؤقت الدوري
يتحكم ملف
/etc/apt/apt.conf.d/20auto-upgradesفي تكرار التنفيذ. أنشئه أو تحقق من محتواه:APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; APT::Periodic::AutocleanInterval "7";القيمة
"1"تعني التنفيذ اليومي. على Ubuntu، يُفعَّل الخدمةapt-daily-upgrade.timerتلقائيًا بعد هذا التكوين. تحقق من حالته:systemctl status apt-daily-upgrade.timerفحص السجلات
تُكتب سجلات التثبيت في
/var/log/unattended-upgrades/. الملف الرئيسي:tail -50 /var/log/unattended-upgrades/unattended-upgrades.logسطر نجاح يبدو كالتالي:
2026-09-25 04:12:31,847 INFO Packages that will be upgraded: libssl3 openssl 2026-09-25 04:12:45,021 INFO Package libssl3 upgraded to 3.0.2-0ubuntu1.17في حالة الفشل، يحتفظ ملف
unattended-upgrades-dpkg.logبالمخرجات الكاملة لـdpkgللتشخيص.اختبار التنفيذ عند الطلب
لتشغيل فوري دون انتظار المؤقت والتحقق من أن التكوين يعمل:
unattended-upgrade --dry-run --debug 2>&1 | head -60خيار
--dry-runيحاكي التثبيت دون إجراء أي تغييرات. أزله للتنفيذ الفعلي:unattended-upgrade -vإذا أظهرت المخرجات
No packages found that can be upgraded unattended، فالنظام محدّث أو لا توجد حزمة مؤهلة — وهو النتيجة المتوقعة على خادم تم توفيره مؤخرًا.
تكوين إشعارات البريد الإلكتروني
تتيح إشعارات البريد الإلكتروني للفريق استقبال تنبيه عند فشل تحديث أو عند الحاجة لإعادة تشغيل. لا ترسل شيئًا في حالة النجاح الصامت — مما يتجنب إغراق صندوق البريد بتقارير يومية.
في /etc/apt/apt.conf.d/50unattended-upgrades، فعّل الخيار:
Unattended-Upgrade::Mail "[email protected]";
Unattended-Upgrade::MailReport "only-on-error";القيمة only-on-error (الموصى بها) ترسل بريدًا فقط في حالة الخطأ. القيمة on-change ترسل بريدًا مع كل تثبيت. القيمة always ترسل بريدًا حتى عندما لا يُثبَّت شيء — تجنب هذا على أسطول من عشرات الأجهزة.
لكي يعمل الإرسال، يجب أن يمتلك الخادم MTA محليًا قادرًا على توجيه رسائل البريد. على VPS بسيط، postfix في وضع satellite هو الخيار الأخف:
apt-get install -y postfix
# اختر "Satellite system" في المعالج
# أدخل تتابع SMTP الخاص بمزودك أو بنيتك التحتيةبديلًا، يمكن لـ msmtp أن يعمل كوسيط لخدمة بريد تحويلية (Mailgun أو Postmark أو SendGrid) دون تثبيت MTA كامل.
مراقبة عمليات إعادة التشغيل المطلوبة مع needrestart
بعض تصحيحات الأمان — خاصةً تلك الخاصة بالنواة أو libc أو OpenSSL — تتطلب إعادة تشغيل لتكون فعّالة بالكامل. تكشف أداة needrestart الخدمات والعمليات التي لا تزال تستخدم الإصدارات القديمة في الذاكرة.
ثبّتها بـ:
apt-get install -y needrestartبعد كل تحديث، تسرد needrestart الخدمات التي تحتاج إلى إعادة تشغيل. في الوضع التلقائي ($nrconf{restart} = 'a'; في /etc/needrestart/needrestart.conf)، تعيد تشغيل الخدمات المتأثرة دون تدخل. بالنسبة للنوى، لا تعيد تشغيل الجهاز تلقائيًا أبدًا دون تكوين صريح — وهو السلوك المتوقع على VPS الإنتاجي.
ادمج needrestart مع إشعارات unattended-upgrades: بريد إلكتروني يشير إلى الحاجة لإعادة تشغيل يسمح للفريق بجدولة التدخل في الوقت المناسب.
إعادة التشغيل التلقائية لتصحيحات النواة
إعادة التشغيل التلقائية بعد تصحيح النواة هي القرار الأكثر حساسية في سياسة التحديث. تضمن أن الإصلاح نشط فورًا، لكنها تقاطع الخدمات الجارية — مما قد يكون غير مقبول لبعض أعباء العمل.
في /etc/apt/apt.conf.d/50unattended-upgrades، الخيارات المعنية:
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";Automatic-Reboot-Time يجدول إعادة التشغيل في ساعة هادئة. Automatic-Reboot-WithUsers "false" يمنع إعادة التشغيل إذا كانت جلسة مستخدم مفتوحة.
احتياطات أساسية قبل تفعيل هذا الخيار:
- تحقق من أن خدماتك تعيد الإقلاع تلقائيًا (systemctl is-enabled <service>).
- اختبر وقت إعادة التشغيل الكاملة على خادم staging قبل النشر في الإنتاج.
- إذا كان تطبيقك يتطلب ترتيب إقلاع محددًا، وثّق هذا السيناريو واختبره.
- لأسطول VPS متعدد، وزّع أوقات إعادة التشغيل — انظر القسم التالي.
التحديثات اليدوية مقابل التلقائية: مقارنة
مرّر الجدول أفقيًا
| المعيار | التحديث اليدوي | التحديث التلقائي (unattended-upgrades) |
|---|---|---|
| وقت التطبيق | يعتمد على جدول الصيانة — غالبًا 3 إلى 7 أيام | ساعات قليلة بعد النشر في المستودعات المستقرة |
| قابلية التتبع | تعتمد على دقة ملاحظات الصيانة | سجل موقّت تلقائيًا في `/var/log/unattended-upgrades/` |
| خطر التراجع | محكوم: كل تحديث يُتحقق منه قبل التطبيق | منخفض على التصحيحات المستقرة، تحدّه القائمة السوداء |
| العبء التشغيلي | مرتفع على أسطول أكثر من 5 VPS | لا يُذكر بعد نشر التكوين |
| تصحيحات النواة الفعّالة | فورية إذا تمت جدولة إعادة التشغيل | تتطلب تكوين إعادة التشغيل التلقائي أو تدخلًا يدويًا |
| تغطية CVE الحرجة | غير كافية إذا كانت الدورة أسبوعية | مثلى — تُطبَّق التصحيحات في أضيق نافذة ممكنة |
| الامتثال الموثّق | صعب الإثبات دون أدوات إضافية | ملفات سجل وتكوين قابلان للإصدار والتدقيق |
نشر وإدارة unattended-upgrades عبر أسطول VPS متعدد
التكوين الموضح حتى الآن ينطبق على خادم واحد. لأسطول من عشرات خوادم VPS العميل، تصبح قابلية الإعادة والتنسيق تحديات قائمة بذاتها.
الأتمتة مع Ansible
دور Ansible بسيط يكفي لنشر التكوين عبر الأسطول بالكامل في دقائق. خزّن ملفات 50unattended-upgrades و20auto-upgrades في templates/ واجعل خيارات إعادة التشغيل قابلة للتكوين عبر متغيرات الجرد:
- name: نشر unattended-upgrades
hosts: vps_clients
become: true
tasks:
- name: تثبيت unattended-upgrades
apt:
name: [unattended-upgrades, apt-listchanges]
state: present
update_cache: true
- name: نشر التكوين
template:
src: 50unattended-upgrades.j2
dest: /etc/apt/apt.conf.d/50unattended-upgrades
owner: root
mode: '0644'
- name: نشر apt-periodic
copy:
src: 20auto-upgrades
dest: /etc/apt/apt.conf.d/20auto-upgrades
owner: root
mode: '0644'توزيع أوقات إعادة التشغيل
إذا كانت إعادة التشغيل التلقائية مُفعّلة، لا تكوّن نفس الوقت على جميع خوادمك. إعادة تشغيل متزامنة لـ 30 VPS يمكن أن تولّد حمل إعادة اتصال غير معتادة. وزّع الأوقات على نافذة ساعتين باستخدام متغير Ansible لكل مجموعة أو خادم.
الاختبار على staging قبل أسطول الإنتاج
للتكوينات التي تُفعّل إعادة التشغيل التلقائي أو تعدّل قائمة الحزم المستثناة، تحقق أولًا على خادم staging تمثيلي. VPS بسعر 99 درهم/شهر مخصص لاختبارات التكوين يتجنب نشر خطأ عبر الأسطول بأكمله.
مركزة التنبيهات
بدلًا من استقبال رسائل بريد فردية من كل خادم، كوّن اسمًا مستعارًا للبريد يجمع التنبيهات في قناة مراقبة واحدة. إذا كانت بنيتك التحتية تستخدم بالفعل مجمّع سجلات (Loki أو OpenSearch)، يمكن توجيه ملفات سجل unattended-upgrades إليه عبر عميل خفيف لعرض مركزي للأسطول.
لمزيد من تأمين VPS، راجع قائمة تدقيق تصليب Linux ومقارنتنا CrowdSec مقابل Fail2ban. إذا كنت تدير أيضًا تطبيقات self-hosted، روتين تصحيح تطبيقات self-hosted يكمل هذا النهج.
