Ubuntu 24.04 پر Fail2ban انسٹال کر کے SSH bots روکیں

Fail2ban درحقیقت کیا کرتا ہے

Fail2ban ایک ڈیمون ہے جو لاگز پڑھتا ہے۔ یہ آپ کے SSH authentication پیغامات پر نظر رکھتا ہے۔ مختصر عرصے میں کسی ایک پتے سے چند ناکامیوں کے بعد، یہ ایک firewall کمانڈ چلاتا ہے جو اس پتے کو کچھ دیر کے لیے بلاک کر دیتا ہے۔ یہی اس کا مکمل تصور ہے۔ یہ ایک فائل میں تقریباً تیس سطروں کی کنفیگریشن ہے۔ Ubuntu 24.04 پر انسٹالیشن ایک واحد apt کمانڈ ہے جو آپ کو کچھ بھی ایڈٹ کیے بغیر تحفظ فراہم کرتی ہے۔

یہ واضح رکھیں کہ یہ کیا ہے اور کیا نہیں۔ Fail2ban کسی کی authentication نہیں کرتا، کچھ بھی encrypt نہیں کرتا، اور ایک واحد پُرعزم لاگن کوشش کو نہیں روکتا۔ یہ صرف ایک ہی ذریعے سے آنے والی بار بار کوششوں کو روکتا ہے۔ یہ ایک شور فلٹر اور ریٹ لیمیٹر ہے، تالا نہیں۔ اس کا کام پورٹ 22 کے مسلسل بیک گراؤنڈ سکیننگ کو آپ کے CPU، بینڈوڈتھ، اور لاگ اسپیس ضائع ہونے سے روکنا ہے۔ نیز، کسی ایسے حملہ آور کو سست کرنا جسے ایک وقت میں صرف ایک پتے سے آنا پڑتا ہے۔

Fail2ban کیا تبدیل نہیں کرتا

Fail2ban تیسرا تہہ ہے، پہلا نہیں۔ اگر آپ کا سرور اب بھی SSH پاسورڈز قبول کرتا ہے، تو ہزاروں پتوں پر پھیلا کوئی بوٹ نیٹ اندازہ لگاتا رہ سکتا ہے، کیونکہ ہر پتہ آپ کی پابندی کی حد سے نیچے رہتا ہے اور کبھی اسے متاثر نہیں کرتا۔ اس کے خلاف اصل دفاع صرف کلید پر مبنی تصدیق ہے، جو کوششوں کی تعداد سے قطع نظر پاسورڈ کا اندازہ لگانا ناممکن بنا دیتا ہے۔ صرف کلید پر مبنی تصدیق کے ساتھ Fail2ban دو مفید کام کرتا ہے: یہ آپ کے لاگز سے brute-force کے شور کو صاف کرتا ہے، اور یہ اسکینرز کو جلدی بے دخل کرتا ہے تاکہ وہ پورٹ پر بار بار حملہ کرنا بند کر دیں۔ اسے گہرائی میں دفاع کے طور پر لیں۔ یہ کلید تصدیق اور فائر وال کے پیچھے ہے، ان کے آگے کبھی نہیں۔

پیش نیازات، اور Ubuntu 24.04 کی حقیقت

آپ کو ایک VPS درکار ہے جس پر Ubuntu 24.04 چل رہا ہو، جس میں root یا sudo دسترسی ہو، اور SSH پہلے سے کام کر رہا ہو — بالکل بہتر ہے کہ کلید-based توثیق پر ہو۔ Fail2ban نہایت ہلکا ہے: اسے RAM کی چند دسیوں میگا بائٹس درکار ہیں، اس میں limits کی کوئی tuning ضروری نہیں۔

اب وہ حصہ جسے ہر پرانی گائیڈ غلط بتاتی ہے۔ برسوں سے معیاری مشورہ یہ تھا کہ "Fail2ban انسٹال کریں، پھر backend = systemd شامل کریں، کیونکہ Ubuntu نے /var/log/auth.log لکھنا بند کر دیا ہے۔" یہ مشورہ ایک حقیقی تبدیلی کو بیان کرتا ہے — جدید سرور اور کلاؤڈ امیجز rsyslog کے بغیر آتے ہیں، اس لیے SSH صرف systemd journal میں لاگ کرتا ہے اور وہ ٹیکسٹ فائل موجود نہیں رہتی — لیکن Ubuntu 24.04 پر Fail2ban پیکیج پہلے ہی اس کا حساب رکھتا ہے۔ پیکیج /etc/fail2ban/jail.d/defaults-debian.conf شامل کر دیتا ہے، اور یہ فائل، نہ کہ اپ سٹریم ڈیفالٹس، وہ ہے جو آپ کا سرور دراصل چلاتا ہے:

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

