DDoS Protection

DDoS Protection হলো ISPbills-এর স্বতন্ত্র detection ও response workspace। এটি flow ও sensor telemetry থেকে আক্রমণের মতো traffic pattern শনাক্ত করে, evidence সংরক্ষণ করে এবং NOC-কে পর্যালোচিত response পরিচালনা করতে সাহায্য করে।

Tenant-এর paid DDoS Protection plan অথবা Group Admin কর্তৃক স্পষ্টভাবে শুরু করা একবারের ১৪ দিনের decision trial প্রয়োজন। Trial শেষে panel ও sensor API pause হয়; Group Admin plan নেবেন অথবা service বন্ধ রাখবেন। Trial থেকে কোনো invoice তৈরি বা plan স্বয়ংক্রিয়ভাবে চালু হয় না।

কোথা থেকে খুলবেন

Group Admin বা অনুমোদিত NOC user sidebar-এর একক DDoS Protection entry থেকে workspace খুলবেন। এর ভেতরের navigation-এ আছে:

Workspace	ব্যবহার
Setup	ছয় ধাপের onboarding ও readiness review
Overview	monitoring state, sensor health, policy ও unresolved attack summary
Attacks	শনাক্ত traffic event যাচাই ও lifecycle update
Telemetry	flow exporter, sensor ও cloud log source পরিচালনা
Detection	bps, pps ও fps policy এবং vector signal coverage
Mitigation	response path, approval mode ও connector readiness পর্যালোচনা
Integrations	RouterOS RTBH, scrubber, blocklist ও webhook connector configuration
Runbook	incident triage, approval, verification ও recovery checklist

কার কী permission প্রয়োজন

• Group Admin network profile, protected scope, source, policy ও connector পরিচালনা করতে পারেন।
• NOC user workspace দেখতে পারেন; policy বা source পরিচালনায় manage-ddos-policies এবং attack lifecycle update-এ manage-ddos-mitigation permission প্রয়োজন।
• Sensor token দেখার প্রয়োজন হলে শুধু অনুমোদিত user-কে view-ddos-sensor-token দিন। Token secret manager-এ রাখুন।

Permission থাকলেও প্রতিটি response-এর আগে target, scope, impact ও rollback যাচাই করতে হবে।

---

ছয় ধাপের onboarding

১. Network profile

Setup → Network profile-এ লিখুন:

• প্রতিষ্ঠান বা network-এর নাম
• Local ASN, যদি প্রযোজ্য হয়
• পর্যবেক্ষণ করা capacity (Gbps)
• baseline শেখার সময়সীমা
• NOC notification email
• response approval mode

Approval mode-এর অর্থ:

Mode	আচরণ
Manual queue	অনুমোদিত responder প্রতিটি সমর্থিত action স্পষ্টভাবে queue করেন
Single approval	proposal একজন অনুমোদিত responder-এর approval-এর জন্য অপেক্ষা করে
Dual control	দুইজন আলাদা অনুমোদিত responder-এর approval প্রয়োজন
Verified automatic	যোগ্য critical detection অন্য সব safety gate পূরণ করলে verified automatic connector queue করতে পারে

২. Protected scope

আপনার প্রতিষ্ঠানের মালিকানাধীন অথবা monitor ও protect করার অনুমতি থাকা public বা private IPv4/IPv6 CIDR অথবা single host যোগ করুন। Single host স্বয়ংক্রিয়ভাবে IPv4 /32 বা IPv6 /128 হিসেবে সংরক্ষিত হয়। Subscriber space, infrastructure range, point-to-point link, transit segment এবং private service network এতে থাকতে পারে। এটি allowlist নয়; address যোগ করা মানে route announce, filter বা scrub করা নয়, বরং কোথায় detection ও approved exact-host response করা যাবে তা নির্ধারণ করে।

৩. Telemetry

Telemetry → Add source থেকে একটি source নিবন্ধন করুন। সমর্থিত source type:

• sFlow
• NetFlow v5 ও NetFlow v9
• IPFIX
• SPAN sensor
• AWS VPC Flow Logs
• GCP VPC Flow Logs

এখানে NetFlow v5/v9 কেবল সমর্থিত flow telemetry protocol।

