تقوية السيرفر Hardening وقياسها مع Lynis ومعايير CIS

«قوينا السيرفر» جملة تسمعها في كل اجتماع أمني، لكنها بلا معنى حتى تجيب على سؤال واحد: بكم؟ فالتقوية Hardening ليست شعوراً بالأمان، بل حالة تقاس برقم قبل التغيير وبعده، فترى هل نفع ما فعلته، وأين ما زال سيرفرك ضعيفاً. وفي هذا المقال نأخذ خادم Debian جديداً، ونقيس حالته بأداتين معروفتين هما Lynis ومعايير CIS، ثم نطبق تقوية فعلية، ونعيد القياس على السيرفر نفسه، فنرى الفرق رقماً حقيقياً لا وعداً.

وهذا المقال هو الثالث في مرحلة الأمن السيبراني، ويكمل ما بدأناه في تأمين خادم VPS من أول دخول، فذلك الدليل يشرح الخطوات اليدوية الأولى، وهنا نضيف طبقة القياس: كيف تعرف أين تقف، وكيف تثبت التحسن. وسوف نتناول ما يلي:

• ما معنى التقوية Hardening، وطبقاتها على خادم واحد.
• قياس الحالة بأداة Lynis، وقراءة مؤشر التقوية Hardening Index.
• قياسها بمعايير CIS عبر أداة debian-cis مفتوحة المصدر.
• تطبيق تقوية فعلية خطوة بخطوة، ثم إعادة القياس على السيرفر نفسه.
• النتيجة الحقيقية: Lynis من 59 إلى 73، وCIS من 55.96% إلى 60.49%، ولماذا لم يصل الرقم إلى المئة.
• درس مهم ظهر في المختبر: تثبيت خدمة ثم تقويتها جزئياً قد يخفض درجتك على معيار صارم.

ما معنى التقوية Hardening؟ طبقات لا خطوة واحدة

التقوية هي تقليل ما يمكن للمهاجم أن يستغله على السيرفر، عبر إزالة ما لا تحتاجه وضبط ما تبقى بإعداد آمن. والخطأ الشائع أن يظنها الناس خطوة واحدة مثل «ثبتنا جدار الحماية»، بينما هي طبقات يبنى بعضها على بعض، والصورة التالية تبينها:

وكل طبقة تغلق باباً مختلفاً: تقليل سطح الهجوم Attack Surface يزيل الحزم والخدمات والـ Drivers التي لا تستخدمها فلا يبقى فيها ثغرة تهمك، وضبط الحسابات يصعب تخمين كلمات المرور Cracking، وتقوية النواة Kernel بقيم sysctl يغلق خدعاً شبكية قديمة، وتأمين SSH يمنع أكثر طريق يدخل منه المهاجمون، والكشف Detection يجعلك ترى ما يحدث، والتحديث المستمر يغلق الثغرات الجديدة. ولا معنى لإحداها دون البقية، ولذلك نحتاج أداة تقيسها كلها معاً.

القياس الأول: أداة Lynis ومؤشر التقوية

أداة Lynis سكربت مفتوح المصدر من شركة CISOfy، يفحص مئات النقاط على السيرفر ويعطيك مؤشر تقوية Hardening Index من مئة، مع قائمة تحذيرات Warnings واقتراحات Suggestions لكل ما يمكن تحسينه. ولا يغير شيئاً، بل يقرأ ويقيس فقط، وهذا ما يجعله آمناً لتشغيله على خادم إنتاج. والمختبر هنا Container من Debian 13، وهي قريبة من خادم حقيقي بما يكفي لنقيس عليها، وسوف نرى في النهاية حدود هذا الاختيار بصراحة.

ننزل أحدث إصدار رسمي من Lynis، وهو 3.1.7 الصادر في 25 يونيو 2026، ونشغله على نظام الملفات:

