VPS abuse complaint আসলে কী এবং কীভাবে সমাধান করবেন

VPS abuse complaint আসলে কী

একটি VPS abuse complaint হলো আপনার IP address থেকে আসা ট্রাফিক সংক্রান্ত একটি রিপোর্ট। এটি প্রথমে সেই IP ব্লকের জন্য প্রকাশিত abuse contact-এ পাঠানো হয়, এরপর আপনার হোস্ট সেটি আপনার কাছে পৌঁছে দেয় এবং উত্তর দেওয়ার জন্য একটি নির্দিষ্ট সময়সীমা দেয়। প্রকাশিত contact ঠিকানাটি সেই কোম্পানির, যারা ওই address space-এর মালিক। তাই আপনার সার্ভার সংক্রান্ত রিপোর্টটি পড়ার প্রথম ব্যক্তিটি প্রায় কখনোই আপনি নন। আপনার হোস্ট IP এবং timestamp মিলিয়ে আপনার অ্যাকাউন্ট শনাক্ত করে এবং রিপোর্টটি ফরোয়ার্ড করে।

এই নোটিশটি কোনো প্রমাণ নয় যে আপনি ইচ্ছাকৃতভাবে কিছু করেছেন। রিপোর্টকারীর কাছে IP address-ই একমাত্র শনাক্তকারী তথ্য। একটি compromised application রাত 03:00 টায় spam পাঠালে যে রিপোর্ট তৈরি হয়, একজন ব্যক্তি রাত 03:00 টায় spam পাঠালেও একই রিপোর্ট তৈরি হয়। এই কারণেই আপনার উত্তরটি সবচেয়ে গুরুত্বপূর্ণ। আপনাকে জিজ্ঞাসা করা হচ্ছে যে ট্রাফিকের উৎস কী ছিল এবং আপনি কী পরিবর্তন করেছেন।

রিপোর্ট কারা পাঠায় এবং এটি কীভাবে আপনার হোস্টের কাছে পৌঁছায়

প্রতিটি পাবলিক IP ব্লক একটি আঞ্চলিক ইন্টারনেট রেজিস্ট্রি (RIR)-এর সাথে নিবন্ধিত থাকে: RIPE NCC, ARIN, APNIC, LACNIC অথবা AFRINIC। প্রতিটি নিবন্ধনের সাথে একটি abuse contact বা অপব্যবহার সংক্রান্ত যোগাযোগের ঠিকানা প্রকাশ করা হয় এবং রিপোর্টগুলো সেখানেই পাঠানো হয়। রিপোর্টার যে রেকর্ডটি দেখেন, আপনিও সেই একই রেকর্ড পড়তে পারেন:

whois 203.0.113.10 | grep -iE 'netname|descr|abuse'

RIPE রেকর্ডে একটি abuse-c: role অবজেক্ট থাকে যাতে একটি abuse-mailbox: লাইন থাকে। ARIN রেকর্ডে OrgAbuseEmail: থাকে। সেখানে যে ঠিকানাটি প্রকাশিত থাকে, অভিযোগ সেখানেই পৌঁছায়। এই কারণেই আপনার সার্ভার সংক্রান্ত রিপোর্ট আপনার ইনবক্সে না এসে আপনার হোস্টের কাছে পৌঁছায়।

যারা এই রিপোর্ট ফাইল করে তারা সাধারণত মেশিন। আপনি সচরাচর যে চার ধরনের রিপোর্টের মুখোমুখি হবেন তা নিচে দেওয়া হলো:

