VPS hosting কি নিরাপদ? আপনি কী নিয়ন্ত্রণ করেন

VPS hosting কি নিরাপদ? সংক্ষিপ্ত উত্তর

হ্যাঁ। অধিকাংশ মানুষ যে কাজের জন্য VPS hosting নেন, তার জন্য এটি নিরাপদ এবং shared hosting-এর তুলনায় এটি বাস্তব উন্নতি। VPS (virtual private server) হলো এমন একটি virtual machine যার নিজস্ব kernel, নিজস্ব memory, নিজস্ব disk এবং নিজস্ব user account থাকে। এটি চালানো hypervisor অন্য গ্রাহকদের এই চারটি সম্পদ থেকেই আলাদা রাখে। একই physical machine-এ আপনার পাশের server ভাড়া নেওয়া ব্যক্তি আপনার file পড়তে, process-এর তালিকা দেখতে, আপনার server-এ login করতে বা আপনার network traffic দেখতে পারেন না।

সৎ উত্তরটির দুটি দিক আছে। Provider hardware এবং hypervisor-এর মালিক। আপনার virtual machine-এর ভেতরের সবকিছুর দায়িত্ব আপনার, এবং প্রায় সব বাস্তব security incident সেখান থেকেই শুরু হয়। একটি খোলা port, দুর্বল SSH password, আপডেট না করা package অথবা প্রকাশিত হয়ে যাওয়া file-এর কোনো secret-এর মাধ্যমে server-এ অননুমোদিত প্রবেশ ঘটে। hypervisor-এর মাধ্যমে এ ধরনের অননুমোদিত প্রবেশ খুবই বিরল।

হাইপারভাইজার আসলে কী আলাদা রাখে

একটি hypervisor হলো সেই software, যা একটি physical host-এ virtual machine চালায়। KVM VPS-এ (KVM-এর অর্থ kernel based virtual machine; Linux host-এ এটিই standard) আপনার server একটি পূর্ণাঙ্গ virtual machine। এটি নিজের kernel boot করে। host এটিকে physical memory-এর একটি নির্দিষ্ট অংশ দেয়। processor-এর memory management unit ওই অংশের বাইরে কোনো access প্রত্যাখ্যান করে। তাই অন্য guest-এ চলা code আপনার RAM address করতে পারে না। কোনো shared filesystem বা shared user table নেই। তাই পাশের server-এর file permission আপনার server-এ কোনো প্রভাব ফেলে না।

Shared hosting ভিন্নভাবে কাজ করে। একটি operating system-এর মধ্যে, একটি web server ও একটি PHP install-এর অধীনে, বহু site সাধারণ user account হিসেবে চলে। একমাত্র boundary হলো file permission। কোনো permission ভুল থাকলে, অথবা অতিরিক্ত file পড়তে পারে এমন user হিসেবে চলা কোনো vulnerable plugin থাকলে, সেটি অন্য account-এর file-এ পৌঁছাতে পারে। shared hosting থেকে VPS-এ স্থানান্তর এই সীমাবদ্ধতা দূর করে।

আপনি কী কিনছেন তা যাচাই করুন। কারণ VPS নামে বিক্রি হওয়া প্রতিটি plan virtual machine নয়। Container based plan (OpenVZ, LXC, Virtuozzo) host-এর kernel share করে। এগুলো hardware virtualization-এর বদলে namespace ও cgroup ব্যবহার করে customer-দের আলাদা রাখে। এই boundary দুর্বল। কারণ host-এর kernel-এ কোনো bug থাকলে আপনার server-এও একই kernel bug থাকে। এসব plan-এ kernel module load করাও যায় না। ফলে কিছু software ব্যবহার করা সম্ভব হয় না। KVM হলো নিরাপদ default। অর্থ দেওয়ার আগে আপনি কোনটি পাচ্ছেন তা জেনে নিন।

একজন সমস্যাজনক প্রতিবেশী আপনার ওপর কী প্রভাব ফেলতে পারে