cd /opt
curl -sSL -o lynis.tar.gz https://downloads.cisofy.com/lynis/lynis-3.1.7.tar.gz
tar xzf lynis.tar.gz
cd lynis
./lynis audit system --quick --no-colors

وبعد انتهاء الفحص يكتب Lynis نتيجته في ملف /var/log/lynis-report.dat، ومنه نقرأ الرقم الذي يهمنا:

grep hardening_index /var/log/lynis-report.dat
echo "warnings: $(grep -c '^warning\[\]' /var/log/lynis-report.dat)"
echo "suggestions: $(grep -c '^suggestion\[\]' /var/log/lynis-report.dat)"

والمخرج على السيرفر قبل أي تقوية كان كما يلي:

hardening_index=59
warnings: 2
suggestions: 35

فالدرجة الأولى 59 من مئة، مع تحذيرين وخمسة وثلاثين اقتراحاً. ولتعرف ماذا تصلح، اقرأ الاقتراحات نفسها، فكل سطر يبدأ برمز الاختبار ثم وصفه:

grep '^suggestion\[\]' /var/log/lynis-report.dat | sed 's/suggestion\[\]=//' | cut -d'|' -f1-2

ومن المخرج تظهر أمور واضحة يمكن إصلاحها: سياسة أعمار كلمات المرور في /etc/login.defs، وغياب أداة لفحص قوة كلمة المرور، وعدم وجود لافتة قانونية Legal Banner، وعدم تفعيل التدقيق auditd، وغياب أداة لسلامة الملفات File Integrity، وقيم sysctl تحتاج ضبطاً، وغيرها. وهذه قائمة عملك.

القياس الثاني: معايير CIS عبر debian-cis

يعطيك Lynis رقماً عاماً جيداً، لكن كثيراً من المؤسسات والمدققين يطلبون المطابقة مع معيار محدد، وأشهرها معيار CIS لنظام Debian، وهو وثيقة من مركز CIS تحدد مئات الضوابط بدقة: ما القيمة المطلوبة بالضبط لكل إعداد. والوثيقة نفسها طويلة، لكن مشروع debian-cis من شركة OVH يحولها إلى سكربتات تفحص كل ضابط وتقول نجح أم فشل، وهو مفتوح المصدر ويدعم Debian 12 و13، وآخر إصداراته v4.1-6.

ننزله ونشغل وضع التدقيق فقط Audit، الذي يقرأ ولا يغير:

mkdir -p /opt/cis-hardening
curl -sSL https://github.com/ovh/debian-cis/archive/refs/tags/v4.1-6.tar.gz \
  | tar xz -C /opt/cis-hardening --strip-components=1
cd /opt/cis-hardening
cp debian/default etc/hardening.cfg
export CIS_LIB_DIR=/opt/cis-hardening/lib CIS_CHECKS_DIR=/opt/cis-hardening/bin/hardening \
  CIS_CONF_DIR=/opt/cis-hardening/etc CIS_TMP_DIR=/opt/cis-hardening/tmp \
  CIS_VERSIONS_DIR=/opt/cis-hardening/versions
bin/hardening.sh --audit-all

وفي آخر المخرج يظهر الملخص على السيرفر قبل التقوية:

################### SUMMARY ###################
      Total Available Checks : 243
         Total Runned Checks : 243
         Total Passed Checks : [ 136/243 ]
         Total Failed Checks : [ 107/243 ]
   Enabled Checks Percentage : 100.00 %
       Conformity Percentage : 55.96 %

أي 136 ضابطاً ناجحاً من 243، وهي نسبة مطابقة 55.96%. ولاحظ أن عدد الضوابط هنا (243) هو ما يمكن فحصه في الـ Container، وهو أقل مما يفحص على خادم كامل، لسبب سوف نعود إليه.

التقوية الفعلية خطوة بخطوة

