নতুন VPS নিরাপদ করার প্রথম 10 মিনিটের চেকলিস্ট

আপনার সার্ভার কতটা নিরাপদ, তা প্রথম 10 মিনিটেই নির্ধারিত হয়

একটি নতুন VPS নিরাপদ নয়। সার্ভারে public IP যুক্ত হওয়ার সঙ্গে সঙ্গেই scanner-গুলো লগইন করার চেষ্টা শুরু করে। Default image তাদের জন্য বড় আক্রমণ-লক্ষ্য তৈরি করে: root account প্রায়ই network-এর মাধ্যমে reachable থাকে, password authentication প্রায়ই চালু থাকে, firewall থাকে না, এবং নির্ধারিত সময়সূচি অনুযায়ী কোনো patch প্রয়োগ করা হয় না। ভালো বিষয় হলো, এগুলো বন্ধ করতে প্রায় 10 মিনিট এবং অল্প কয়েকটি command-ই যথেষ্ট। নতুন কোনো server-এ কিছু deploy করার আগে আমি প্রতিবার এই runbook অনুসরণ করি।

ধাপগুলো ক্রমানুসারে সম্পন্ন করুন, কারণ এগুলো পরস্পরের ওপর নির্ভরশীল। প্রতিটি ধাপের নিজস্ব guide আছে এবং প্রয়োজনমতো link দেওয়া হয়েছে। এই page-টি সেই guide-গুলোকে একত্র করা দ্রুততম পথ।

মিনিট 1: সবকিছু আপডেট করুন

আপনার provider দেওয়া credentials ব্যবহার করে root হিসেবে লগ ইন করুন। অন্য কিছু করার আগে system পুরোপুরি আপডেট করুন:

apt update && apt upgrade -y

যে system-এ patch প্রয়োগ করা হয়নি, সেটিই আক্রমণের সবচেয়ে সহজ লক্ষ্য। তাই এই কাজটি প্রথমে করুন। এটি শেষ হলে automatic security updates চালু করুন, যাতে আপনাকে মনে না রাখলেও system আপডেটেড থাকে।

মিনিট 2: sudo-সহ একটি সাধারণ ব্যবহারকারী তৈরি করুন

root হিসেবে কাজ চালিয়ে যাবেন না। নিজের জন্য একটি ব্যবহারকারী তৈরি করুন এবং তাকে sudo ব্যবহারের অনুমতি দিন:

adduser matt
usermod -aG sudo matt

এরপর থেকে এই ব্যবহারকারী হিসেবে লগ ইন করুন এবং প্রশাসনিক কাজের জন্য sudo ব্যবহার করুন। সব সময় root হিসেবে চললে প্রতিটি ভুল এবং প্রতিটি breached হওয়ার ঘটনা সীমাহীন ক্ষমতা নিয়ে ঘটে। unprivileged user হিসেবে চলা প্রতিরোধ করার উদ্দেশ্যই হলো এটি।

মিনিট 4: SSH key সেট আপ করুন

Password অনুমান করা যায়; key অনুমান করা যায় না। আপনার নিজের laptop-এ আগে থেকে key না থাকলে একটি তৈরি করুন:

ssh-keygen -t ed25519

এরপর public অংশটি server-এ কপি করুন:

ssh-copy-id matt@YOUR_SERVER

নতুন user-এর জন্য ssh-copy-id-এ password login চালু থাকতে হবে। এটি আগে থেকেই বন্ধ থাকলে root-এর ~/.ssh/authorized_keys-কে /home/matt/.ssh/authorized_keys-এ কপি করুন (যার মালিক হবে matt), অথবা আপনার public key নিজে হাতে ওই file-এ পেস্ট করুন।

এই ধাপের পেছনের ধারণা—প্রতিটি device-এর জন্য একটি key, key login ব্যর্থ করার মতো permission, এবং হারানো key বাতিল করা—SSH key management-এর মৌলিক বিষয়-এ ব্যাখ্যা করা হয়েছে।

key ব্যবহার করে matt হিসেবে logout করে আবার login করুন এবং পরবর্তী ধাপে যাওয়ার আগে এটি কাজ করছে কি না নিশ্চিত করুন। key দিয়ে login করতে পারার আগেই SSH কঠোরভাবে সীমাবদ্ধ করলে নিজেকেই server থেকে আটকে ফেলতে পারেন। login-এর সময় Permission denied (publickey) দেখা গেলে password-এ ফিরে না গিয়ে এখনই সমস্যাটি সমাধান করুন, কারণ ওই একটি message পাঁচটি ভিন্ন সমস্যাকে নির্দেশ করতে পারে এবং ssh -v output-এ আপনি আসলে কোন সমস্যায় পড়েছেন তা দেখা যাবে।