• স্বয়ংক্রিয় স্ক্যানার এবং honeypot। একটি মেশিন আপনার IP থেকে সংযোগের প্রচেষ্টা রেকর্ড করে এবং লগ থেকে অংশবিশেষ সংযুক্ত করে একটি রিপোর্ট ফাইল করে।
• মেইলবক্স প্রোভাইডারদের দ্বারা পরিচালিত Feedback loops (FBL)। কোনো প্রাপক যখন junk বাটনে ক্লিক করেন, তখন বার্তার একটি কপি ARF (abuse reporting format)-এ ফিরে আসে, যা মেশিনের বিশ্লেষণের জন্য তৈরি একটি কাঠামোগত মেইল ফরম্যাট।
• কপিরাইট এজেন্ট। তারা টরেন্ট সোয়ার্ম পর্যবেক্ষণ করে বা পাবলিক URL ক্রল করে, তারপর DMCA (digital millennium copyright act) নোটিশ পাঠায় যেখানে ফাইলের নাম, আপনার IP এবং UTC টাইমস্ট্যাম্প উল্লেখ থাকে।
• ব্লকলিস্ট অপারেটর এবং নেটওয়ার্ক ইঞ্জিনিয়ার, যারা তাদের নিজস্ব লগ থেকে আপত্তিকর লাইনগুলোসহ একটি সংক্ষিপ্ত মেইল পাঠায়।

যেহেতু বেশিরভাগ প্রাথমিক রিপোর্ট স্বয়ংক্রিয়ভাবে তৈরি হয়, তাই উত্তরে কোনো যুক্তি দেখানো কোনো কাজে আসে না। তথ্যই সবকিছু: কী চলছিল এবং কখন তা বন্ধ হয়েছে, সেটি জানানোই যথেষ্ট।

নোটিশের সাথে সময়সীমা কেন থাকে

আপনার হোস্টও একজন ভাড়াটিয়া। এর অ্যাড্রেস স্পেসটি আপস্ট্রিম ক্যারিয়ার এবং অন্যদের পরিচালিত রেপুটেশন ডেটাবেসের ভেতরে থাকে। যেসব রিপোর্টের উত্তর দেওয়া হয় না, সেগুলো আপনার একক অ্যাড্রেসের পরিবর্তে পুরো ব্লকের স্কোর বাড়িয়ে দেয়। তাই আপনি যে সময়সীমা পান, তা মূলত ওপরের দিক থেকে আসা চাপের বহিঃপ্রকাশ। নোটিশে উল্লিখিত সময়সীমাটি পড়ুন এবং সেটিকে বাস্তব হিসেবে গণ্য করুন।

যখন কোনো অমীমাংসিত ঘটনার ক্ষেত্রে ব্যবস্থা নেওয়া হয়, তখন সাধারণত সেটিকে null route করা হয়। এর মানে হলো, ওই নির্দিষ্ট IP-এর ট্রাফিক আপস্ট্রিম থেকে ড্রপ করা হয় অথবা ইনস্ট্যান্সটি সাসপেন্ড করা হয়। এই পদক্ষেপের মূল কারণ সাধারণত নীরবতা, মূল ঘটনাটি নয়। কোনো নির্দিষ্ট হোস্ট কী করবে এবং কখন করবে, তা তাদের নিজস্ব পলিসি এবং নোটিশেই লেখা থাকে। শুধুমাত্র এই দুটি নথিপত্রই অনুসরণযোগ্য, তাই কোনো ফোরামে কোনো প্রোভাইডার কী অনুমতি দেয় বলে দাবি করা হচ্ছে, তার ওপর ভিত্তি করে কাজ করবেন না।

আউটবাউন্ড স্প্যাম: আমার VPS কেন আমার পাঠানো নয় এমন মেইল পাঠাচ্ছে

রিপোর্টে বলা হয়েছে যে আপনার IP থেকে কোনো স্প্যাম ট্র্যাপে মেইল পাঠানো হয়েছে, অথবা প্রাপকরা আপনার মেইলকে জাঙ্ক হিসেবে চিহ্নিত করেছেন। চারটি উৎস থেকে সাধারণত এমনটি ঘটে: মেইল ফর্ম আছে কিন্তু রেট লিমিট নেই এমন কোনো ওয়েব অ্যাপ্লিকেশন, ফাঁস হয়ে যাওয়া SMTP ক্রেডেনশিয়াল যা অন্য কেউ ব্যবহার করছে, এমন একটি মেইল সার্ভার যা অননুমোদিত হোস্টের জন্য রিলে করছে, এবং নিউজলেটার অ্যাপ্লিকেশনের চুরি হওয়া লগইন। প্রথমে মেইল কিউ (queue) পরীক্ষা করুন, কারণ আপস হওয়া সেন্ডার সাধারণত সেখানেই দৃশ্যমান থাকে:

