نئے VPS پر پہلے 10 منٹ میں کیا کریں؟

سرور کی حفاظت کا فیصلہ پہلے 10 منٹ میں ہو جاتا ہے

نیا VPS محفوظ نہیں ہوتا۔ جیسے ہی اسے public IP ملتا ہے، scanners اس میں login کرنے کی کوشش شروع کر دیتے ہیں۔ default image انہیں بڑا ہدف فراہم کرتی ہے: root عموماً reachable ہوتا ہے، passwords اکثر allowed ہوتے ہیں، firewall موجود نہیں ہوتا، اور patches مقررہ schedule کے مطابق install نہیں ہوتے۔ اچھی بات یہ ہے کہ ان تمام کمزوریوں کو بند کرنے میں تقریباً 10 منٹ اور چند commands کافی ہیں۔ کسی بھی نئے server پر کچھ deploy کرنے سے پہلے یہی runbook استعمال کرتا ہوں۔

اسے اسی ترتیب سے مکمل کریں، کیونکہ ہر step پچھلے step پر منحصر ہے۔ ہر step کی اپنی guide ہے اور متعلقہ جگہ پر اس کا link دیا گیا ہے۔ یہ صفحہ ان تمام steps کو تیزی سے مکمل کرنے کا مربوط طریقہ ہے۔

منٹ 1: ہر چیز update کریں

اپنے provider کی فراہم کردہ credentials کے ذریعے root کے طور پر login کریں، اور کسی بھی دوسرے کام سے پہلے system کو مکمل طور پر up to date کریں:

apt update && apt upgrade -y

Unpatched system سب سے آسان target ہوتا ہے، اس لیے یہ کام پہلے کریں۔ جب یہ مکمل ہو جائے تو automatic security updates configure کریں تاکہ آپ کو خود یاد رکھنے کی ضرورت نہ پڑے اور system مسلسل patched رہے۔

منٹ 2: sudo کے ساتھ عام صارف بنائیں

root کے طور پر کام جاری نہ رکھیں۔ اپنے لیے ایک صارف بنائیں اور اسے sudo کی اجازت دیں:

adduser matt
usermod -aG sudo matt

اب سے اسی صارف کے طور پر لاگ ان کریں اور انتظامی کاموں کے لیے sudo استعمال کریں۔ ہر وقت root کے طور پر چلنے کا مطلب ہے کہ ہر غلطی اور ہر breach لامحدود اختیارات کے ساتھ واقع ہوتی ہے۔ یہی وہ مسئلہ ہے جس سے غیر مراعات یافتہ صارف کے طور پر چلنا بچانے کے لیے موجود ہے۔

منٹ 4: SSH keys ترتیب دیں

Passwords کا اندازہ لگایا جا سکتا ہے، keys کا نہیں۔ اپنے laptop پر، اگر key پہلے سے موجود نہ ہو، تو ایک بنائیں:

ssh-keygen -t ed25519

پھر public حصے کو server پر copy کریں:

ssh-copy-id matt@YOUR_SERVER

نئے user کے لیے ssh-copy-id میں password login فعال ہونا ضروری ہے۔ اگر یہ پہلے ہی بند ہو تو root کی ~/.ssh/authorized_keys کو /home/matt/.ssh/authorized_keys میں copy کریں، جس کی ملکیت matt کے پاس ہو، یا اپنی public key دستی طور پر اس file میں paste کریں۔

اس مرحلے کے بنیادی تصور، یعنی ہر device کے لیے ایک key، key login کو ناکام بنانے والی permissions، اور گم شدہ key کو منسوخ کرنے کا طریقہ، SSH key management کی بنیادی باتیں میں بیان کیا گیا ہے۔

Log out کریں اور key استعمال کرتے ہوئے matt کے طور پر دوبارہ login کریں۔ اگلے مرحلے سے پہلے تصدیق کریں کہ یہ کام کرتا ہے۔ Key کے ذریعے login کرنے کے قابل ہونے سے پہلے SSH کو محدود کرنا خود کو server سے lock out کرنے کا طریقہ ہے۔ اگر اس login پر Permission denied (publickey) ظاہر ہو تو اسے ابھی حل کریں، password پر واپس نہ جائیں، کیونکہ اس ایک message میں پانچ مختلف خرابیاں شامل ہو سکتی ہیں، اور ssh -v کا output بتاتا ہے کہ ان میں سے آپ کے server پر کون سی خرابی موجود ہے۔

