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

Fail2ban اصل میں کیا کرتا ہے

Fail2ban لاگ پڑھنے والا daemon ہے۔ یہ آپ کے SSH authentication messages کی نگرانی کرتا ہے اور مختصر مدت کے اندر کسی ایک address سے متعدد ناکام کوششیں ہونے کے بعد firewall command چلاتا ہے، جو اس address کو کچھ وقت کے لیے block کر دیتی ہے۔ یہی اس کا بنیادی کام ہے۔ اس کی configuration ایک file میں تقریباً 30 سطروں پر مشتمل ہوتی ہے، اور Ubuntu 24.04 پر installation کے لیے صرف ایک apt command درکار ہوتی ہے۔ اس command کے بعد آپ نے کوئی configuration تبدیل کیے بغیر بھی تحفظ حاصل کر لیا ہوتا ہے۔

یہ واضح رکھیں کہ Fail2ban کیا ہے اور کیا نہیں ہے۔ Fail2ban کسی کو authenticate نہیں کرتا، کسی چیز کو encrypt نہیں کرتا، اور ایک ہی login attempt کو نہیں روکتا۔ یہ صرف ایک ہی source سے بار بار ہونے والی کوششوں کو روکتا ہے۔ یہ noise filter اور rate limiter ہے، lock نہیں۔ اس کا کام port 22 کی مسلسل background scanning کو آپ کے CPU، bandwidth اور log space ضائع کرنے سے روکنا ہے۔ یہ ایسے attacker کو بھی سست کرتا ہے جسے ہر بار ایک ہی address سے کوشش کرنی پڑتی ہے۔

Fail2ban کس چیز کا متبادل نہیں ہے

Fail2ban تیسری حفاظتی تہہ ہے، پہلی نہیں۔ اگر آپ کا سرور اب بھی SSH passwords قبول کرتا ہے تو ہزاروں addresses پر پھیلا ہوا botnet اندازے لگاتا رہ سکتا ہے، کیونکہ ہر address آپ کی ban threshold سے نیچے رہتا ہے اور اسے فعال نہیں کرتا۔ اس کے خلاف حقیقی دفاع key-only authentication ہے۔ اس سے password guessing ناممکن ہو جاتی ہے، چاہے کوئی بھی کتنی ہی کوششیں کرے۔ key-only auth کے اوپر Fail2ban دو مفید کام کرتا ہے: یہ آپ کے logs سے brute-force شور کم کرتا ہے، اور scanners کو ابتدا ہی میں خارج کر دیتا ہے تاکہ وہ port پر بار بار کوشش نہ کریں۔ اسے defence in depth کا حصہ سمجھیں۔ یہ key authentication اور firewall کے پیچھے کام کرتا ہے، ان کے سامنے نہیں۔

شرائطِ ضروریات، اور Ubuntu 24.04 کی صورتِ حال

آپ کو Ubuntu 24.04 چلانے والا VPS درکار ہے، جس پر root یا sudo دستیاب ہو اور SSH پہلے سے کام کر رہا ہو۔ بہتر ہے کہ key authentication استعمال ہو۔ Fail2ban کم وسائل استعمال کرتا ہے: RAM کے چند دسیوں MB کافی ہیں، اور limits کی tuning ضروری نہیں۔

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

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

[sshd]
enabled = true

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

پرانا auth.log مسئلہ اب بھی 3 صورتوں میں سامنے آتا ہے، اس لیے انہیں پہچاننا ضروری ہے: آپ نے Fail2ban کو pip کے بجائے apt کے ذریعے انسٹال کیا، اس لیے defaults-debian.conf موجود نہیں؛ آپ ایک ایسے unprivileged container کے اندر ہیں جہاں پڑھنے کے لیے systemd journal موجود نہیں؛ یا آپ نے پرانی tutorial پر عمل کرتے ہوئے backend = auto کو اپنی jail.local میں paste کر دیا، جس سے درست default override ہو گیا۔ failure-modes section میں ہر صورت کی واضح شکل دکھائی گئی ہے۔

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

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 کے ساتھ Fail2ban 1.0.2 جاری ہوتا ہے، اور package میں python3-systemd کو لازمی dependency کے طور پر شامل کیا جاتا ہے، اس لیے journal backend کے پاس درکار تمام چیزیں موجود ہیں۔ service خود enable اور start ہو جاتی ہے:

