أحمد حايس
الرئيسيةمن أناالدوراتالمدونةالعروض
أحمد حايس

دورات عربية متخصصة في التقنية والبرمجة والذكاء الاصطناعي.

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

تعلم أسرعوصول مباشر للدورات والمسارات من الموبايل.
تنقل أوضحالروابط الأساسية والدعم في مكان واحد بدون تشتيت.

المنصة

  • الرئيسية
  • من أنا
  • الدورات
  • العروض
  • المدونة

الدعم

  • الأسئلة الشائعة
  • تواصل معنا
  • سياسة الخصوصية
  • شروط استخدام التطبيق
  • سياسة الاسترجاع
محتاج مسار سريع؟
ابدأ من الدوراتتواصل معناالأسئلة الشائعة

© 2026 أحمد حايس. جميع الحقوق محفوظة.

الرئيسيةالدوراتالعروضالمدونةالدخول

Fail2ban للـ SSH: اقفل الباب قبل ما البوتات تملأ اللوج

📅 ٢٦ أبريل ٢٠٢٦⏱ 5 دقائق قراءة
Fail2ban للـ SSH: اقفل الباب قبل ما البوتات تملأ اللوج

Fail2ban للـ SSH: اقفل الباب قبل ما البوتات تملأ اللوج

هتخرج من المقال بإعداد عملي يقلل محاولات SSH الفاشلة من آلاف السطور في الساعة لعشرات قليلة، بدون ما تغيّر بورت SSH لمجرد الإحساس بالأمان.

مستوى القارئ: متوسط

المشكلة باختصار

لو عندك VM عامة على الإنترنت، أول حاجة هتحصل غالبًا إن بوتات كتير هتجرّب الدخول على SSH. اللي بيحصل فعلاً إن اللوج يمتلئ بمحاولات أسماء مستخدمين عشوائية، ووقت التحقيق في حادثة بسيطة يتحول لفرز آلاف السطور.

الافتراض هنا إن عندك Ubuntu أو Debian VM، وSSH مفتوح للإدارة، وعدد الأدمن قليل. السيناريو الواقعي: سيرفر صغير يستقبل 3200 محاولة فاشلة في الساعة على بورت 22. بعد Fail2ban بإعداد محافظ، الرقم ممكن ينزل لحوالي 85 محاولة ظاهرة في الساعة لأن العناوين المزعجة بتتحظر بسرعة. الرقم تقديري للتوضيح، ولازم تقيسه على لوجاتك.

مخطط يوضح مسار محاولات SSH الفاشلة من البوت إلى Fail2ban ثم حظر العنوان في الجدار الناري

الفكرة بمثال بسيط

ركز في المثال ده. عندك باب مكتب عليه حارس. أول محاولة بكلمة سر غلط مش معناها إن الشخص خطر. لكن لو نفس الشخص جرّب 5 مرات في 10 دقائق، الحارس يمنعه من الوقوف أمام الباب لمدة ساعة. Fail2ban بيعمل نفس الفكرة، لكن بدل الحارس بيقرأ لوج SSH، وبدل منعه بالكلام بيضيف rule في firewall.

علميًا، Fail2ban بيراقب ملفات اللوج أو systemd journal بفلاتر جاهزة. لما عدد الأحداث المطابقة يتجاوز maxretry داخل نافذة findtime، ينفذ banaction مثل حظر IP عبر nftables أو iptables. هو مش بديل لمفاتيح SSH، لكنه طبقة تقليل ضرر ممتازة.

الإعداد العملي على Ubuntu

ابدأ بالإعداد المحافظ. لا تعدّل jail.conf مباشرة لأنه ممكن يتغير مع تحديثات الحزمة. استخدم ملف تحت jail.d بالظبط.

Bash
sudo apt update
sudo apt install -y fail2ban