الآن نطبق تقوية حقيقية تعالج ما ظهر في القياسين. ونضع كل الخطوات في سكربت واحد harden.sh حتى تكون قابلة للتكرار Reproducible، وفيما يلي أهم أجزائه.

الحسابات وكلمات المرور

نضبط سياسة أعمار كلمات المرور وقوة التشفير وقيمة umask في /etc/login.defs، ونثبت أداة فحص قوة كلمة المرور:

sed -i 's/^PASS_MAX_DAYS.*/PASS_MAX_DAYS 365/' /etc/login.defs
sed -i 's/^PASS_MIN_DAYS.*/PASS_MIN_DAYS 1/'   /etc/login.defs
sed -i 's/^PASS_WARN_AGE.*/PASS_WARN_AGE 7/'   /etc/login.defs
grep -q '^SHA_CRYPT_MIN_ROUNDS' /etc/login.defs || echo 'SHA_CRYPT_MIN_ROUNDS 65536' >> /etc/login.defs
grep -q '^UMASK' /etc/login.defs || echo 'UMASK 027' >> /etc/login.defs
apt-get install -y libpam-passwdqc

تقوية النواة بقيم sysctl

نكتب ملف إعداد واحد بقيم تغلق خدعاً شبكية معروفة وتشدد حماية الذاكرة:

# /etc/sysctl.d/99-hardening.conf
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.all.log_martians=1
net.ipv4.tcp_syncookies=1
net.ipv4.icmp_echo_ignore_broadcasts=1
kernel.randomize_va_space=2
kernel.kptr_restrict=2
kernel.dmesg_restrict=1
fs.protected_hardlinks=1
fs.protected_symlinks=1
fs.suid_dumpable=0

تقليل سطح الهجوم والمراقبة والتحديث

نعطل الـ Drivers والبروتوكولات التي لا يحتاجها خادم عادي، ونضيف لافتة قانونية، ونثبت أدوات الكشف والتحديث والتدقيق:

# disable rarely-needed drivers and protocols
cat > /etc/modprobe.d/99-hardening.conf <<'EOF'
install usb-storage /bin/true
install firewire-core /bin/true
install dccp /bin/true
install sctp /bin/true
install rds /bin/true
install tipc /bin/true
EOF

# legal banner with several legal keywords (Lynis counts them)
BANNER='WARNING: Authorized access only. All activity may be monitored, logged and recorded. Unauthorized access is prohibited and violators will be prosecuted.'
printf '%s\n' "$BANNER" > /etc/issue
printf '%s\n' "$BANNER" > /etc/issue.net

# detection, patching and auditing tools
apt-get install -y auditd audispd-plugins sysstat acct aide aide-common \
  rkhunter chrony unattended-upgrades needrestart debsums apt-show-versions

ثم ننشئ قاعدة سلامة الملفات لأداة AIDE، وهي تسجل بصمة لكل ملف مهم فتكشف لاحقاً أي تعديل:

sed -i 's/^Checksums = .*/Checksums = sha256+sha512/' /etc/aide/aide.conf
aide --config=/etc/aide/aide.conf --init
cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

تأمين SSH بإعداد كامل مطابق لـ CIS

هذه الخطوة أهم ما تعلمناه في المختبر، وسوف نشرح سبب أهميتها في القسم التالي. المطلوب ليس سطرين أو ثلاثة، بل إعداد كامل يغطي كل ضوابط CIS الخاصة بـ SSH، من منع دخول root إلى خوارزميات التشفير المعتمدة:

# /etc/ssh/sshd_config (excerpt)
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
HostbasedAuthentication no
PubkeyAuthentication yes
IgnoreRhosts yes
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no
MaxAuthTries 4
MaxSessions 10
MaxStartups 10:30:60
LoginGraceTime 60
ClientAliveInterval 300
ClientAliveCountMax 3
LogLevel VERBOSE
Banner /etc/issue.net
AllowGroups ssh-users
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
MACs [email protected],[email protected],hmac-sha2-512,hmac-sha2-256
KexAlgorithms curve25519-sha256,[email protected],diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256
RekeyLimit 512M 6h