Source সংরক্ষণ করলে প্রথমে Pending থাকে। Sensor heartbeat ও event পাওয়া গেলে Healthy হতে পারে; দীর্ঘ সময় data না এলে Stale, validation ব্যর্থ হলে Error এবং ইচ্ছাকৃতভাবে বন্ধ থাকলে Disabled দেখা যায়।

ISPbills-এ আগে থেকে connected RouterOS device-এর জন্য Telemetry অথবা Integrations থেকে Configure Traffic Flow in one step ব্যবহার করুন। শুধু device এবং NetFlow v5/v9 অথবা IPFIX বাছাই করুন। ISPbills ছয় অক্ষরের shared service ID তৈরি করে, managed collector address ও reserved port read-only দেখায় এবং saved API connection দিয়ে Traffic Flow enable করে। একই ID RTBH connector-এ ব্যবহৃত হয়। API 8728 ও API-SSL 8729 দুটিই সমর্থিত।

Sensor token নিরাপদে রাখুন

Monitoring activate বা token rotate করার পর optional self-hosted sensor token collapsed section-এ একবারই দেখানো হয়। Connected RouterOS device ISPbills managed collector ব্যবহার করলে Group Admin-এর এই token প্রয়োজন নেই। নিজস্ব sensor/collector ব্যবহার করলে তখনই:

1. token copy করুন;
2. অনুমোদিত secret manager-এ রাখুন;
3. প্রয়োজনীয় sensor configuration-এ দিন;
4. ticket, chat, screenshot বা সাধারণ note-এ token লিখবেন না।

Token rotate করলে আগের token সঙ্গে সঙ্গে অকার্যকর হতে পারে। সব sender update করার maintenance plan ছাড়া rotate করবেন না।

৪. Detection policy

Detection তিনটি মূল metric ব্যবহার করে:

Metric	কী বোঝায়
bps	প্রতি সেকেন্ডে traffic bandwidth; link saturation signal
pps	প্রতি সেকেন্ডে packet; packet-processing pressure ও flood signal
fps	প্রতি সেকেন্ডে নতুন flow; session/connection surge signal

Capacity-based recommended policy প্রয়োগ করলে তিন metric-এর জন্য শুরু করার threshold তৈরি হয়। প্রতিটি policy-তে scope, absolute threshold, learned-baseline multiplier, evaluation window ও severity review করুন।

Signal configured মানে সংশ্লিষ্ট metric-এর policy আছে; এটি সব attack ধরার নিশ্চয়তা নয়। Application-layer abuse শুধু flow record দিয়ে নিশ্চিত করা যায় না—application, CDN বা WAF telemetry দিয়ে যাচাই করুন।

৫. Response controls

Response connector detection থেকে আলাদা। উপলভ্য connector type:

Connector	উদ্দেশ্য	প্রধান ঝুঁকি
RTBH	অনুমোদিত host target-এর traffic blackhole করার response path	target-এর সব traffic হারাতে পারে
RouterOS local blackhole	BGP neighbor ছাড়াই selected router-এ exact /32 বা /128 blackhole route	traffic router পর্যন্ত link ব্যবহার করে
Scrubbing provider	চুক্তিবদ্ধ provider-এ escalation বা diversion	provider ও route design-এর ওপর নির্ভরশীল
Blocklist	reviewed indicator edge/firewall workflow-এ পাঠানো	ভুল indicator বৈধ source block করতে পারে
Webhook	authenticated বাহ্যিক incident/automation system-এ event পাঠানো	বাহ্যিক system-এর policy ও credential boundary প্রযোজ্য

নতুন connector Pending অবস্থায় তৈরি হয়। Ready শুধু verification বোঝায়, active mitigation নয়। Observe mode network change পাঠায় না; Approval mode review চায়; Automatic mode নির্বাচন করা configuration intent মাত্র—backend safety gate ও target authorization ছাড়া এটি কোনো action চালানোর প্রমাণ নয়।

Configure response শুরুতে collapsed থাকে। Expand করে connected RouterOS device বাছাই করলে ISPbills existing BGP session থেকে shared ছয় অক্ষরের connector name, local ASN, neighbor ASN/address, session name, local address, router ID এবং address family পাওয়া গেলে auto-fill করে। Neighbor internal mitigation speaker অথবা external RTBH service হতে পারে; transit-provider peer বাধ্যতামূলক নয়।

