VPS-এ IPv6 দিয়ে খোলা port বন্ধ করবেন যেভাবে

এক বাক্যে IPv6 firewall-এর ফাঁদ

আপনার firewall IPv4 সুরক্ষিত করে। আপনার VPS-এ প্রায় নিশ্চিতভাবেই একটি public IPv6 address আছে, এবং অনেক service ডিফল্টভাবে সেটিতে listening করে। আপনার firewall যদি শুধু IPv4 কভার করে, অথবা আপনি এমন cloud firewall-এর ওপর নির্ভর করেন যা শুধু IPv4 filter করে, তাহলে IPv4 অংশ locked down দেখালেও ওই সব service-এর প্রতিটিই IPv6-এর মাধ্যমে পুরো Internet থেকে reachable থাকে। আপনি curl দিয়ে একটি port test করে refused connection দেখতে পান এবং নিরাপদ বোধ করেন। একজন attacker একই port-এ IPv6-এর মাধ্যমে connect করে ভেতরে ঢুকে যায়।

এই guide-এ দেখানো হয়েছে, একটি সাধারণ Ubuntu 24.04 VPS-এ এই gap কোথা থেকে তৈরি হয়, আপনি ঠিক কী expose করছেন তা কীভাবে দেখবেন, এবং কীভাবে তা বন্ধ করবেন। এখানে UFW দোষী নয়। আধুনিক Ubuntu install-এ UFW ইতিমধ্যেই IPv6 পরিচালনা করে। Exposure তৈরি হয় এর চারপাশের layer-গুলো এবং আপনি যে service-গুলো listening করছে তা জানতেন না—সেগুলোর কারণে।

আপনার VPS শুরু থেকেই IPv6-এ কেন থাকে

বর্তমানে প্রায় প্রতিটি VPS-এ IPv4 address-এর পাশাপাশি একটি public IPv6 address, প্রায়ই একটি সম্পূর্ণ /64, দেওয়া হয়। আপনারটি পরীক্ষা করুন:

ip -6 addr show scope global

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    inet6 2001:db8:2a::1/64 scope global

ওই 2001:db8:2a::1 Internet-এর যেকোনো স্থান থেকে routable, ঠিক আপনার IPv4 address-এর মতো। এবার কোন কোন service listening করছে তা দেখুন:

sudo ss -tlnp

State   Recv-Q  Local Address:Port   Process
LISTEN  0       0.0.0.0:22           sshd
LISTEN  0       [::]:22              sshd
LISTEN  0       127.0.0.1:5432       postgres
LISTEN  0       [::]:8080            docker-proxy

Local Address column-টি ভালোভাবে দেখুন। 0.0.0.0:22-এর অর্থ হলো “প্রতিটি IPv4 address-এ listen করা।” [::]:22-এর অর্থ হলো “প্রতিটি IPv6 address-এ listen করা।” 127.0.0.1:5432 loopback-এর সঙ্গে bound এবং মোটেও public নয়, তাই Postgres-এর line-টি নিরাপদ। দুটি [::] line IPv6-এর মাধ্যমে সমগ্র Internet-এর অনুরোধের উত্তর দিচ্ছে, আর docker-proxy-টি সেই ধরনের service, যেটি আপনি চালু করেছিলেন কিন্তু পরে ভুলে গেছেন।

বেশিরভাগ daemon শুরুতেই ::-এর সঙ্গে bind করে, কারণ Linux-এ একটি :: socket সাধারণত IPv4 অনুরোধও গ্রহণ করে। তাই নতুন server-এর default posture হলো “দুই stack-এই, সর্বত্র অনুরোধের উত্তর দেওয়া।” এর সামনে আপনার firewall-ই একমাত্র প্রতিরক্ষা। তাই শুধু একটি stack দেখতে পাওয়া firewall একটি বাস্তব সমস্যা।

IPv6 ব্যবধান আসলে যেখান থেকে তৈরি হয়

এর 4টি সাধারণ উৎস আছে। কোনো একটি সার্ভারে এর মধ্যে একটি বা একাধিক কারণ একসঙ্গে থাকতে পারে।

1. এমন একটি cloud firewall, যা শুধু IPv4 ফিল্টার করে। অনেক provider firewall এবং security-group product IPv4-কেন্দ্রিকভাবে তৈরি হয়েছে। এগুলো IPv6 উপেক্ষা করতে পারে, অথবা আলাদা IPv6 rule প্রয়োজন হতে পারে, যা আপনাকে হাতে যোগ করতে হবে। আপনার একমাত্র firewall যদি provider dashboard-এর firewall হয় এবং সেটি IPv6 কভার না করে, তাহলে IPv4-এ port 22 সম্পর্কে যা-ই বলা থাকুক, আপনার [::] service উন্মুক্ত থাকবে। আপনার provider-এর firewall documentation পড়ুন এবং বিশেষভাবে IPv6 শব্দটি খুঁজুন।