ثم نضبط صلاحيات الملف، لأن معيار CIS يفحص ملكيته وصلاحياته أيضاً:

chmod 600 /etc/ssh/sshd_config
chown root:root /etc/ssh/sshd_config

إعادة القياس: النتيجة الحقيقية

الآن نعيد تشغيل Lynis وdebian-cis على السيرفر نفسه بعد التقوية، والصورة التالية تلخص النتيجة:

بالأرقام:

فالتقوية رفعت مؤشر Lynis أربع عشرة نقطة، وأغلقت أكثر من عشرين اقتراحاً، ورفعت مطابقة CIS. وهذا هو المقصود بالقياس: لم نقل «صار أأمن»، بل أثبتنا كم تحسن.

درس المختبر: لماذا كادت التقوية تخفض درجة CIS؟

في أول محاولة كتبنا إعدادات SSH في ملف منفصل داخل /etc/ssh/sshd_config.d/ وأضفنا بضعة أسطر فقط، فحدث شيء غريب: ارتفع مؤشر Lynis، لكن مطابقة CIS انخفضت من 136 إلى 127. وقد يتساءل البعض: كيف تنخفض الدرجة بعد التقوية؟ والإجابة أن السيرفر الأول لم يكن عليه خادم SSH أصلاً، فكانت debian-cis تتخطى كل ضوابط SSH ولا تحسبها. وبمجرد أن ثبتنا openssh-server، صارت الأداة تفحص خمسة وعشرين ضابطاً جديداً لـ SSH، وأغلبها فشل لأن إعدادنا المختصر لم يحدد خوارزميات التشفير Ciphers ولا MACs ولا KexAlgorithms ولا حدود الجلسات، التي يطلبها المعيار بدقة.

وهذا الدرس ينطبق على معظم الخدمات: قبل أن تثبت قاعدة بيانات أو خادم ويب، اعرف ما الضوابط التي سيفحصها المعيار لها، وطبقها كاملة، لا نصفها.

لماذا لم يصل الرقم إلى المئة؟

هنا نكون صريحين مع القارئ: قمنا بالقياس على Container لا على خادم افتراضي كامل، والـ Container يشارك نواة Kernel المضيف ولا تملك محمل إقلاع GRUB ولا أقساماً منفصلة Partitions ولا نظام init يشغل الخدمات. ولذلك يبقى عدد من ضوابط CIS فاشلاً مهما فعلنا، وأكبر مجموعات الفشل المتبقية كانت:

• اثنان وعشرون ضابطاً في مجموعة أنظمة الملفات (1.1)، وأغلبها يطلب وضع /tmp و/var و/home على أقسام منفصلة، وهذا لا ينطبق على Container.
• تسعة عشر ضابطاً في مجموعة التدقيق (4.1)، تطلب قواعد auditd محملة وفعالة، وauditd لا يعمل داخل Container دون systemd وصلاحيات خاصة.
• ضوابط النواة ومحمل الإقلاع، التي لا معنى لها في Container يشارك نواة المضيف.

بعبارة أخرى، فإن ثبتنا auditd وchrony وrsyslog لكنها لم تعمل لأن الـ Container بلا systemd، أما على خادم VPS حقيقي بنظام init كامل، فهذه الخدمات تنشط عند الإقلاع، ويرتفع الرقمان أعلى مما ظهر هنا. فالسقف الذي رأيناه من قيود الـ Container، لا من حدود التقوية نفسها.

مشكلات شائعة Common Problems وحلولها

