ওয়েবসাইট হ্যাক হলে কী করবেন? নিরাপত্তা ও পুনরুদ্ধারের সম্পূর্ণ গাইড

Homepage-এ অচেনা লেখা, Google result-এ spam page, hosting থেকে malware alert, কিংবা admin account হঠাৎ কাজ না করা—এগুলো website compromise-এর লক্ষণ হতে পারে। এমন মুহূর্তে তাড়াহুড়ো করে সব file delete বা যেকোনো পুরোনো backup restore করলে সাময়িকভাবে page ঠিক হলেও প্রমাণ নষ্ট হয় এবং attacker-এর ঢোকার পথ থেকে যেতে পারে। কার্যকর Website Hacked Recovery হলো একটি incident-response process: ক্ষতি সীমিত করা, evidence রাখা, পরিষ্কার environment-এ recovery, মূল কারণ বন্ধ করা এবং পরে নজরদারি চালানো।

এই গাইডটি WordPress-কেন্দ্রিক উদাহরণ দিলেও নীতিগুলো অন্যান্য CMS ও custom website-এও প্রযোজ্য। প্রথম লক্ষ্য “দেখতে ঠিক” করা নয়; visitor, customer data এবং connected system-কে নিরাপদ করা। Payment data, ব্যক্তিগত তথ্য বা business-critical service জড়িত থাকলে hosting provider, experienced security professional, legal counsel এবং প্রযোজ্য কর্তৃপক্ষের সহায়তা দ্রুত নিতে হবে।

প্রতিটি incident আলাদা। তাই নিচের ধাপগুলো checklist, diagnosis এবং coordination framework হিসেবে ব্যবহার করুন। সন্দেহভাজন server-এ random cleanup script চালাবেন না, evidence overwrite করবেন না এবং malware file খুঁজে পেলেই root cause পাওয়া গেছে ধরে নেবেন না। সময়, action, account ও ফল লিখে রাখলে recovery যেমন দ্রুত হয়, পরে একই ঘটনা ঠেকানোও তেমন সহজ হয়।

এই গাইডে যা জানবেন

• হ্যাক হওয়ার সম্ভাব্য লক্ষণ কী?
• প্রথম এক ঘণ্টায় অগ্রাধিকার কী হবে?
• Evidence ও log কেন সংরক্ষণ করবেন?
• Compromise-এর scope কীভাবে নির্ধারণ করবেন?
• Credential rotation কোন ক্রমে করবেন?
• পরিষ্কারভাবে website recovery করার নিরাপদ পদ্ধতি
• Root cause বন্ধ না করলে হ্যাক আবার কেন ফিরে আসে?
• Database, content ও SEO spam পরিষ্কার করবেন কীভাবে?
• Live করার আগে কীভাবে যাচাই করবেন?
• Google warning ও Search Console Security Issues কীভাবে সামলাবেন?
• ব্যবহারকারী ও কর্তৃপক্ষকে জানাতে হবে কি?
• Recovery-এর পর ৩০ দিনের নিরাপত্তা পরিকল্পনা
• যে ভুলগুলো recovery ব্যর্থ করে

হ্যাক হওয়ার সম্ভাব্য লক্ষণ কী?

Defaced page, অচেনা redirect, নতুন admin user, server CPU spike, outgoing spam, unknown scheduled task, modified core file এবং search result-এ Japanese keyword বা medicine spam পরিচিত লক্ষণ। Browser “Deceptive site” warning, Search Console Security Issues, ad platform suspension বা customer complaint-ও signal হতে পারে। একটি symptom না দেখালেও breach হতে পারে; sophisticated attacker চুপচাপ credential বা data সংগ্রহ করতে পারে।

False positive বাদ দিতে monitoring alert, deployment history এবং authorized developer change মিলিয়ে দেখুন। File modified time একা নির্ভরযোগ্য নয়, কারণ update বা attacker দুজনেই timestamp বদলাতে পারে। Server access log, authentication log, audit log, DNS history, CDN event এবং application log—একই timeline-এ রাখুন। ঘটনার প্রথম জানা সময়, কে দেখেছে, কোন URL আক্রান্ত এবং কোন business process ঝুঁকিতে—প্রথম নোটেই লিখুন।

প্রথম এক ঘণ্টায় অগ্রাধিকার কী হবে?