একটি physical host ভাগ করলে আপনার গতি কমতে পারে। এটিই এর একমাত্র খরচ। একই মেশিনের guest-গুলো physical CPU ও disk ভাগ করে ব্যবহার করে। অন্য কোনো guest-এর কাজের কারণে CPU ব্যস্ত থাকলে আপনার virtual CPU অপেক্ষা করে। Linux এই অপেক্ষাকে steal time হিসেবে দেখায়: %st-এর top এবং vmstat field-এ। Steal time যদি কয়েক ঘণ্টা ধরে কয়েক শতাংশের বেশি থাকে, তাহলে host-এ অতিরিক্ত guest বরাদ্দ করা হয়েছে। এর অর্থ কেউ আপনার data পড়ছে না। সমাধান হলো অন্য plan বা অন্য provider বেছে নেওয়া। সিদ্ধান্ত নেওয়ার আগে আপনি বাস্তবে পাওয়া CPU ও disk মাপতে পারেন।

অন্য customer-এর কারণে আপনার ওপর যে একটি প্রভাব পড়তে পারে, তা জানা দরকার। এটি কোনো security hole নয়। আপনি যদি আপনার VPS থেকে email পাঠান, তাহলে আপনার IP address এমন একটি range-এর অন্তর্ভুক্ত থাকে, যা অন্য customer-রাও ব্যবহার করে। কোনো প্রতিবেশী spam পাঠালে সেই range-এর একটি অংশ blocklist-এ যুক্ত হতে পারে। ফলে আপনার mail spam folder-এ পৌঁছাতে পারে, যদিও সমস্যাটি আপনি তৈরি করেননি। Abuse নিয়ন্ত্রণ করে এমন provider-রা সাধারণত পরিষ্কার range বজায় রাখে। Email আপনার জন্য গুরুত্বপূর্ণ হলে এ বিষয়ে জিজ্ঞাসা করুন।

একজন শত্রুভাবাপন্ন প্রতিবেশী কী করতে পারে না, এবং বিরল ক্ষেত্রে কখন পারে

একই host-এর কোনো customer আপনার file-এ পৌঁছানোর পথ পায় না। তারা আপনার process দেখতে, আপনার disk mount করতে বা আপনার server-এ shell খুলতে পারে না, কারণ এসব কোনো কিছুই তাদের virtual machine-এর ভিতরে নেই। একটি ব্যতিক্রম উল্লেখ করা প্রয়োজন: provider-এর private network-কে অপরিচিত ব্যক্তিদের সঙ্গে shared network হিসেবে বিবেচনা করুন। এই network-এর ওপর দিয়ে যেসব data যায়, সেগুলো encrypt করুন। এটি অদৃশ্য ধরে নেবেন না।

Hypervisor escape বাস্তব ঝুঁকি। Virtualization layer-এর কোনো bug একটি guest-এর ভিতরের code-কে host-এ পৌঁছানোর সুযোগ দিতে পারে। এরপর host থেকে ওই host-এর প্রতিটি guest-এ পৌঁছানো সম্ভব হতে পারে। এসব bug খুঁজে পাওয়া হলে CVE (common vulnerabilities and exposures) identifier দিয়ে প্রকাশ করা হয় এবং patch দেওয়া হয়। Hosting provider-রা দ্রুত patch দেয়, কারণ তাদের পুরো ব্যবসা ওই layer-এর ওপর নির্ভর করে। এই আক্রমণ চালাতে নির্দিষ্ট hypervisor version-এর জন্য কার্যকর exploit দরকার হয়। ছোট একটি hosting account-এর বিরুদ্ধে ব্যয় করার মতো মূল্যবান সম্পদ এটি সাধারণত নয়।

Cross-guest side channel-ও বাস্তব ঝুঁকি। Spectre এবং Meltdown এই পরিবারের উদাহরণ। এগুলো shared processor cache ব্যবহার করে একটি boundary-এর ওপারের অল্প পরিমাণ data অনুমান করে। Microcode এবং kernel update এগুলোর প্রভাব কমায়। প্রকাশিত গবেষণায় leak rate অত্যন্ত কম। প্রকাশিত ঘটনাগুলো mass attack নয়; এগুলো মূলত research demonstration। ঝুঁকি শূন্য নয়। তবে যেসব কারণে আপনি ক্ষতিগ্রস্ত হতে পারেন, সেগুলোর তালিকায় এটি শীর্ষের কাছাকাছিও নয়।