[sshd]
enabled = true

اسے احتیاط سے پڑھیں، کیونکہ یہ آپ کے کچھ ہاتھ لگانے سے پہلے ہی دو سوالات حل کر دیتا ہے۔ backend = systemd کا مطلب ہے کہ SSH jail journal کو پڑھتا ہے، اس لیے غائب auth.log کوئی مسئلہ نہیں۔ banaction = nftables کا مطلب ہے کہ پابندیاں nftables کے ذریعے نافذ کی جاتی ہیں، جو Ubuntu 24.04 میں استعمال ہونے والا اصل فائر وال ہے، نہ کہ پرانا iptables۔ اور [sshd] enabled = true کا مطلب ہے کہ jail پہلے بوٹ سے ہی فعال ہے۔ نتیجہ: Ubuntu 24.04 پر ایک اسٹاک apt install fail2ban پہلے دن سے ہی SSH brute-force پر پابندی عائد کرتا ہے۔ آپ کا زیادہ تر کام اس کی تصدیق کرنا، پالیسی کو tune کرنا، اور یہ یقین بنانا ہے کہ آپ خود کو لاک آؤٹ نہیں کر لیں گے۔

پرانا auth.log جال اب بھی تین صورتحالوں میں پھنساتا ہے، اور انہیں پہچاننا مفید ہے: آپ نے Fail2ban کو apt کے بجائے pip سے انسٹال کیا، اس لیے defaults-debian.conf موجود نہیں ہے؛ آپ ایک غیر مراعات یافتہ کنٹینر کے اندر ہیں جس میں پڑھنے کے لیے کوئی systemd journal نہیں ہے؛ یا آپ نے ایک پرانا ٹیوٹوریل مانا اور backend = auto کو اپنے jail.local میں پیسٹ کر دیا، جس سے کام کرنے والا ڈیفالٹ اوور رائیڈ ہو گیا۔ فیلیر موڈز والا حصہ بتاتا ہے کہ ہر ایک کیسی نظر آتا ہے۔

مرحلہ 1: انسٹال کریں اور تصدیق کریں کہ یہ پہلے ہی پابندی عائد کر رہا ہے

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 میں Fail2ban 1.0.2 شامل ہے۔ یہ پیکیج python3-systemd کو لازمی انحصار کے طور پر نصب کرتا ہے۔ لہذا journal بیک اینڈ کو درکار سب کچھ دستیاب ہے۔ یہ سروس خود بخود فعال ہو کر چلنا شروع ہو جاتی ہے:

sudo systemctl status fail2ban

آپ کو active (running) چاہیے۔ پھر اس جیل کو دیکھیں جو پہلے ہی کام کر رہی ہے:

sudo fail2ban-client status sshd

کسی عوامی VPS پر جو چند منٹس کے لیے بھی قابل رسائی رہا ہو، آپ کو اکثر ناکامیوں کی گنتی اور پابندی لگے پتے پہلے ہی نظر آئیں گے۔ انٹرنیٹ مسلسل port 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: دوبارہ شروع کریں اور تصدیق کریں کہ یہ جرنل پڑھ رہا ہے

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

-t پہلے کنفیگریشن ٹیسٹ چلاتا ہے۔ اس لیے jail.local میں کوئی ٹائپنگ کی غلطی یہاں واضح طور پر ناکام ہو جاتی ہے۔ سروس خاموشی سے بند نہیں ہوتی۔ ایک صحت مند جیل کی حیثیت اس طرح نظر آتی ہے:

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 ہے۔ اگر یہ صفر سے زیادہ ہے، یا جب آپ کسی دوسری مشین سے جان بوجھ کر لاگ اِن ناکام کریں تو یہ بڑھتا ہے، تو جرنل پڑھا جا رہا ہے اور آپ کا کام مکمل ہے۔ اگر یہ 0 پر ہی رہے خواہ آپ کتنی ہی بار ناکام ہوں — اور آپ کو یقین ہو کہ آپ ignoreip میں موجود پتے سے ٹیسٹ نہیں کر رہے — تو نیچے دیے گئے ناکامی کے طریقوں پر جائیں۔

