لمراقبة السلامة خاصية مزعجة: فهي تحتاج مرجعًا مأخوذًا من نظام يُعرف أنه نظيف. وإذا كان الخادم يعمل منذ ثلاث سنوات ولم يُطرح سؤال الاختراق إلا اليوم، فقد فات أوان أخذ ذلك المرجع — إذ ستسجّل ما هو موجود هناك على أنه الوضع الطبيعي.
غير أن المرجع موجود سلفًا على Debian و Ubuntu، وهو ليس مرجعك أنت: فكل حزمة مثبتة تحمل المجاميع الاختبارية لملفاتها. والمقارنة بها لا تتطلب إعدادًا ولا لقطة سابقة وتعمل على أي نظام في أي لحظة. واسم الأداة debsums.
الاستخدام
sudo apt install debsums
sudo debsums -cتطبع الراية -c الملفات التي لم تطابق المرجع فقط. وبدونها يكون المخرج تقريرًا سطرًا بسطر عن كل ملف في النظام، عشرات الآلاف من الأسطر.
ويستغرق الفحص دقائق قليلة ويحمّل القرص، لذا يستحق تشغيله على خادم عامل بأولوية منخفضة:
sudo ionice -c3 nice -n19 debsums -cكيف تُقرأ النتيجة
المخرج الفارغ يعني أن كل ملف فُحص يطابق ما ثبّتته التوزيعة. أما المخرج غير الفارغ فيحتاج فحصًا، والنتائج تقع في صنفين مختلفين جدًا.
ملفات الإعداد في /etc. تغييرها عمل طبيعي: فقد حرّرت sshd_config، وضبطت nginx، وأضفت معاملات نواة. ومثل هذه الفروق متوقَّعة. وكي لا تعترض طريقك ثمة وضع منفصل:
sudo debsums -e -cيفحص -e ملفات الإعداد وحدها — وهو مفيد أحيانًا لرؤية قائمة بكل ما غيّرته على هذه الآلة.
الملفات التنفيذية والمكتبات. فرق في /usr/bin أو /usr/sbin أو /bin أو /usr/lib هو ما شُغِّل الفحص من أجله. وثمة أسباب مشروعة لكنها ليست كثيرة: حُرِّر الملف يدويًا أثناء تتبّع الأخطاء، أو طُبِّقت رقعة من طرف ثالث، أو كانت الحزمة تُرقَّى أثناء الفحص. فإن لم ينطبق أي منها فقد حان وقت التحقيق الجاد.
والأهداف الكلاسيكية للاستبدال هي ls وps وnetstat وss وfind وsshd. فالنسخة المستبدلة تخفي من مخرجها الأسطر المهمة، وكل فحص لاحق تجريه يتوقف عن قول الحقيقة.
التغطية ناقصة — ويجب أن تعرف ذلك
قيد لا يُذكر عادة: ليست كل الحزم تشحن مجاميع اختبارية. وملفات هذه الحزم لا تُفحص إطلاقًا ولن تظهر في التقرير تحت أي ظرف. ويمكن رؤية القائمة هكذا:
sudo debsums -lولذلك يعني تقرير debsums النظيف «كل شيء على ما يرام في الجزء الذي فُحص»، لا «لم يُعدَّل النظام». والأمر نفسه ينطبق على كل ما ثُبِّت خارج مدير الحزم: ما تُرجم من الشيفرة المصدرية، وما نُزِّل كملف ثنائي، وما ثُبِّت بسكربت من موقع المطوّر — فـ debsums لا يراقب شيئًا من ذلك بحكم التعريف، وهنا بالضبط يلزم AIDE.
التشغيل المنتظم
تشحن الحزمة مهمة جاهزة، وتُفعَّل في /etc/default/debsums:
CRON_CHECK=weeklyومرة في الأسبوع تواتر معقول: فالفحص يحمّل القرص بوضوح، وملفات النظام نادرًا ما تتغيّر بين التحديثات. والتشغيل اليومي لا يضيف شيئًا سوى الحمل.
إن كان الملف قد استُبدل فعلًا
الدافع الأول هو إعادة تثبيت الحزمة واستعادة الأصل:
sudo apt install --reinstall coreutilsالأمر صحيح، لكن ليس كإجراء أول. فملف نظام ثنائي مستبدل يعني أن أحدهم كان لديه root، واستعادة الملف لا تحل تلك المشكلة — بل تدمّر الآثار فحسب. وينبغي أن يكون الترتيب معكوسًا: احتفظ أولًا بنسخة من الملف المشبوه ووقت تعديله، وانظر ما الذي تغيّر أيضًا في الفترة نفسها، وافحص مهام cron ومفاتيح SSH وقائمة المستخدمين. ولا تستعِد إلا بعد ذلك.
ويجدر تذكّر حدود الطريقة أيضًا: فإن كان النظام مخترقًا في العمق، فقد يكون debsums نفسه والمكتبات التي يستخدمها مستبدلة مع كل شيء آخر. والفحص من الداخل لا يعطي ضمانة مطلقة — وتلك يعطيها الإقلاع من وسيط خارجي. لكن هذا يكفي للعمل اليومي: فالغالبية الساحقة من الهجمات آلية وليست بهذا التعقيد.
موضعه في الصورة العامة
debsums جيد لأنه لا يحتاج شيئًا ويعمل فورًا — وهذا يجعله نقطة انطلاق مريحة لخادم لا تعرف تاريخه. وضعفه هو التغطية الناقصة وجهله بكل ما ثُبِّت خارج الحزم. والثنائي «debsums مع AIDE» يغلق الجانبين: مرجع التوزيعة الجاهز لملفات النظام، ولقطتك أنت لكل ما عداها.
وكالعادة، المعنى ليس في تشغيله بل في أن تكون النتيجة الأخيرة ظاهرة للعيان مع تاريخها. وشكل ذلك يعرضه العرض التوضيحي أدناه.