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	current bandwidth/packet rate, attack workload, BGP peer state ও announced route count
Traffic	১ ঘণ্টা থেকে ৭ দিনের selectable bandwidth, packet-rate ও flow-rate time series
Destinations	Facebook/Meta, YouTube/Google, TikTok, Cloudflare, Amazon/AWS, BDIX, major ASN ও exporter/uplink-এর direction-aware traffic
Attacks	শনাক্ত incident evidence, response ও lifecycle update
Analytics	clean-period baseline/policy coverage অথবা peak rate, timeline, vector/severity, affected device, attacking IP, RIR/community evidence এবং routing-security signal
Sources	source IP ও public origin ASN ranking; private/CGNAT address-এ ASN দেখানো হয় না
Connectivity	inferred অথবা selected ASN, observed path adjacency, IPv4/IPv6 visibility, announced prefix, RPKI state এবং declared exchange presence
Targets	protected destination অনুযায়ী bandwidth, packet, flow ও traffic share
Protocols	flow record থেকে decoded IP protocol ও destination-port distribution
Telemetry	flow exporter, sensor ও cloud log source পরিচালনা
Detection	bps, pps ও fps policy এবং vector signal coverage
Response & BGP	Router peer, live session state, active route count, external connector ও mitigation exclusion
Runbook	incident triage, approval, verification ও recovery checklist

Destinations protected network থেকে external destination-এর দিকে যাওয়া traffic এবং সেখান থেকে আসা traffic আলাদাভাবে দেখায়। Public content ASN স্বয়ংক্রিয়ভাবে label হয়; কোনো provider নির্বাচিত সময়ে দেখা না গেলে zero থাকে, demo data দেখানো হয় না। Local CDN/cache, IIG, BDIX member path বা uplink universal ASN দিয়ে নির্ভুলভাবে বোঝা যায় না, তাই network team-এর দেওয়া exact ASN বা CIDR দিয়ে tenant override যোগ করুন। Longest CIDR match প্রথমে, তারপর tenant ASN, তারপর built-in public-service ASN প্রয়োগ হয়।

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

• Group Admin network profile, protected scope, source, policy ও connector পরিচালনা করতে পারেন।
• NOC user workspace দেখতে পারেন; setup, telemetry, policy বা traffic classification পরিচালনায় manage-ddos-policies এবং BGP/response connector, mitigation allowlist, attack lifecycle বা response action পরিচালনায় 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

Connected RouterOS device বাছাই করলে ISPbills router-এর observed public exporter address পড়ে, একটি managed Traffic Flow target রাখে এবং দ্রুত recovery-এর জন্য NetFlow v9 template refresh configure করে। ISPbills-এর নিজস্ব C++ sensor managed UDP endpoint-এ প্রতিটি exporter-এর template ও baseline state আলাদা রাখে। Real flow record decode হওয়ার আগে source Pending থাকে; শুধু API success বা UDP packet আসা Healthy হিসেবে ধরা হয় না।

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। First-party managed collector NetFlow v5/v9 ও IPFIX decode করে। sFlow, SPAN এবং cloud log-এর জন্য deployed sensor/log adapter observation-কে authenticated sensor contract-এ normalize করে পাঠায়।

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

ISPbills-এ আগে থেকে connected RouterOS device-এর জন্য শুধু Telemetry থেকে 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 চালানোর প্রমাণ নয়।

Response & BGP-এ প্রতিটি connected RouterOS 7 device-এর Configure ISPbills BGP peer action saved API connection দিয়ে ISPbills-এর নিজস্ব speaker-এর সঙ্গে dedicated eBGP multihop session তৈরি করে। Peer address directly connected হওয়া প্রয়োজন নেই; routed hop অতিক্রম করতে পারে। Card-এ real router identity, দুই endpoint address/ASN, Established state এবং active route count দেখা যায়।

ISPbills peer endpoint-টি router থেকে TCP/179-এ সত্যিই reachable IPv4 address হতে হবে। Speaker DNAT-এর পেছনে bind করতে পারে, তবে cloud security group, host firewall ও NAT আগে session permit করতে হবে। আগে থেকে routed private/VPN transport থাকলে সেটিও explicit configuration-এ ব্যবহার করা যায়; unprovisioned shared-space address আর ধরে নেওয়া হয় না।

Approved incident-এ শুধু আক্রান্ত IPv4 /32 community 65535:666-সহ announce হয় এবং expiry-তে withdraw হয়। Suspended-user pool permanent RouterOS input/forward firewall drop-এ থাকে এবং কখনো BGP-তে announce হতে পারে না। BGP ছাড়া fallback হিসেবে RouterOS local exact-host blackhole-ও ব্যবহার করা যায়। External neighbor, scrubber, blocklist বা webhook-এর জন্য advanced form collapsed থাকে।

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 উভয়ই প্রত্যাখ্যাত হয়।

Automatic safety perimeter tenant-এর router, OLT, managed switch/radio, gateway, collector/BGP endpoint, connector address এবং সম্পূর্ণ suspended-user pool নিজে থেকে খুঁজে নেয়। Proposal, approval, sensor claim এবং শেষ RouterOS/BGP execution-এর আগে address আবার যাচাই হয়। তাই pending request তৈরির পরে essential address যোগ হলেও সেটি blackhole হবে না।

Attack Analytics target ও source IP-কে tenant-এর device, customer, live RADIUS session এবং access site-এর সঙ্গে মিলিয়ে দেখায়। Internal attacking source-কে নিশ্চিত malicious না বলে possible self-DDoS, misconfiguration অথবা compromised device হিসেবে investigation-এর জন্য চিহ্নিত করা হয়।

Public source-এর registration IANA bootstrap থেকে নির্বাচিত official APNIC, ARIN, RIPE NCC, LACNIC বা AFRINIC RDAP service দিয়ে আসে। Licensed abuse.ch Feodo Tracker ও Emerging Threats feed কেবল expiring evidence যোগ করে; RIR ownership বা feed match নিজে থেকে কোনো block অনুমোদন করে না। Local ASN ও public protected prefix থাকলে RPKI/origin/path evidence possible BGP hijack বা route leak warning দেখায়—flow telemetry একা এগুলো প্রমাণ করে না। Graph ও metric-এর exact value mouse, keyboard focus এবং touch-এ দেখা যায়।

৬. 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 পাঠাবেন না।