دھیان دیں کہ Journal matches لائن اب بھی sshd.service کا نام لیتی ہے۔ Ubuntu پر SSH یونٹ دراصل ssh.service ہے، لیکن شپ شدہ فلٹر _COMM=sshd پر بھی میچ کرتا ہے، اور 24.04 پر OpenSSH اپنی ناکامیاں 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 پرنٹ کرتا ہے، اور وہ پتہ fail2ban-client status sshd میں Banned IP list کے تحت ظاہر ہوتا ہے۔ اب تصدیق کریں کہ بلاک واقعی فائر وال میں موجود ہے۔ 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 واپس کرتا ہے۔ ہر جیل میں تمام پابندیاں ختم کرنے کے لیے:

sudo fail2ban-client unban --all

پہلے سے کھلی SSH سیشن پر انحصار نہ کریں کہ وہ آپ کو بچا لے گا: nftables پابندی مسدود پتے سے port 22 تک ہر پیکیٹ کو مسترد کرتی ہے — قائم شدہ کنکشن بھی شامل ہیں — اس لیے موجودہ سیشن پابندی لگتے ہی منجمد ہو جاتا ہے۔ اگر آپ نے خود کو مسدود کر لیا ہے اور آپ کے پاس کوئی ignoreip اندراج نہیں ہے، تو آپ پابندی ختم ہونے تک بند رہیں گے — اپنے فراہم کنندہ کے ویب کنسول (VNC یا serial) کے ذریعے بازیاب کریں، جو SSH سے نہیں گزرتا، اور یا تو bantime کا انتظار کریں یا وہاں غیر مسدود کرنے کا کمانڈ چلائیں۔

مرحلہ 7: پابندیاں مستقل اور بڑھتی ہوئی بنائیں

Fail2ban فعال پابندیاں /var/lib/fail2ban/fail2ban.sqlite3 پر ایک چھوٹے SQLite ڈیٹا بیس میں محفوظ رکھتا ہے، تاکہ وہ سروس کی دوبارہ شروعات یا سسٹم کے ریبوٹ پر برقرار رہیں؛ آپ انہیں نہیں کھوتے۔ آپ کے پہلے سے شامل کیے گئے bantime.increment سطرز ہر دہرایا جانے والے مجرم کو خود اس کے لیے بڑھتی ہوئی پریشانی میں بدل دیتے ہیں — تقریباً ایک گھنٹے سے ایک ہفتے تک دوگنا ہوتے ہوئے۔

اس کے علاوہ ایک سسٹم گیر "تین بار کی پابندی" پالیسی کے لیے، Fail2ban میں ایک recidive جیل شامل ہے جو اپنے /var/log/fail2ban.log کی نگرانی کرتا ہے اور ان تمام پتوں کو طویل پابندیاں دیتا ہے جو تمام جیلز میں بار بار پابندی کا شکار ہوئے ہوں۔ چونکہ آپ کا [DEFAULT] اب systemd بیک اینڈ استعمال کرتا ہے، اس لیے اس جیل کو واپس اسی لاگ فائل سے جوڑیں جسے پڑھنے کے لیے یہ ڈیزائن کیا گیا ہے:

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

backend = auto مع صریح logpath یہ یقینی بناتا ہے کہ recidive سادہ fail2ban.log ہی پڑھتا رہے، جہاں اس کے شمار کیے جانے والے Ban سطرز درحقیقت ظاہر ہوتے ہیں — جبکہ آپ کی عالمی سطح پر مقرر کردہ systemd ڈیفالٹ اسے جرنل کی طرف اشارہ کرے گا، جہاں وہ ظاہر نہیں ہوتے۔

مرحلہ 8: اسے صرف کلید والی SSH کے ساتھ جوڑیں، اور اس سے بہتر ایک VPN

Fail2ban صرف کلید-based تصدیق کے ساتھ ہی مؤثر ہے۔ /etc/ssh/sshd_config.d/ کے تحت ایک drop-in فائل میں — مثلاً /etc/ssh/sshd_config.d/00-hardening.conf — یہ سیٹ کریں:

PasswordAuthentication no
KbdInteractiveAuthentication no

