DDoS আক্রমণ: ধরন, লক্ষণ ও প্রতিরোধ

DDoS নতুন কিছু নয়, কিন্তু আজ এটি অনেক বেশি সহজ, সস্তা এবং স্কেলেবল হয়ে গেছে। আগে কয়েকটি ভুল কনফিগার করা সার্ভার বা একটি ছোট botnet দিয়েই কোনো সার্ভিস ব্যাহত করা যেত। এখন আমরা প্রায়ই এমন আক্রমণ দেখি যা সেকেন্ডের ভগ্নাংশে লিংক স্যাচুরেট করতে পারে, firewall ওভারলোড করতে পারে, কিংবা দেখতে “স্বাভাবিক” মনে হওয়া রিকোয়েস্ট দিয়ে অ্যাপ্লিকেশনকে থামিয়ে দিতে পারে।

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

(D)DoS কী?

একটি Denial-of-Service (DoS) আক্রমণে আক্রমণকারী কোনো সার্ভিসকে অচল করতে চায় ডেটা চুরি করে নয়, বরং সেটিকে ওভারলোড করে বা তার রিসোর্স শেষ করে দিয়ে। টার্গেট হলো availability: আপনার ওয়েবসাইট লোড হয় না, API timeout করে, VPN gateway নতুন session নেয় না, অথবা DNS resolver আর সামাল দিতে পারে না।

Distributed-এ “D” মানে ট্রাফিক এক উৎস থেকে নয়, অনেক উৎস থেকে আসে। এটা compromised ডিভাইসের botnet হতে পারে, বৈধ ইনফ্রাস্ট্রাকচার (reflection/amplification) হতে পারে, কিংবা দুটোর মিশ্রণ। অপারেটর হিসেবে আপনার চোখে ফলাফল একই: আপনি একজন আক্রমণকারীর সাথে লড়ছেন না, আপনি একটি বিতরণকৃত ঢেউয়ের সাথে লড়ছেন।

মোটিভেশন: কেন DDoS আক্রমণ করা হয়?

কারণগুলো প্রায়ই খুব সাধারণ, কিন্তু কার্যকর:

• চাঁদাবাজি: “পেমেন্ট করো, নইলে আবার নামিয়ে দেব।”
• অ্যাক্টিভিজম/রাজনীতি: দৃশ্যমানতা, বার্তা, বিঘ্ন।
• ডিস্ট্রাকশন: DDoS টিমকে ব্যস্ত রাখে, একই সময়ে অন্য কিছু ঘটতে পারে।
• কম্পিটিশন/স্যাবোটাজ: সময়-সংবেদনশীল মুহূর্তে (ticketing, release, launch) সামান্য ডাউনটাইমও ক্ষতি করে।
• কস্ট প্রেসার: সব আক্রমণ পূর্ণ outage-এর জন্য নয়; অনেক সময় লক্ষ্য থাকে cloud খরচ, support লোড বা অপারেশনাল স্ট্রেস বাড়ানো।

গুরুত্বপূর্ণ লেয়ার (এবং কেন এগুলো গুরুত্বপূর্ণ)

DDoS-কে প্রায়ই লেয়ার অনুযায়ী ব্যাখ্যা করা হয়, কারণ লেয়ার বলে দেয় কোন সিগন্যাল দেখতে হবে এবং কোন ডিফেন্স সম্ভব।

• Layer 3 (IP): কোথা থেকে এসেছে, কোথায় যাচ্ছে।
• Layer 4 (TCP/UDP): পোর্ট, কানেকশন, handshake, state।
• Layer 7 (Application): HTTP(S) রিকোয়েস্ট, API, বিজনেস এন্ডপয়েন্ট।
• “Layer 8” (Business logic): অফিসিয়াল নয়, কিন্তু বাস্তব: অ্যাপে থাকা ব্যয়বহুল লজিক যেটা অপব্যবহার করা যায়।

মূল কথা: Layer 3/4-এ দারুণ ডিফেন্স থাকলেও Layer 7 আক্রমণে ব্যর্থ হতে পারে, কারণ রিকোয়েস্টগুলো বৈধ মনে হয় এবং অ্যাপে ঢোকার পরেই ব্যয়বহুল হয়ে ওঠে।

আক্রমণের ধরন 1: ভলিউম ও amplification (প্রায়ই UDP)

