تثبيت Fail2ban على Ubuntu 24.04 لإيقاف روبوتات SSH

ما يفعله Fail2ban فعلياً

Fail2ban خدمة تعمل في الخلفية وتقرأ السجلات. تراقب رسائل مصادقة SSH، وبعد تسجيل عدة محاولات فاشلة من عنوان واحد خلال فترة قصيرة، تنفّذ أمراً في الجدار الناري يحظر ذلك العنوان مؤقتاً. هذه هي الفكرة بالكامل. يتطلب ذلك نحو 30 سطراً من الإعدادات في ملف واحد، وعلى Ubuntu 24.04 يكون التثبيت عبر أمر apt واحد يوفّر الحماية قبل تعديل أي إعداد.

يجب أن تكون وظيفته وحدوده واضحة. لا ينفّذ Fail2ban المصادقة، ولا يشفّر أي شيء، ولا يوقف محاولة تسجيل دخول واحدة يصرّ عليها المهاجم، بل يوقف المحاولات المتكررة من المصدر نفسه فقط. إنه أداة لتصفية الضوضاء وتحديد معدل المحاولات، وليس قفلاً. تتمثل مهمته في منع عمليات الفحص المستمرة في الخلفية للمنفذ 22 من استهلاك وحدة المعالجة المركزية وعرض النطاق الترددي ومساحة السجلات، وإبطاء أي مهاجم يضطر إلى استخدام عنوان واحد في كل مرة.

ما لا يستبدله Fail2ban

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

المتطلبات الأساسية، وواقع Ubuntu 24.04

تحتاج إلى VPS يعمل بنظام Ubuntu 24.04، مع صلاحيات root أو sudo، وأن يكون SSH مهيأً ويعمل مسبقاً، ويفضّل استخدام المصادقة بالمفاتيح. يستهلك Fail2ban موارد قليلة: بضع عشرات من الميغابايتات من الذاكرة، ولا يتطلب ضبط حدود إضافية.

نصل الآن إلى النقطة التي تخطئ فيها الأدلة القديمة. لسنوات، كانت النصيحة المعتادة هي: «ثبّت Fail2ban، ثم أضف backend = systemd، لأن Ubuntu توقف عن كتابة /var/log/auth.log». تصف هذه النصيحة تغييراً حقيقياً؛ فصور الخوادم والسحابة الحديثة تُصدَر من دون rsyslog، لذلك يكتب SSH السجلات في systemd journal فقط، ولم يعد ذلك الملف النصي موجوداً. لكن حزمة Fail2ban في Ubuntu 24.04 تتعامل مع هذا الأمر مسبقاً. إذ تضيف الحزمة الملف /etc/fail2ban/jail.d/defaults-debian.conf، وهذا الملف، لا الإعدادات الافتراضية upstream، هو ما يشغله خادمك فعلياً:

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

اقرأ ذلك بعناية، لأنه يحسم سؤالين قبل أن تغيّر أي إعداد. يعني backend = systemd أن jail الخاص بـSSH يقرأ من journal، ولذلك لا يهم غياب auth.log. ويعني banaction = nftables أن الحظر يُطبَّق عبر nftables، وهو جدار الحماية الذي يستخدمه Ubuntu 24.04 فعلياً، بدلاً من iptables القديم. ويعني [sshd] enabled = true أن jail مفعّل منذ الإقلاع الأول. والخلاصة هي أن apt install fail2ban القياسي على Ubuntu 24.04 يحظر محاولات التخمين بالقوة الغاشمة على SSH مباشرةً. يتركّز معظم عملك على تأكيد ذلك، وضبط السياسة، والتأكد من أنك لن تمنع وصولك إلى الخادم.