BGP neighbor না পাওয়া গেলে RouterOS local blackhole স্বয়ংক্রিয়ভাবে নির্বাচিত হয়। Saved API connection দিয়ে route capability যাচাই হয়; approved detection হলে শুধু আক্রান্ত IPv4 /32 বা IPv6 /128 blackhole route যোগ হয় এবং expiry-তে একই route সরানো হয়। এতে BGP লাগে না, তবে traffic selected router পর্যন্ত link ব্যবহার করে। BGP RTBH বাছাই করলে receiving neighbor-এর ASN/address এবং accepted blackhole community দিতে হবে।

Protected scope বলে কোন address monitor ও approved exact-host response করা যাবে; CIDR বা single host দেওয়া যায় এবং single host /32 বা /128 হয়। Mitigation allowlist আলাদা ও উল্টো safety control: এখানে যেকোনো public বা private host/CIDR রাখা যায়; সেটি protected scope বা ISPbills-এর অন্য inventory-তে থাকার প্রয়োজন নেই। Peering, point-to-point, DNS, management, monitoring এবং সবসময় reachable রাখতে হবে এমন address এখানে দিন। Matching target-এর manual ও automatic mitigation উভয়ই প্রত্যাখ্যাত হয়।

৬. Activate monitoring

Activation-এর আগে readiness review-তে অন্তত নিশ্চিত করুন:

• network profile সংরক্ষিত;
• অন্তত একটি protected prefix আছে;
• অন্তত একটি telemetry source configured;
• bps, pps ও fps policy enabled;
• response approval policy বোঝা ও review করা হয়েছে।

Activate monitoring baseline-learning mode শুরু করে। এটি connector চালায় না এবং attack traffic থামায় না। Baseline পর্যাপ্ত না হওয়া পর্যন্ত static threshold-এর signal বেশি গুরুত্ব পেতে পারে।

---

Attack queue ব্যবহার

প্রতিটি attack record-এ vector, target IP, severity, confidence, peak bps/pps/fps, baseline এবং first/last-seen সময় দেখুন। তারপর:

1. telemetry freshness ও exporter identity যাচাই করুন;
2. interface counter, upstream graph বা service telemetry দিয়ে signal মিলিয়ে দেখুন;
3. record-টি Investigating করুন;
4. traffic চলতে থাকলে Monitoring রাখুন;
5. স্থিতিশীল হলে Resolved, অথবা যাচাই করে ভুল signal হলে False positive করুন।

Status বদলানো mitigation নয়। এটি incident lifecycle ও audit trail হালনাগাদ করে।

নিরাপদ response checklist

কোনো network-impacting action প্রস্তাবের আগে নিশ্চিত করুন:

1. target declared protected scope-এর ভেতরে;
2. source data সাম্প্রতিক এবং একাধিক signal-এর সঙ্গে সামঞ্জস্যপূর্ণ;
3. connector সত্যিই Ready এবং expected peer/endpoint-এর সঙ্গে যুক্ত;
4. action-এর exact target, duration, blast radius ও rollback লেখা আছে;
5. configured approval mode পূরণ হয়েছে;
6. execution-এর পর route/filter state, traffic change ও customer reachability স্বাধীনভাবে যাচাই করা হয়েছে;
7. temporary control expire বা withdraw হয়েছে এবং outcome নথিভুক্ত হয়েছে।

সাধারণ সমস্যা

অবস্থা	কী পরীক্ষা করবেন
Source Pending	monitoring activated কি না, token ও source identity সঠিক কি না
Source Stale	sender path, recent heartbeat/event এবং cloud-log delay
Source Error	source configuration ও displayed validation error; secret প্রকাশ করবেন না
Baseline learning দীর্ঘ হচ্ছে	source নিয়মিত data পাঠাচ্ছে কি না এবং profile-এর baseline days
Vector coverage pending	bps, pps ও fps policy enabled কি না; targeted coverage-এর জন্য scoped policy আছে কি না
Connector pending/error	endpoint/peer reference, external readiness ও last test result
খালি attack queue	telemetry Healthy ও monitoring active কি না; খালি queue-কে “network safe” ধরে নেবেন না

সমস্যা থাকলে Support → Ticket-এ source type, status, timestamp ও non-secret error detail দিন। Sensor token, API key বা routing credential পাঠাবেন না।