Language: ur

VPS سیکیورٹی ابتدا سے: SSH Keys، Firewall اور Fail2ban

Ubuntu انسٹال ہونے کے فوراً بعد نئے VPS کو محفوظ نہیں سمجھنا چاہیے۔ رسائی ترتیب دینے سے پہلے ہی سرور اسکینرز کو نظر آ رہا ہوتا ہے: وہ SSH پاس ورڈ آزماتے، کھلے ہوئے کنٹرول پینلز تلاش کرتے اور عام کمزوریوں کی جانچ کرتے ہیں۔ اس گائیڈ میں ہم VPS کو ابتدا سے محفوظ بنانے کے بنیادی مراحل دیکھیں گے: الگ صارف بنانا، SSH key authentication ترتیب دینا، UFW کے ذریعے نیٹ ورک پورٹس محدود کرنا اور Fail2ban شامل کرنا۔ تمام مراحل Ubuntu 22.04 اور 24.04 پر اس وقت کام کرتے ہیں جب کمانڈز sudo اختیارات والے صارف سے چلائی جائیں۔

شروع کرنے سے پہلے: پورٹس کی فہرست بنائیں

پورٹس کو ”شاید ضرورت پڑے“ کے لیے نہ کھولیں۔ ایک عام ویب سرور کو عموماً یہ درکار ہوتے ہیں:

• 22/tcp — SSH؛ بہتر ہے کہ اسے IP کے ذریعے محدود کریں یا صرف اضافی اقدام کے طور پر کسی دوسرے پورٹ پر منتقل کریں؛
• 80/tcp — HTTP؛ عموماً HTTPS پر ری ڈائریکٹ کرنے اور سرٹیفکیٹ کی توثیق کے لیے ضروری؛
• 443/tcp — HTTPS۔

اگر Nginx یا Caddy سامنے چل رہا ہو تو 3000، 8080 یا 9000 جیسا ایپلیکیشن پورٹ انٹرنیٹ سے قابلِ رسائی نہیں ہونا چاہیے۔ ایپلیکیشن کو 127.0.0.1 سے bind کریں یا اس کے پورٹ کو صرف اندرونی نیٹ ورک پر اجازت دیں۔ پہلے معلوم کریں کہ سرور پر کیا سن رہا ہے:

sudo ss -tulpn

Docker انسٹال کرنے کے بعد اس کے iptables rules الگ سے چیک کریں: -p 3000:3000 شائع کرنے سے پورٹ توقع سے مختلف طریقے سے کھل سکتا ہے۔ عوامی سروس کے لیے HTTPS proxy استعمال کرنا اور اندرونی پورٹ چھپا کر رکھنا زیادہ محفوظ ہے۔

مرحلہ 1۔ سسٹم اپ ڈیٹ کریں اور منتظم بنائیں

فراہم کردہ credentials استعمال کرتے ہوئے VPS سے جڑیں اور updates انسٹال کریں:

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ufw fail2ban unattended-upgrades

اپنا ذاتی صارف بنائیں۔ alex کو اپنے نام سے بدلیں:

sudo adduser alex
sudo usermod -aG sudo alex

جب تک آپ الگ ٹرمینل ونڈو میں نئے اکاؤنٹ کی جانچ نہ کر لیں، اصل رسائی ختم نہ کریں۔ یہ اہم اصول ہے: موجودہ session کھلا ہو تو SSH کی غلطی درست کرنا آسان ہوتا ہے۔

مرحلہ 2۔ SSH key بنائیں اور سرور پر انسٹال کریں

اپنے Linux، macOS یا Windows PowerShell کمپیوٹر پر چلائیں:

ssh-keygen -t ed25519 -C "alex@my-computer"

Key کو default فائل میں محفوظ کرنے کے لیے Enter دبائیں، پھر passphrase مقرر کریں۔ Private key کبھی chat میں نہ بھیجیں، اسے repository میں نہ رکھیں اور VPS پر copy نہ کریں۔ صرف .pub extension والی فائل سرور پر منتقل ہونی چاہیے:

ssh-copy-id alex@SERVER_IP

اگر ssh-copy-id دستیاب نہ ہو تو PowerShell میں Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub کے ذریعے public key دکھائیں، پھر اسے سرور پر شامل کریں:

sudo install -d -m 700 -o alex -g alex /home/alex/.ssh
sudo nano /home/alex/.ssh/authorized_keys
sudo chown alex:alex /home/alex/.ssh/authorized_keys
sudo chmod 600 /home/alex/.ssh/authorized_keys

Key کو ایک ہی لائن میں paste کریں اور پاس ورڈ بند کرنے سے پہلے login آزمائیں:

ssh alex@SERVER_IP
sudo whoami