sudo systemctl status fail2ban

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

sudo fail2ban-client status sshd

ایسے public VPS پر جو چند منٹ سے بھی accessible ہو، عموماً آپ کو پہلے ہی failures کی گنتی اور banned addresses نظر آئیں گے، کیونکہ internet مسلسل port 22 کو scan کرتا ہے۔ اس سے ثابت ہوتا ہے کہ stock config درست کام کرتی ہے۔ اس مرحلے سے آپ اسے بہتر بنا رہے ہیں، نہ کہ صفر سے تیار کر رہے ہیں۔

مرحلہ 2: jail.local میں ترمیم کریں، jail.conf میں نہیں

Fail2ban اپنی upstream default settings /etc/fail2ban/jail.conf میں رکھتا ہے۔ اس فائل میں ترمیم نہ کریں۔ پیکیج کی ہر apt upgrade اسے تبدیل کر سکتی ہے، اور آپ کی تبدیلیاں بغیر کسی warning کے ختم ہو سکتی ہیں۔ Fail2ban فائلیں ایک مقررہ ترتیب سے پڑھتا ہے: پہلے jail.conf، پھر jail.d/ میں موجود تمام فائلیں، اور آخر میں jail.local۔ آخر میں پڑھی جانے والی value نافذ ہوتی ہے۔ .local فائل آپ کے استعمال کے لیے ہے، اور package upgrades اسے کبھی تبدیل نہیں کرتے۔ یہی اصول filters پر بھی لاگو ہوتا ہے، جہاں *.local فائل فراہم کردہ filter.d/*.conf کو override کرتی ہے۔

اس لیے ایک چھوٹی jail.local فائل بنائیں، جس میں صرف وہ چند settings override ہوں جن کی آپ کو ضرورت ہے، اور jail.conf اور package کی فراہم کردہ jail.d/defaults-debian.conf دونوں کو reference کے طور پر بغیر ترمیم کے رہنے دیں۔

مرحلہ 3: /etc/fail2ban/jail.local لکھیں

sudo nano /etc/fail2ban/jail.local

اسے فائل میں شامل کریں۔ ignoreip والی لائن میں address کو اپنے public 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 پالیسی متعین کرتے ہیں۔ فراہم کردہ default bantime صرف دس منٹ ہے؛ ایک گھنٹہ زیادہ مناسب کم از کم مدت ہے۔ دس منٹ کے اندر ایک address سے پانچ ناکام کوششیں ban کے لیے کافی ہیں۔ حقیقی صارف password ایک یا دو بار غلط لکھ سکتے ہیں؛ دس منٹ میں پانچ ناکامیاں کسی script کی علامت ہیں۔
• ignoreip آپ کا safety belt ہے۔ یہاں وہ public address درج کریں جس سے آپ connect کرتے ہیں، تاکہ Fail2ban آپ کو اپنے ہی server سے کبھی lock out نہ کر سکے۔ اگر home connection کا IP تبدیل ہوتا رہتا ہے تو آخر میں دیے گئے VPN طریقے کو ترجیح دیں؛ اس لائن کو چھوڑنے کی یہ وجہ نہیں ہے۔
• bantime.increment = true ہر بار لگنے والے ban کی مدت پچھلے ban سے زیادہ کر دیتا ہے: پہلے ایک گھنٹہ، پھر دو، پھر چار، یہاں تک کہ bantime.maxtime تک۔ جو addresses بار بار واپس آتے ہیں، انہیں بتدریج زیادہ دیر کے لیے lock out کر دیا جاتا ہے۔

whitelist کے لیے address اس machine سے معلوم کریں جس سے آپ SSH کرتے ہیں، server سے نہیں:

curl -s ifconfig.me

آپ یہاں اپنے ports اور ban policy کے مطابق تیار کردہ jail.local بنا سکتے ہیں، پھر اسے فائل میں paste کریں:

مرحلہ 4: اسے restart کریں اور تصدیق کریں کہ یہ journal پڑھ رہا ہے

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

-t پہلے config test چلاتا ہے، اس لیے jail.local میں typo یہاں واضح طور پر failure پیدا کرتی ہے، بجائے اس کے کہ service خاموشی سے بند رہے۔ درست jail status کچھ یوں دکھائی دیتا ہے:

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

آپ کی login attempts کو Fail2ban واقعی پڑھ رہا ہے، اس کا ثبوت دینے والی تعداد Total failed ہے۔ اگر یہ صفر سے زیادہ ہو، یا آپ کسی دوسری machine سے جان بوجھ کر login failure پیدا کریں تو بڑھ جائے، تو journal پڑھا جا رہا ہے اور آپ کا کام مکمل ہے۔ اگر یہ متعدد failures کے باوجود 0 پر برقرار رہے، اور آپ کو یقین ہو کہ آپ ignoreip میں موجود address سے testing نہیں کر رہے، تو نیچے دیے گئے failure modes دیکھیں۔

غور کریں کہ Journal matches لائن اب بھی sshd.service کا نام دیتی ہے۔ Ubuntu پر SSH unit دراصل ssh.service ہے، لیکن فراہم کردہ filter _COMM=sshd سے بھی match کرتا ہے، اور OpenSSH on 24.04 اپنی failures کو sshd نامی process سے log کرتا ہے، اس لیے match کام کرتا ہے۔ یہ تفصیل صرف اس صورت میں اہم ہے جب آپ نیا OpenSSH استعمال کر رہے ہوں، یعنی 9.8 یا بعد کا، جہاں فی connection worker sshd-session ہے؛ failure modes میں اس صورت کا احاطہ کیا گیا ہے۔

مرحلہ 5: حقیقی ban دیکھیں، یا جانچ کے لیے خود ایک ban لگائیں

کسی بھی public VPS پر حقیقی bans چند منٹ میں خود ظاہر ہو جاتے ہیں۔ کسی ban کو دیکھنے کے لیے log کو مسلسل monitor کریں:

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

ban اس طرح دکھائی دیتا ہے:

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

انتظار کیے بغیر پورے طریقۂ کار کی end-to-end جانچ کے لیے کسی documentation address کو دستی طور پر ban کریں، اپنے address کو کبھی نہیں:

sudo fail2ban-client set sshd banip 10.0.0.66

یہ 1 دکھاتا ہے، اور address fail2ban-client status sshd میں Banned IP list کے تحت ظاہر ہوتا ہے۔ اب firewall میں block واقعی موجود ہونے کی تصدیق کریں۔ Ubuntu 24.04 پر یہ nftables ہے، iptables نہیں:

sudo nft list table inet f2b-table

آپ کو addr-set-sshd نام کا ایک set نظر آئے گا، جس میں 10.0.0.66 موجود ہوگا، اور f2b-chain نام کی ایک chain ہوگی جو اس set میں موجود ہر source کو reject کرتی ہے۔ اگر fail2ban-client کہتا ہے کہ کوئی address banned ہے، لیکن nft list میں کچھ ظاہر نہیں ہوتا، تو آپ کا ban action firewall کے مطابق نہیں ہے۔ failure modes میں موجود nftables/iptables نوٹ دیکھیں۔

مرحلہ 6: خود کو پابندی سے نکالیں اور لاک آؤٹ ہونے کی صورت میں بحالی کریں

اگر آپ نے کسی ایسے address پر پابندی لگا دی ہے جس پر نہیں لگنی چاہیے تھی، مثلاً اپنے address پر، تو اسے ہٹا دیں:

sudo fail2ban-client set sshd unbanip 10.0.0.66

کامیابی کی صورت میں یہ 1 واپس کرتا ہے۔ تمام jails میں موجود ہر پابندی ختم کرنے کے لیے:

sudo fail2ban-client unban --all

آپ کو پہلے سے کھلے ہوئے SSH session پر بھروسا نہیں کرنا چاہیے۔ nftables کی پابندی banned address سے port 22 پر آنے والے ہر packet کو رد کر دیتی ہے، جس میں قائم شدہ connections بھی شامل ہیں۔ اس لیے پابندی نافذ ہوتے ہی موجودہ session منجمد ہو جاتا ہے۔ اگر آپ نے خود کو پابندی لگا دی اور آپ کے پاس ignoreip entry نہیں ہے، تو پابندی ختم ہونے تک آپ لاک آؤٹ رہیں گے۔ اپنے provider کے web console، مثلاً VNC یا serial، کے ذریعے بحالی کریں۔ یہ SSH کے ذریعے نہیں گزرتا۔ وہاں یا تو bantime کے ختم ہونے کا انتظار کریں یا unban command چلائیں۔

مرحلہ 7: پابندیاں مستقل بنائیں اور بتدریج سخت کریں

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

اس کے علاوہ system-wide "three strikes" پالیسی نافذ کرنے کے لیے Fail2ban ایک recidive jail فراہم کرتا ہے۔ یہ اپنی /var/log/fail2ban.log کی نگرانی کرتا ہے اور ان addresses پر طویل پابندیاں عائد کرتا ہے جنہیں تمام jails میں بار بار banned کیا گیا ہو۔ چونکہ آپ کا [DEFAULT] اب systemd backend استعمال کرتا ہے، اس لیے اس jail کو واپس اسی log file پر مقرر کریں جسے پڑھنے کے لیے یہ بنایا گیا ہے:

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

واضح logpath کے ساتھ backend = auto، recidive کو plain fail2ban.log پڑھنے پر برقرار رکھتا ہے۔ یہی وہ جگہ ہے جہاں گنی جانے والی Ban لائنیں حقیقتاً ظاہر ہوتی ہیں۔ آپ نے globally مقرر کردہ systemd default اسے journal کی طرف بھیج دیتا، جہاں یہ لائنیں موجود نہیں ہوتیں۔

مرحلہ 8: اسے صرف کلید پر مبنی SSH کے ساتھ استعمال کریں، اور VPN کے ساتھ تو مزید بہتر ہے

Fail2ban صرف کلید پر مبنی authentication کے ساتھ مؤثر ثابت ہوتا ہے۔ /etc/ssh/sshd_config.d/ کے اندر ایک drop-in فائل، مثلاً /etc/ssh/sshd_config.d/00-hardening.conf، میں یہ ترتیب دیں:

PasswordAuthentication no
KbdInteractiveAuthentication no

پھر sudo systemctl restart ssh۔ Password authentication بند ہونے پر brute-force حملہ کامیاب نہیں ہو سکتا؛ اس کے بعد Fail2ban کا مقصد صرف log میں غیر ضروری شور کم کرنا اور scanners کو ابتدا ہی میں خارج کرنا رہ جاتا ہے۔ اس سے بھی مضبوط طریقہ یہ ہے کہ SSH کو public internet سے مکمل طور پر الگ رکھا جائے: SSH کو self-hosted WireGuard VPN کے پیچھے رکھیں اور port 22 پر firewall اس طرح لگائیں کہ وہ صرف tunnel پر درخواستیں قبول کرے۔ جس port تک رسائی ہی نہ ہو، اس پر کوئی brute-force حملہ نہیں کر سکتا، اور Fail2ban پہلی دفاعی سطح کے بجائے اضافی حفاظتی انتظام بن جاتا ہے۔

Fail2ban صرف SSH کے لیے نہیں ہے۔ ہر وہ service جو ناکام login attempts کو log کرتی ہے، jail حاصل کر سکتی ہے، خواہ وہ mail server ہو، nginx site ہو، یا self-hosted Vaultwarden password manager ہو جس کا web login آپ credential stuffing کے لیے کھلا نہیں چھوڑنا چاہتے۔ جب کوئی web app Let's Encrypt certificate والی nginx site کے پیچھے چل رہی ہو، تو اسی طرح اس کے access log کے لیے Fail2ban filter مقرر کریں جس طرح SSH jail journal پر filter مقرر کرتا ہے۔

خرابی کی صورتیں، اور وہ عین strings جو آپ دیکھیں گے

"Have not found any log file for sshd jail"، اور Fail2ban شروع نہیں ہوگا۔ یہ پرانا auth.log مسئلہ ہے۔ Ubuntu 24.04 پر یہ صرف اسی وقت پیش آتا ہے جب کسی چیز نے packaged default کو override کیا ہو، pip installation میں defaults-debian.conf موجود نہ ہو، container میں journal نہ ہو، یا کوئی اضافی backend = auto آپ نے jail.local میں paste کر دیا ہو۔ ایسے file backend میں جہاں /var/log/auth.log موجود نہ ہو، sshd jail اپنی log تلاش نہیں کر پاتا اور پورا daemon بند ہو جاتا ہے۔ fail2ban.log یہ دکھاتا ہے:

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

چونکہ یہ error ناقابلِ نظرانداز ہے، اس لیے service شروع ہی نہیں ہوتی۔ پھر fail2ban-client status اس کے نتیجے میں پیدا ہونے والی علامت دکھاتا ہے:

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

یہ "socket path" والی سطر اس بات کی علامت نہیں کہ Fail2ban خراب ہے۔ اس کا مطلب یہ ہے کہ ایک jail اپنی log تلاش نہیں کر سکی، اس لیے Fail2ban شروع نہیں ہوا۔ [DEFAULT] میں backend = systemd set کرنے سے دونوں messages ایک ساتھ درست ہو جاتے ہیں۔ Ubuntu package یہ setting پہلے ہی آپ کے لیے کرتا ہے۔

Jail فعال ہے، لیکن Total failed آگے نہیں بڑھتا۔ Daemon چل رہا ہے اور journal پڑھی جا رہی ہے، لیکن حقیقی failures journalctl -u ssh میں جمع ہو رہی ہیں جبکہ counter 0 پر رکا ہوا ہے۔ پہلے واضح وجہ کو خارج کریں: آپ ایسے address سے test کر رہے ہیں جو ignoreip میں درج ہے، اس لیے design کے مطابق آپ کی اپنی failures نظرانداز کی جاتی ہیں۔ اگر یہ وجہ نہیں ہے تو آپ OpenSSH کے ایسے build پر ہیں جس میں فی connection worker sshd-session ہے، یعنی 9.8 اور بعد کے versions میں۔ اس کا journal _COMM، sshd-session ہے، نہ کہ sshd۔ اس لیے فراہم کردہ match اس سے مطابقت نہیں رکھتا۔ [sshd] block میں match کو وسیع کریں:

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

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

آپ نے خود کو ban کر دیا: Connection refused۔ آپ نے اپنا address ignoreip میں شامل نہیں کیا، چند غلط logins آزمائے، اور اب:

ssh: connect to host 10.0.0.10 port 22: Connection refused

خاموش timeout کے بجائے refusal اس بات کی علامت ہے کہ nftables action کا default reject verdict آپ کے خلاف کام کر رہا ہے۔ اسے Step 6 کے مطابق درست کریں: کسی دوسرے، unbanned address سے کھلے session میں unban کریں، یا provider console استعمال کریں۔ banned address سے پہلے سے کھلا session بھی freeze ہو جاتا ہے۔ پھر اپنا address ignoreip میں شامل کریں تاکہ یہ دوبارہ نہ ہو۔

Fail2ban کہتا ہے کہ address banned ہے، لیکن وہ اب بھی connect کر سکتا ہے۔ status sshd میں counter بڑھ رہا ہے، پھر بھی address port 22 تک پہنچ رہا ہے۔ یہ ban action اور firewall کے درمیان mismatch ہے۔ Ubuntu 24.04 پر اس کا تقریباً ہمیشہ مطلب ہوتا ہے کہ آپ نے فعال banaction = nftables کو پرانی guide سے نقل کیے گئے banaction = iptables-multiport سے override کر دیا ہے، جبکہ system پر iptables layer موجود نہیں۔ fail2ban.log یہ دکھاتا ہے:

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

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

jail.local میں ترمیم کے بعد Fail2ban شروع نہیں ہوگا۔ Typo، اضافی heading یا غلط time value کی وجہ سے service شروع ہونے سے انکار کر سکتی ہے۔ Fail2ban کے چلنے سے پہلے اس سے configuration check کروائیں:

sudo fail2ban-client -t

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

FAQ

کیا Ubuntu 24.04 کی stock Fail2ban installation واقعی SSH حملوں کو ban کرتی ہے؟

ہاں۔ package میں /etc/fail2ban/jail.d/defaults-debian.conf شامل ہے، جو sshd jail فعال کرتا ہے، backend = systemd مقرر کرتا ہے تاکہ یہ missing /var/log/auth.log کے بجائے systemd journal پڑھے، اور banaction = nftables مقرر کرتا ہے تاکہ bans Ubuntu کے حقیقی firewall کے ذریعے نافذ ہوں۔ سادہ apt install fail2ban پہلے boot سے SSH کو محفوظ کرتا ہے۔ sudo fail2ban-client status sshd سے اس کی تصدیق کریں اور non-zero Total failed تلاش کریں۔

Fail2ban میرے سرور پر کچھ بھی ban کیوں نہیں کر رہا؟

تین عام وجوہات کو اسی ترتیب سے خارج کریں۔ ممکن ہے آپ ignoreip میں موجود address سے test کر رہے ہوں، جسے design کے مطابق مستثنیٰ رکھا گیا ہے۔ ممکن ہے آپ نے کسی پرانی guide سے backend = auto کو jail.local میں paste کر کے کام کرنے والی default configuration کو override کر دیا ہو، جس سے ایسے image پر journal reading ناکام ہو جاتی ہے جس میں auth.log موجود نہیں۔ یا ممکن ہے آپ ایسے container کے اندر ہوں جہاں پڑھنے کے لیے systemd journal ہی موجود نہ ہو۔ fail2ban-client status sshd میں Total failed چیک کریں: اگر journalctl -u ssh حقیقی failures دکھا رہا ہو لیکن یہ کبھی نہ بڑھے، تو jail غلط جگہ سے data پڑھ رہا ہے۔

میں اپنا IP address unban کیسے کروں؟

sudo fail2ban-client set sshd unbanip YOUR.IP.HERE چلائیں؛ کامیابی پر یہ 1 واپس کرتا ہے۔ تمام bans ختم کرنے کے لیے sudo fail2ban-client unban --all چلائیں۔ اگر آپ SSH سے lock out ہو گئے ہیں تو اپنے provider کے web یا VNC console سے یہی command چلائیں۔ ban آپ کے address سے port 22 کو بھیجے گئے ہر packet کو مسترد کرتا ہے، اس لیے پہلے سے کھلا ہوا session بھی کام کرنا بند کر دیتا ہے۔ اس کے بعد اپنا address ignoreip میں شامل کریں تاکہ یہ مسئلہ دوبارہ نہ ہو۔

jail.conf اور jail.local میں کیا فرق ہے؟

jail.conf میں Fail2ban کی upstream defaults ہوتی ہیں اور ہر package upgrade پر اسے overwrite کر دیا جاتا ہے، اس لیے وہاں کی گئی ہر ترمیم بالآخر ضائع ہو جاتی ہے۔ Debian/Ubuntu package اپنی settings کو jail.d/defaults-debian.conf کے ذریعے اس configuration کے اوپر لاگو کرتا ہے۔ آپ کی تبدیلیاں jail.local میں ہونی چاہییں، جسے آخر میں پڑھا جاتا ہے اور جو دونوں configurations پر غالب آتی ہے؛ upgrades اسے کبھی تبدیل نہیں کرتے۔ jail.conf کو صرف read-only reference کے طور پر رکھیں۔

کیا Fail2ban key-based SSH authentication کی جگہ لے سکتا ہے؟

نہیں۔ Fail2ban ایک address سے ہونے والی repeated failures کی rate limit کرتا ہے؛ اس کے خلاف یہ slow، distributed guessing کچھ نہیں کرتا جس میں ہر address threshold سے کم رہتا ہے۔ Key-only authentication (PasswordAuthentication no) password guessing کو براہِ راست ناممکن بنا دیتی ہے، جبکہ Fail2ban log noise کم کرتا ہے اور scanners کو ابتدائی مرحلے میں خارج کر دیتا ہے۔ دونوں استعمال کریں، اور بہتر یہ ہے کہ SSH کو public internet سے مکمل طور پر دور رکھا جائے۔