2. ip6tables ছাড়া হাতে তৈরি iptables configuration। iptables command শুধু IPv4 table-এ প্রয়োগ হয়। IPv6-এর জন্য সম্পূর্ণ আলাদা command, ip6tables, এবং আলাদা rule রয়েছে। আপনি যদি iptables -A INPUT ... line-সমৃদ্ধ একটি firewall script লিখে থাকেন, কিন্তু সংশ্লিষ্ট ip6tables rule না লিখে থাকেন, তাহলে আপনার IPv6 firewall ফাঁকা থাকবে। Default ACCEPT policy-সহ ফাঁকা INPUT chain সব সংযোগ অনুমোদন করে:

sudo ip6tables -L INPUT -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

একটি screen-এ পুরো সমস্যাটি এখানে দেখা যায়। IPv4 ফিল্টার করা হচ্ছে, কিন্তু IPv6 সবার জন্য অনুমোদিত।

3. Docker firewall অতিক্রম করে সরাসরি port publish করছে। আপনি যখন docker run -p 8080:80 চালান, Docker UFW-এর rule-এর আগে নিজের rule যোগ করে। তাই ufw status কোনো port-কে denied দেখালেও published port-এ পৌঁছানো যায়। আধুনিক Docker-এ IPv6-এর ক্ষেত্রেও একই বিষয় প্রযোজ্য। Docker কীভাবে UFW অতিক্রম করে এবং container port সঠিকভাবে filter করবেন-এ mechanism এবং সমাধান ব্যাখ্যা করা হয়েছে। এই published port কীভাবে ঘোষণা করা হয়, তা জানতে VPS-এ Docker Compose-এর প্রাথমিক বিষয় দেখুন।

4. IPv6 বন্ধ থাকা UFW। UFW IPv6 পরিচালনা করতে পারে, তবে সেটি সক্রিয় করে দিতে হয়। Switch-এর অবস্থা দেখুন:

grep IPV6 /etc/default/ufw

আধুনিক Ubuntu-তে IPV6=yes থাকে, তাই UFW প্রতিটি rule উভয় stack-এ প্রয়োগ করে। আপনি যদি পুরোনো image বা পুরোনো guide থেকে IPV6=no দেখেন, তাহলে আপনার লেখা প্রতিটি UFW rule শুধু IPv4-এর জন্য প্রযোজ্য। IPv6 তখন অরক্ষিত অবস্থায় থাকে।

আপনি ঠিক কী উন্মুক্ত করছেন তা দেখুন

অনুমান করবেন না। বাইরে থেকে পরিমাপ করুন। প্রথমে আপনার listener-গুলোর তালিকা তৈরি করুন এবং ::-এর সঙ্গে bound থাকা প্রতিটি listener নোট করুন:

sudo ss -tlnp | grep '::'

এরপর অন্য একটি মেশিন থেকে সার্ভারের public IPv6 address-এ সংযোগ করুন এবং যে port-টি বন্ধ বলে মনে করছেন সেটিতে চেষ্টা করুন:

curl -6 -v http://[2001:db8:2a::1]:8080/

এতে যদি কোনো page বা banner দেখা যায়, তাহলে IPv6-এ port-টি open। বন্ধ port-এর ক্ষেত্রে Connection refused অথবা timeout দেখা যায়। এই দুটি failure একই সংকেত নয়। refused এবং timed out-এর পার্থক্য থেকে বোঝা যায় host উত্তর দিয়ে সংযোগ প্রত্যাখ্যান করেছে, নাকি firewall নীরবে আপনার packet drop করেছে। সম্পূর্ণ চিত্র পেতে সার্ভারের বাইরে থেকে nmap দিয়ে IPv6 address scan করুন:

nmap -6 2001:db8:2a::1

IPv6-এ nmap যে port-গুলোকে open হিসেবে দেখায়, সেগুলোতে IPv4 scan-এ যা-ই দেখা যাক, পুরো Internet থেকে পৌঁছানো যায়। IPv4 এবং IPv6 scan পাশাপাশি তুলনা করলে gap দ্রুত শনাক্ত করা যায়: -6-এ open কিন্তু IPv4-এ closed থাকা যেকোনো port এমন একটি service নির্দেশ করে, যেটি আপনার firewall সুরক্ষিত করছে না।