ভলিউমেট্রিক আক্রমণের লক্ষ্য হলো ব্যান্ডউইথ বা প্যাকেট প্রসেসিং (pps) ধ্বসিয়ে দেওয়া। একটি ক্লাসিক পদ্ধতি হলো reflection/amplification:

1. আক্রমণকারী পাবলিকলি রিচেবল সার্ভারে ছোট রিকোয়েস্ট পাঠায় (যেমন open DNS resolver)।
2. সে source IP spoof করে এবং ভিকটিমের IP-কে “source” হিসেবে দেয়।
3. সার্ভারগুলো অনেক বড় রেসপন্স ভিকটিমের দিকে পাঠায়।

যদি 100-byte রিকোয়েস্টে 1,000-byte রেসপন্স আসে, তাহলে আপনার amplification factor 10। প্রোটোকল ও payload অনুযায়ী এটি অনেক বেশি হতে পারে। সমস্যাটি হলো: ভিকটিমের দৃষ্টিতে ট্রাফিক “স্বাভাবিক” সার্ভিস থেকে আসছে, যেগুলো আপনি সাধারণত ব্লক করতে চান না।

গুরুত্বপূর্ণ পয়েন্ট: amplification সাধারণত source IP spoofing-এর ওপর নির্ভর করে। তাই ingress filtering (BCP 38) এত গুরুত্বপূর্ণ। প্রোভাইডার যদি edge-এ forged source address ব্লক করে, এই ভেক্টর অনেক কঠিন হয়ে যায়।

আক্রমণের ধরন 2: প্রোটোকল ও state exhaustion (TCP/Layer 4)

সব DDoS সর্বোচ্চ ব্যান্ডউইথের জন্য নয়। অনেক সময় লক্ষ্য হলো টার্গেটে state তৈরি করা, যতক্ষণ না টেবিল বা রিসোর্স পূর্ণ হয়ে যায়।

একটি ক্লাসিক উদাহরণ হলো TCP-তে SYN flood:

• সাধারণত TCP three-way handshake দিয়ে কানেকশন তৈরি করে (SYN -> SYN/ACK -> ACK)।
• SYN flood-এ আক্রমণকারী বিপুল SYN পাঠায়, কিন্তু শেষ ACK আসে না।
• সার্ভার অনেক half-open কানেকশন (state) ধরে রাখে এবং timeout হওয়া পর্যন্ত retry করে।

এতে মেমোরি ও CPU খরচ হয় এবং outbound ব্যান্ডউইথও ক্ষতিগ্রস্ত হতে পারে। আর আপনার কাছে ব্যান্ডউইথ থাকলেও, session tracking টেবিল পূর্ণ হলেই সার্ভিস ডাউন হতে পারে।

একই ক্যাটেগরির আরেকটি ধরন হলো low and slow: আক্রমণকারী বাস্তব কানেকশন খুলে খুব অল্প ট্রাফিক দিয়ে সেগুলো খোলা রাখে, যতক্ষণ না web server বা load balancer কানেকশন লিমিটে পৌঁছায়। বড় ট্রাফিক স্পাইকের মতো এটি অনেক কম দৃশ্যমান হতে পারে।

আক্রমণের ধরন 3: Layer 7 এবং “Layer 8” (HTTP, API, ব্যয়বহুল এন্ডপয়েন্ট)

Layer 7 আক্রমণ সাধারণত সবচেয়ে বিরক্তিকর, কারণ এগুলোকে বৈধ ট্রাফিক থেকে আলাদা করা কঠিন। উদাহরণ:

• HTTP flood: ডাইনামিক পেজ, সার্চ এন্ডপয়েন্ট, বা login flow-এ প্রচুর রিকোয়েস্ট।
• Slowloris/slow headers: হেডার/বডি খুব ধীরে পাঠিয়ে কানেকশন খোলা রাখা।
• “ব্যয়বহুল” বিজনেস লজিক: DB query, এক্সটার্নাল API কল, PDF জেনারেশন, ক্রিপ্টোগ্রাফি বা AI/agent workflow ট্রিগার করা এন্ডপয়েন্ট।