মিনিট 6: root login এবং password বন্ধ করুন

আপনার key এখন কাজ করছে। তাই scanner-নির্ভর দুটি প্রবেশপথ বন্ধ করুন। একটি drop-in file ব্যবহার করুন, যাতে package upgrade এটিকে overwrite না করে। এর নাম 00- দিন, যাতে এটি 50-cloud-init.conf-এর আগে sort হয়। Ubuntu cloud image-গুলো 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

তারপর sshd বাস্তবে যে settings ব্যবহার করছে, তা পরীক্ষা করুন। এতে অকার্যকর drop-in আপনাকে বিভ্রান্ত করতে পারবে না:

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

password বন্ধ এবং root login নিষ্ক্রিয় থাকলে আপনার server-এ চলমান brute-force network traffic সফল হতে পারবে না। ঐচ্ছিক port পরিবর্তনসহ সম্পূর্ণ নির্দেশনা VPS-এ SSH hardening-এ রয়েছে।

মিনিট 8: Firewall চালু করুন

Inbound সব সংযোগের জন্য default-deny সেট করুন। এরপর শুধু প্রয়োজনীয় সংযোগ অনুমোদন করুন। এটি চালু করার আগে SSH অনুমোদন করুন। নইলে নিজের সংযোগ বিচ্ছিন্ন হয়ে যাবে:

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

আপনি বাস্তবে চালু রেখেছেন এমন প্রতিটি service-এর জন্য allow rule যোগ করুন। যেমন, website-এর জন্য 80/tcp এবং 443/tcp যোগ করতে পারেন। এরপর নতুন SSH session সংযোগ করতে না পারলে কিছু পরিবর্তন করার আগে error পড়ুন। কারণ refusal-এর অর্থ sshd উত্তর দিয়েছে, আর timeout সাধারণত বোঝায় firewall packet-টি আটকে দিয়েছে। IPv4 এবং IPv6 উভয়ই কভার করা হয়েছে কি না পরীক্ষা করুন। কারণ শুধু IPv4 filter করা firewall IPv6 দিকটি সম্পূর্ণ উন্মুক্ত রেখে দেয়। সম্পূর্ণ নির্দেশিকা VPS-এ Firewalls 101-এ রয়েছে। এই ufw command-গুলো Ubuntu বা Debian ধরে নেওয়া হয়েছে। Rocky বা AlmaLinux সার্ভারে default-deny লক্ষ্য একই থাকে, কিন্তু tool হিসেবে firewalld ব্যবহৃত হয়। তাই এর পরিবর্তে এই ধাপের firewalld সংস্করণ অনুসরণ করুন।

মিনিট 10: Fail2ban দিয়ে স্ক্যানারদের ধীর করুন

সবশেষে, আপনার port-গুলোতে বারবার অনুরোধ পাঠানো address বাদ দিতে Fail2ban যোগ করুন:

sudo apt install -y fail2ban

Ubuntu 24.04-এর default install প্রথম boot থেকেই SSH সুরক্ষিত রাখে। আগে থেকেই key authentication বাধ্যতামূলক থাকলে, এটি আপনার প্রধান প্রতিরক্ষা নয়; বরং log-এর অপ্রয়োজনীয় বার্তা কমায় এবং পুনরায় আক্রমণকারী address block করে।

আপনার চেকলিস্ট

এটাই runbook। নিচের generator ব্যবহার করে প্রতিটি control সম্পন্ন হয়েছে কি না চিহ্নিত করুন এবং একটি ব্যক্তিগতকৃত checklist তৈরি করুন। এটি সার্ভারের সঙ্গে সংরক্ষণ করতে পারবেন। প্রতিটি ধাপের জন্য সঠিক command-ও এতে থাকবে:

প্রতিটি নতুন সার্ভারের জন্য একবার এই তালিকা অনুসরণ করুন। পরে পুরো প্রক্রিয়াটি অভ্যাসে পরিণত হবে। এখন দশ মিনিট সময় দিলে server breach হওয়ার পরের অত্যন্ত সমস্যাপূর্ণ বিকেল এড়ানো যায়।