ফাঁক বন্ধ করুন

UFW-কে উভয় stack কভার করতে দিন এবং ডিফল্টভাবে deny করুন। পরিবর্তনটি নিশ্চিত করুন। এরপর inbound-এর জন্য default-deny policy সেট করুন এবং শুধু প্রয়োজনীয় জিনিস অনুমোদন করুন:

sudo sed -i 's/^IPV6=no/IPV6=yes/' /etc/default/ufw
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

IPV6=yes পরিবর্তন করার সময় UFW সক্রিয় থাকলে, sudo ufw reload চালানো পর্যন্ত পরিবর্তনটি কার্যকর হয় না।

ufw status প্রতিটি rule দুবার দেখায়: একবার সাধারণভাবে এবং একবার (v6) suffix-সহ। (v6) line দেখা গেলে বুঝবেন, UFW IPv6 filter করছে:

22/tcp                     ALLOW IN    Anywhere
22/tcp (v6)                ALLOW IN    Anywhere (v6)

আপনি যদি হাতে iptables পরিচালনা করেন, প্রতিটি rule ip6tables-এও অনুরূপভাবে যোগ করুন, অথবা nftables ব্যবহার করুন। nftables-এর inet table একই জায়গা থেকে IPv4 ও IPv6 কভার করে এবং এই ধরনের ভুলের সুযোগ দূর করে। নিজে rule লিখলে একটি nftables inet filter table ব্যবহার করাই সবচেয়ে পরিষ্কার সমাধান। আপনার VPS যদি Ubuntu-এর বদলে Rocky বা AlmaLinux চালায়, তাহলে configure করার মতো UFW নেই। সেক্ষেত্রে আপনি firewalld-কে front end হিসেবে পরিচালনা করবেন, যা একসঙ্গে উভয় stack-এ zone rule প্রয়োগ করে।

যেসব service public করতে চান না, সেগুলোকে loopback-এ bind করুন। Database, admin panel বা metrics endpoint-এর সাধারণত public address-এর প্রয়োজন হয় না। এগুলোকে 127.0.0.1 এবং ::1-এ bind করুন, যাতে শুরু থেকেই কোনো routable address-এ listen না করে। Postgres-এর জন্য listen_addresses = 'localhost' সেট করুন। App server-এর ক্ষেত্রে 127.0.0.1-এ bind করে সামনে একটি reverse proxy রাখুন। Listener বন্ধ করা firewall দিয়ে block করার চেয়ে কার্যকর, কারণ তখন পৌঁছানোর মতো কোনো listener থাকে না।

Docker-এর published port সুরক্ষার জন্য UFW-এর ওপর নির্ভর করবেন না। Container port প্রতিটি interface-এ publish না করে নির্দিষ্ট address-এ publish করুন, যেমন -p 127.0.0.1:8080:80। তাহলে port-এ শুধু host এবং আপনি ইচ্ছাকৃতভাবে যেসব proxy-তে traffic পাঠান, সেখান থেকেই পৌঁছানো যাবে। কোনো container সত্যিই public করতে হলে একটি Traefik reverse proxy-এর পেছনে রাখুন এবং প্রতিটি app নয়, শুধু proxy publish করুন।

আপনার provider firewall-এ IPv6 rule যোগ করুন, অথবা মেনে নিন যে IPv6-এর ক্ষেত্রে সেটি আপনার firewall নয়। সে ক্ষেত্রে host-এর UFW বা nftables-কে এই কাজ করতে দিন।

আপনি সত্যিই বন্ধ করেছেন কি না যাচাই করুন

পরিবর্তন করার পরে একই বাহ্যিক পরীক্ষা আবার চালান:

curl -6 -v http://[2001:db8:2a::1]:8080/
nmap -6 2001:db8:2a::1

আগে যে port সাড়া দিয়েছিল, সেটি এখন connection প্রত্যাখ্যান করবে অথবা timeout হবে। nmap-এর সেটিকে filtered বা closed হিসেবে দেখানো উচিত। কোনো port এখনও open থাকলে উপরের চারটি উৎস আবার পরীক্ষা করুন: কোনো service এখনও ::-এ bind করা আছে কিন্তু তার সামনে কোনো rule নেই, UFW-এর আগে কোনো Docker rule কার্যকর হচ্ছে, অথবা provider-এর firewall IPv6 traffic কখনও পরীক্ষা করেনি।