প্রোভাইডারের দায়িত্ব যেখানে শেষ এবং আপনার দায়িত্ব যেখানে শুরু

প্রোভাইডার building, host hardware, hypervisor ও host kernel, physical network এবং সেই control panel-এর জন্য দায়ী, যেটি আপনার server start, stop, rebuild ও snapshot করতে পারে। এগুলোর কোনোটি ব্যর্থ হলে সেটি ঠিক করার দায়িত্ব প্রোভাইডারের।

আপনার দায়িত্ব operating system থেকে শুরু করে তার ওপরের সবকিছুর। এর মধ্যে আপনি যে packages install করেন, যে ports open রাখেন, যেসব accounts ও cryptographic keys দিয়ে login করা যায়, যে updates প্রয়োগ করেন, আপনার backups এবং আপনার নিজের application code অন্তর্ভুক্ত। অধিকাংশ VPS plan unmanaged। অর্থাৎ আপনার server patch করার দায়িত্ব অন্য কেউ নেবে না এবং কোনো support ticket দিয়েও এই কাজ করানো যাবে না। কেনার আগে managed ও unmanaged ব্যবস্থার পার্থক্য পড়ে নেওয়া ভালো, কারণ এই তালিকার কতটা দায়িত্ব আপনার ওপর পড়বে তা সেটিই নির্ধারণ করে।

আপনার দায়িত্বের একটি অংশ সহজেই ভুলে যাওয়া যায়: hosting control panel নিজেই। যে ব্যক্তি ওই login-এর নিয়ন্ত্রণে থাকে, সে server-এর ভেতরের কোনো password না জেনেও আপনার server rebuild করতে বা আপনার disk একটি rescue system-এ attach করতে পারে। Hosting account-এ two factor authentication (2FA) চালু করুন এবং ওই password অন্য কোথাও পুনরায় ব্যবহার করবেন না।

আপনার hosting provider কি আপনার data দেখতে পারে?

হ্যাঁ, নীতিগতভাবে পারে। VPS আপনাকে যে সুরক্ষা দেয়, তার সৎ সীমা এটাই। আপনার disk image provider-এর storage-এ থাকে। তাদের console আপনার virtual machine-এ screen-level access দেয়। Rescue mode আপনার disk সংযুক্ত করে অন্য একটি system boot করতে পারে। VPS আপনাকে অন্য customer-দের থেকে সুরক্ষা দেয়। তবে provider এই সুরক্ষা-প্রতিশ্রুতির আওতায় থাকে না।

যে data host-এর কাছেও অপাঠ্য রাখতে হবে, তা লেখার আগে application-এ encrypt করুন। Guest-এর ভিতরে full disk encryption ব্যবহার করলে সংরক্ষিত অবস্থায় copied image-এর বিরুদ্ধে সুরক্ষা পাওয়া যায়। তবে server চলার সময় key-টি memory-তে থাকতে হয়। তাই provider-কে এই security model-এর বাইরে রাখা যায় না। একই trust model প্রযোজ্য আপনার এককভাবে ভাড়া নেওয়া dedicated server-এর ক্ষেত্রেও। তবে সেখানে একটি shared layer কম থাকে।

VPS-এ বাস্তবে কীভাবে অনুপ্রবেশ ঘটে

প্রতিটি interface-এ listen করা service। Database, cache, message queue এবং admin panel প্রায়ই ডিফল্টভাবে 0.0.0.0-এ bind করে। এর অর্থ public interface-সহ প্রতিটি network interface-এ service-টি listen করছে। Internet জুড়ে scanning সব সময় স্বয়ংক্রিয়ভাবে চলে। তাই নতুন কোনো IP address online হওয়ার কয়েক মিনিটের মধ্যেই সেটি প্রথম unsolicited probe পেয়ে যায়। Password ছাড়া Redis, authentication-বিহীন Elasticsearch node, port 2375-এ উন্মুক্ত Docker API এবং default login ব্যবহার করা admin panel—এসবই এভাবে খুঁজে পাওয়া যায়। Scanner আপনাকে চেনে না বা আপনার পরিচয় জানে না। শুধু local machine-এর প্রয়োজন হলে service-টিকে 127.0.0.1-এ bind করুন এবং বাকি access firewall-এ block করুন।

