Linux সার্ভারে পোর্ট কী এবং কোন সার্ভিস কোন পোর্টে চলছে
পোর্ট হলো একটি 16-bit সংখ্যা যা সার্ভারে ট্রাফিক সঠিক সার্ভিসে পৌঁছে দেয়। ss কমান্ড দিয়ে দেখুন কোন পোর্টে কী listen করছে এবং local ও public পোর্টের পার্থক্য বুঝুন।
পোর্ট আসলে কী
পোর্ট হলো একটি সংখ্যা, যা একটি সার্ভারে একই সঙ্গে অনেক সার্ভিস চালানোর সুবিধা দেয়, কিন্তু তাদের ট্রাফিক একসঙ্গে মিশে যায় না। আপনার VPS-এর একটি IP address আছে, কিন্তু তাতে একই সময়ে একটি web server, একটি SSH server এবং একটি database চলতে পারে। কোনো প্যাকেট এলে অপারেটিং সিস্টেমকে জানতে হয় সেটি কোনটির জন্য। পোর্ট সংখ্যাই এর উত্তর। Web ট্রাফিক যায় পোর্ট 443-এ, SSH যায় পোর্ট 22-এ। IP address প্যাকেটটিকে আপনার সার্ভারে পৌঁছে দেয়; পোর্ট সেটিকে সার্ভারের সঠিক প্রোগ্রামের কাছে পৌঁছে দেয়।
পোর্ট হলো একটি 16-bit সংখ্যা: 16 bit মানে 0 থেকে 65535, এবং 0 সংরক্ষিত, তাই বাস্তবে পোর্ট চলে 1 থেকে 65535 পর্যন্ত। 1024-এর নিচের পোর্টগুলো হলো "well-known" পোর্ট এবং খুলতে root প্রয়োজন, তাই স্ট্যান্ডার্ড সার্ভিসগুলো এখানেই থাকে: SSH-এর জন্য 22, HTTP-এর জন্য 80, HTTPS-এর জন্য 443, DNS-এর জন্য 53। 1024-এর ওপরের যেকোনো পোর্ট সাধারণ প্রোগ্রামের জন্য ব্যবহারযোগ্য।
এর দুটি ধরন আছে, TCP এবং UDP, এবং এক ধরনের পোর্ট সংখ্যা অন্য ধরনের একই সংখ্যা থেকে আলাদা। TCP হলো কানেকশন-ভিত্তিক প্রোটোকল যা বেশিরভাগ সার্ভিস ব্যবহার করে, যেমন SSH, HTTP এবং database। UDP হলো কানেকশনবিহীন এবং এটি DNS ও কিছু VPN-এর মতো কাজে ব্যবহৃত হয়। আপনি যখন ফায়ারওয়াল খোলেন, তখন সাধারণত উল্লেখ করেন কোনটি, যেমন 22/tcp।
Listening মানে একটি প্রোগ্রাম পোর্টে অপেক্ষা করছে
যে প্রোগ্রাম কানেকশন গ্রহণ করতে চায়, সে কার্নেলকে একটি পোর্টে "listen" করতে বলে। সেই মুহূর্ত থেকে মেশিনে সেই পোর্টটি খোলা থাকে এবং ফায়ারওয়ালের শর্ত মেনে প্রোগ্রামটি সেখানে আসা সবকিছুর উত্তর দেয়। যে পোর্টে কিছু listen করছে না, সেটি সরাসরি কানেকশন প্রত্যাখ্যান করে। তাই যেকোনো নিরাপত্তা পরীক্ষার প্রথম প্রশ্ন হলো: কী listen করছে, এবং কোথায়।
এর উত্তর দেওয়ার কমান্ড হলো ss:
sudo ss -tlnpফ্ল্যাগগুলোর মানে হলো TCP (t), শুধুমাত্র listening সকেট (l), সংখ্যাসূচক পোর্ট (n, যাতে আপনি ssh নয় বরং 22 দেখেন), এবং মালিকানাধীন প্রসেস (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 nginxProcess কলাম আপনাকে বলে কোন প্রোগ্রাম প্রতিটি পোর্টের মালিক, আর এভাবেই আপনি এমন কিছু খুঁজে বের করেন যা চালানো আপনার উদ্দেশ্য ছিল না।
Local Address কলামটিই গুরুত্বপূর্ণ অংশ
প্রতিটি পোর্টের সামনের ঠিকানাটি মনোযোগ দিয়ে পড়ুন, কারণ এটিই নির্ধারণ করে কে সার্ভিসটিতে পৌঁছাতে পারবে। আপনি যে তিনটি অবস্থা প্রায়ই দেখবেন সেগুলো হলো:
0.0.0.0:22 মানে "এই মেশিনের প্রতিটি IPv4 ঠিকানায় listen করা," তার পাবলিক ঠিকানাসহ। ফায়ারওয়াল অনুমতি দিলে সার্ভিসটি IPv4-এ ইন্টারনেট থেকে পৌঁছানো যায়।
[::]:80 মানে IPv6-এর জন্য একই কথা: প্রতিটি IPv6 ঠিকানায় listen করা, পাবলিক ঠিকানাসহ। অনেক প্রোগ্রাম ডিফল্টভাবে এখানে bind করে, এবং Linux-এ একটি :: সকেট প্রায়ই IPv4-ও গ্রহণ করে।
127.0.0.1:5432 মানে "শুধুমাত্র loopback-এ listen করা।" 127.0.0.1 হলো সেই ঠিকানা যা একটি মেশিন নিজের সঙ্গে কথা বলার জন্য ব্যবহার করে, এবং এটি অন্য কোথাও থেকে routable নয়। এখানে bind করা একটি সার্ভিস শুধুমাত্র একই সার্ভার থেকে পৌঁছানো যায়, ইন্টারনেট থেকে কখনোই নয়, আপনার ফায়ারওয়াল যাই বলুক না কেন। উপরের Postgres লাইনটি গঠনগতভাবেই নিরাপদ।
এর থেকে সরাসরি একটি ব্যবহারিক নিয়ম বেরিয়ে আসে: একটি database, একটি cache, বা একটি admin panel যা শুধুমাত্র আপনার নিজের অ্যাপ্লিকেশন ব্যবহার করে, সেটি 0.0.0.0 নয় বরং 127.0.0.1-এ bind করা উচিত। এটি যদি কখনো পাবলিক ঠিকানায় listen না করে, তবে আক্রমণকারীর পৌঁছানোর মতো কিছুই থাকে না।
Listening আর reachable এক জিনিস নয়
আরও একটি পার্থক্য অনেক ভুল বোঝাবুঝি দূর করে। মেশিনে একটি পোর্ট খোলা থাকা, অর্থাৎ একটি প্রোগ্রাম listen করছে, এটি বাইরে থেকে সেই পোর্টে reachable হওয়ার সমতুল্য নয়, যার মানে ফায়ারওয়াল এটি অনুমতি দিচ্ছে। একটি রিমোট ক্লায়েন্টের কানেক্ট করার জন্য দুটিই সত্য হতে হবে।
তাই নিয়ন্ত্রণের দুটি স্তর আছে। আপনি প্রতিটি সার্ভিসের bind address সেট করে ঠিক করেন কী listen করবে। আর ফায়ারওয়াল দিয়ে আপনি ঠিক করেন বাইরের জগৎ কী পৌঁছাতে পারবে। একটি সুপরিচালিত সার্ভার দুটিই ব্যবহার করে: সার্ভিসগুলো শুধু যেখানে প্রয়োজন সেখানেই bind করে, এবং ফায়ারওয়াল এমন সবকিছু প্রত্যাখ্যান করে যা আপনি স্পষ্টভাবে অনুমতি দেননি। ss দিয়ে কী listen করছে তা পড়া হলো প্রথম ধাপ; ফায়ারওয়াল কী অনুমতি দেয় তা ঠিক করা হলো দ্বিতীয় ধাপ, যা UFW দিয়ে firewalls 101-এ আলোচনা করা হয়েছে।
এখানে একটি সূক্ষ্ম বিষয় আছে যা মানুষকে ফাঁদে ফেলে। IPv4 এবং IPv6 আলাদা, এবং একটি ফায়ারওয়াল যদি শুধু IPv4 কভার করে, তবে [::] সার্ভিসগুলো IPv6-এ খোলা থেকে যায়। এই নির্দিষ্ট ফাঁদটির জন্য একটি আলাদা পোস্ট আছে: IPv6 ফায়ারওয়াল ফাঁদ।
FAQ
আমার Linux সার্ভারে কোন পোর্টগুলো খোলা আছে তা কীভাবে দেখব?
TCP-এর জন্য sudo ss -tlnp অথবা UDP-এর জন্য sudo ss -ulnp চালান। এটি প্রতিটি listening সকেট, পোর্ট, যে লোকাল ঠিকানায় এটি bind করা, এবং এর মালিক প্রসেস তালিকাভুক্ত করে। Local Address কলামটি পড়ুন: 0.0.0.0 বা [::] মানে সার্ভিসটি নেটওয়ার্কে উন্মুক্ত, অন্যদিকে 127.0.0.1 মানে এটি শুধুমাত্র মেশিন নিজের মধ্যে listen করছে।
0.0.0.0 এবং 127.0.0.1-এর মধ্যে পার্থক্য কী?
0.0.0.0 মানে "সব IPv4 ঠিকানায় listen করা," পাবলিক ঠিকানাসহ, তাই সার্ভিসটিতে নেটওয়ার্ক থেকে পৌঁছানো যায়। 127.0.0.1 হলো loopback, ঠিকানাটি মেশিন নিজের সঙ্গে কথা বলার জন্য ব্যবহার করে, এবং এটি অন্য কোথাও থেকে routable নয়, তাই এতে bind করা একটি সার্ভিস শুধুমাত্র লোকালি reachable। অভ্যন্তরীণ সার্ভিসগুলো 127.0.0.1-এ bind করুন যাতে সেগুলো কখনো উন্মুক্ত না হয়।
একটি সার্ভিস কাজ করার জন্য কি ফায়ারওয়ালে পোর্ট খুলতে হবে?
শুধুমাত্র সেই সার্ভিসগুলোর জন্য যেগুলোতে অন্য মেশিন থেকে পৌঁছাতে হবে। 127.0.0.1-এ bind করা একটি সার্ভিসের কোনো ফায়ারওয়াল নিয়মের প্রয়োজন নেই, কারণ বাইরের কিছুই এতে পৌঁছাতে পারে না। 0.0.0.0 বা [::]-এর একটি সার্ভিসের ট্রাফিক অনুমতি দেওয়ার জন্য একটি ফায়ারওয়াল নিয়ম প্রয়োজন, এবং আপনি একটি যোগ না করা পর্যন্ত এটি ডিফল্টভাবে প্রত্যাখ্যান করা উচিত।
একটি TCP পোর্ট এবং একটি UDP পোর্টের মধ্যে পার্থক্য কী?
TCP হলো কানেকশন-ভিত্তিক এবং বেশিরভাগ সার্ভিস এটি ব্যবহার করে, যেমন SSH, web server এবং database। UDP হলো কানেকশনবিহীন এবং DNS ও কিছু VPN এটি ব্যবহার করে। TCP এবং UDP-তে একই সংখ্যা হলো আলাদা পোর্ট, তাই 53/tcp এবং 53/udp আলাদা। আপনি যখন ফায়ারওয়াল নিয়ম লেখেন তখন প্রোটোকল উল্লেখ করেন, যেমন 22/tcp।