আগে একটি incident lead ঠিক করুন, যাতে সবাই আলাদা করে server বদলে evidence নষ্ট না করে। Customer login, payment বা malware distribution চললে affected service isolate করুন—WAF rule, maintenance page, load balancer থেকে unhealthy instance সরানো কিংবা host-এর quarantine সুবিধা ব্যবহার করা যায়। শুধু homepage hide করলে hidden malicious endpoint চলতে পারে; containment scope বাস্তব threat অনুযায়ী হওয়া দরকার।

Registrar, DNS, email, hosting ও cloud account takeover সন্দেহ হলে পরিচ্ছন্ন এবং updated device থেকে session revoke ও credential reset শুরু করুন। Compromised email দিয়ে password reset করলে attacker আবার ঢুকতে পারে; তাই recovery email ও MFA আগে সুরক্ষিত করুন। গুরুত্বপূর্ণ stakeholder, host এবং security contact-কে নির্ভুল facts জানান—অনুমানকে নিশ্চিত তথ্য হিসেবে ছড়াবেন না।

Evidence ও log কেন সংরক্ষণ করবেন?

Cleanup-এর আগে সম্ভব হলে provider-assisted snapshot, files, database, access log, error log, audit log, process list এবং relevant configuration-এর copy নিন। এটি production-এ ফিরিয়ে ব্যবহারের backup নয়; forensic evidence হিসেবে read-only ও access-controlled location-এ রাখুন। Hash, collection time, collector এবং source লিখলে পরে file বদলেছে কি না বোঝা যায়। Sensitive evidence public cloud link বা সাধারণ chat-এ পাঠাবেন না।

Attacker কীভাবে ঢুকেছে, কী data দেখেছে, অন্য system-এ গেছে কি না—এসব জানতে evidence দরকার। তাড়াহুড়ো করে infected file delete, log truncate, server reimage বা শুধু backup restore করলে timeline হারিয়ে যায়। তবে evidence রাখার নামে আক্রান্ত site চালু রাখাও ঠিক নয়; containment ও preservation parallel-এ করুন। উচ্চ ঝুঁকির incident-এ trained forensic team-এর নির্দেশনা নিন।

Compromise-এর scope কীভাবে নির্ধারণ করবেন?

একটি domain নয়, একই hosting account-এর সব site, subdomain, database, email, FTP/SFTP user, SSH key, API token, cron job এবং CDN configuration inventory করুন। Shared hosting-এ একটি দুর্বল site sibling site-এ প্রভাব ফেলতে পারে। Cloud server-এ IAM role, object storage এবং snapshot-ও scope-এর অংশ। Unknown account, privilege change, suspicious login geography ও অস্বাভাবিক outbound connection খুঁজুন।

WordPress-এ core integrity, plugin/theme source, must-use plugin, uploads folder-এর executable file, wp-config.php, .htaccess, database option, scheduled event এবং admin user দেখুন। Malware signature scan সহায়ক, কিন্তু obfuscated বা নতুন backdoor বাদ পড়তে পারে। Clean baseline ও official package-এর সঙ্গে compare করুন। Business data access বা exfiltration-এর evidence থাকলে privacy, contractual ও regulatory notification obligation দ্রুত মূল্যায়ন করুন।

Credential rotation কোন ক্রমে করবেন?

পরিষ্কার device থেকে প্রথমে email, password manager, registrar, DNS, hosting এবং identity provider সুরক্ষিত করুন; এগুলো অন্য account reset করতে পারে। এরপর server admin, control panel, SSH/SFTP, database, CMS admin, CDN, backup storage, API, payment এবং deployment token বদলান। Unique long password ও phishing-resistant MFA যেখানে সম্ভব ব্যবহার করুন। শুধু password বদলে active session বা app password রেখে দিলে attacker থাকতে পারে, তাই session revoke ও token inventory জরুরি।

WordPress secret salts rotate করলে active session invalidate হয়। SSH authorized keys, CI/CD secret, webhook secret ও service account ভুলবেন না। Rotation-এর আগে কোন application কোন secret ব্যবহার করে লিখুন, যাতে production ভেঙে না যায়। Compromised server-এ নতুন secret বসিয়ে তারপরও পুরোনো malware থাকলে সেটিও চুরি হতে পারে; তাই containment এবং clean rebuild-এর সঙ্গে সমন্বয় করুন।

পরিষ্কারভাবে website recovery করার নিরাপদ পদ্ধতি