সংবেদনশীল service-গুলোকে সম্পূর্ণভাবে public Internet-এর বাইরে রাখা আরও নিরাপদ। SSH এবং admin panel-কে WireGuard VPN-এর পেছনে রাখুন এবং তাদের port-এ firewall প্রয়োগ করুন, যাতে সেগুলো কেবল tunnel-এর মাধ্যমে সাড়া দেয়। তাহলে IPv6 exposure-এর প্রশ্নটি আর তাদের ক্ষেত্রে প্রযোজ্য হবে না। public থাকা service-গুলোতে আসা brute-force scan ধীর করতে default-deny firewall-এর পাশাপাশি SSH-এর সামনে Fail2ban ব্যবহার করুন।

port আপনার কাছে নতুন হলে, আগে port কী এবং service কীভাবে listen করে পড়ুন।

FAQ

UFW কি ডিফল্টভাবে IPv6 ব্লক করে?

আধুনিক Ubuntu 24.04 ইনস্টলে, হ্যাঁ। UFW /etc/default/ufw থেকে IPV6=yes পড়ে এবং প্রতিটি rule IPv4 ও IPv6 উভয়ের জন্য প্রয়োগ করে। ufw status-এ IPv6 rule-গুলো (v6) suffix-সহ দেখা যায়। সমস্যা দেখা দেয় যখন IPV6=no (পুরোনো image বা পুরোনো tutorial থেকে), যখন আপনি এমন provider firewall-এর ওপর নির্ভর করেন যা শুধু IPv4 filter করে, অথবা যখন Docker UFW-এর নিয়ম পাশ কাটিয়ে একটি port publish করে। grep IPV6 /etc/default/ufw দিয়ে switch-এর অবস্থা পরীক্ষা করুন।

আমার VPS IPv6-এ কী expose করছে, তা কীভাবে পরীক্ষা করব?

sudo ss -tlnp চালান। যে প্রতিটি listener-এর local address [::] দিয়ে শুরু হয়, সেগুলো নোট করুন। এর অর্থ listener-টি প্রতিটি IPv6 interface-এ উত্তর দেয়। এরপর অন্য একটি machine থেকে server-এর public IPv6 address-এ সরাসরি curl -6 -v http://[YOUR:IPV6::ADDR]:PORT/ দিয়ে test করুন, অথবা nmap -6 YOUR:IPV6::ADDR দিয়ে scan করুন। IPv6 scan-এ খোলা কিন্তু IPv4-এ বন্ধ যেকোনো port-ই আপনার security gap।

UFW blocked দেখালেও Docker container-এর port-এ পৌঁছানো যায় কেন?

-p দিয়ে port publish করলে Docker UFW-এর আগে নিজের firewall rule বসায়। তাই ufw status port-টিকে denied হিসেবে দেখালেও published port-এ পৌঁছানো যায়। এটি IPv4-এ ঘটে। Docker-এর IPv6 support চালু থাকলে IPv6-এও ঘটে। -p 127.0.0.1:8080:80-এর মতো নির্দিষ্ট address-এ publish করুন, অথবা container-কে একটি reverse proxy-এর পেছনে রাখুন এবং শুধু proxy-টি publish করুন।

আমার IPv4 firewall শক্তভাবে configured হলে কি এখনও IPv6 firewall দরকার?

হ্যাঁ। IPv4 ও IPv6 আলাদা network stack এবং তাদের firewall rule-ও আলাদা। IPv4-এর নিখুঁত rule সেট IPv6 traffic-এর ওপর কোনো প্রভাব ফেলে না। আপনার VPS-এর public IPv6 address থাকলে—এবং প্রায় সব VPS-এই থাকে—::-এ listening করা যেকোনো service IPv6-এর মাধ্যমে reachable থাকে, যতক্ষণ না কোনো IPv6 firewall rule বা loopback binding সেটি বন্ধ করে।

কোনো service-কে কীভাবে শুধু IPv4-এ, অথবা শুধু localhost-এ listen করাব?

Service-এর নিজস্ব config-এ bind address সেট করুন। শুধু IPv4 loopback-এর জন্য 127.0.0.1-এ bind করুন। IPv6 listener ছাড়া সব IPv4 address-এর জন্য 0.0.0.0-এ bind করুন। Postgres listen_addresses ব্যবহার করে, SSH ListenAddress ব্যবহার করে, এবং অধিকাংশ app server-এ host বা bind flag থাকে। sudo ss -tlnp দিয়ে ফলাফল নিশ্চিত করুন এবং পরীক্ষা করুন যে Local Address-এ আর [::] দেখা যাচ্ছে না।