ট্রিকটা সবসময় “আরও ট্রাফিক” নয়, বরং প্রতি রিকোয়েস্টে আরও কাজ। সঠিকভাবে টার্গেট করা সামান্য ট্রাফিকও ক্যাশড স্ট্যাটিক GET-এর বড় ঢেউয়ের চেয়ে বেশি ব্যয়বহুল হতে পারে।

প্রোডাকশনে DDoS শনাক্ত করবেন কীভাবে?

শুধু CPU আর RAM দেখলে অনেক আক্রমণ দেরিতে ধরা পড়বে। বাস্তবে baseline এবং কিছু শক্তিশালী মেট্রিক অনেক সাহায্য করে:

• Traffic: edge-এ bps ও pps (router, firewall, load balancer)।
• Connection metrics: নতুন কানেকশন/s, ওপেন session, SYN backlog, TLS handshake/s।
• HTTP metrics: RPS, latency (p95/p99), 4xx/5xx রেশিও, timeout।
• Upstream symptoms: packet loss, RTT বৃদ্ধি, লিংক স্যাচুরেশন, BGP ইভেন্ট।
• Log/WAF signals: অস্বাভাবিক path, invalid header, অসম্পূর্ণ রিকোয়েস্ট বেশি, সন্দেহজনক user-agent/pattern।

সবচেয়ে গুরুত্বপূর্ণ বিষয় সহজ: আপনার baseline দরকার। baseline ছাড়া সব কিছু “অনেক” মনে হয়। baseline থাকলে হঠাৎ বোঝা যায় “ছোট প্যাকেট” বা “অসম্পূর্ণ রিকোয়েস্ট” স্বাভাবিক থেকে কতটা বিচ্যুত।

Mitigation: বাস্তবে কী কাজ করে?

দুটি প্রধান পথ আছে: make (নিজে বানানো) বা buy (সার্ভিস ব্যবহার করা)। বেশিরভাগ টিমের জন্য “buy” বাস্তবসম্মত, কারণ DDoS mitigation দ্রুতই এমন একটি সমস্যা হয়ে দাঁড়ায় যা সাইড প্রজেক্ট হিসেবে চালানো যায় না।

1) অ্যাপের সামনে কিছু রাখুন: CDN/WAF/DDoS প্রোভাইডার

ওয়েবসাইট ও API-এর ক্ষেত্রে এটি অনেক সময় সবচেয়ে কার্যকর:

• Anycast নেটওয়ার্ক ট্রাফিক অনেক লোকেশনে ছড়িয়ে দেয়।
• WAF রুল স্পষ্ট Layer 7 প্যাটার্ন ফিল্টার করতে পারে।
• Bot management, rate limit এবং challenge/response “সস্তা” আক্রমণ কমায়।

মনে রাখবেন: সব আক্রমণ HTTP নয়। VPN, VoIP, গেম সার্ভার বা UDP-ভিত্তিক সার্ভিস থাকলে সেটআপ অনুযায়ী আলাদা সুরক্ষা দরকার হবে।

2) Rate limiting এবং timeout ঠিকভাবে সেট করুন

সাধারণ, কিন্তু ঠিকভাবে করলে কার্যকর:

• ICMP/“ping”: সীমিত করুন, পুরোপুরি বন্ধ করবেন না (troubleshooting লাগে)।
• HTTP: IP/token/route অনুযায়ী limit দিন, বিশেষ করে ব্যয়বহুল এন্ডপয়েন্টে।
• Slow requests: অসম্পূর্ণ header/body-এর জন্য কঠোর timeout।

উদাহরণ (Nginx, খুব সরল):

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;

location /api/ {
  limit_req zone=api_per_ip burst=40 nodelay;
}

এটা silver bullet নয়, তবে economics বদলায়: “সস্তা” আক্রমণ কঠিন হয়ে যায়।

3) আর্কিটেকচার: ব্যয়বহুল কাজ আলাদা করুন

Layer 7 DDoS অনেক সময় ব্যান্ডউইথে আঘাত করে না। আঘাত করে সেই জায়গাগুলোতে যেখানে একটি রিকোয়েস্টই খুব ব্যয়বহুল। এবং স্বাভাবিক কোম্পানি সেটআপে এমন জায়গা অনেক: login, search, PDF export, report, upload, complex query, বা external API call।