sudo postqueue -p | tail -n 20
sudo postqueue -p | grep -c '^[0-9A-F]'

কিউতে হাজার হাজার মেসেজ থাকা এবং প্রাপকদের ঠিকানা অপরিচিত হওয়ার অর্থ হলো সার্ভার থেকে মেইল পাঠানো হচ্ছে। এরপর, কে অথেন্টিকেট করেছে তা খুঁজে বের করুন:

sudo grep -o 'sasl_username=[^ ]*' /var/log/mail.log | sort | uniq -c | sort -rn | head

অন্যান্য অ্যাকাউন্টের তুলনায় একটি অ্যাকাউন্টের মেইল পাঠানোর সংখ্যা অনেক বেশি হলে বুঝতে হবে সেই ক্রেডেনশিয়ালটি ফাঁস হয়েছে। যদি /var/log/mail.log ফাইলটি না থাকে, তবে সিস্টেমে rsyslog ইনস্টল করা নেই এবং একই লাইনগুলো জার্নালে পাওয়া যাবে: sudo journalctl -t postfix --since '2 days ago'।

যদি কেউ অথেন্টিকেট না করে থাকে, তবে সেন্ডার হলো কোনো লোকাল প্রসেস। রিলে রুল এবং ওপেন কানেকশনগুলো পরীক্ষা করুন:

sudo postconf -n | grep -E 'mynetworks|inet_interfaces|relay'
sudo ss -tnp state established '( dport = :25 )'

স্টক Debian বা Ubuntu Postfix অপরিচিতদের জন্য রিলে করে না। এটি ওপেন রিলেতে পরিণত হয় যখন mynetworks ম্যানুয়ালি পুরো হোস্টিং সাবনেটের জন্য উন্মুক্ত করে দেওয়া হয়, কারণ তখন ওই সাবনেটের অন্য সব টেন্যান্ট আপনার সার্ভারের মাধ্যমে মেইল পাঠানোর অনুমতি পেয়ে যায়। মেইল সার্ভার ছাড়া অন্য কোনো প্রসেসের পোর্ট 25-এ কানেকশন থাকা মানে হলো কোনো স্ক্রিপ্ট নিজে থেকে মেইল পাঠাচ্ছে, যা সাধারণত আপস হওয়া PHP অ্যাপ্লিকেশনের ক্ষেত্রে ঘটে।

তদন্ত করার আগে মেইল পাঠানো বন্ধ করুন এবং প্রমাণগুলো সংরক্ষণ করুন:

sudo systemctl stop postfix
sudo tar czf /root/mailqueue.tgz -C /var/spool postfix

sudo postsuper -d ALL কমান্ডটি কিউ খালি করে দেয়, তবে এটি কী পাঠানো হয়েছিল তার রেকর্ডও মুছে ফেলে, তাই আগে একটি কপি রাখুন। এরপর অ্যাপ্লিকেশনের সব ক্রেডেনশিয়াল পরিবর্তন করুন, অ্যাপ্লিকেশন আপডেট করুন এবং অনুপ্রবেশকারী কোনো ফাইল রেখে গেছে কি না তা খুঁজুন। স্প্যাম ইনসিডেন্ট এবং সার্ভার হ্যাক হওয়া বেশিরভাগ ক্ষেত্রেই একই ঘটনার অংশ, তাই শুধু কিউ খালি না করে হ্যাক হওয়া VPS পুনরুদ্ধারের ধাপগুলো অনুসরণ করুন।

পোর্ট স্ক্যানিং এবং ব্রুট ফোর্স: একটি compromised কন্টেইনার দেখতে কেমন হয়

এই রিপোর্টে অন্য একজন অপারেটরের লগ থেকে কিছু লাইন দেওয়া হলো, যা দেখতে অনেকটা এরকম:

sshd[2841]: Invalid user admin from 203.0.113.10 port 51992

এর কারণ প্রায় সবসময়ই এমন একটি সার্ভিস, যা আপনি ভেবেছিলেন firewall দিয়ে সুরক্ষিত। Docker-এর ক্ষেত্রে এটি প্রায়ই ঘটে। -p 6379:6379 দিয়ে কোনো পোর্ট publish করলে তা DOCKER-USER এবং nat চেইনে রুল লিখে দেয়। এই রুলগুলো ufw-এর রুলের আগেই কার্যকর হয়, তাই ufw deny 6379 সেগুলোকে ব্লক করতে পারে না এবং ডাটাবেসটি পুরো ইন্টারনেটের কাছে উন্মুক্ত হয়ে যায়।