آخری کمانڈ کا متوقع نتیجہ root ہے۔ اگر SSH client کو key نہ ملے تو اسے واضح طور پر بتائیں: ssh -i ~/.ssh/id_ed25519 alex@SERVER_IP۔

مرحلہ 3۔ root login اور password authentication بند کریں

SSH configuration کا backup بنائیں:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

یقینی بنائیں کہ فائل میں یہ parameters موجود ہوں:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
MaxAuthTries 3

Ubuntu پر settings /etc/ssh/sshd_config.d/*.conf میں بھی ہو سکتی ہیں، اس لیے مؤثر configuration چیک کریں:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries'

اگر sshd -t error دے تو syntax درست کرنے تک service restart نہ کریں۔ چیک کامیاب ہونے کے بعد settings لاگو کریں:

sudo systemctl reload ssh

پرانی SSH connection کھلی رکھیں اور نئی window میں key-based login آزمائیں۔ تصدیق شدہ key کے بغیر passwords بند کرنا سرور کی رسائی کھونے کی سب سے عام وجہ ہے۔

مرحلہ 4۔ SSH کو block کیے بغیر UFW configure کریں

UFW Linux network rules کے اوپر ایک آسان wrapper ہے۔ پہلے محفوظ defaults مقرر کریں، پھر SSH اور web ports کی اجازت دیں:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

صرف SSH rule شامل کرنے کے بعد activation کی تصدیق کریں۔ نتیجہ دیکھیں:

sudo ufw status verbose
sudo ufw status numbered

مستقل office IP کے لیے SSH کو اسی پتے تک محدود کر سکتے ہیں:

sudo ufw delete allow 22/tcp
sudo ufw allow from YOUR.PUBLIC.IP to any port 22 proto tcp comment 'SSH office'

یہ option صرف مستقل IP اور provider console تک رسائی کے ساتھ استعمال کریں: پتہ بدلنے پر آپ خود کو lock out کر سکتے ہیں۔

ایپلیکیشن پورٹ عارضی طور پر کیسے کھولیں

اگر کسی service کو براہِ راست چیک کرنا ہو تو محدود source کے ساتھ rule بنائیں:

sudo ufw allow from YOUR.PUBLIC.IP to any port 8080 proto tcp

ٹیسٹ کے بعد ufw status numbered میں دکھائے گئے نمبر سے اسے delete کریں:

sudo ufw delete RULE_NUMBER

sudo ufw allow 1:65535/tcp استعمال نہ کریں: ایسا rule firewall کو محض رسمی بنا دیتا ہے۔

مرحلہ 5۔ SSH کے لیے Fail2ban فعال کریں

Fail2ban logs کا تجزیہ کرتا ہے اور کئی ناکام login کوششوں کے بعد عارضی blocking rule شامل کرتا ہے۔ یہ SSH keys یا firewall کا متبادل نہیں، لیکن خودکار brute-force کوششوں کا شور کم کرتا ہے۔

ایک local configuration بنائیں تاکہ package updates آپ کی settings overwrite نہ کریں:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

[DEFAULT] section میں مناسب values مقرر کریں:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
banaction = ufw

[sshd]
enabled = true
port = 22

Service شروع کریں اور jail چیک کریں:

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

sshd output میں ناکام کوششوں اور blocked addresses کی تعداد دیکھیں۔ اپنا IP ban list میں شامل نہ کریں۔ مستقل exception کے لیے ignoreip = 127.0.0.1/8 YOUR.PUBLIC.IP کو [DEFAULT] میں استعمال کریں۔

مرحلہ 6۔ خودکار updates فعال کریں

Security packages کے لیے automatic updates مفید ہیں، لیکن kernel reboots پھر بھی manage کرنے پڑتے ہیں:

sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades

ہفتے میں ایک بار چیک کریں کہ reboot درکار ہے یا نہیں:

test -f /var/run/reboot-required && echo 'Требуется перезапуск'

دستی reboot سے پہلے یقینی بنائیں کہ working key اور VPS console تک رسائی موجود ہے۔ reboot کے بعد application services، Nginx، UFW اور Fail2ban چیک کریں۔

مرحلہ 7۔ باہر سے نتیجہ چیک کریں

Protection کو صرف configuration پڑھ کر نہیں بلکہ کسی دوسرے کمپیوٹر سے چیک کریں:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no alex@SERVER_IP

کمانڈ denial پر ختم ہونی چاہیے۔ الگ سے working key-based login آزمائیں:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 alex@SERVER_IP

VPS پر listening addresses اور rules چیک کریں:

sudo ss -lntup
sudo ufw status numbered
sudo fail2ban-client status sshd

اگر application port کو direct access کے لیے نہیں رکھا گیا تو اسے 127.0.0.1 پر listen کرنا چاہیے۔ External host سے nmap SERVER_IP استعمال کر سکتے ہیں، لیکن صرف اپنا server scan کریں: اجازت کے بغیر کسی اور infrastructure کی جانچ قانون اور provider کے rules کی خلاف ورزی ہو سکتی ہے۔

Backups اور recovery

SSH protection حذف شدہ data، administrator کی غلطی یا compromised application سے نہیں بچاتی۔ Database، configuration اور user files کی copies VPS سے الگ رکھیں۔ کم از کم setup میں روزانہ backup، پچھلے دنوں کے کئی versions اور باقاعدہ recovery tests شامل ہونے چاہئیں۔

Passwords یا tokens کو plain-text scripts میں نہ لکھیں۔ اگر کوئی secret ظاہر ہو جائے تو اسے فوراً revoke کریں اور نیا بنائیں۔

محفوظ project کے لیے VPS کا انتخاب

Security infrastructure پر control سے شروع ہوتی ہے۔ VPS پر آپ operating system، firewall rules، access method، backups اور service placement خود منتخب کر سکتے ہیں۔ چھوٹی website یا API کے لیے اضافی virtual cores سے زیادہ اہم stable network، SSD storage اور recovery console ہیں۔

جب tropic.host کے VPS پر project شروع کریں تو public entry points پہلے سے طے کریں: زیادہ تر صورتوں میں SSH، HTTP اور HTTPS کافی ہوتے ہیں۔ Database اور control panels کو internal network کے اندر رکھیں۔ Project بڑھنے پر application، database اور monitoring کے لیے الگ VPS instances failure domains کو isolate کرنے میں مدد دیتے ہیں۔

عام غلطیاں

• Key-based login آزمائے بغیر passwords بند کرنا۔ موجودہ session کھلا رکھیں اور نئی login الگ سے آزمائیں۔
• 22/tcp کو پوری دنیا کے لیے کھلا چھوڑنا، حالانکہ اسے trusted addresses تک محدود کیا جا سکتا ہے۔
• Docker ports کو براہِ راست publish کرنا۔ پہلے Docker اور UFW rules چیک کریں۔
• Fail2ban انسٹال کر کے دوبارہ logs نہ دیکھنا۔ تبدیلیوں کے بعد journalctl -u ssh اور jail status کا جائزہ لیں۔

خلاصہ

جب مراحل درست ترتیب سے کیے جائیں تو بنیادی VPS protection میں زیادہ وقت نہیں لگتا: الگ user بنائیں، SSH key انسٹال کریں، access verify کریں، root login اور passwords بند کریں، UFW فعال کریں، Fail2ban configure کریں اور automatic updates set کریں۔ پھر backups، logging اور external monitoring شامل کریں۔

یہ اقدامات سرور کو ناقابلِ تسخیر نہیں بناتے، لیکن ابتدائی configuration کی عام غلطیوں کو ختم کرتے ہیں۔ اگلا قدم security profile کو مخصوص application کے مطابق ڈھالنا ہے: dependencies اپ ڈیٹ کریں، service permissions محدود کریں، admin panels محفوظ کریں اور کھلی ports باقاعدگی سے چیک کریں۔

FAQ

کیا default SSH port تبدیل کرنا ضروری ہے؟

ضروری نہیں۔ Port منتقل کرنے سے خودکار شور کم ہوتا ہے، لیکن یہ keys، disabled passwords، UFW یا Fail2ban کا متبادل نہیں۔ اگر port تبدیل کریں تو firewall rule اور Fail2ban jail میں port parameter بھی اپ ڈیٹ کریں۔

UFW configure کرنے کے بعد access کھو جائے تو کیا کروں؟

Provider کا web یا rescue console استعمال کریں، پھر SSH rule اور sshd configuration چیک کریں۔ جب تک نئی login کی تصدیق نہ ہو، پرانی working session بند نہ کریں۔

کیا Fail2ban SSH کی حفاظت کے لیے کافی ہے؟

نہیں۔ Fail2ban ان login failures کے بعد ردِعمل دیتا ہے جو پہلے ہی ہو چکے ہیں۔ بنیاد SSH keys، disabled password authentication، کم سے کم user permissions اور restricted firewall ہونی چاہیے۔

کیا SSH کو صرف ایک IP address سے اجازت دی جا سکتی ہے؟

ہاں، اگر address مستقل ہو: اس IP کے لیے UFW allow from rule شامل کریں۔ Provider console access یا کوئی اور fallback پہلے سے ترتیب دیں، کیونکہ IP بدلنے کے بعد connection block ہو جائے گا۔

VPS security کتنی بار چیک کرنی چاہیے؟

SSH، firewall یا Docker port publishing میں ہر تبدیلی کے بعد port check چلائیں اور login آزمائیں۔ معمول کی دیکھ بھال کے طور پر کم از کم ہفتے میں ایک بار updates اور logs کا جائزہ لیں اور backup recovery باقاعدگی سے آزمائیں۔