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 کو tune کرنے کی ضرورت نہیں۔

اب وہ نکتہ جس میں ہر پرانی guide غلطی کرتی ہے۔ کئی سال تک عمومی مشورہ یہ تھا: "Fail2ban انسٹال کریں، پھر backend = systemd شامل کریں، کیونکہ Ubuntu نے /var/log/auth.log لکھنا بند کر دیا ہے۔" یہ مشورہ صرف بعض images پر درست ہے۔ عام Ubuntu 24.04 server یا cloud image اب بھی rsyslog انسٹال کرتی ہے۔ اس کے default rules auth,authpriv.* کو /var/log/auth.log میں لکھتے ہیں، اس لیے زیادہ تر VPS پر SSH failures اس file کے علاوہ systemd journal میں بھی درج ہوتی ہیں۔ Minimal images، جن میں Ubuntu 24.04 minimal cloud image rsyslog کے بغیر آتی ہے، اور زیادہ تر containers، SSH logs صرف journal میں لکھتے ہیں؛ ایسی صورت میں text file واقعی موجود نہیں ہوتی۔ دونوں صورتوں میں Ubuntu 24.04 کا Fail2ban package اس صورتِ حال کو پہلے ہی handle کرتا ہے۔ 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 پڑھتا ہے، اس لیے اس سے فرق نہیں پڑتا کہ آپ کی image auth.log لکھتی ہے یا نہیں۔ banaction = nftables کا مطلب ہے کہ bans کا نفاذ nftables کے ذریعے ہوتا ہے۔ Ubuntu 24.04 دراصل یہی firewall استعمال کرتا ہے، نہ کہ legacy iptables۔ [sshd] enabled = true کا مطلب ہے کہ jail پہلے boot سے فعال ہے۔ نتیجہ یہ ہے کہ Ubuntu 24.04 پر عام apt install fail2ban SSH brute-force حملوں کو بطورِ ڈیفالٹ روک دیتا ہے۔ آپ کے زیادہ تر کام میں اس کی تصدیق، policy کی tuning، اور یہ یقینی بنانا شامل ہے کہ آپ خود server سے lock out نہ ہوں۔

پرانی auth.log والی غلطی اب بھی تین صورتوں میں سامنے آتی ہے، اور انہیں پہچاننا ضروری ہے: آپ نے Fail2ban کو pip کے ساتھ انسٹال کیا، apt کے ساتھ نہیں، اس لیے defaults-debian.conf موجود نہیں؛ آپ کسی unprivileged container کے اندر ہیں جہاں پڑھنے کے لیے systemd journal موجود نہیں؛ یا آپ نے کسی پرانی tutorial پر عمل کرتے ہوئے backend = auto کو اپنی jail.local میں paste کر دیا، جس سے کام کرنے والا default override ہو گیا۔ پہلی اور تیسری صورت صرف ایسی image پر SSH banning کو ناکام بناتی ہیں جس میں rsyslog موجود نہ ہو، مثلاً minimal image، کیونکہ جہاں rsyslog چلتا ہے وہاں file backend /var/log/auth.log تلاش کر کے کام کرتا ہے۔ 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 میں رکھتا ہے۔ اس file میں ترمیم نہ کریں۔ Package upgrade اسے replace کر سکتا ہے، جیسا کہ اس file کا اپنا header خبردار کرتا ہے، اور آپ کی تبدیلیاں ضائع ہو سکتی ہیں۔ Fail2ban files کو ایک مقررہ ترتیب سے پڑھتا ہے: پہلے jail.conf، پھر alphabetical order میں jail.d/*.conf، اس کے بعد jail.local، اور آخر میں alphabetical order میں jail.d/*.local۔ آخری value نافذ ہوتی ہے۔ اس لیے jail.local، packaged defaults-debian.conf کو override کرتا ہے، لیکن jail.d/ میں رکھی گئی کوئی بھی *.local file اس کے بعد پڑھی جاتی ہے اور اسے دوبارہ override کر دیتی ہے۔ اپنی overrides ایک ہی جگہ رکھیں تاکہ آپ کو معلوم رہے کہ کون سی value فعال ہے۔ .local file آپ کی اپنی ہوتی ہے، اور package upgrades اسے کبھی تبدیل نہیں کرتے۔ یہی اصول filters پر بھی لاگو ہوتا ہے، جہاں *.local file، shipped filter.d/*.conf کو override کرتی ہے۔

اس لیے ایک مختصر jail.local لکھیں جو صرف ان چند settings کو override کرے جن کی آپ کو ضرورت ہے، اور jail.conf اور packaged 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: اسے دوبارہ شروع کریں اور تصدیق کریں کہ یہ 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:   203.0.113.66

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

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

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

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

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

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

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

انتظار کیے بغیر پورے طریقۂ کار کی end-to-end تصدیق کرنے کے لیے کسی documentation address کو دستی طور پر ban کریں، اپنے address کو کبھی نہیں۔ 203.0.113.66 TEST-NET-3 میں ہے۔ یہ block documentation کے لیے reserved ہے، اس لیے یہ حقیقی host یا آپ کے provider کے network پر private address نہیں ہو سکتا:

sudo fail2ban-client set sshd banip 203.0.113.66

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

sudo nft list table inet f2b-table

آپ کو 203.0.113.66 رکھنے والا addr-set-sshd نامی set اور f2b-chain نامی 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 203.0.113.66

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

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 پر یہ صرف اس صورت میں پیش آتا ہے جب /var/log/auth.log موجود نہ ہو (ایسی image جس میں rsyslog شامل نہ ہو، مثلاً minimal image یا container) اور journal پڑھا نہ جا رہا ہو: defaults-debian.conf کے بغیر pip installation، journal کے بغیر container، یا jail.local میں paste کیا گیا غیر متعلقہ backend = auto۔ /var/log/auth.log کے بغیر file backend میں 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 مقرر کرنے سے، جو Ubuntu package پہلے ہی آپ کے لیے کرتا ہے، دونوں messages بیک وقت درست ہو جاتے ہیں۔

Jail فعال ہے، لیکن Total failed کبھی آگے نہیں بڑھتا۔ daemon چل رہا ہے اور journal پڑھی جا رہی ہے، لیکن حقیقی failures journalctl -u ssh میں جمع ہوتے رہتے ہیں جبکہ counter 0 پر رہتا ہے۔ پہلے واضح وجہ کو خارج کریں: آپ ایسے address سے test کر رہے ہیں جو ignoreip میں درج ہے، اس لیے design کے مطابق آپ کی اپنی failures مستثنیٰ ہیں۔ اگر یہ وجہ نہیں ہے تو آپ OpenSSH کی ایسی build استعمال کر رہے ہیں جس میں فی connection worker sshd-session ہے (9.8 اور اس کے بعد)، اور اس کی journal _COMM، sshd نہیں بلکہ sshd-session ہے، اس لیے فراہم کردہ 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 یا provider console کے ذریعے unban کریں۔ 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 سے copy کیے گئے banaction = iptables-multiport سے override کر دیا ہے، جبکہ اس machine پر 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 مقرر کریں۔ Restart کریں اور sudo nft list ruleset | grep f2b کے ذریعے تصدیق کریں کہ rule ظاہر ہو رہا ہے۔

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

sudo fail2ban-client -t

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

FAQ

کیا Ubuntu 24.04 پر Fail2ban کی بنیادی تنصیب واقعی SSH حملوں کو بلاک کرتی ہے؟

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

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

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

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

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

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

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

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

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