sudo ss -ltnp
sudo iptables -S DOCKER-USER
docker ps

ss -ltnp-এ থাকা যেকোনো কিছু যা 0.0.0.0 বা [::]-এ bind করা, তা পাবলিক অ্যাড্রেসে লিসেন করে। যখন শুধুমাত্র হোস্টের সেটির সাথে যোগাযোগের প্রয়োজন হয়, তখন সেটিকে লুপব্যাক অ্যাড্রেস -p 127.0.0.1:6379:6379-এ publish করুন। ডাটাবেস কোথায় থাকা উচিত তা একটি ভিন্ন সিদ্ধান্ত, এবং Docker-এ নাকি হোস্টে ডাটাবেস চালানো বিষয়টি সেই তুলনামূলক আলোচনার কভার করে।

আপনার নিজের সার্ভার বর্তমানে স্ক্যান করছে কি না তা দেখতে:

sudo ss -tnp state syn-sent

অনেকগুলো ভিন্ন গন্তব্যে অনেকগুলো half-open কানেকশন থাকা মানে হলো একটি আউটবাউন্ড স্ক্যান চলছে। কার্নেল লগে nf_conntrack: table full, dropping packet ভরে যাওয়া একই বিষয় অন্যভাবে নির্দেশ করে: কোনো কিছু এই সার্ভারের স্বাভাবিক প্রয়োজনের তুলনায় অনেক বেশি কানেকশন ওপেন করছে।

একটি compromised কন্টেইনার পরিষ্কার না করে বরং নতুন করে তৈরি (rebuild) করুন। এর ভেতরে আর কী কী পরিবর্তন হয়েছে তা নিশ্চিতভাবে প্রমাণ করা সম্ভব নয়, তাই আপনার বিশ্বস্ত ইমেজ থেকে নতুন করে তৈরি করুন, শুধুমাত্র বিশ্বস্ত ডাটা পুনরুদ্ধার করুন এবং সেই কন্টেইনারে থাকা কি (keys) পরিবর্তন (rotate) করুন।

কপিরাইট নোটিশ: তারা আসলে কোন ফাইলটি দেখেছে

একটি DMCA নোটিশে একটি URL বা টরেন্ট ইনফো হ্যাশ, আপনার IP এবং UTC-তে একটি টাইমস্ট্যাম্প উল্লেখ থাকে। প্রায় সব নোটিশের পেছনে দুটি কারণ থাকে: একটি ডিরেক্টরি যা ওয়েব সার্ভার পাবলিকলি লিস্ট করে রেখেছে এবং তাতে মিডিয়া ফাইল আছে, অথবা একটি টরেন্ট ক্লায়েন্ট যা ডাউনলোড শেষ হওয়ার পরেও seeding করছে।

আপনার অ্যাক্সেস লগের সাথে টাইমস্ট্যাম্পটি মিলিয়ে দেখুন। Nginx-এর combined log ফরম্যাটে স্ট্যাটাস থাকে 9 নম্বর ফিল্ডে এবং রিকোয়েস্ট পাথ থাকে 7 নম্বর ফিল্ডে:

sudo grep '14/Aug/2026:03' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head

কোনো কিছু সার্ভ করা হয়নি এমন সিদ্ধান্তে পৌঁছানোর আগে ঘড়িটি পরীক্ষা করুন। নোটিশটি UTC-তে থাকে এবং আপনার লগগুলো সার্ভারের টাইমজোন ব্যবহার করে, তাই কয়েক ঘণ্টার পার্থক্যের কারণে আপনি ভুল সময়ে অনুসন্ধান করতে পারেন এবং ভুল নেতিবাচক রিপোর্ট পেতে পারেন:

timedatectl
sudo timedatectl set-timezone UTC