Docker আপনার firewall-এর নিয়ম এড়িয়ে যাচ্ছে। কোনো container port publish করলে এমন network address translation (NAT) rule তৈরি হয়, যা ufw (uncomplicated firewall)-এর rule-এর আগে মূল্যায়ন করা হয়। তাই ufw status-এ ওই port denied দেখালেও container-টি Internet থেকে reachable হতে পারে। অন্য সবকিছু সঠিকভাবে করা ব্যবহারকারীরাও এই সমস্যায় পড়েন। Container port publish করার আগে Docker port কেন ufw-এর নিয়ম উপেক্ষা করে তা পড়ে নেওয়া ভালো।

Password চালু থাকা SSH। কোনো public server-এ /var/log/auth.log পড়লে Failed password for root from 203.0.113.10 port 54312 ssh2-এর মতো হাজার হাজার line দিনরাত দেখতে পাবেন। Bot-গুলো প্রচলিত username এবং প্রচলিত password দিয়ে চেষ্টা চালায়। Password login চালু থাকা এবং login গ্রহণকারী root account—আক্রমণকারীর জন্য এটুকুই যথেষ্ট। শুধু key ব্যবহার করলে এবং root login বন্ধ রাখলে এই traffic উপেক্ষা করার মতো noise-এ পরিণত হয়।

সব জায়গায় একই private key ব্যবহার করা। প্রতিটি laptop এবং প্রতিটি server-এ একই key copy করা থাকলে একটি চুরি হওয়া laptop দিয়েই সবকিছুতে প্রবেশ করা যায়। SSH key-এর মেয়াদ শেষ হয় না। তাই দুই বছর আগে কোনো contractor-কে দেওয়া key আজও কাজ করতে পারে। প্রতিটি ব্যক্তি ও প্রতিটি machine-এর জন্য একটি করে key ব্যবহার করতে কোনো খরচ নেই এবং একটি চুরি হওয়া key কী কী access করতে পারবে, তা সীমিত করে।

যে package-গুলো কেউ update করেনি। আপনার web server বা application framework-এর বিরুদ্ধে প্রকাশিত কোনো CVE আসলে সেটি কাজে লাগানোর প্রকাশ্য নির্দেশনা। Scanner-গুলো কয়েক দিনের মধ্যেই সেই দুর্বলতার জন্য পরীক্ষা শুরু করে। Security update হলো সবচেয়ে কম খরচের প্রতিরক্ষা। এগুলো স্বয়ংক্রিয়ভাবেও চালানো যায়: Ubuntu-তে automatic security update দেখুন।

ফাঁস হওয়া secret। Database password এবং API key .env file-এ রাখা থাকে। পরে সেই file public repository-তে commit হয়ে যায়, অথবা ভুল directory-তে নির্দেশ করা web server সেটি serve করে। কোনো AI coding agent-এর context-এ paste করা তথ্যও log-এ চলে যেতে পারে। এটি আলাদা একটি বিষয়: agent-এর access থেকে secret দূরে রাখা।

সবকিছু root হিসেবে চালানো। আপনার application root হিসেবে চললে application-এর একটি bug পুরো machine-এর নিয়ন্ত্রণ পেয়ে যায়। কারণ server-এর ভেতরে সেটি ছড়িয়ে পড়া ঠেকানোর মতো আর কোনো boundary থাকে না।

আপনার দায়িত্বের অংশ

নিচের কোনো কাজই hypervisor-সংক্রান্ত নয়। এগুলো সব আপনার দায়িত্বের অংশ। আপনার VPS নিরাপদ কি না, তা মূলত এই কাজগুলোর ওপর নির্ভর করে।