একটি সাধারণ উদাহরণ: কাস্টমার পোর্টালে একটি export বাটন থাকে (“invoice PDF”, “report তৈরি”, “সব ZIP”)। স্বাভাবিক সময়ে কেউ কয়েক মিনিট পরপর ব্যবহার করে। আক্রমণে একই এন্ডপয়েন্ট প্রতি মিনিটে শত শত বা হাজার বার ট্রিগার হয়। ব্যান্ডউইথ নয়, আসল সমস্যা CPU (rendering), DB (query) আর worker pool (thread/connection)। বাইরে থেকে শুধু মনে হয় “সাইট স্লো”। ভিতরে আপনি দেখবেন timeout, queueing আর DB আর পারছে না।

ভাল খবর হলো: সবকিছু নতুন করে বানাতে হবে না। কিছু আর্কিটেকচার সিদ্ধান্ত অনেক সময় যথেষ্ট:

• Caching (error page সহ), যুক্তিযুক্ত TTL, edge caching।
• ব্যয়বহুল কাজের জন্য asynchronous processing (queue): “এখনই PDF” না করে job ট্রিগার করুন।
• কঠোর validation ও early abort: কমপ্লেক্সিটি ও হার্ড লিমিট দিন।
• login/search/upload/export-এর জন্য আলাদা সুরক্ষা: আলাদা rate limit/timeout, প্রয়োজনে আলাদা worker pool।
• “Degraded mode” (feature flag): ডিপ্লয় স্ট্রেস ছাড়াই সাময়িকভাবে ফিচার বন্ধ।

4) Upstream অপশন: filtering, scrubbing, ইমার্জেন্সি প্ল্যান

স্কেল খুব বড় হলে ট্রাফিক আপনার লিঙ্কে আসার আগেই ফিল্টার করতে হয়:

• প্রোভাইডারের filtering / scrubbing center
• অস্থায়ী ব্লক রুল (যেমন: “আমার web server-এ UDP কেন?”)
• ইমার্জেন্সি routing (যেমন: “protected” IP-তে সুইচ করা)

এটা তখনই কাজ করে যখন আপনি প্রোভাইডারের সাথে আগে থেকেই আলোচনা করেছেন। ইনসিডেন্টের মাঝে “ad hoc” শুরু করা সময় ও খরচ দুটোই বাড়ায়।

একটি প্র্যাগম্যাটিক চেকলিস্ট (DDoS বিশেষজ্ঞ ছাড়া টিমের জন্য)

• Inventory: কোন সার্ভিসগুলো পাবলিক? HTTP, DNS, VPN, mail, gaming, VoIP?
• Single point of failure: DNS প্রোভাইডার, reverse proxy, load balancer, একটাই region?
• Observability: bps/pps, RPS, latency, error, connection count, baseline-ভিত্তিক alert।
• Harden defaults: timeout, limit, max header size, connection limit, backpressure।
• Provider plan: কে scrubbing করবে, কে ফিল্টার করবে, escalation path কী।
• Runbook: “X হলে Y”, contacts/threshold/switch (feature flags) সহ।
• Practice: নিয়ন্ত্রিত load test ও incident drill (আইনসম্মত ও সমন্বিত)।

শেষ কথা: টেস্ট করুন, তবে আইনসম্মত ও কাজে লাগে এমনভাবে

DDoS টেস্ট করা সংবেদনশীল। পাবলিক ইন্টারনেট, তৃতীয় পক্ষের সিস্টেম বা অনুমতি ছাড়া ইনফ্রা - সবই অফ লিমিট। যা করতে পারেন:

• নিজের staging-এ load test (বিশেষ করে ব্যয়বহুল এন্ডপয়েন্টে)।
• dependency নিয়ে chaos test (cache down, DB slow, rate limit কঠোর)।
• রেসপন্স প্রক্রিয়া অনুশীলন: alert, কমিউনিকেশন, প্রোভাইডার escalation, জরুরি ব্যবস্থা।

সূত্র ও আরও পড়া

• Cloudflare: Defending the Internet: How Cloudflare blocked a monumental 7.3 Tbps DDoS attack (2025)
• Cloudflare: DDoS threat report for 2025 Q1
• CISA: Understanding Denial-of-Service Attacks
• RFC 2827 (BCP 38): Network Ingress Filtering
• RFC 3704: Ingress Filtering for Multihomed Networks

পরবর্তীবার পর্যন্ত, Joe