সবচেয়ে নির্ভরযোগ্য পথ প্রায়ই clean server বা clean account-এ operating environment তৈরি করে official source থেকে CMS core, plugin ও theme reinstall করা। Custom code version control-এর reviewed commit থেকে নিন। Upload ও database আলাদাভাবে scan ও review করুন; uploads folder থেকে script execution বন্ধ রাখুন। Unknown nulled theme বা plugin ফিরিয়ে আনবেন না। পুরোনো server-এর executable file wholesale copy করলে backdoor-ও ফিরে আসতে পারে।

Known-good backup ব্যবহার করলে backup নেওয়ার সময় সত্যিই compromise-এর আগের কি না evidence দিয়ে যাচাই করুন। শুধু “গত সপ্তাহের” লেখা দেখে পরিষ্কার ধরে নেওয়া যায় না; attacker মাস ধরে থাকতে পারে। Restore-এর পর সব patch, credential rotation, configuration hardening ও indicator scan আবার করুন। Backup না থাকলে আক্রান্ত file edit করে চলার চেয়ে clean rebuild অধিক নির্ভরযোগ্য, যদিও business data carefully salvage করতে হবে।

Root cause বন্ধ না করলে হ্যাক আবার কেন ফিরে আসে?

Visible spam file মুছলেও vulnerable plugin, stolen admin cookie, leaked API key, exposed database, weak control-panel password বা developer laptop malware থেকে গেলে attacker আবার ঢুকতে পারে। Timeline-এ প্রথম suspicious request-এর path, preceding login, vulnerable component version এবং created persistence মিলিয়ে entry point অনুমান করুন। Assumption ও confirmed finding আলাদা লিখুন।

তারপর affected component update, replace বা remove করুন; unused account ও service বন্ধ করুন; least privilege দিন; file permission ও web server rule review করুন। একই vulnerability অন্য site-এ আছে কি না fleet-wide search চালান। Control panel account শক্ত করার জন্য control panel security checklist অনুসরণ করা যায়। Vendor patch না থাকলে risky feature disable, WAF virtual patch বা service isolation ব্যবহার করুন।

Database, content ও SEO spam পরিষ্কার করবেন কীভাবে?

Post ও page ছাড়াও options, widgets, user profile, redirect table, SEO metadata এবং injected JavaScript খুঁজুন। Spam URL delete করার আগে list export করুন, কারণ পরে search cleanup ও monitoring-এ দরকার হবে। Legitimate content আলাদা করে reviewed clean copy-তে migrate করুন। Database search-and-replace চালালে serialization ও encoding বোঝে এমন tool ব্যবহার করুন এবং backup রাখুন।

Attackers doorway page, hidden link, cloaking rule বা sitemap তৈরি করতে পারে। XML sitemap, robots.txt, canonical, redirect ও server rewrite পরীক্ষা করুন। Valid page ফিরিয়ে আনলে একই URL রাখা ভালো; সত্যিই ভুয়া URL-এর জন্য context অনুযায়ী 404 বা 410 দিন, unrelated homepage-এ blanket redirect নয়। Search engine আবার crawl করতে সময় নিতে পারে—instant ranking recovery নিশ্চিত নয়।

Live করার আগে কীভাবে যাচাই করবেন?

Staging বা isolated environment-এ core integrity, malware scan, account list, scheduled tasks, outgoing connection এবং security header পরীক্ষা করুন। এরপর homepage, article, search, login, password reset, form, checkout, email, webhook ও mobile layout ব্যবহার করে দেখুন। Error log ও browser console পর্যবেক্ষণ করুন। Scan clean দেখানো গুরুত্বপূর্ণ, কিন্তু manual review ও root-cause fix ছাড়া এটিই একমাত্র release criterion নয়।

Release approval কে দেবেন এবং rollback condition কী—আগে লিখুন। DNS TTL, CDN cache ও WAF rule বিবেচনা করে controlled cutover করুন। Live হওয়ার পর file-integrity baseline তৈরি করুন এবং high-sensitivity monitoring সাময়িকভাবে চালু রাখুন। Customer-facing statement দিলে কী ঘটেছে, কী প্রভাব, কী করা হয়েছে এবং ব্যবহারকারীকে কী করতে হবে—পরিষ্কারভাবে বলুন; অনিশ্চিত বিষয়কে নিশ্চিত দাবি করবেন না।

Google warning ও Search Console Security Issues কীভাবে সামলাবেন?

