Linux میں ports کیا ہیں اور services کیسے listen کرتی ہیں؟

پورٹ دراصل کیا ہوتا ہے

پورٹ ایک ایسا نمبر ہے جو ایک ہی سرور کو متعدد سروسز بیک وقت چلانے دیتا ہے، بغیر اس کے کہ ان کا network traffic آپس میں مل جائے۔ آپ کے VPS کا ایک IP address ہوتا ہے، لیکن اس پر بیک وقت web server، SSH server اور database چل سکتے ہیں۔ جب کوئی packet پہنچتا ہے تو operating system کو معلوم ہونا چاہیے کہ وہ ان میں سے کس سروس کے لیے ہے۔ پورٹ نمبر اس سوال کا جواب دیتا ہے۔ Web traffic port 443 پر، جبکہ SSH port 22 پر جاتا ہے۔ IP address packet کو آپ کے سرور تک پہنچاتا ہے؛ پورٹ اسے اس سرور پر موجود درست program تک پہنچاتا ہے۔

پورٹ ایک 16-bit نمبر ہوتا ہے: 16 bits کی حد 0 سے 65535 تک ہوتی ہے، اور 0 reserved ہے، اس لیے عملی طور پر ports کی حد 1 سے 65535 تک ہے۔ 1024 سے کم ports کو "well-known" ports کہا جاتا ہے اور انہیں کھولنے کے لیے root درکار ہوتا ہے۔ اسی وجہ سے standard services ان ports پر چلتی ہیں: SSH کے لیے 22، HTTP کے لیے 80، HTTPS کے لیے 443، اور DNS کے لیے 53۔ 1024 سے زیادہ کوئی بھی پورٹ عام programs استعمال کر سکتے ہیں۔

پورٹس کی دو اقسام ہیں: TCP اور UDP۔ ایک قسم میں موجود پورٹ نمبر دوسری قسم میں موجود اسی نمبر سے الگ ہوتا ہے۔ TCP connection-based protocol ہے جسے SSH، HTTP اور databases جیسی زیادہ تر services استعمال کرتی ہیں۔ UDP connectionless ہے اور DNS اور بعض VPNs جیسی سروسز کے لیے استعمال ہوتا ہے۔ Firewall کھولتے وقت عموماً آپ کو یہ بھی بتانا ہوتا ہے کہ کون سا protocol استعمال ہوگا، مثلاً 22/tcp۔

Listening سے مراد ہے کہ کوئی پروگرام کسی port پر connections کا انتظار کر رہا ہے

جو پروگرام connections وصول کرنا چاہتا ہے، وہ kernel سے کسی port پر "listen" کرنے کی درخواست کرتا ہے۔ اس کے بعد مشین پر یہ port open ہو جاتا ہے، اور firewall کی اجازت کے مطابق پروگرام وہاں آنے والی ہر درخواست کا جواب دیتا ہے۔ جس port پر کوئی پروگرام listening نہ کر رہا ہو، وہ connections کو مسترد کر دیتا ہے۔ اس لیے ہر security check میں پہلا سوال یہ ہوتا ہے: کیا چیز listening کر رہی ہے، اور کہاں؟

اس سوال کا جواب دینے والی command ss ہے:

sudo ss -tlnp

flags کا مطلب TCP (t)، صرف listening sockets (l)، numeric ports (n، اس لیے آپ کو 22 نظر آتا ہے، ssh نہیں)، اور owning process (p) ہے۔ ایک عام نتیجہ:

State   Recv-Q  Local Address:Port   Process
LISTEN  0       0.0.0.0:22           sshd
LISTEN  0       127.0.0.1:5432       postgres
LISTEN  0       [::]:80              nginx

Process column بتاتا ہے کہ ہر port کا مالک کون سا program ہے۔ اسی کی مدد سے آپ یہ معلوم کر سکتے ہیں کہ کون سی ایسی چیز چل رہی ہے جسے آپ نے جان بوجھ کر running نہیں چھوڑا تھا۔

مقامی پتے کا کالم اہم ہے

ہر port کے سامنے موجود پتا غور سے پڑھیں، کیونکہ اسی سے طے ہوتا ہے کہ کون اس service تک رسائی حاصل کر سکتا ہے۔ آپ کو عموماً یہ تین صورتیں نظر آئیں گی۔

0.0.0.0:22 کا مطلب ہے کہ service اس machine کے ہر IPv4 پتے پر listen کر رہی ہے، جس میں public address بھی شامل ہے۔ Firewall اجازت دے تو یہ service IPv4 کے ذریعے internet سے قابلِ رسائی ہے۔

[::]:80 کا مطلب IPv6 کے لیے یہی ہے: service ہر IPv6 پتے پر listen کر رہی ہے، جس میں public address بھی شامل ہے۔ بہت سے programs default طور پر یہاں bind ہوتے ہیں، اور Linux میں :: socket اکثر IPv4 requests بھی قبول کرتا ہے۔

127.0.0.1:5432 کا مطلب ہے کہ service صرف loopback پر listen کر رہی ہے۔ 127.0.0.1 وہ address ہے جسے machine خود سے رابطے کے لیے استعمال کرتی ہے، اور یہ کسی دوسرے مقام سے route نہیں کیا جا سکتا۔ یہاں bound service صرف اسی server سے قابلِ رسائی ہوتی ہے، internet سے کبھی نہیں، چاہے آپ کا firewall کچھ بھی کہے۔ اوپر دکھائی گئی Postgres کی line اپنی ساخت کے لحاظ سے محفوظ ہے۔