• প্রথম ঘণ্টার কাজ সঠিকভাবে করুন: নতুন VPS-এর প্রথম দশ মিনিট-এ non-root user এবং firewall সেটআপের বিষয়টি দেখানো হয়েছে।
• Remote access সুরক্ষিত করুন: VPS-এ SSH hardening।
• যেসব port ব্যবহার করছেন না, সেগুলো বন্ধ করুন: ufw firewall-এর মৌলিক বিষয়।
• প্রতিটি service-কে শুধু প্রয়োজনীয় access দিন: VPS-এ least-privilege user।
• Brute-force login ধীর করুন: Ubuntu 24.04-এ fail2ban।
• অন্তত একবার restore করেছেন—এমন একটি backup রাখুন: VPS-এর জন্য restic backup।

আপনার server boot হওয়ার সময় provider-এর দায়িত্বের অংশ ইতিমধ্যে সম্পন্ন হয়ে যায়। প্রথম দিনে আপনার প্রায় এক ঘণ্টা সময় লাগবে। এরপর মাসে কয়েক মিনিটই যথেষ্ট। আপনি যদি এখনও বিভিন্ন বিকল্প তুলনা করে থাকেন, VPS আসলে কী-তে এই সবকিছুর ভিত্তি ব্যাখ্যা করা হয়েছে।

FAQ

একই physical server-এ থাকা অন্য customer কি আমার file পড়তে পারে?

না, KVM VPS-এ পারে না। আপনার server একটি virtual machine। এর নিজস্ব kernel, নিজস্ব virtual disk এবং host কর্তৃক বরাদ্দ করা physical memory-এর একটি নির্দিষ্ট অংশ থাকে। Processor ওই memory region-এর বাইরে কোনো access block করে। Guest-গুলোর মধ্যে কোনো shared filesystem নেই। তাই পাশের server-এর ভিতরের file permission আপনার server-এর ভিতরে কার্যকর নয়। OpenVZ এবং LXC-এর মতো container-based plan host kernel ভাগ করে এবং তুলনামূলক দুর্বল isolation দেয়। তাই কোন ধরনের plan কিনছেন তা যাচাই করুন।

Shared hosting কি VPS-এর চেয়ে নিরাপদ?

Isolation-এর ক্ষেত্রে, হ্যাঁ। Shared hosting-এ অনেক site একই operating system-এর ভিতরে চলে। সেখানে একমাত্র boundary হলো file permission। তাই অন্য account-এ কোনো ভুল হলে কখনও কখনও file প্রকাশ পেতে পারে। VPS-এ boundary হলো একটি virtual machine। তবে shared hosting-এ host patch প্রয়োগ করে, আর unmanaged VPS-এ আপনাকেই patch প্রয়োগ করতে হয়। আপনি update প্রয়োগ এবং port বন্ধ রাখলেই VPS নিরাপদ।

Hosting provider কি আমার data পড়তে পারে?

নীতিগতভাবে, পারে। কোনো VPS product এই বিষয়টি পরিবর্তন করে না। Disk image provider-এর hardware-এ সংরক্ষিত থাকে। Console চলমান machine-এ screen-level access দেয়। Rescue mode আপনার disk সংযুক্ত করে অন্য একটি system boot করতে পারে। কোনো data host-এর কাছে unreadable রাখতে হলে তা লেখার আগে application-এ encrypt করুন। Guest-এর ভিতরের disk encryption server চলার সময় key memory-তে রাখে। তাই provider-কে trust boundary থেকে বাদ দেয় না।

VPS compromise হওয়ার সবচেয়ে সাধারণ উপায় কী?

বিস্তর ব্যবধানে, exposed service অথবা দুর্বল SSH login। Automated scanner প্রতিটি public IP address ক্রমাগত probe করে। তাই password ছাড়া 0.0.0.0-এ bind করা database অথবা default credential-এ রেখে দেওয়া admin panel মাসের বদলে কয়েক মিনিটের মধ্যে শনাক্ত হয়ে যায়। /var/log/auth.log যেকোনো public server-এ এর SSH অংশটি দেখায়: সারা বিশ্বের বিভিন্ন address থেকে আসা পুনরাবৃত্ত Failed password for root line। Hypervisor escape-এর ঘটনা আছে। তবে সেগুলো high-value target-কে লক্ষ্য করা research-grade কাজ। সাধারণ breach-এর কারণ এগুলো নয়।