sudo tee /etc/fail2ban/jail.d/sshd-hardening.local > /dev/null <<'EOF'
[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
bantime.increment = true
ignoreip = 127.0.0.1/8 ::1 YOUR_OFFICE_IP
EOF

sudo systemctl enable --now fail2ban
sudo fail2ban-client reload
sudo fail2ban-client status sshd

لو السيرفر بيستخدم nftables حديثًا، اترك Fail2ban يختار الإجراء الافتراضي من توزيعك الأول. لو احتجت تحديده لاحقًا، اختبر banaction على staging قبل الإنتاج. أفضل طريقة هنا إنك تبدأ بأقل تغيير ثم تقيس.

اقفل SSH نفسه قبل ما تعتمد على الحظر

الطريقة الشائعة الغلط هي تثبيت Fail2ban فقط وترك تسجيل الدخول بكلمة سر مفتوح. الطريقة دي بتفشل لأن أي IP جديد يقدر يجرّب قبل ما يتحظر. البديل: خلي SSH يقبل المفاتيح، قلل محاولات المصادقة، واقفل root login.

Bash
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

sudo tee /etc/ssh/sshd_config.d/20-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
MaxAuthTries 3
LoginGraceTime 30
EOF

sudo sshd -t
sudo systemctl reload ssh

مهم: افتح جلسة SSH ثانية قبل تنفيذ reload، وجرب الدخول بمفتاحك. لا تقفل الجلسة القديمة إلا بعد ما تتأكد. الـ trade-off هنا واضح: بتكسب تقليل سطح الهجوم وضوضاء اللوج، وبتخسر سهولة الدخول السريع بكلمة سر من جهاز جديد.

قياس قبل وبعد

متنشرش الإعداد وتفترض إنه اشتغل. قِس عدد المحاولات الفاشلة قبل وبعد، وراجع العناوين المحظورة. مثال سريع:

Bash
# آخر ساعة من محاولات SSH الفاشلة على systemd
sudo journalctl -u ssh --since "1 hour ago" | grep -c "Failed password" || true

# حالة jail وعدد العناوين المحظورة
sudo fail2ban-client status sshd

# آخر قرارات Fail2ban
sudo journalctl -u fail2ban --since "1 hour ago" --no-pager
رسم أعمدة يقارن محاولات SSH الفاشلة في الساعة قبل وبعد تفعيل Fail2ban

لو شفت بان كتير جدًا لعناوين شرعية، زوّد maxretry أو أضف IP المكتب في ignoreip. لو مفيش أي بان رغم وجود محاولات، غالبًا backend أو اسم خدمة SSH مختلف عندك: بعض التوزيعات تستخدم ssh وبعضها sshd.

الـ trade-offs وما يجب الانتباه له

  • Fail2ban يقلل الضوضاء، لكنه لا يمنع كل هجوم. البوتات الموزعة ممكن تستخدم IP جديد لكل محاولة.
  • الحظر الطويل يحميك أكثر، لكنه يعاقب الأخطاء البشرية. لو أدمن نسي المفتاح أو بيشتغل من شبكة متغيرة، ساعة ban ممكن تعطل شغله.
  • إغلاق PasswordAuthentication أقوى من تغيير البورت. تغيير البورت يقلل الضوضاء فقط، لكن كلمة السر الضعيفة تظل مشكلة.
  • ignoreip مفيد وخطر. لا تضف رينج واسع مثل شبكة VPN كاملة إلا لو واثق من التحكم فيها.

متى لا تستخدم هذه الطريقة

لا تستخدم Fail2ban كحل رئيسي لو عندك عشرات الأدمن أو دخول من شبكات غير متوقعة؛ استخدم VPN أو bastion host أو SSO-aware access proxy. لا تستخدمه وحده لو السيرفر عليه بيانات حساسة جدًا؛ ابدأ بعزل SSH خلف شبكة خاصة. ولا تعتمد عليه لو اللوجات نفسها لا تصل لـ systemd أو ملف auth.log بشكل ثابت.

مصادر اعتمدت عليها

  • Fail2ban jail.conf reference لتفضيل ملفات .local وخيارات bantime وmaxretry.
  • OpenSSH sshd_config manual لخيارات PasswordAuthentication وPubkeyAuthentication وMaxAuthTries.
  • jail.conf manual page لفكرة الـ jails والقيم التي تتحكم في الحظر.

الخطوة التالية

الخطوة التالية: شغّل أوامر القياس لمدة ساعة قبل التغيير، طبّق sshd-hardening.local، ثم قارن عدد محاولات SSH الفاشلة بعد ساعة. لو الرقم ما نزلش، أصلح backend قبل ما تزود مدة الحظر.

هل استفدت من المقال؟

اطّلع على المزيد من المقالات والدروس المجانية من نفس المسار المعرفي.

تصفّح المدونة