عملی اصول براہِ راست واضح ہے: وہ database، cache یا admin panel جسے صرف آپ کی اپنی applications استعمال کرتی ہیں، اسے 127.0.0.1 پر bind ہونا چاہیے، 0.0.0.0 پر نہیں۔ اگر service کسی public address پر listen ہی نہ کرے تو attacker کے لیے اس تک پہنچنے کا کوئی راستہ نہیں ہوتا۔

سننے پر دستیاب ہونا لازم نہیں

ایک اور فرق بہت سی الجھنیں دور کرتا ہے۔ مشین پر کسی port کا open ہونا، یعنی کوئی program اس port پر listening کر رہا ہو، اس port کے باہر سے reachable ہونے سے مختلف ہے، یعنی firewall اس تک network traffic کی اجازت دے رہا ہو۔ کسی remote client کے connect ہونے کے لیے دونوں شرائط پوری ہونا ضروری ہیں۔ Client کی جانب سے دونوں failures بھی مختلف دکھائی دیتی ہیں: connection refused ہونے کا مطلب ہے کہ کوئی process listening نہیں کر رہا، جبکہ connection کا معلق رہنے کے بعد timeout ہونا عموماً اس بات کی علامت ہے کہ firewall نے packet drop کر دیا ہے۔ یہی وہ بات ہے جو SSH کی ان دونوں errors سے واضح ہوتی ہے۔

لہٰذا control کی دو سطحیں ہیں۔ آپ ہر service کا bind address مقرر کر کے طے کرتے ہیں کہ کون سی service کہاں listening کرے گی۔ اور firewall کے ذریعے طے کرتے ہیں کہ باہر سے کن services تک رسائی ممکن ہو۔ اچھی طرح managed server میں دونوں طریقے استعمال ہوتے ہیں: services صرف ان addresses پر bind ہوتی ہیں جہاں انہیں ضرورت ہو، اور firewall ہر اس چیز کو deny کرتا ہے جس کی آپ نے واضح طور پر اجازت نہ دی ہو۔ ss سے یہ دیکھنا کہ کون سی services listening کر رہی ہیں، پہلا قدم ہے؛ firewall کن connections کی اجازت دیتا ہے، یہ طے کرنا دوسرا قدم ہے۔ اس کی وضاحت UFW کے ساتھ firewalls 101 میں کی گئی ہے۔

یہاں ایک باریک نکتہ ہے جو اکثر مسائل پیدا کرتا ہے۔ IPv4 اور IPv6 الگ الگ ہیں، اور اگر firewall صرف IPv4 کو cover کرے تو IPv6 پر موجود [::] services کھلی رہ جاتی ہیں۔ اس مخصوص مسئلے پر الگ post موجود ہے: IPv6 firewall trap۔

FAQ

میں کیسے دیکھوں کہ میرے Linux server پر کون سے ports کھلے ہیں؟

TCP کے لیے sudo ss -tlnp یا UDP کے لیے sudo ss -ulnp چلائیں۔ یہ ہر listening socket، port، اس local address کو دکھاتا ہے جس سے socket bind ہے، اور اس process کو بھی دکھاتا ہے جو اس کا مالک ہے۔ Local Address column دیکھیں: 0.0.0.0 یا [::] کا مطلب ہے کہ service network پر exposed ہے، جبکہ 127.0.0.1 کا مطلب ہے کہ یہ صرف اسی machine پر listening کر رہی ہے۔

0.0.0.0 اور 127.0.0.1 میں کیا فرق ہے؟

0.0.0.0 کا مطلب ہے "تمام IPv4 addresses پر listen کریں"، جس میں public address بھی شامل ہے، اس لیے service network سے قابل رسائی ہو سکتی ہے۔ 127.0.0.1 loopback address ہے۔ Machine اسی address کے ذریعے خود سے رابطہ کرتی ہے، اور یہ کسی دوسری جگہ سے routable نہیں ہے۔ اس لیے اس سے bound service صرف مقامی طور پر قابل رسائی ہوتی ہے۔ Internal services کو 127.0.0.1 سے bind کریں تاکہ وہ کبھی exposed نہ ہوں۔

کیا service کے کام کرنے کے لیے firewall میں port کھولنا ضروری ہے؟

صرف ان services کے لیے جو دوسری machines سے قابل رسائی ہونی چاہییں۔ 127.0.0.1 سے bound service کے لیے firewall rule کی ضرورت نہیں، کیونکہ کوئی external system بہرحال اس تک نہیں پہنچ سکتا۔ 0.0.0.0 یا [::] پر چلنے والی service کے لیے traffic کی اجازت دینے والا firewall rule درکار ہے۔ Rule شامل کرنے تک اسے default طور پر deny رہنا چاہیے۔

TCP port اور UDP port میں کیا فرق ہے؟

TCP connection-based ہے اور زیادہ تر services، مثلاً SSH، web servers اور databases، اسے استعمال کرتی ہیں۔ UDP connectionless ہے اور DNS اور بعض VPNs میں استعمال ہوتا ہے۔ TCP اور UDP میں ایک ہی number الگ ports ہوتے ہیں، اس لیے 53/tcp اور 53/udp مختلف ports ہیں۔ Firewall rules لکھتے وقت protocol کا نام درج کریں، مثلاً 22/tcp۔