Search Console-এর Security Issues report-এ hacked content, malware বা social engineering warning দেখা যেতে পারে। প্রথমে ownership সুরক্ষিত করুন, sample URL দেখে পুরো site-এ একই pattern খুঁজুন এবং সব affected area পরিষ্কার করুন। শুধু sample URL সরালেই যথেষ্ট নয়। Clean-up, vulnerability fix ও access-control পরিবর্তন শেষ হওয়ার পর review request দিন এবং কীভাবে সমস্যা সমাধান করেছেন সংক্ষেপে নির্দিষ্টভাবে লিখুন।

Review request recovery-এর বিকল্প নয় এবং approval-এর সময় নিশ্চয়তা নেই। Warning সরে যাওয়ার অপেক্ষায় monitoring চালু রাখুন। Google-এ অচেনা URL index থাকলে sitemap ও internal link পরিষ্কার করুন; indexing diagnosis-এর জন্য Google indexing problem guide দেখুন। Search result স্বাভাবিক হতে recrawl দরকার হতে পারে।

ব্যবহারকারী ও কর্তৃপক্ষকে জানাতে হবে কি?

কোন data access হয়েছে, কারা affected, আপনার jurisdiction, contract এবং industry requirement অনুযায়ী notification duty বদলে যায়। Payment processor, cyber-insurance provider, regulator, law enforcement বা customer-কে জানানোর deadline থাকতে পারে। তাই early stage-এ qualified legal ও privacy adviser যুক্ত করুন। প্রমাণ ছাড়া “কোন data চুরি হয়নি” বলা এড়িয়ে চলুন।

User action দরকার হলে direct official channel-এ জানান—password reset, session logout, phishing সতর্কতা বা card monitoring যেটি প্রাসঙ্গিক। Email-এ এমন link বা attachment দেবেন না যা attacker-এর phishing-এর সঙ্গে মিলে যায়; user-কে official domain নিজে type করতে বলুন। Incident communication log ও approved message version সংরক্ষণ করুন। Transparency আস্থা ফেরাতে সাহায্য করে, তবে sensitive defensive detail public করবেন না।

Recovery-এর পর ৩০ দিনের নিরাপত্তা পরিকল্পনা

প্রথম কয়েক দিন authentication, file change, new admin, DNS, outbound mail, WAF hit এবং unusual traffic ঘন ঘন দেখুন। এক সপ্তাহের মধ্যে unused plugin/account remove, backup restore test, least privilege, MFA coverage এবং patch process review করুন। এক মাসের মধ্যে incident retrospective করুন: detection কেন দেরি হলো, recovery-তে কী বাধা, কোন log ছিল না এবং owner কে—এসব থেকে নির্দিষ্ট task ও deadline তৈরি করুন।

Offsite immutable বা access-separated backup রাখুন এবং production credential দিয়ে backup delete করা না যায় এমন design বিবেচনা করুন। Monitoring alert পরীক্ষা করতে tabletop exercise চালান। Vendor ও freelancer access সময়সীমাবদ্ধ করুন। একটি incident playbook, contact tree এবং asset inventory থাকলে পরের ঘটনা কম বিশৃঙ্খল হবে। নিরাপত্তা একবারের plugin installation নয়; এটি people, process এবং technology-এর নিয়মিত চর্চা।

যে ভুলগুলো recovery ব্যর্থ করে

• Evidence না রেখে সঙ্গে সঙ্গে সব infected file delete করা।
• শুধু homepage ঠিক করে hidden backdoor ও scheduled task উপেক্ষা করা।
• অজানা সময়ের backup blindly restore করে patch না করা।
• Compromised computer থেকেই সব নতুন password বদলানো।
• একই password, token বা SSH key অন্য account-এ রেখে দেওয়া।
• Nulled plugin, unofficial cleanup script বা অচেনা “security expert”-কে full access দেওয়া।
• Google review পাঠিয়ে site clean ধরে নেওয়া।
• Customer data impact মূল্যায়ন বা আইনগত advice দেরি করা।

প্রতিটি পরিবর্তনে কে, কখন, কেন এবং ফল কী লিখুন। Structured record না থাকলে এক দল যে file clean করেছে, অন্য দল সেটিই restore করে ফেলতে পারে। বড় incident-এ command ও evidence access আলাদা privilege-এ রাখা ভালো।

কাজ শুরুর আগে চেকলিস্ট