• Lynis لا يجد /vmlinuz (KRNL-5788): طبيعي داخل Container لأنها تشارك نواة المضيف، وتجاهله على الـ Container.
• auditd مثبت لكن اقتراح ACCT-9628 ما زال ظاهراً: لأنه لا يعمل، فالـ Container بلا systemd، وعلى خادم حقيقي شغله بـ systemctl enable --now auditd.
• تحذير «No AIDE database was found» رغم تثبيت AIDE: لم تنشئ القاعدة بعد، فشغل aide --init ثم انسخ aide.db.new إلى aide.db.
• قفلت نفسك خارج SSH بعد تطبيق الإعداد: احتفظ دائماً بجلسة مفتوحة أثناء التغيير، واختبر الإعداد بـ sshd -t قبل إعادة التشغيل، وتأكد أن مستخدمك ضمن المجموعة التي سمحت بها في AllowGroups.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما ظهر:

• التقوية حالة تقاس برقم قبل وبعد، لا شعور، وLynis وdebian-cis يعطيانك هذا الرقم مجاناً ودون تغيير أي شيء في وضع التدقيق.
• على نفس الـ Container رفعت التقوية مؤشر Lynis من 59 إلى 73، ومطابقة CIS من 55.96% إلى 60.49%.
• كل خدمة تثبتها تضيف ضوابط يجب أن تحققها كاملة، فتقوية ناقصة لخدمة قد تخفض درجتك على معيار صارم.
• السقف على الـ Container من قيودها لا من التقوية، وعلى خادم VPS كامل بنظام init تنشط الخدمات ويرتفع الرقمان.
• اقرأ الاقتراحات واحداً واحداً، وافصل ما تستطيع إصلاحه عما لا ينطبق على بيئتك، ووثق الاستثناءات.

وفي المقال القادم ننتقل من الدفاع الساكن إلى الدفاع النشط: الحظر الجماعي للهجمات مع CrowdSec.

دليلتأمين سيرفر VPS على Ubuntu من أول دخولقبل أن تثبت أي تطبيق على سيرفرك الجديد، هذه الخطوات تغلق أبرز الثغرات وأولها الدخول بمفتاح SSH بدل كلمة المرور.دليلمصطلحات الأمن السيبراني للمبتدئين: من CVE إلى Purple Teamماذا تعني الكلمات التي تتكرر في كل عرض أمني، من رقم الثغرة وخطورتها إلى أدوات المراقبة SOC والفرق الحمراء والزرقاء.دليلCrowdSec: اكتشاف هجمات التخمين وحظرها جماعياًنبني مختبراً من حاويتين، نشن تخميناً حقيقياً على SSH، ونرى CrowdSec يكتشفه ويصدر قرار حظر ينفذه الجدار الناري.دليلإدارة الثغرات Vulnerability Management: هل سيرفرك متأثر؟كيف تعرف خلال ساعات أن ثغرة جديدة تمس سيرفراتك، ولماذا يخدعك رقم الإصدار، وكيف ترتب الإصلاح وتتأكد أنه تم فعلاً.دليلالضوابط الأساسية للأمن السيبراني NCA ECC بلغة بسيطةكيف تقرأ الضوابط الأساسية ECC دون أن تضيع في أرقامها، وعلى من تنطبق، وما المطلوب من جهتك فعلاً في كل مكون.

تدريب عملي Practice

• شغل Lynis على خادمك في وضع القراءة فقط، وسجل مؤشرك الحالي، ثم اختر خمسة اقتراحات تنطبق عليك وأصلحها، وأعد القياس وقارن.
• شغل debian-cis في وضع --audit-all، واستخرج قائمة الضوابط الفاشلة، وصنفها إلى: ما ينطبق وتستطيع إصلاحه، وما لا ينطبق على بيئتك فتوثقه استثناءً.

سجل التحديثات

• أكتوبر 2026: كتابة المقال وتنفيذ المختبر يوم 25 أكتوبر 2026 على Container Debian 13 (trixie) مع Lynis 3.1.7 وdebian-cis v4.1-6، والنتيجة Lynis من 59 إلى 73 وCIS من 55.96% إلى 60.49%.