এরপর কারণটি সমাধান করুন। ফাইলটি সরিয়ে ফেলুন বা সীমাবদ্ধ করুন, Nginx-এর location ব্লকে autoindex off; ব্যবহার করে ডিরেক্টরি লিস্টিং বন্ধ করুন এবং টরেন্ট ক্লায়েন্টকে এমন একটি ইন্টারফেসে বাইন্ড করুন যা পাবলিক নয়। রিপ্লাইতে ফাইলের নাম, আপনার করা পরিবর্তন এবং পরিবর্তনের সময় উল্লেখ করুন। যদি আপনি মনে করেন যে দাবিটিই ভুল, তবে এটি আপনার এবং প্রেরকের মধ্যে একটি আইনি বিষয় এবং নোটিশেই উল্লেখ থাকে কীভাবে এটি বিতর্ক করতে হবে। আপনার হোস্ট এই বিষয়ে সিদ্ধান্ত নেওয়ার পক্ষ নয়, তাই দাবির যথার্থতা নিয়ে কোনো টিকিট খুললে কোনো লাভ হবে না।

ব্লকলিস্ট লিস্টিং: আমার আউটবাউন্ড মেইল কেন কাজ করা বন্ধ করে দিল

এটি এমন একটি সমস্যা যেখানে আপনার কাছে কোনো মেইলই পৌঁছায় না। আউটবাউন্ড মেইল গ্রহণ করা বন্ধ হয়ে যায় এবং বাউন্স মেসেজে এর কারণ উল্লেখ থাকে:

554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.org

IP-এর চারটি অক্টেট উল্টে দিয়ে এবং লিস্টের জোনে কুয়েরি করে লিস্টিং চেক করুন:

dig +short 10.113.0.203.zen.spamhaus.org

ফলাফল খালি আসা মানে আপনি সেখানে তালিকাভুক্ত নন। 127.0.0.x উত্তর আসার অর্থ হলো আপনি তালিকাভুক্ত এবং শেষ অক্টেটটি নির্দেশ করে কোন সাবলিস্টের সাথে মিল পাওয়া গেছে। 127.255.255.x রেঞ্জের কোনো উত্তর আসার মানে হলো কুয়েরিটি উত্তর দেওয়ার পরিবর্তে প্রত্যাখ্যান করা হয়েছে, সাধারণত কারণ এটি কোনো বড় পাবলিক রিজলভারের মাধ্যমে পাঠানো হয়েছে, যা এই ফ্রি সার্ভিস সাপোর্ট করে না। সঠিক ফলাফল পেতে সার্ভারের নিজস্ব রিজলভার থেকে এটি পুনরায় চালান।

ডিলিস্টিং বা তালিকা থেকে নাম সরানোর প্রক্রিয়াটি লিস্ট অপারেটরের সাইটে সম্পন্ন করতে হয়, আপনার হোস্টের মাধ্যমে নয়। এটি তখনই কার্যকর হয় যদি আগে সোর্স বা উৎস ঠিক করা হয়, কারণ যে ফাঁদটি আপনাকে তালিকাভুক্ত করেছে তা পরবর্তী মেসেজেই আপনাকে আবার তালিকাভুক্ত করবে। এরপর মেইল প্রবাহ স্বাভাবিক হবে কি না তা আরও দুটি বিষয় নির্ধারণ করে। আপনার PTR রেকর্ড, অর্থাৎ IP-এর রিভার্স DNS নাম, আপনার হোস্টের নিয়ন্ত্রণে থাকে। তাই তাদের বলুন এমন একটি নাম সেট করতে যা পুনরায় একই ঠিকানায় রিজলভ হয় এবং সেই নামটিই আপনার HELO হিসেবে ব্যবহার করুন। এছাড়া, আগের কোনো ব্যবহারকারীর কাছ থেকে পাওয়া IP ঠিকানায় এমন ইতিহাস থাকতে পারে যা আপনি তৈরি করেননি; তাই DNS নতুন করে সাজানোর পেছনে এক সপ্তাহ ব্যয় করার আগে এ বিষয়ে খোঁজ নেওয়া বুদ্ধিমানের কাজ। SPF (sender policy framework) এবং DKIM (domainkeys identified mail) রেকর্ড সঠিকভাবে সেট করা এবং সেগুলোকে সংযুক্তকারী DMARC পলিসি সম্পর্কে বিস্তারিত জানতে Mailcow দিয়ে নিজস্ব মেইল সার্ভার চালানোর গাইড দেখুন।