لا يزال فخ auth.log القديم يظهر في ثلاث حالات، ومن المفيد التعرّف إليها: ثبّت Fail2ban باستخدام pip بدلاً من apt، ولذلك لا يوجد defaults-debian.conf؛ أو أنك تعمل داخل حاوية غير مميّزة لا يتوفر فيها systemd journal لقراءته؛ أو أنك اتبعت دليلاً قديماً ولصقت backend = auto في jail.local الخاص بك، فاستبدلت الإعداد الافتراضي العامل. يوضح قسم أوضاع الفشل الشكل الدقيق لكل حالة.

الخطوة 1: ثبّت Fail2ban وتحقق من أنه يحظر الاتصالات بالفعل

sudo apt update
sudo apt install -y fail2ban

يتضمن Ubuntu 24.04 الإصدار Fail2ban 1.0.2، وتسحب الحزمة python3-systemd باعتبارها اعتماداً إلزامياً، لذلك تتوفر في backend الخاص بـjournal جميع المكونات اللازمة. تُفعّل الخدمة نفسها وتبدأ تشغيلها:

sudo systemctl status fail2ban

تريد ظهور active (running). ثم افحص jail الذي يؤدي مهمته بالفعل:

sudo fail2ban-client status sshd

على VPS عام كان متاحاً من الإنترنت لبضع دقائق فقط، سترى غالباً أن بعض حالات الفشل قد عُدّت وأن بعض العناوين قد حُظرت، لأن الإنترنت يفحص المنفذ 22 باستمرار. هذا يثبت أن الإعداد الافتراضي يعمل. من هنا ستُحسّنه، لا أنشئه من الصفر.

الخطوة 2: عدّل jail.local، ولا تعدّل jail.conf مطلقاً