پھر sudo systemctl restart ssh۔ پاس ورڈز بند ہونے سے brute force حملہ بالکل کامیاب نہیں ہو سکتا؛ پھر Fail2ban کا مقصد صرف لاگ کے شور کو کم کرنا اور اسکینرز کو جلدی خارج کرنا ہوتا ہے۔ اس سے بھی زیادہ مضبوط طریقہ یہ ہے کہ SSH کو عوامی انٹرنیٹ سے مکمل طور پر ہٹا دیا جائے: SSH کو ایک self-hosted WireGuard VPN کے پیچھے رکھیں اور پورٹ 22 کو فائر وال سے بند کر دیں تاکہ وہ صرف ٹنل پر ہی جواب دے۔ کوئی بھی ایسے پورٹ پر brute-force نہیں کر سکتا جس تک وہ پہنچ ہی نہیں سکتا، اور پھر Fail2ban پہلی لائن کی بجائے محض ایک بیک اپ بن جاتا ہے۔

Fail2ban صرف SSH کے لیے نہیں ہے۔ جو بھی سروس failed لاگ اِن کی لاگنگ کرتی ہے، اس کے لیے ایک jail بنایا جا سکتا ہے — چاہے وہ میل سرور ہو، ایک nginx سائٹ ہو، یا ایک self-hosted Vaultwarden پاس ورڈ منیجر جس کے ویب لاگ اِن کو آپ credential stuffing کے لیے کھلا نہیں چھوڑنا چاہتے۔ جب کوئی ویب ایپ Let's Encrypt سرٹیفکیٹ والی nginx سائٹ کے پیچھے آ جاتی ہے، تو اس کے access log کی طرف ایک Fail2ban filter اسی طرح pointing کرتا ہے جیسے SSH jail جرنل کی طرف pointing کرتا ہے۔

ناکامی کے طریقے، جن کی عین مطابق اسٹرنگز آپ دیکھیں گے

"Have not found any log file for sshd jail"، اور Fail2ban شروع نہیں ہوگا۔ یہ پرانا auth.log مسئلہ ہے، اور Ubuntu 24.04 پر آپ اس کا سامنا تب کرتے ہیں جب کسی چیز نے پیکیج کی طے شدہ ترتیب کو تبدیل کر دیا ہو — ایک ایسی pip انسٹالیشن جس میں defaults-debian.conf نہ ہو، ایک کنٹینر جس میں journal نہ ہو، یا کوئی اسٹرے backend = auto جسے آپ نے jail.local میں پیسٹ کر دیا ہو۔ ایک فائل بیک اینڈ پر جہاں /var/log/auth.log موجود نہ ہو، sshd jail اپنا log نہیں ڈھونڈ پاتا اور پورا daemon abort ہو جاتا ہے۔ fail2ban.log یہ ظاہر کرتا ہے:

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

چونکہ وہ error fatal ہے، service کبھی شروع نہیں ہوتی، اور fail2ban-client status پھر نیچے کی طرف کا علامتی نتیجہ رپورٹ کرتا ہے:

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

وہ "socket path" لائن اس کا مطلب نہیں کہ Fail2ban ٹوٹ گیا ہے — اس کا مطلب ہے کہ یہ کبھی شروع ہی نہیں ہوا کیونکہ ایک jail اپنا log نہیں ڈھونڈ سکا۔ [DEFAULT] میں backend = systemd سیٹ کرنا، جو Ubuntu پیکیج پہلے ہی آپ کے لیے کرتا ہے، دونوں پیغامات ایک ساتھ درست کر دیتا ہے۔

Jail active ہے لیکن Total failed کبھی نہیں بدلتا۔ daemon چل رہا ہے اور journal پڑھا جا رہا ہے، پھر بھی journalctl -u ssh میں اصل ناکامیاں جمع ہو رہی ہیں جبکہ کاؤنٹر 0 پر جما رہتا ہے۔ پہلے ظاہری وجہ کو خارج کریں: آپ ایک ایسے پتے سے ٹیسٹ کر رہے ہیں جو ignoreip میں درج ہے، اس لیے آپ کی اپنی ناکامیوں کو ڈیزائن کے مطابق مستثنیٰ قرار دیا گیا ہے۔ اگر یہ وجہ نہیں، تو آپ ایک OpenSSH build پر ہیں جہاں per-connection worker sshd-session ہے (9.8 اور بعد کے ورژن)، جس کا journal _COMM ہے sshd-session، نہ کہ sshd، اس لیے شپ شدہ match اسے نظر انداز کرتا ہے۔ [sshd] بلاک میں match کو وسیع کریں:

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