প্রয়োজনীয় বিষয়গুলো সম্পন্ন হলে Ubuntu-তে স্বয়ংক্রিয় security update আপনাকে আবার লগ ইন না করেই সার্ভার আপডেট রাখে। এরপর যোগ করা প্রতিটি service-এর আলাদা security review প্রয়োজন, এবং দুর্বলতার স্থানও বদলে যায়: self-hosted password vault ব্যবহার করলে সার্ভারে plaintext সংরক্ষিত থাকে না। তাই Vaultwarden-এর প্রকৃত ঝুঁকি হলো admin token এবং backup file।

FAQ

নতুন VPS-এ প্রথমে কী করা উচিত?

apt update && apt upgrade -y দিয়ে সিস্টেম আপডেট করুন। এরপর sudo-সহ একটি সাধারণ user তৈরি করুন এবং root হিসেবে কাজ করা বন্ধ করুন। তারপর SSH key সেট আপ করুন, root login ও password authentication নিষ্ক্রিয় করুন, default-deny firewall সক্রিয় করুন এবং Fail2ban ইনস্টল করুন। এই ক্রম অনুসরণ করলে প্রতিটি ধাপ নেওয়ার আগে নিজেকে server থেকে বিচ্ছিন্ন করে ফেলার ঝুঁকি থাকে না।

SSH hardening করার সময় নিজেকে server থেকে বিচ্ছিন্ন করা এড়াব কীভাবে?

Password বা root নিষ্ক্রিয় করার আগে SSH key login সেট আপ করে পরীক্ষা করুন। Logout করে key দিয়ে আবার login করুন এবং এটি কাজ করছে কি না নিশ্চিত করুন। এরপরই PasswordAuthentication ও PermitRootLogin বন্ধ করুন। Firewall সক্রিয় করার সময় ufw enable চালানোর আগে port 22 অনুমোদন করুন। তবু login থেকে বিচ্ছিন্ন হয়ে গেলে provider-এর web console ব্যবহার করে SSH ছাড়াই আবার server-এ প্রবেশ করতে পারবেন।

ছোট server-এ কি সত্যিই এগুলো সব প্রয়োজন?

হ্যাঁ, কারণ scanner আপনার server কত ছোট তা বিবেচনা করে না। তারা প্রতিটি public IP একইভাবে পরীক্ষা করে। পুরো runbook শেষ করতে প্রায় দশ মিনিট লাগে এবং সহজ আক্রমণপথগুলো বন্ধ করে: root login নেই, password guessing নেই, আপনার অনুমতি ছাড়া কিছু exposed নেই, এবং পরিচিত bug স্বয়ংক্রিয়ভাবে patch হয়।

সবচেয়ে গুরুত্বপূর্ণ একক ধাপ কোনটি?

Root login নিষ্ক্রিয় রেখে key-only SSH চালু করা। নতুন VPS-এ অধিকাংশ আক্রমণ root account লক্ষ্য করে চালানো স্বয়ংক্রিয় password guess। দুটিই বন্ধ করলে এই ধরনের আক্রমণ সম্পূর্ণ অসম্ভব হয়। এরপর firewall ও Fail2ban exposed অংশ সীমিত করে এবং অবশিষ্ট আক্রমণ ধীর করে।

Server সত্যিই locked down হয়েছে কি না কীভাবে নিশ্চিত করব?

Server-কে নির্ভরযোগ্য মনে করার আগে হাতে তিনটি বিষয় পরীক্ষা করুন। sudo ss -tlnp চালিয়ে নিশ্চিত করুন যে public address-এ শুধু আপনার খোলার কথা থাকা port-গুলোই listening করছে এবং কোনো ভুলে যাওয়া 0.0.0.0 বা [::] service নেই। sudo ufw status verbose চালিয়ে নিশ্চিত করুন যে default incoming policy deny এবং plain ও (v6)—উভয় ধরনের rule উপস্থিত আছে। প্রথম SSH session বন্ধ করার আগে সবসময় দ্বিতীয় একটি SSH session খুলুন। এতে SSH configuration-এর ভুলের কারণে server থেকে নিজেকে বিচ্ছিন্ন হতে হবে না। তিনটিই সঠিক হলে মৌলিক সুরক্ষা ব্যবস্থা কার্যকর আছে।