منٹ 6: root login اور passwords بند کریں

اب جبکہ آپ کی key کام کر رہی ہے، ان دو راستوں کو بند کریں جن پر scanners انحصار کرتے ہیں۔ drop-in file استعمال کریں تاکہ package upgrades اسے overwrite نہ کریں۔ اسے 00- نام دیں تاکہ یہ 50-cloud-init.conf سے پہلے sort ہو۔ Ubuntu cloud images اسے PasswordAuthentication yes کے ساتھ فراہم کرتی ہیں؛ sshd پہلی پڑھی جانے والی value برقرار رکھتا ہے، اس لیے بعد میں sort ہونے والی file خاموشی سے غیر مؤثر ہو جائے گی:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

اب SSH reload کریں:

sudo systemctl restart ssh

پھر وہ settings چیک کریں جو sshd حقیقت میں استعمال کر رہا ہے، تاکہ غیر مؤثر drop-in آپ کو گمراہ نہ کر سکے:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Passwords بند ہونے اور root login ختم ہونے کے بعد آپ کے server کے خلاف جاری brute-force traffic کامیاب نہیں ہو سکتا۔ مکمل طریقہ، جس میں port change کا optional طریقہ بھی شامل ہے، VPS پر SSH hardening میں موجود ہے۔

منٹ 8: firewall فعال کریں

تمام inbound traffic کو بطور default deny کریں، پھر صرف مطلوبہ traffic کی اجازت دیں۔ اسے فعال کرنے سے پہلے SSH کی اجازت دیں، ورنہ آپ اپنا موجودہ connection ختم کر دیں گے:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

واقعی چلنے والی ہر service کے لیے allow کے rules شامل کریں، مثلاً website کے لیے 80/tcp اور 443/tcp۔ اگر اس کے بعد نیا SSH session connect ہونا بند ہو جائے تو کچھ تبدیل کرنے سے پہلے error پڑھیں، کیونکہ refusal کا مطلب ہے کہ sshd نے جواب دیا، جبکہ timeout عموماً اس بات کی علامت ہے کہ firewall نے packet روک دیا ہے۔ تصدیق کریں کہ IPv4 اور IPv6 دونوں شامل ہیں، کیونکہ ایسا firewall جو صرف IPv4 کو filter کرتا ہے IPv6 کو مکمل طور پر کھلا چھوڑ دیتا ہے۔ مکمل طریقہ VPS پر Firewalls 101 میں موجود ہے۔ یہ ufw commands Ubuntu یا Debian فرض کرتی ہیں؛ Rocky یا AlmaLinux server پر default-deny کا مقصد وہی رہتا ہے، لیکن tool firewalld ہوتا ہے، اس لیے اس کے بجائے اس مرحلے کا firewalld ورژن استعمال کریں۔

منٹ 10: Fail2ban سے scanners کو سست کریں

آخر میں Fail2ban شامل کریں تاکہ ان addresses کو خارج کیا جا سکے جو آپ کے ports پر مسلسل requests بھیجتے ہیں:

sudo apt install -y fail2ban

Ubuntu 24.04 میں default installation پہلے boot سے SSH کو محفوظ رکھتی ہے۔ چونکہ keys پہلے ہی required ہیں، اس لیے یہ بنیادی دفاع کے بجائے اضافی حفاظتی تہہ ہے جو log noise کم کرتی ہے اور بار بار خلاف ورزی کرنے والے addresses کو block کرتی ہے۔

آپ کی چیک لسٹ

یہی رن بک ہے۔ ذیل کے generator کو استعمال کرتے ہوئے ہر control کی تکمیل درج کریں اور ایک ذاتی چیک لسٹ تیار کریں جسے آپ server کے ساتھ رکھ سکیں۔ اس میں ہر مرحلے کے لیے درست command بھی شامل ہوگی:

ہر نئے server پر اسے ایک بار مکمل کریں، پھر پورا عمل خودکار معمول بن جائے گا۔ ابھی کے 10 منٹ آپ کو اس بہت خراب دوپہر سے بچا سکتے ہیں جو server کے compromise ہونے کے بعد آتی ہے۔

ضروری انتظامات مکمل ہونے کے بعد، Ubuntu پر خودکار security updates آپ کے دوبارہ login کیے بغیر server کو updated رکھتے ہیں۔ اس کے بعد شامل کی جانے والی ہر service کا الگ جائزہ لینا ضروری ہے، اور کمزور مقامات بھی بدل جاتے ہیں: self-hosted password vault کے ساتھ server plaintext محفوظ نہیں کرتا، اس لیے Vaultwarden کے حقیقی risks admin token اور backup file ہیں۔

FAQ

نئے VPS پر مجھے سب سے پہلے کیا کرنا چاہیے؟

`apt update && apt upgrade -y` کے ذریعے system update کریں، پھر sudo کے ساتھ ایک عام user بنائیں اور root کے طور پر کام کرنا بند کریں۔ اس کے بعد SSH keys ترتیب دیں، root login اور password authentication کو disable کریں، default-deny firewall enable کریں، اور Fail2ban install کریں۔ یہ کام اسی ترتیب سے کرنے پر ہر اگلا قدم آپ کو server سے lock out کیے بغیر محفوظ طریقے سے انجام دیا جا سکتا ہے۔

SSH کو harden کرتے وقت خود کو lock out ہونے سے کیسے بچاؤں؟

Passwords یا root کو disable کرنے سے پہلے SSH key login ترتیب دے کر test کریں۔ logout کریں اور key کے ذریعے دوبارہ login کر کے تصدیق کریں کہ یہ کام کر رہا ہے، پھر `PasswordAuthentication اور PermitRootLogin کو بند کریں۔ Firewall enable کرتے وقت ufw enable` چلانے سے پہلے port 22 کی اجازت دیں۔ اگر آپ واقعی lock out ہو جائیں تو provider کا web console آپ کو SSH کے بغیر دوبارہ login کرنے دے گا۔

کیا چھوٹے server پر بھی یہ سب ضروری ہے؟

ہاں، کیونکہ scanners کو اس بات سے فرق نہیں پڑتا کہ آپ کا server کتنا چھوٹا ہے۔ وہ ہر public IP کو ایک ہی طریقے سے آزماتے ہیں۔ پورا runbook تقریباً 10 منٹ لیتا ہے اور آسان attack paths ختم کر دیتا ہے: root login بند، password guessing ناممکن، کوئی غیر ضروری چیز exposed نہیں، اور معلوم bugs خودکار طور پر patched رہتے ہیں۔

سب سے اہم واحد قدم کون سا ہے؟

Root login disable کر کے صرف key-based SSH استعمال کرنا۔ تازہ VPS پر زیادہ تر attacks root کے خلاف automated password guesses ہوتے ہیں، اور دونوں چیزیں بند کرنے سے attacks کی یہ پوری قسم ناممکن ہو جاتی ہے۔ Firewall اور Fail2ban اس کے بعد exposed services کو محدود کرتے ہیں اور باقی attacks کو سست کرتے ہیں۔

میں کیسے تصدیق کروں کہ server واقعی locked down ہے؟

اعتماد کرنے سے پہلے ہاتھ سے 3 چیزیں check کریں۔ `sudo ss -tlnp چلائیں اور تصدیق کریں کہ public address پر صرف وہی ports listening ہیں جنہیں آپ نے کھولنے کا ارادہ کیا تھا، اور کوئی 0.0.0.0 یا [::] service موجود نہیں جسے آپ بھول گئے ہوں۔ sudo ufw status verbose چلائیں اور تصدیق کریں کہ default incoming policy deny ہے اور plain اور (v6)` دونوں rules موجود ہیں۔ پہلی SSH session بند کرنے سے پہلے ہمیشہ دوسری SSH session کھولیں، تاکہ SSH configuration کی کوئی غلطی آپ کو server سے lock out نہ کر دے۔ اگر تینوں چیزیں درست ہوں تو بنیادی security controls موجود ہیں۔