Restart کریں، ایسے پتے سے جان بوجھ کر login ناکام کریں جو ignoreip میں نہیں ہے، اور تصدیق کریں کہ Total failed بالآخر بڑھتا ہے۔

آپ نے خود کو ban کر لیا: Connection refused۔ آپ نے اپنا پتہ ignoreip سے باہر رکھا، کچھ غلط logins ٹیسٹ کیے، اور اب:

ssh: connect to host 10.0.0.10 port 22: Connection refused

انکار، بجائے خاموش timeout کے، nftables action کا طے شدہ reject verdict ہے جو اپنا کام کر رہا ہے — آپ پر۔ اسے Step 6 کی طرح درست کریں: کسی دوسرے، unban شدہ پتے پر موجود session سے، یا فراہم کنندہ کے کنسول سے unban کریں — ban شدہ پتے سے پہلے سے کھلی ہوئی session بھی freeze ہو جاتی ہے۔ پھر اپنا پتہ ignoreip میں شامل کریں تاکہ یہ دوبارہ نہ ہو سکے۔

Fail2ban کہتا ہے کہ ایک پتہ ban ہے، لیکن یہ اب بھی connect کر سکتا ہے۔ status sshd میں کاؤنٹر بڑھتا ہے، پھر بھی پتہ port 22 تک پہنچتا ہے۔ یہ ban-action اور firewall کے درمیان بے میل ہے، اور Ubuntu 24.04 پر یہ تقریباً ہمیشہ اس کا مطلب ہے کہ آپ نے کام کرنے والے banaction = nftables کو banaction = iptables-multiport سے تبدیل کر دیا، جسے کسی پرانے گائیڈ سے کاپی کیا تھا، ایک ایسے سسٹم پر جہاں iptables layer موجود نہیں۔ fail2ban.log یہ ظاہر کرتا ہے:

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

وہ override حذف کریں اور پیکیج شدہ nftables action کو برقرار رکھیں، یا، اگر آپ firewall مکمل طور پر ufw کے ذریعے منظم کرتے ہیں اور چاہتے ہیں کہ bans وہاں نظر آئیں، تو [DEFAULT] میں banaction = ufw سیٹ کریں۔ Restart کریں اور تصدیق کریں کہ rule sudo nft list ruleset | grep f2b کے ساتھ ظاہر ہوتا ہے۔

jail.local میں ترمیم کے بعد Fail2ban شروع نہیں ہوتا۔ ایک typo — کوئی اسٹرے heading یا ایک غلط time value — service کو شروع ہونے سے انکار کرتا ہے۔ Fail2ban سے کہیں کہ وہ چلنے سے پہلے config چیک کرے:

sudo fail2ban-client -t

یہ فائل اور jail کا نام بتاتا ہے جس میں مسئلہ ہے، مثلاً Errors in jail 'sshd'. Skipping...، تاکہ آپ اندازہ لگانے کے بجائے source کو درست کریں۔

FAQ

کیا Ubuntu 24.04 پر Fail2ban کی پیشہوار انسٹالیشن واقعی SSH حملوں کو روکتی ہے؟

ہاں۔ یہ پیکیج /etc/fail2ban/jail.d/defaults-debian.conf فراہم کرتا ہے، جو sshd جیل کو فعال کرتا ہے، backend = systemd کو اس طرح سیٹ کرتا ہے کہ یہ systemd journal پڑھتا ہے بجائے غیر موجود /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 موجود نہیں۔ یا ہو سکتا ہے آپ ایسے کنٹینر کے اندر ہوں جس میں پڑھنے کے لیے کوئی systemd journal موجود ہی نہ ہو۔ fail2ban-client status sshd میں Total failed چیک کریں: اگر journalctl -u ssh حقیقی ناکامیوں کو دکھاتے ہوئے یہ کبھی بڑھتا ہی نہیں، تو جیل غلط جگہ سے پڑھ رہی ہے۔

میں اپنے 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 کو عوامی انٹرنیٹ سے مکمل طور پر الگ رکھیں۔