التشغيل الأول لـ Lynis على خادم VPS جديد يعطي عادة نحو 60 وقائمة طويلة من التوصيات لا يتضح فيها بماذا تبدأ. الخبر السار: 80 إلى 85 عمل أمسية واحدة، ومعظم الخطوات ليست تجميلية بل تستحق فعلًا. والخبر السيئ: النقاط الخمس عشرة الأخيرة غير قابلة للبلوغ على آلة افتراضية مستأجرة، ومطاردتها خطأ.
ماذا يُظهر المؤشر وماذا لا يُظهر
مؤشر التحصين هو نسبة الاختبارات الناجحة إلى مجموعها مع أوزان — لا نسبة أمان مئوية. يشغّل Lynis نحو ثلاثمئة اختبار وينتج قائمتين منفصلتين: warnings التي تبدو مشكلات حقيقية، وsuggestions وهي أمور يمكن تحسينها. ويُبدأ دائمًا بالتحذيرات؛ وهي قليلة عادة.
المئة نقطة غير موجودة: بعض التوصيات يتطلب قرارات تُتخذ عند تثبيت النظام (أقسام منفصلة لـ /home و/tmp و/var)، وبعضها يحتاج وصولًا إلى محمّل الإقلاع وهو غير متاح في VPS، وبعضها يتناقض مع بعض. ومقارنة مؤشرك بمؤشر غيرك بلا معنى: فـ Lynis يخصم نقاطًا مقابل ما يعمل على الآلة. كل خدمة تعمل تعني منفذًا مفتوحًا إضافيًا وإعدادها الخاص وعشرات التوصيات الجديدة، ولهذا تُصادَف الأرقام العالية أكثر حيث لا يعمل شيء سوى SSH. أما لخادم عامل عليه موقع وقاعدة بيانات وبريد، فـ 85 نتيجة جيدة.
شغّله بصلاحيات root
sudo lynis audit system
بدون sudo يتخطى Lynis كل اختبار يحتاج ملفات النظام ويبلّغ عن مؤشر أدنى — لا لأن الخادم سيئ بل لأن الفحوص كانت غير مرئية. يُكتب التقرير في /var/log/lynis-report.dat، والسجل القابل للقراءة في /var/log/lynis.log.
يبدأ كل سطر من المخرج بمعرّف اختبار مثل SSH-7408 أو KRNL-6000. وبهذا المعرّف تجد الشرح وطريقة تعطيل الاختبار معًا — احفظ شكله، فكل ما يلي يدور حوله.
ما الذي يحرّك الرقم فعلًا
SSH (SSH-7408). أثقل كتلة: اختبار واحد يفحص عشرات المعاملات دفعة واحدة. لا تحرّر ملف sshd_config بأكمله؛ ضع ملفًا منفصلًا كي لا يمحو تحديث الحزمة عملك:
sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
MaxSessions 2
X11Forwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE
TCPKeepAlive no
EOF
sudo sshd -t && sudo systemctl reload ssh
تشغيل sshd -t قبل إعادة تحميل الخدمة إلزامي: خطأ في الإعداد بينما جلستك حية سيتركك في الخارج. وقبل وضع PasswordAuthentication no تأكّد أن المفتاح يعمل فعلًا — من طرفية ثانية مفتوحة.
معاملات النواة (KRNL-6000). يفحص الاختبار نحو عشرين قيمة من sysctl. وملفٌ لها:
sudo tee /etc/sysctl.d/99-hardening.conf <<'EOF'
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.sysrq = 0
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.log_martians = 1
EOF
sudo sysctl --system
أدوات ناقصة. جزء لا بأس به من التوصيات هو ببساطة «ثبّت ما هو غير موجود»: auditd (تسجيل أحداث النظام)، وaide (سلامة الملفات)، وdebsums (سلامة الحزم)، وunattended-upgrades (تحديثات الأمان التلقائية)، وsysstat وacct (محاسبة العمليات)، وماسح للبرمجيات الخبيثة. كلٌّ منها يغلق توصية أو اثنتين، لكن لا تثبّتها من أجل النقاط: بدونها لن تعيد بناء أي شيء بعد حادثة.
تفاصيل صغيرة بنسبة جهد إلى مردود جيدة. umask 027 في /etc/login.defs؛ وتقادم كلمات المرور في الملف نفسه؛ واللافتات في /etc/issue و/etc/issue.net؛ ومترجمات يقرأها root وحده (chmod 700 /usr/bin/gcc). وبصراحة عن اللافتات: هي لا تفعل شيئًا للأمان، بل هي شكليّة قانونية — لكنها تعطي نقطة.
فخ واحد في login.defs
تحرير umask باستبدال السطر عبر sed يترك غالبًا عدة أسطر UMASK في الملف دفعة واحدة. عندها لا يحتسب Lynis القيمة ويبقى الاختبار AUTH-9328 أحمر رغم أن الإعداد يبدو منجزًا. تحقّق بعد التحرير:
grep -c '^UMASK' /etc/login.defs
يجب أن يكون واحدًا بالضبط. وينطبق الأمر نفسه على كل معامل آخر في ذلك الملف.
الإنذارات الكاذبة وكيف تُسكَت بشكل صحيح
بعض التحذيرات لا ينطبق على خادمك إطلاقًا. مثال واقعي: على خادم VPS لدى مزوّد كبير يبلّغ الاختبار PKGS-7388 بأنه لم يُعثر على مستودع أمان — لمجرد أن المستودعات موصوفة بصيغة deb822 مع إشارة إلى ملف مرآة، بينما يبحث Lynis عن السطر المألوف. وتحديثات الأمان تصل بشكل ممتاز.
أسكِت ذلك لا بحذف أسطر من التقرير بل بملف تعريف. تستخدم ملفات التعريف الامتداد .prf (لا .prof — ومن السهل ضياع نصف ساعة هنا)، وقواعدك الخاصة تذهب إلى /etc/lynis/custom.prf:
skip-test=PKGS-7388
skip-test=KRNL-5788
قاعدة واحدة: كل سطر يحتاج إلى تعليق بجانبه يوضّح سبب تخطي الاختبار. فبعد ستة أشهر لن تتذكر هل عُطِّل لأنه لا ينطبق أم لأن إصلاحه كان مرهقًا — والفرق بين هاتين الحالتين هو كل المعنى.
ما لا ينبغي فعله
لا تطارد الرقم. من السهل تضخيم المؤشر بتعطيل الاختبارات المزعجة، وهذا هو السبيل الوحيد بعد مستوى معيّن — إلا أن الخادم لا يصبح أكثر أمانًا قيد أنملة. المفيد شيء آخر: سجّل قيمتك الخاصة وراقب تغيّرها. فمؤشر ينخفض بعد تحديث أو بعد تعديل أجراه شخص آخر على إعداد ما هو إشارة أثمن بكثير من حجمه المطلق.
ولهذا بالذات يستحق Lynis أن يُشغَّل وفق جدول لا مرة واحدة، مع حفظ التقارير كي يكون هناك ما تقارن به. وشكل ذلك مجمّعًا على صفحة واحدة يعرضه العرض التوضيحي أدناه: المؤشر، وقائمة التحذيرات بمعرّفات اختباراتها، وما تغيّر منذ التشغيل السابق.