يحتفظ Fail2ban بالإعدادات الافتراضية التي يوفرها المشروع الأصلي في /etc/fail2ban/jail.conf. لا تعدّل هذا الملف. يمكن لأي apt upgrade من الحزمة استبداله، فتختفي تغييراتك دون أي تحذير. يقرأ Fail2ban الملفات بترتيب ثابت: jail.conf أولاً، ثم كل ما في jail.d/، ثم jail.local، وتكون الأولوية للقيمة الأخيرة. ملف .local مخصص لك، ولا تلمسه تحديثات الحزمة مطلقاً. وتنطبق القاعدة نفسها على المرشحات، إذ يتجاوز ملف *.local الملف filter.d/*.conf الذي توفره الحزمة.

لذلك، أنشئ jail.local صغيراً يتجاوز الإعدادات القليلة التي تهمك فقط، واترك كلاً من jail.conf وjail.d/defaults-debian.conf المضمّن في الحزمة دون تعديل، لاستخدامهما كمرجع.

الخطوة 3: اكتب الملف /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

أضف المحتوى التالي، وغيّر العنوان في السطر ignoreip إلى عنوان IP العام الخاص بك:

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

كل سطر له وظيفة محددة:

• تحدد bantime وfindtime وmaxretry السياسة. القيمة الافتراضية المضمّنة bantime هي عشر دقائق فقط؛ وتُعد ساعة واحدة حداً أدنى أكثر ملاءمة. تؤدي خمس محاولات فاشلة من عنوان واحد خلال عشر دقائق إلى الحظر. قد يخطئ المستخدم الحقيقي في كتابة كلمة المرور مرة أو مرتين، أما خمس محاولات فاشلة خلال عشر دقائق فتشير إلى برنامج نصي.
• ignoreip هو إجراء الأمان الخاص بك. أضف هنا العنوان العام الذي تتصل منه، حتى لا يتمكن Fail2ban من حظرك خارج خادمك. إذا كان اتصال المنزل يستخدم عنوان IP متغيراً، فهذا سبب لتفضيل نهج VPN الوارد في النهاية، وليس سبباً لتجاوز هذا السطر.
• تجعل bantime.increment = true مدة كل حظر متكرر أطول من السابق: ساعة واحدة، ثم ساعتان، ثم أربع ساعات، وصولاً إلى bantime.maxtime. تُحظر العناوين التي تستمر في العودة تدريجياً لمدة أطول.

اعرف العنوان الذي تريد إضافته إلى قائمة السماح من الجهاز الذي تتصل منه عبر SSH، وليس من الخادم:

curl -s ifconfig.me

يمكنك إنشاء jail.local مضبوطاً وفق المنافذ وسياسة الحظر لديك هنا، ثم لصقه في الملف:

الخطوة 4: أعد التشغيل وتحقق من قراءة journal

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

يشغّل -t اختباراً للإعداد أولاً، لذلك يفشل أي خطأ مطبعي في jail.local بوضوح هنا بدلاً من ترك الخدمة متوقفة. تبدو حالة jail السليمة كما يلي:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   10.0.0.66

الرقم الذي يثبت أن Fail2ban يقرأ فعلياً سجلات تسجيل الدخول هو Total failed. إذا كان أكبر من الصفر، أو ازداد عند تعمّد فشل تسجيل دخول من جهاز آخر، فهذا يعني أن journal تُقرأ، وقد انتهيت. إذا بقي عند 0 مهما كررت فشل تسجيل الدخول، وكنت متأكداً من أنك لا تختبر من العنوان الموجود في ignoreip، فانتقل إلى أوضاع الفشل أدناه.

لاحظ أن السطر Journal matches لا يزال يذكر sshd.service. في Ubuntu، وحدة SSH هي فعلياً ssh.service، لكن المرشح المضمّن يطابق أيضاً _COMM=sshd، ويسجّل OpenSSH في 24.04 حالات الفشل من عملية باسم sshd، لذلك تنجح المطابقة. لا تهم هذه التفاصيل إلا إذا كنت تستخدم OpenSSH أحدث، بإصدار 9.8 أو أحدث، حيث تكون عملية العامل الخاصة بكل اتصال هي sshd-session؛ وتغطي أوضاع الفشل هذه الحالة.

الخطوة 5: راقب تنفيذ حظر فعلي أو نفّذ حظراً للاختبار

تصل حالات الحظر الفعلية تلقائياً خلال دقائق في أي VPS عام. لمراقبة إحدى هذه الحالات، اعرض نهاية السجل باستمرار:

sudo tail -f /var/log/fail2ban.log

يظهر الحظر بهذا الشكل:

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 10.0.0.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 10.0.0.66

لاختبار العملية كاملة من دون انتظار، احظر عنواناً مخصصاً للتوثيق يدوياً، ولا تستخدم عنوانك أبداً:

sudo fail2ban-client set sshd banip 10.0.0.66

يعرض الأمر 1، ويظهر العنوان ضمن Banned IP list في fail2ban-client status sshd. تأكد الآن من وجود الحظر فعلياً في جدار الحماية. في Ubuntu 24.04، تكون الأداة هي nftables وليس iptables:

sudo nft list table inet f2b-table

سترى مجموعة باسم addr-set-sshd تحتوي على 10.0.0.66، وسلسلة باسم f2b-chain ترفض أي مصدر موجود في تلك المجموعة. إذا أظهر fail2ban-client أن العنوان محظور، لكن لم يظهر شيء في nft list، فإن إجراء الحظر لا يتوافق مع جدار الحماية لديك. راجع ملاحظة nftables/iptables في قسم أوضاع الفشل.

الخطوة 6: أزل الحظر عن نفسك واستعد الوصول إذا مُنعت منه

إذا حظرت عنواناً لا ينبغي حظره، مثل عنوانك، فأزله:

sudo fail2ban-client set sshd unbanip 10.0.0.66

يعرض 1 عند النجاح. لمسح جميع حالات الحظر في جميع jail:

sudo fail2ban-client unban --all

لا تعتمد على جلسة SSH مفتوحة مسبقاً لإنقاذك. يرفض حظر nftables كل حزمة من العنوان المحظور إلى المنفذ 22، بما في ذلك الاتصالات القائمة، لذلك تتجمد الجلسة الحالية فور تطبيق الحظر. إذا حظرت نفسك ولم يكن لديك إدخال ignoreip، فستُمنع من الوصول حتى تنتهي مدة الحظر. استعد الوصول عبر وحدة تحكم الويب لدى مزود الخدمة، مثل VNC أو وحدة التحكم التسلسلية، لأنها لا تمر عبر SSH، ثم انتظر حتى انتهاء bantime أو شغّل أمر إزالة الحظر من هناك.

الخطوة 7: اجعل عمليات الحظر مستمرة ومتزايدة

يحتفظ Fail2ban بعمليات الحظر النشطة في قاعدة بيانات SQLite صغيرة في /var/lib/fail2ban/fail2ban.sqlite3، لذلك تبقى بعد إعادة تشغيل الخدمة أو إعادة تشغيل النظام؛ ولن تفقدها. تجعل أسطر bantime.increment التي أضفتها كلَّ مصدر متكرر للمخالفات يواجه مشكلة تتصاعد ضده، إذ تتضاعف المدة تقريباً من ساعة واحدة حتى نحو أسبوع.

لتطبيق سياسة «ثلاث مخالفات» على مستوى النظام، يوفّر Fail2ban jail باسم recidive يراقب /var/log/fail2ban.log الخاص به، ويطبّق عمليات حظر طويلة على أي عنوان تكررت عمليات حظره عبر جميع jails. وبما أنّ [DEFAULT] يستخدم الآن الواجهة الخلفية systemd، ثبّت هذا jail على ملف السجل المصمم لقراءته:

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

يُبقي backend = auto مع logpath الصريح recidive يقرأ fail2ban.log العادي، وهو المكان الذي تظهر فيه أسطر Ban التي يحسبها فعلياً؛ أما إعداد systemd الافتراضي الذي ضبطته عالمياً فسيشير إلى journal، حيث لا تظهر هذه الأسطر.

الخطوة 8: اربطه بمصادقة SSH باستخدام المفاتيح فقط، والأفضل عبر VPN

لا تكون فائدة Fail2ban كاملة إلا عند استخدام مصادقة المفاتيح. في ملف إعدادات إضافي ضمن /etc/ssh/sshd_config.d/، وليكن /etc/ssh/sshd_config.d/00-hardening.conf، اضبط ما يلي:

PasswordAuthentication no
KbdInteractiveAuthentication no

ثم sudo systemctl restart ssh. عند تعطيل كلمات المرور، لا يمكن لهجمات التخمين بالقوة الغاشمة أن تنجح إطلاقاً؛ ويصبح دور Fail2ban عندها تقليل ضجيج السجلات وحظر أدوات الفحص مبكراً. والأفضل من ذلك إبقاء SSH خارج الإنترنت العام تماماً: ضع SSH خلف VPN ذاتي الاستضافة باستخدام WireGuard واضبط جدار الحماية بحيث لا يستجيب المنفذ 22 إلا عبر النفق. لا يستطيع أحد تنفيذ هجوم تخمين بالقوة الغاشمة على منفذ لا يمكنه الوصول إليه، ويصبح Fail2ban إجراءً احتياطياً بدلاً من خط الدفاع الأول.

لا يقتصر استخدام Fail2ban على SSH. يمكن لأي خدمة تسجّل محاولات تسجيل الدخول الفاشلة أن تستخدم jail، مثل خادم البريد أو موقع nginx أو مدير كلمات المرور Vaultwarden ذاتي الاستضافة الذي قد تفضّل عدم ترك تسجيل الدخول إليه عبر الويب مفتوحاً لهجمات حشو بيانات الاعتماد. بعد وضع تطبيق الويب خلف موقع nginx مزوّد بشهادة Let's Encrypt، وجّه مرشح Fail2ban إلى سجل الوصول الخاص به بالطريقة نفسها التي يوجّه بها jail الخاص بـSSH إلى journal.

أوضاع الفشل، مع السلاسل النصية الدقيقة التي ستظهر لك

"Have not found any log file for sshd jail"، ولن يبدأ Fail2ban. هذه هي مشكلة auth.log القديمة. في Ubuntu 24.04 لن تواجهها إلا إذا تجاوز شيء ما الإعداد الافتراضي المضمّن في الحزمة، أو ثبّتَّ pip من دون defaults-debian.conf، أو كنت تستخدم حاوية بلا journal، أو أضفت backend = auto زائداً إلى jail.local. عند استخدام backend يعتمد على الملفات من دون /var/log/auth.log، لا يستطيع jail الخاص بـ sshd العثور على سجله، ويتوقف daemon بالكامل. يعرض fail2ban.log ما يلي:

ERROR   Failed during configuration: Have not found any log file for sshd jail

لأن هذا الخطأ قاتل، لا تبدأ الخدمة أبداً. ثم يعرض fail2ban-client status العرض الناتج عن ذلك:

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

لا يعني سطر "socket path" أن Fail2ban معطّل. بل يعني أنه لم يبدأ لأن أحد jail لم يتمكن من العثور على سجله. يؤدي ضبط backend = systemd في [DEFAULT]، وهو ما تفعله حزمة Ubuntu مسبقاً، إلى إصلاح الرسالتين معاً.

Jail نشط، لكن Total failed لا يتغير أبداً. يعمل daemon وتتم قراءة journal، لكن الإخفاقات الفعلية تتراكم في journalctl -u ssh، بينما يبقى العداد عند 0. استبعد أولاً السبب الواضح: أنت تختبر من عنوان مدرج في ignoreip، ولذلك تُستثنى إخفاقاتك عمداً. إذا لم يكن هذا هو السبب، فأنت تستخدم إصدار OpenSSH يكون فيه العامل لكل اتصال sshd-session (9.8 والإصدارات الأحدث). وفي هذا الإصدار تكون قيمة _COMM في journal هي sshd-session، لا sshd، ولذلك لا يطابقها النمط المضمّن في الحزمة. وسّع المطابقة في كتلة [sshd]:

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

أعد التشغيل، وأجرِ محاولة تسجيل دخول فاشلة عمداً من عنوان غير مدرج في ignoreip، ثم تأكد من أن Total failed بدأ بالارتفاع.

حظرت عنوانك: Connection refused. تركت عنوانك خارج ignoreip، واختبرت عدة محاولات تسجيل دخول فاشلة، والآن يظهر ما يلي:

ssh: connect to host 10.0.0.10 port 22: Connection refused

سبب الرفض، بدلاً من انتهاء المهلة بصمت، هو أن الإجراء الخاص بـ nftables طبّق verdict reject الافتراضي عليك. أصلح ذلك كما هو موضح في الخطوة 6: ألغِ الحظر من جلسة على عنوان مختلف وغير محظور، أو من وحدة تحكم مزود الخدمة. كما أن الجلسة المفتوحة مسبقاً من العنوان المحظور ستتجمد. بعد ذلك أضف عنوانك إلى ignoreip حتى لا يتكرر الأمر.

يقول Fail2ban إن العنوان محظور، لكنه لا يزال يستطيع الاتصال. يرتفع العداد في status sshd، ومع ذلك لا يزال العنوان يصل إلى المنفذ 22. هذه حالة عدم توافق بين إجراء الحظر والجدار الناري. في Ubuntu 24.04، يعني ذلك في الغالب أنك تجاوزت الإجراء العامل banaction = nftables بإعداد banaction = iptables-multiport منسوخ من دليل قديم، على خادم لا يحتوي على طبقة iptables. يعرض fail2ban.log ما يلي:

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

احذف ذلك التجاوز واترك إجراء nftables المضمّن في الحزمة كما هو. أو، إذا كنت تدير الجدار الناري بالكامل عبر ufw وتريد أن تظهر عمليات الحظر فيه، فاضبط banaction = ufw في [DEFAULT]. أعد التشغيل، ثم تأكد من ظهور القاعدة باستخدام sudo nft list ruleset | grep f2b.

لن يبدأ Fail2ban بعد تعديل jail.local. قد تؤدي غلطة مطبعية، أو عنوان قسم زائد، أو قيمة زمنية غير صحيحة إلى رفض الخدمة للبدء. اطلب من Fail2ban التحقق من الإعداد قبل تشغيله:

sudo fail2ban-client -t

سيذكر الملف و jail الذي يحتوي على المشكلة، مثل Errors in jail 'sshd'. Skipping...، لكي تصلح المصدر بدلاً من التخمين.

FAQ

هل يحظر تثبيت Fail2ban الافتراضي على Ubuntu 24.04 هجمات SSH فعلاً؟

نعم. تتضمن الحزمة /etc/fail2ban/jail.d/defaults-debian.conf، الذي يفعّل jail ‏sshd، ويضبط backend = systemd لكي يقرأ journal الخاص بـsystemd بدلاً من /var/log/auth.log المفقود، ويضبط banaction = nftables لكي تُفرض عمليات الحظر عبر جدار الحماية الفعلي في Ubuntu. يحمي apt install fail2ban العادي SSH منذ أول إقلاع. أكّد ذلك باستخدام sudo fail2ban-client status sshd وابحث عن قيمة غير صفرية في Total failed.

لماذا لا يحظر Fail2ban أي شيء على خادمي؟

استبعد الأسباب الشائعة الثلاثة بالترتيب. قد تكون تختبر من عنوان موجود في ignoreip، وهو مستثنى عن قصد. وقد تكون قد عطّلت الإعداد الافتراضي العامل بلصق backend = auto في jail.local استناداً إلى دليل قديم، ما يمنع قراءة journal على صورة لا تحتوي على auth.log. أو قد تكون داخل حاوية لا يتوفر فيها journal الخاص بـsystemd للقراءة أصلاً. افحص Total failed في fail2ban-client status sshd: إذا لم ترتفع قيمته مطلقاً بينما يعرض journalctl -u ssh إخفاقات فعلية، فإن jail يقرأ من المكان الخطأ.

كيف ألغي حظر عنوان IP الخاص بي؟

شغّل sudo fail2ban-client set sshd unbanip YOUR.IP.HERE، الذي يعرض 1 عند النجاح، أو استخدم sudo fail2ban-client unban --all لمسح جميع عمليات الحظر. إذا مُنعت من الوصول إلى SSH، فاستخدم وحدة التحكم على الويب أو وحدة VNC التي يوفرها مزود الخدمة لتشغيل الأمر نفسه؛ إذ يرفض الحظر كل حزمة من عنوانك إلى المنفذ 22، لذلك تتوقف حتى الجلسة المفتوحة مسبقاً عن العمل. ثم أضف عنوانك إلى ignoreip حتى لا يتكرر حظره.

ما الفرق بين jail.conf و jail.local؟

يحتوي jail.conf على الإعدادات الافتراضية التي يوفرها Fail2ban، ويُستبدل في كل ترقية للحزمة، لذلك يضيع أي تعديل فيه في النهاية. تضع حزمة Debian/Ubuntu إعداداتها الخاصة فوق ذلك عبر jail.d/defaults-debian.conf. يجب وضع تغييراتك في jail.local، الذي يُقرأ أخيراً وتتغلب إعداداته على الملفين معاً، ولا تلمسه الترقيات. اترك jail.conf كمرجع للقراءة فقط.

هل يستبدل Fail2ban مصادقة SSH المستندة إلى المفاتيح؟

لا. يحد Fail2ban معدل الإخفاقات المتكررة من عنوان واحد؛ لكنه لا يتعامل مع التخمين البطيء والموزع عندما يبقى كل عنوان دون الحد المسموح. تجعل المصادقة باستخدام المفاتيح فقط (PasswordAuthentication no) تخمين كلمات المرور مستحيلاً تماماً، ثم يقلل Fail2ban ضوضاء السجلات ويطرد أدوات الفحص مبكراً. استخدم الطريقتين، ويفضل أن تُبقي SSH خارج الإنترنت العام بالكامل.