معظم الخوادم لا تُخترق عبر ثغرات zero-day معقدة، بل من خلال أخطاء بسيطة في الإعدادات، وإعدادات افتراضية منسية، وتحديثات مؤجلة. الخادم الذي يُنشأ حديثاً ليس خادماً آمناً — إنه نقطة بداية فحسب.
هذا الدليل يأخذك خطوة بخطوة عبر إجراءات التقوية التي تُحدث فارقاً حقيقياً — تلك التي تُغلق أكثر نقاط الدخول شيوعاً في بيئات الإنتاج.
ابدأ بإدارة المستخدمين والوصول عبر SSH
SSH هو الباب الرئيسي لخادمك، وهو أيضاً أكثر الخدمات التي تتعرض للمسح على الإنترنت. البوتات تبحث الآن عن المنفذ 22 المفتوح، وتجرب بيانات الاعتماد الافتراضية والثغرات المعروفة.
تعطيل تسجيل الدخول كـ Root وتسجيل الدخول بكلمة المرور
أول تغييرين يجب إجراؤهما على أي خادم جديد:
# In /etc/ssh/sshd_config PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yesتعطيل تسجيل دخول root يجبر المهاجم على معرفة اسم مستخدم صالح وامتلاك مفتاح SSH الصحيح في آنٍ واحد. بالإضافة إلى تعطيل المصادقة بكلمة المرور كلياً، ستُلغي هجمات Brute Force من المعادلة تماماً.
بعد التعديل، أعد تحميل الخدمة:
systemctl reload sshdتغيير المنفذ الافتراضي لـ SSH
هذا ما يُعرف بالأمان عبر الغموض — ليس دفاعاً حقيقياً بمفرده، لكنه يُزيل كميات هائلة من الضجيج الآلي من سجلاتك:
# In /etc/ssh/sshd_config Port 2222تذكر أن تفتح المنفذ الجديد في جدار الحماية قبل إعادة تحميل SSH، وإلا ستُقفل نفسك خارج الخادم.
إنشاء مستخدم مخصص للإدارة
لا تستخدم أبداً اسماً عاماً مثل admin أو ubuntu للوصول اليومي. أنشئ مستخدماً باسم محدد وامنحه صلاحيات sudo:
useradd -m -s /bin/bash yourname usermod -aG sudo yourname mkdir -p /home/yourname/.ssh cp ~/.ssh/authorized_keys /home/yourname/.ssh/ chown -R yourname:yourname /home/yourname/.ssh chmod 700 /home/yourname/.ssh chmod 600 /home/yourname/.ssh/authorized_keysإعداد جدار الحماية باستخدام UFW
جدار الحماية أمر لا تنازل عنه. على أنظمة Ubuntu وDebian، يوفر UFW واجهة مباشرة وسهلة لـ iptables يصعب الوقوع في أخطاء معها.
المبدأ الأساسي يجب أن يكون: رفض كل شيء، ثم السماح صراحةً بما تحتاجه.
ufw default deny incoming ufw default allow outgoing ufw allow 2222/tcp # Your custom SSH port ufw allow 80/tcp ufw allow 443/tcp ufw enableتحقق من الحالة في أي وقت:
ufw status verboseإذا كنت تشغّل قاعدة بيانات مثل MySQL أو PostgreSQL، لا تفتح تلك المنافذ للعموم. يجب أن تكون متاحة فقط عبر localhost أو واجهة شبكة خاصة. قاعدة بيانات PostgreSQL مكشوفة على المنفذ 5432 للإنترنت هي دعوة مفتوحة للمشاكل.
ابقِ النظام محدَّثاً — تلقائياً
الحزم غير المُرقَّعة مسؤولة عن نسبة كبيرة غير متناسبة من الاختراقات الحقيقية. الحل بسيط: ابقِ الأمور محدَّثة.
تفعيل التحديثات التلقائية
على Debian/Ubuntu:
apt install unattended-upgrades dpkg-reconfigure --priority=low unattended-upgradesالإعدادات الرئيسية موجودة في /etc/apt/apt.conf.d/50unattended-upgrades. على الأقل، فعّل تحديثات الأمان التلقائية:
Unattended-Upgrade::Allowed-Origins { "${distro_id}:${distro_codename}-security"; }; Unattended-Upgrade::Automatic-Reboot "false"; Unattended-Upgrade::Mail "you@yourdomain.com";ضبط Automatic-Reboot على false في بيئات الإنتاج يمنحك التحكم في توقيت إعادة تشغيل النواة — وهذا مهم للاستمرارية. ستتلقى بريداً إلكترونياً عند الحاجة لإعادة التشغيل.
في خطط الاستضافة المُدارة، تُعالَج تحديثات النواة والتصحيحات على مستوى نظام التشغيل عادةً نيابةً عنك. لكن إذا كنت تدير VPS خاصاً بك، فالتحديثات التلقائية ليست اختيارية.
تقوية النواة باستخدام sysctl
تُتيح نواة Linux التحكم في كثير من سلوكيات الشبكة والذاكرة عبر sysctl. بعض الإعدادات الافتراضية مناسبة للتطوير لكنها تحتاج إلى تشديد في بيئات الإنتاج.
أضف ما يلي إلى /etc/sysctl.d/99-hardening.conf:
# Disable IP source routing net.ipv4.conf.all.accept_source_route = 0 net.ipv6.conf.all.accept_source_route = 0 # Ignore ICMP redirects net.ipv4.conf.all.accept_redirects = 0 net.ipv6.conf.all.accept_redirects = 0 # Enable SYN flood protection net.ipv4.tcp_syncookies = 1 # Disable IP forwarding (unless this is a router) net.ipv4.ip_forward = 0 # Protect against time-wait assassination net.ipv4.tcp_rfc1337 = 1 # Restrict dmesg to root kernel.dmesg_restrict = 1 # Prevent core dumps from setuid programs fs.suid_dumpable = 0طبّق التغييرات فوراً:
sysctl -p /etc/sysctl.d/99-hardening.confمراجعة الخدمات قيد التشغيل
كل خدمة تعمل على خادمك هي سطح هجوم محتمل. راجع ما يعمل فعلاً:
ss -tulnpهذا يُظهر جميع المنافذ المستمعة مع العملية المرتبطة بها. مرّ على النتائج سطراً سطراً. إذا لم تتعرف على خدمة ما، فاستقصِ أمرها. وإذا لم تكن بحاجة إليها، عطّلها:
systemctl stop service-name systemctl disable service-nameمن أكثر الخدمات الشائعة في عمليات التثبيت الافتراضية التي لا مكان لها في خادم إنتاج: avahi-daemon وcups وخدمات Bluetooth المتنوعة.
إعداد Fail2ban للكشف عن التطفل
يراقب Fail2ban ملفات السجل ويحظر مؤقتاً عناوين IP التي تُظهر سلوكاً خبيثاً — كتكرار فشل تسجيل الدخول عبر SSH مثلاً.
apt install fail2banأنشئ ملف تجاوز محلياً (حتى تظل إعداداتك سليمة عند تحديث الحزمة):
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.localثم اضبط حماية SSH في /etc/fail2ban/jail.local:
[sshd] enabled = true port = 2222 filter = sshd logpath = /var/log/auth.log maxretry = 4 bantime = 3600 findtime = 600هذا يحظر أي عنوان IP يفشل في المصادقة عبر SSH 4 مرات خلال 10 دقائق، لمدة ساعة كاملة. عدّل هذه الحدود وفق مستوى المخاطر المقبول لديك.
النسخ الاحتياطية: خط دفاعك الأخير
التقوية تُقلص سطح الهجوم، لكن لا توجد تقوية مثالية. إذا حدث خطأ ما — بيانات اعتماد مخترقة، أو ثغرة zero-day، أو خطأ في الإعدادات — فالنسخ الاحتياطية هي ما يُمكّنك من الاستعادة دون خسارة كارثية للبيانات.
المقياسان الأساسيان لأي استراتيجية نسخ احتياطي هما RPO (هدف نقطة الاسترداد) وRTO (هدف وقت الاسترداد). يُحدد RPO مقدار البيانات التي يمكنك تحمّل خسارتها، بينما يُحدد RTO مدى السرعة المطلوبة للعودة إلى الإنترنت.
نسخة احتياطية يومية واحدة تمنحك RPO يصل إلى 24 ساعة. بالنسبة لمعظم مواقع الإنتاج هذا مقبول، لكن للتطبيقات كثيفة المعاملات — التجارة الإلكترونية، ومنتجات SaaS، وأي شيء يكتب البيانات باستمرار — فغالباً لا يكفي. إجراء النسخ الاحتياطية عدة مرات يومياً (ندعم ما يصل إلى أربع مرات يومياً مع إمكانية تخصيص النسخ الكاملة أو الجزئية) يُقلص هذه النافزة بشكل كبير دون زيادة متناسبة في تكاليف التخزين، إذ يمكن أن تكون النسخ خلال اليوم جزئية وتغطي قواعد البيانات والملفات المتغيرة فقط.
مهما كانت استراتيجية النسخ الاحتياطي التي تختارها، تحقق منها بانتظام. النسخة الاحتياطية التي لم تختبرها قط هي نسخة لا يمكنك الوثوق بها.
الخادم المُقوَّى هو خادم يُصان باستمرار
التقوية ليست مهمة تُنجزها مرة واحدة وتنساها. إنها ممارسة مستمرة. الخدمات تتغير، وثغرات CVE جديدة تظهر، والإعدادات تنحرف مع الوقت — خاصة على الخوادم التي يتعامل معها أشخاص متعددون.
جدوِل مراجعة ربع سنوية: راجع الخدمات قيد التشغيل، وتحقق من إعدادات SSH، وتأكد من دقة قواعد جدار الحماية، وتحقق من عمل النسخ الاحتياطية. أدوات مثل lynis يمكنها أتمتة الكثير من هذا:
apt install lynis lynis audit systemيُقيّم Lynis نظامك ويُقدم توصيات محددة ومرتبة حسب الأولوية. لا يُغني عن فهم ما تفعله، لكنه فحص ممتاز للتأكد من سلامة الأمور.
الخوادم التي تُخترق هي دائماً تقريباً تلك التي لا يراقبها أحد بجدية. كن متعمداً في قراراتك، وابقَ على اطلاع دائم، وتعامل مع الأمان باعتباره جزءاً من البنية التحتية — لا فكرة لاحقة.