রিলে অবকাঠামো, যেখানে অপব্যবহারমূলক ইমেইল কাজেরই অংশ

আপনি যদি একটি Tor exit node, পাবলিক VPN বা অন্য কারো জন্য প্রক্সি চালান, তবে আপনার তৈরি করা ট্রাফিক নয় এমন ট্রাফিকের জন্য অভিযোগ আসা একটি স্বাভাবিক পরিচালন ব্যয়। আপনার সার্ভারটি যে একটি রিলে, তা যেন কোনো compromised বক্সের মতো না দেখায় সেদিকে খেয়াল রাখুন। reverse DNS-কে একটি বর্ণনামূলক নামে সেট করুন, port 80-এ একটি সংক্ষিপ্ত নোটিশ পেজ রাখুন যা ব্যাখ্যা করবে এই ঠিকানাটি কী, একই ব্যাখ্যা দিয়ে দ্রুত অপব্যবহারমূলক ইমেইলের উত্তর দিন এবং যে পোর্টগুলো থেকে সবচেয়ে বেশি অভিযোগ আসে সেগুলো বন্ধ করতে সফটওয়্যারের পলিসি ব্যবহার করুন। এটি নিজস্ব IP ঠিকানায় চালান এবং আদর্শগতভাবে নিজস্ব instance-এ রাখুন, যাতে সেই ঠিকানায় null route প্রয়োগ করলে আপনার ওয়েব অ্যাপ্লিকেশনটি বন্ধ না হয়ে যায়। শুরু করার আগে আপনার হোস্টের সাথে কথা বলুন, কারণ কোম্পানিভেদে এবং ক্ষেত্রবিশেষে IP ব্লকের ওপর ভিত্তি করে নিয়ম ভিন্ন হয়, আর এটি তাদের কাছেই জিজ্ঞাসা করা উচিত, কোনো ফোরাম থ্রেডে নয়। VPS-এ Tor exit node চালানো অংশে exit policy এবং নোটিশ পেজ সম্পর্কে বিস্তারিত আলোচনা করা হয়েছে।

কিভাবে উত্তর দিলে টিকিট বন্ধ হবে

• এমন একটি কন্টাক্ট ঠিকানা প্রকাশ করুন যা কেউ একজন পড়ে। RFC 2142 অনুযায়ী আপনার ডোমেইনে abuse@ এবং postmaster@ হলো সেই ঠিকানা যা রিপোর্টাররা সবার আগে চেষ্টা করে। সেই মেইলবক্সটি এমন কোনো সার্ভারে হোস্ট করুন যা আপনার সুরক্ষিত সার্ভার থেকে আলাদা, কারণ একটি সাসপেন্ডেড ইনস্ট্যান্স আপনাকে এটি সাসপেন্ড হওয়ার নোটিশ পাঠাতে পারে না।
• লগগুলো এত দীর্ঘ সময় ধরে রাখুন যাতে উত্তর দেওয়া সম্ভব হয়। বারো দিন আগের ট্রাফিক সংক্রান্ত রিপোর্টের উত্তর দেওয়া সম্ভব নয় যদি লগ সাত দিন পরেই রোটেট হয়ে যায়। journalctl --disk-usage চেক করুন, /etc/systemd/journald.conf-এ MaxRetentionSec=90d সেট করুন, তারপর sudo systemctl restart systemd-journald চালান। ওয়েব এবং মেইল লগগুলো /etc/logrotate.d/-এর অধীনে তাদের নিজস্ব সময়সূচী অনুযায়ী রোটেট হয়।
• সার্ভারকে UTC-তে রাখুন, যাতে রিপোর্টে থাকা টাইমস্ট্যাম্প এবং আপনার লগের টাইমস্ট্যাম্পের মধ্যে কোনো গাণিতিক হিসাব ছাড়াই মিল পাওয়া যায়।
• যা অভিযোগের কারণ হতে পারে তা থেকে আপনার গুরুত্বপূর্ণ ডেটা আলাদা রাখুন। মেইল এক ঠিকানায়, ওয়েব অ্যাপ্লিকেশন অন্য ঠিকানায় এবং রিলে সার্ভিসগুলো তাদের নিজস্ব ইনস্ট্যান্সে রাখুন। একটি IP-এর বিরুদ্ধে নেওয়া ব্যবস্থা মানেই তার পেছনে থাকা সবকিছুর বিরুদ্ধে নেওয়া ব্যবস্থা।
• তদন্ত শেষ না হলেও নির্ধারিত সময়ের মধ্যে উত্তর দিন। একটি প্রাথমিক উত্তর যাতে সময় উল্লেখ আছে, তা প্রথম ধাপের জন্য একটি সম্পূর্ণ উত্তর হিসেবে গণ্য হয়।