• Incident lead, timeline ও affected asset list তৈরি করা হয়েছে।
• ঝুঁকি অনুযায়ী service isolate; evidence ও log নিরাপদে সংরক্ষিত।
• পরিচ্ছন্ন device থেকে email, registrar, hosting ও privileged account সুরক্ষিত।
• Session, token, API key, SSH key ও application credential rotate/revoke করা হয়েছে।
• Known-clean source বা যাচাইকৃত backup দিয়ে clean recovery সম্পন্ন।
• Vulnerability patch, persistence removal ও root-cause action যাচাই করা হয়েছে।
• Functional, malware, integrity ও monitoring test শেষে controlled release হয়েছে।
• Search Console review এবং প্রযোজ্য legal/customer notification সম্পন্ন।

সম্পর্কিত আরও গাইড

Recovery-এর পরে server account শক্ত করতে web hosting control panel security guide পড়ুন। স্থিতিশীল ও support-ready infrastructure বাছার সময় Best Web Hosting Bangladesh 2026 গাইডের checklist কাজে লাগতে পারে।

সাধারণ প্রশ্ন ও উত্তর

Website hack হলে প্রথমে কি site delete করব?

না। ঝুঁকি অনুযায়ী isolate বা maintenance mode দিন, কিন্তু log ও forensic evidence সংরক্ষণ করুন। Delete করলে entry point ও data impact বোঝা কঠিন হয়। গুরুতর ঘটনার ক্ষেত্রে host বা incident-response specialist নিন।

শুধু backup restore করলেই কি website clean?

নিশ্চিত নয়। Backup compromise-এর পরের হতে পারে এবং vulnerability বা stolen credential থেকেই যেতে পারে। Restore-এর সঙ্গে evidence review, patch, credential rotation, persistence check এবং root-cause fix জরুরি।

Malware scanner clean বললে কি live করা যাবে?

Scanner গুরুত্বপূর্ণ signal, কিন্তু সব নতুন বা obfuscated backdoor ধরতে পারে না। Integrity comparison, account/cron review, log analysis, functional test ও root-cause closure মিলিয়ে release decision নিন।

Google-এর hacked warning কত দ্রুত সরবে?

Clean-up ও review-এর সময় incident ও review queue অনুযায়ী বদলায়; নিশ্চয়তা দেওয়া যায় না। পুরো site clean করে Security Issues report থেকে নির্দিষ্ট review পাঠান এবং monitoring চালিয়ে যান।

সব user-কে password বদলাতে বলব?

Credential exposure বা session risk থাকলে forced reset ও session revocation প্রয়োজন হতে পারে। Evidence, authentication design এবং legal advice অনুযায়ী সিদ্ধান্ত নিন; admin ও privileged account আগে সুরক্ষিত করুন।

হ্যাক হওয়া site নিজে পরিষ্কার করা কি নিরাপদ?

ছোট ও সীমিত incident-এ skilled owner guide অনুসরণ করতে পারেন। Payment, personal data, server takeover, repeated infection বা scope অনিশ্চিত হলে qualified security professional ও provider-এর সহায়তা নেওয়া নিরাপদ।

SSL থাকলে website hack হয় কীভাবে?

HTTPS connection encrypt করে; vulnerable code, weak password, stolen session বা malicious plugin আটকায় না। তাই patching, MFA, least privilege, backup, monitoring এবং secure development আলাদাভাবে দরকার।

শেষ কথা

Website Hacked Recovery-এর সফলতা মাপা হয় শুধু homepage স্বাভাবিক দেখাচ্ছে কি না দিয়ে নয়। Attacker-এর access বন্ধ, persistence অপসারণ, data impact বোঝা, clean rebuild, root cause fix এবং পুনরায় আক্রমণ দ্রুত ধরার ব্যবস্থা—সবগুলো শেষ হলে recovery বিশ্বাসযোগ্য হয়। Evidence না রেখে তাড়াহুড়ো cleanup বা blindly backup restore ভবিষ্যতের ঝুঁকি লুকিয়ে রাখে।

এখনই একটি ছোট incident card তৈরি করুন: hosting emergency contact, registrar access, backup location, technical owner এবং legal/privacy contact। নিয়মিত restore test ও account review করুন। সমস্যা ঘটলে এই প্রস্তুতি team-কে panic থেকে process-এ নিয়ে আসে এবং visitor ও business—দুই পক্ষের ক্ষতি কমায়।

Threat pattern, CMS feature, Search Console interface, hosting tool ও notification obligation সময় ও jurisdiction অনুযায়ী বদলায়। বাস্তব incident-এ বর্তমান vendor documentation এবং যোগ্য security/legal professional-এর পরামর্শ যাচাই করুন।