প্রথম যে উত্তরটি অধিকাংশ টিকিট বন্ধ করে দেয় তা সংক্ষিপ্ত এবং সুনির্দিষ্ট:

Received, thank you. Confirmed at 09:14 UTC.
Source: a contact form in our web app that allowed unauthenticated sending.
Action: form disabled, Postfix stopped, all SMTP credentials rotated 09:31 UTC.
Evidence: mail queue and logs preserved for 90 days if you need them.
Next: patched app redeployed by 18:00 UTC today. I will confirm here.

আপনি যা জানেন তা বলুন এবং যা এখনো বের করতে পারেননি তাও জানান। নীরবতা মানেই একটি রক্ষণাবেক্ষণহীন সার্ভার, আর রক্ষণাবেক্ষণহীন সার্ভারের জন্যই এসকেলেশন পাথ বা অভিযোগের পথ খোলা থাকে। এই কাজের কোনো অংশ আপনার দায়িত্ব কি না তা নির্ভর করে আপনি কোন প্রোডাক্ট কিনেছেন তার ওপর, যা managed এবং unmanaged VPS hosting-এর মধ্যে ব্যবহারিক পার্থক্য। একটি unmanaged প্ল্যানে ভাড়াটিয়াই হলো সিকিউরিটি টিম।

সবকিছু ঠিকঠাক চললে বিষয়টি যেমন দেখায়

একটি abuse complaint বা অপব্যবহারের অভিযোগ পাওয়ার পর প্রথম কাজ হলো সেটিকে সঠিক গন্তব্যে পৌঁছে দেওয়া। কোনো নির্দিষ্ট IP address সম্পর্কে অভিযোগ এলে তা সেই ঠিকানার জন্য দায়বদ্ধ পক্ষের কাছে যায় এবং সেখান থেকে এমন ব্যক্তির কাছে পৌঁছায় যিনি সমস্যাটি সমাধান করতে পারেন। আপনার নিয়ন্ত্রণে থাকা বিষয়গুলো হলো আপনার contact address, log retention, বিভিন্ন IP-তে আপনার সার্ভিসগুলো কীভাবে ভাগ করা হয়েছে এবং আপনি কত দ্রুত উত্তর দিচ্ছেন। এই বিষয়গুলো ঠিকঠাক থাকলে অধিকাংশ অভিযোগ একটি আদান-প্রদানের মাধ্যমেই শেষ হয়ে যায়। একই অভ্যাস VPS hosting নিরাপদ কি না—এই বড় প্রশ্নটিরও সমাধান দেয়, কারণ যে সার্ভার কেউ পর্যবেক্ষণ করে না, সেটিই শেষ পর্যন্ত অন্যের লগে ধরা পড়ে।

FAQ

কোনো abuse complaint আসার মানে কি আমার VPS হ্যাক হয়েছে?

শুধু এই অভিযোগের ভিত্তিতে তা বলা যায় না, তবে এটিই প্রথম বিষয় যা যাচাই করা প্রয়োজন। এই রিপোর্ট কেবল প্রমাণ করে যে আপনার IP থেকে ট্রাফিক বের হয়েছে। আউটবাউন্ড স্প্যাম এবং পোর্ট স্ক্যানিং সাধারণত অ্যাকাউন্টের মালিকের চেয়ে কোনো compromised অ্যাপ্লিকেশন বা কন্টেইনার থেকে বেশি ঘটে। তাই অন্য কিছু করার আগে sudo postqueue -p দিয়ে মেইল কিউ এবং sudo ss -ltnp দিয়ে লিসেনিং সকেটগুলো পরীক্ষা করুন। কপিরাইট এবং ব্লকলিস্ট নোটিশের ধরন ভিন্ন; এগুলো সাধারণত আপনার ইচ্ছাকৃতভাবে চালানো কোনো কিছুর দিকে নির্দেশ করে।

একটি abuse নোটিশের উত্তর দেওয়ার জন্য আমি কত সময় পাব?

নোটিশে সময়সীমা উল্লেখ থাকে, যা হোস্ট এবং অভিযোগের ধরনের ওপর নির্ভর করে। কপিরাইট এবং স্প্যাম-ট্র্যাপ রিপোর্টের ক্ষেত্রে সময়সীমা সাধারণত সবচেয়ে কম হয়। নোটিশে উল্লিখিত সময়কে গুরুত্ব দিন এবং সময় শেষ হওয়ার আগেই একটি সংক্ষিপ্ত প্রাথমিক উত্তর পাঠান, এমনকি আপনি যদি তখনও কারণ অনুসন্ধান করতে থাকেন। টিকিট হ্যান্ডেল করা ব্যক্তির কাছে গুরুত্বপূর্ণ হলো, একজন মানুষ বিষয়টি দেখছেন এবং ক্ষতিকর ট্রাফিক বন্ধ হয়েছে।

আমার IP একটি ব্লকলিস্টে আছে। আমার হোস্ট কি এটি সরিয়ে দিতে পারবে?

না। ব্লকলিস্ট থেকে নাম সরানোর কাজটি সেই তালিকার অপারেটর তাদের নিজস্ব সাইটে করে থাকে, এবং আপনার হোস্টের তাদের ডেটাবেসের ওপর কোনো নিয়ন্ত্রণ নেই। আপনার হোস্ট কেবল PTR রেকর্ড বা আপনার IP-এর রিভার্স DNS নাম নিয়ন্ত্রণ করে, যা একই সময়ে অনুরোধ করার মতো একটি আলাদা বিষয়। ডিলিস্টিংয়ের অনুরোধ করার আগে পাঠানোর সমস্যাটি সমাধান করুন, কারণ যে স্প্যাম-ট্র্যাপ আপনাকে তালিকাভুক্ত করেছে, পরবর্তী মেসেজেই তারা আপনাকে পুনরায় তালিকাভুক্ত করবে।

আসলে কী ঘটেছে তা কি আমাকে হোস্টকে জানাতে হবে?

টিকিট বন্ধ করার জন্য যতটুকু তথ্য প্রয়োজন, ততটুকু আপনাকে জানাতে হবে: উৎসের প্রকৃতি কী ছিল এবং কখন তা বন্ধ হয়েছে। আপনাকে কোনো ফরেনসিক রিপোর্ট বা ব্যবহারকারীদের ডেটা দিতে হবে না। অস্পষ্ট উত্তরের চেয়ে সংক্ষিপ্ত উত্তর দেওয়া ভালো, কারণ হ্যান্ডলার যদি বুঝতে না পারেন কী পরিবর্তন করা হয়েছে, তবে তার কাছে কেসটি সমাধান করার কোনো কারণ থাকে না।

স্ক্যানার থেকে আসা কোনো automated রিপোর্ট কি আমি উপেক্ষা করতে পারি?

না। অটোমেটেড রিপোর্টগুলো গণনা করা হয় এবং একটি IP সম্পর্কে বারবার রিপোর্ট আসলে তা আপনার হোস্টের পুরো অ্যাড্রেস ব্লকের স্কোর কমিয়ে দেয়, যা একটি ছোট বিষয়কে বড় সমস্যায় রূপান্তর করে। আপনার উত্তর একটি অনুচ্ছেদের হতে পারে। অটোমেটেড রিপোর্টার সাধারণত এটি পড়ে না, কিন্তু আপনার হোস্টের যে ব্যক্তি টিকিটটি হ্যান্ডেল করছেন তিনি এটি পড়েন, এবং তিনিই সিদ্ধান্ত নেন আপনার ইনস্ট্যান্সের ক্ষেত্রে কী ব্যবস্থা নেওয়া হবে।