WAF, Shield, Firewall Manager আর DDoS ঠেকানো

এই লেসন শেষে তুমি পারবে

• AWS WAF কী পরীক্ষা করে (layer 7: path, query string, header, cookie, body), কোন কোন resource-এ web ACL লাগানো যায়, আর NLB, Classic Load Balancer বা সরাসরি EC2 instance-এ কেন লাগানো যায় না, বুঝিয়ে বলতে।
• Rule আর rule group দিয়ে একটা web ACL সাজাতে: priority, default action, Allow, Block, Count, CAPTCHA আর Challenge action, IP set, geo match, size constraint, regex, SQL injection আর XSS statement, আর AWS-এর managed rule group।
• Rate-based rule বানাতে (কমপক্ষে ১০টা request, ১, ২, ৫ বা ১০ মিনিটের window, aggregation key), আর এটা কী পারে না তাও জানতে।
• ALB-এর সামনে Global Accelerator বসিয়ে WAF-সুরক্ষিত application-কে static IP address দিতে, আর NLB দিয়ে বিকল্প পথটাও জানতে।
• Shield Standard আর Shield Advanced তুলনা করতে (কোন resource রক্ষা করে, দাম আর চুক্তি, SRT, health দেখে আক্রমণ চেনা, automatic application layer mitigation, cost protection)।
• Firewall Manager দিয়ে পুরো Organization জুড়ে WAF, Shield Advanced, security group, network ACL, Network Firewall আর DNS Firewall policy চাপাতে, আর এর পূর্বশর্তগুলো জানতে।
• DDoS ঠেকানোর AWS best practice BP1 থেকে BP7 কাজে লাগাতে: edge service, scaling, decoupling, caching, application layer-এর প্রতিরক্ষা আর আক্রমণের পথ কমানো।

#তিনটা আলাদা কাজ

বাংলাদেশের একটা পরীক্ষার result-এর website বছরে ৩৬৪ দিন চুপচাপ থাকে, তারপর result-এর দিন এক ঘণ্টার মধ্যে দশ লাখ ছাত্রছাত্রী একসাথে সেটা খোলে। আক্রমণকারীদেরও সবচেয়ে পছন্দের দিন এটাই। Site-টার সামনে তিন রকমের বিপদ, আর AWS-এর কাছে প্রতিটার জন্য আলাদা service:

• খারাপ request: roll নম্বরে SQL injection, comment form-এ লুকানো script, admin page-এ একটার পর একটা password চেষ্টা করা bot, প্রতিটা result কপি করে নেওয়া scraper। এর প্রতিটা আসল HTTP request, পড়লে তবেই বোঝা যায় খারাপ। এর জন্য AWS WAF, এমন একটা firewall যেটা layer 7 পড়তে পারে।
• বন্যা (flood): লাখ লাখ SYN packet, UDP reflection traffic, অথবা লাখ লাখ একদম বৈধ HTTP request, যাদের একটাই উদ্দেশ্য: server-কে হাঁপিয়ে তোলা। এর জন্য AWS Shield (layer 7-এর অংশের জন্য সাথে WAF-এর rate-based rule), আর এমন একটা design যেটা বোঝা সইতে পারে।
• অনেক account: শিক্ষা বোর্ড ২০টা AWS account চালায়। প্রতিটায় হাতে হাতে WAF আর security group সাজালে কোনো একটা যে বাদ পড়বেই, তা নিশ্চিত। এর জন্য AWS Firewall Manager।

লেসন ১১.২-এ CloudFront-এর edge-এর সুরক্ষা হিসেবে Shield Standard, WAF আর Shield Advanced-এর সাথে পরিচয় হয়েছে, কোন layer কোন আক্রমণ থামায় তার একটা table-সহ। এই লেসন প্রতিটা service-এর ভেতরে ঢুকবে, Firewall Manager যোগ করবে, আর শেষ করবে DDoS ঠেকানোর সেই AWS best practice দিয়ে, যেগুলো এই সবকিছুকে একসাথে বাঁধে।

#AWS WAF: যে firewall HTTP পড়তে পারে

AWS WAF (web application firewall) layer 7-এ চেনা web আক্রমণ থেকে web application-কে বাঁচায়। Security group বা network ACL দেখে address আর port (layer 3 আর 4); WAF দেখে HTTP request-এর ভেতরটা: URI path, query string, header, cookie, HTTP method আর body। প্রতিটা request ধরে সে ঠিক করে: যেতে দেবে, আটকাবে, শুধু গুনে রাখবে, নাকি client-কে একটা পরীক্ষা দিতে বলবে।

WAF এমন কোনো যন্ত্র না যেটা তুমি কোথাও বসাও। তুমি একটা web ACL বানাও আর একটা resource-এর সাথে associate করো; সেই resource-এর নিজের service (CloudFront, ALB, API Gateway…) প্রতিটা request process করার আগে WAF-এর হাতে তুলে দেয়।

#Web ACL কোথায় লাগানো যায়

তালিকায় যা নেই, পরীক্ষার জন্য সেটাও সমান জরুরি:

• Network Load Balancer, Gateway Load Balancer আর Classic Load Balancer: WAF নেই। NLB কাজ করে layer 4-এ, HTTP কখনো পড়েই না (লেসন ৬.৩)।
• সরাসরি EC2 instance: না। সামনে একটা ALB বা CloudFront বসাও।
• API Gateway HTTP API (কম দামের API type): না; শুধু REST API (লেসন ১৫.৬)।

Associate করার দুটো নিয়ম: একটা resource-এ একটাই web ACL থাকতে পারে, কিন্তু একটা web ACL তার scope-এর অনেকগুলো resource রক্ষা করতে পারে; আর web ACL এবং সে যা যা ব্যবহার করে (IP set, rule group, regex pattern set) সব থাকতে হবে resource-এর একই Region-এ। us-east-1-এর web ACL সিঙ্গাপুরের ALB-এর জন্য বাছাই করাই যায় না।

#Web ACL, rule আর rule group

একটা web ACL (web access control list) হলো সাজানো একটা rule-এর তালিকা, সাথে একটা default action:

• প্রতিটা rule-এর থাকে একটা priority (সবচেয়ে ছোট সংখ্যাটা WAF আগে যাচাই করে), একটা statement যেটা বলে কী মেলাতে হবে, আর একটা action।
• Rule group হলো আবার ব্যবহার করা যায় এমন একগুচ্ছ rule, যেটা web ACL-এ একটা entry হিসেবে বসে। এটা তোমার নিজের হতে পারে, AWS managed rule group হতে পারে, বা AWS Marketplace-এ কোনো vendor-এর বিক্রি করা group হতে পারে।
• কোনো rule যাচাই না থামালে খাটে default action (Allow বা Block)। বেশিরভাগ public site default Allow রাখে আর খারাপ traffic-এর জন্য Block rule দেয়; একটা private admin tool হয়তো default Block রেখে শুধু অফিসের address-এর জন্য Allow rule দেবে।

Rule-এর action-গুলো:

Label দিয়ে rule-গুলো একটার সাথে আরেকটা জোড়া যায়: একটা Count rule (বা managed rule group) awswaf:managed:aws:sql-database:SQLi_QueryArguments-এর মতো একটা label লাগাতে পারে, আর পরের কোনো rule সেই label দেখে কাজ করতে পারে। “সব জায়গায় SQL injection block করো, শুধু এই একটা ঘর বাদে” এভাবেই বানানো হয়, পুরো group বন্ধ না করে।

প্রতিটা rule-এর একটা capacity unit খরচ আছে (web ACL capacity unit, মানে একটা rule চালাতে কতটা প্রক্রিয়াকরণ লাগে তার মাপ; IP set-এর চেয়ে regex-এর খরচ বেশি)। একটা web ACL-এর মূল দামের মধ্যে থাকে ১,৫০০ unit, বাড়তি দাম দিয়ে ৫,০০০ পর্যন্ত নেওয়া যায়। দামের একটা আন্দাজ: web ACL-প্রতি মাসে প্রায় ৫ USD, rule বা rule group-প্রতি মাসে ১ USD, আর প্রতি দশ লাখ request পরীক্ষায় ০.৬০ USD; Bot Control, Fraud Control আর কিছু managed group-এর জন্য বাড়তি।

#একটা rule কী কী মেলাতে পারে

বড় body-র শুধু শুরুর অংশটুকু WAF পরীক্ষা করে: ALB আর AppSync-এ 8 KB (বদলানো যায় না), CloudFront, API Gateway, Cognito, App Runner আর Verified Access-এ default 16 KB (বাড়তি দামে 64 KB পর্যন্ত বাড়ানো যায়)। Oversize handling setting ঠিক করে সীমার চেয়ে বড় body হলে কী হবে: চালিয়ে যাওয়া, match ধরা, নাকি no match। আক্রমণকারী body-তে আজেবাজে জিনিস ভরে আসল payload-টা 8 KB-র পরে লুকাতে পারে; এজন্যই setting-টা ঠিক করা, বা একটা size constraint যোগ করা দরকার।

#AWS managed rule group

ভালো SQL injection আর XSS rule লেখা কঠিন কাজ। AWS কিছু rule group নিজে সামলায়, যেগুলো তাদের threat research দল তোমার হয়ে হালনাগাদ রাখে:

• Baseline group: core rule set (OWASP Top 10-এর অনেক ঝুঁকি থেকে সুরক্ষা, যেমন XSS, local file inclusion, আর 8 KB-র বড় request body), admin protection (বাইরে থেকে admin page-এ ঢোকা আটকায়), আর known bad inputs (exploit-এর সাথে জড়িত request-এর ধরন, Log4j দুর্বলতাসহ)।
• Use-case group: SQL database (SQL injection), Linux, POSIX আর Windows operating system, PHP আর WordPress application।
• IP reputation group: Amazon IP reputation list (যেসব address আক্রমণ, bot বা খোঁজাখুঁজিতে ধরা পড়েছে) আর anonymous IP list (VPN, Tor exit node, hosting provider, যারা আসল client-কে আড়াল করে)।

এই baseline, use-case আর reputation group-এর জন্য সাধারণ WAF দামের বাইরে আলাদা কোনো fee নেই। প্রথমে Count mode-এ যোগ করো, এক সপ্তাহ log পড়ো, তারপর Block-এ নাও; আর যে একটা rule আসল traffic-কে ধরে, শুধু সেটাকে override করো।

একই web ACL নিজে চালিয়ে দেখো। SQL group-কে Count-এ নাও, ভর্তির ছবি upload চেষ্টা করো, আর default action Block করে দেখো বেশিরভাগ public site কেন Allow রাখে।

#Log আর চোখে দেখা

• Logging: একটা web ACL পুরো log (প্রতিটা request, কোন rule মিলল, কী action, label, header) পাঠাতে পারে CloudWatch Logs, একটা S3 bucket বা একটা Amazon Data Firehose stream-এ। Log group, bucket বা stream-এর নাম শুরু হতে হবে aws-waf-logs- দিয়ে। Authorization header-এর মতো স্পর্শকাতর ঘর ঢেকে (redact) রাখা যায়। তারপর CloudWatch Logs Insights বা Athena উত্তর দেয় “এই ছাত্রকে কোন rule block করল?” (লেসন ১৯.২, লেসন ১৭.১)।
• Sampled request: পুরো logging না থাকলেও console প্রতিটা rule-এর মিলে যাওয়া সাম্প্রতিক request-এর একটা নমুনা ৩ ঘণ্টা পর্যন্ত দেখায়।
• Metric: প্রতিটা rule আর web ACL allowed, blocked আর counted request-এর সংখ্যা CloudWatch-এ পাঠায়, তাই blocked request হঠাৎ বেড়ে গেলে alarm বাজানো যায়।

#WAF-এর সামনে একটা fixed IP address

Notes আর slide p687-এর একটা প্যাঁচালো design প্রশ্ন। বাংলাদেশের এক garments রপ্তানিকারকের order API-তে call করে ইউরোপের এক buyer। Buyer-এর firewall শুধু তালিকায় থাকা IP address-এ বাইরে যেতে দেয়, আর তালিকায় প্রতিটা বদলের জন্য কয়েক সপ্তাহের অনুমোদন লাগে। রপ্তানিকারক আবার চায় API-টা AWS WAF দিয়ে সুরক্ষিত থাকুক।

• ALB-তে web ACL লাগানো যায়, কিন্তু তার কোনো static IP নেই। Scale করার সময় আর node বদলানোর সময় তার address বদলে যায়, আর allow করার মতো কোনো তালিকা AWS দেয় না।
• NLB-এর static IP আছে (প্রতি AZ-এ একটা Elastic IP), কিন্তু সে layer 4-এর, তাই তার সাথে WAF জোড়া যায় না।

উত্তর হলো ALB-এর সামনে AWS Global Accelerator। Accelerator দেয় দুটো static anycast IPv4 address, যেগুলো তার পুরো জীবনে বদলায় না (লেসন ১১.৪)। Buyer ওই দুটো address একবারই allow করে। Global Accelerator traffic-টা AWS-এর network দিয়ে ALB-তে পৌঁছে দেয়, আর ALB-এর web ACL (ALB-এর Region-এ) সেটা পরীক্ষা করে।

User → Global Accelerator (২টা fixed IP) → web ACL-ওয়ালা ALB → target।

Global Accelerator-এর নিজের কোনো WAF নেই, HTTP-ও পড়ে না; সে শুধু স্থির একটা প্রবেশপথ দেয় আর Region-এর মধ্যে দ্রুত failover করে। Edge-এ তাকে Shield Standard রক্ষা করে, আর Shield Advanced-ও তাকে রক্ষা করতে পারে।

#AWS Shield: DDoS থেকে সুরক্ষা

একটা DDoS (distributed denial of service) আক্রমণে একসাথে অনেক machine থেকে traffic পাঠিয়ে একটা service-কে অচল করার চেষ্টা হয়। Slide p688 এক কথায় বলে “একই সময়ে অনেক request”; সেই request হতে পারে এমন packet যেগুলো কখনো connection-ই হয় না (layer 3 আর 4), আবার হতে পারে বৈধ HTTP request (layer 7)।

#Shield Standard

Shield Standard বিনা পয়সার, নিজে থেকে চালু, আর প্রতিটা AWS customer-এর জন্য খোলা; subscribe বা চালু করার কিছু নেই। এটা চেনা layer 3 আর layer 4-এর আক্রমণ থেকে রক্ষা করে: SYN flood, UDP flood, reflection attack (DNS, NTP বা memcached server-কে ঠকিয়ে শিকারের দিকে বড় বড় উত্তর পাঠানো), আর এরকম আরও। সুরক্ষা সবচেয়ে শক্ত edge service-গুলোতে, CloudFront, Route 53 আর Global Accelerator, যেখানে AWS শত শত location জুড়ে flood শুষে নেয়; Region-এর resource-ও (ELB, Elastic IP) আওতায় আছে। Shield Standard HTTP পড়ে না, তাই বৈধ HTTP request-এর flood তার কাজ না: ওটা WAF-এর কাজ।

#Shield Advanced

Shield Advanced হলো টাকার tier, সেইসব application-এর জন্য যাদের বন্ধ হওয়া চলবে না:

• Protected resource: CloudFront distribution, Route 53 hosted zone, Global Accelerator standard accelerator, Application আর Classic Load Balancer, আর Elastic IP address। EC2 instance আর NLB রক্ষা পায় তাদের Elastic IP-র মাধ্যমে। Shield Advanced নিজে থেকে কিছুই রক্ষা করে না: প্রতিটা resource তোমাকে যোগ করতে হয় (বা একটা Firewall Manager policy যোগ করে দেয়)।
• দাম: organization-প্রতি মাসে ৩,০০০ USD (payer account-এ একবার নেওয়া হয়, তার সব member account এর আওতায়), এক বছরের চুক্তি, সাথে protected resource-এর data transfer out-এর usage fee। Protected resource-এর AWS WAF-এর খরচ এর মধ্যেই ধরা (মাসে বিশাল একটা request সংখ্যা পর্যন্ত, default capacity-তে), আর Shield Advanced customer-দের জন্য Firewall Manager policy বিনা পয়সায়।
• প্রতিটা resource-এর মাপে detection: Shield Advanced প্রতিটা protected resource-এর স্বাভাবিক traffic শিখে নেয়, আর Standard-এর চেয়ে নিচু, resource-ভিত্তিক সীমা ব্যবহার করে।
• Health দেখে detection: একটা protected resource-এর সাথে একটা Route 53 health check জুড়ে দাও (লেসন ৮.৪)। Traffic অস্বাভাবিক আর application-ও অসুস্থ হলে Shield Advanced বেশি নিশ্চিত হয় যে এটা আক্রমণ; দ্রুত ধরে, আর শুধু ভিড়ের দিনে ভুল সতর্কতা কম দেয়।
• Automatic application layer DDoS mitigation: layer 7 আক্রমণের সময় Shield Advanced protected resource-এর web ACL-এ WAF rule বানায়, যাচাই করে আর বসিয়ে দেয়, তুমি যেভাবে বেছে নাও সেভাবে Block বা Count mode-এ। এর জন্য resource-এর সাথে একটা web ACL associate থাকতে হয় (CloudFront, ALB)।
• Shield Response Team (SRT): AWS-এর DDoS বিশেষজ্ঞ দল, আক্রমণের সময় সাহায্যের জন্য দিনে-রাতে ২৪ ঘণ্টা (Business বা Enterprise Support লাগে; December 2025-এর plan বদলের পর এর মানে Business Support+, Enterprise Support বা Unified Operations, যদিও পরীক্ষার প্রশ্নে এখনো Business বা Enterprise-ই লেখা থাকে)। Proactive engagement চালু থাকলে কোনো ঘটনার সময় protected resource-এর health check খারাপ হলে SRT নিজেই তোমাকে ফোন করে। Slide p688 এদের বলে DRP; পুরোনো নাম ছিল DDoS Response Team (DRT), এখনকার নাম SRT।
• DDoS cost protection: protected resource-এ আক্রমণের কারণে scaling-এর খরচ বাড়লে (বেশি EC2 instance, বেশি CloudFront বা ELB ব্যবহার), সেই খরচের জন্য service credit চাইতে পারো।
• Protection group: কয়েকটা protected resource একসাথে বাঁধো (যেমন একটা application-এর সব ALB), যাতে detection আর mitigation-এ Shield এদের একটা একক হিসেবে দেখে।
• চোখে দেখা: resource-প্রতি আক্রমণের report আর CloudWatch metric, সাথে বিশ্বজুড়ে হুমকির একটা dashboard।

#AWS Firewall Manager

AWS Firewall Manager একটা AWS Organization-এর সব account জুড়ে এক জায়গা থেকে firewall rule সামলায়। Firewall Manager-এর administrator account-এ তুমি একবার একটা security policy লেখো; Firewall Manager সেটা scope-এর প্রতিটা account আর resource-এ চাপিয়ে দেয়, যাচাই করতে থাকে, আর নতুন account আর নতুন resource তৈরি হলেই তাদের ওপরও চাপায়।

#পূর্বশর্ত

1. Account-গুলো AWS Organizations-এ, all features চালু (লেসন ২০.১)।
2. একটা Firewall Manager administrator account ঠিক করা (management account থেকে; সাধারণত আলাদা একটা security account)।
3. Scope-এর প্রতিটা member account আর Region-এ AWS Config চালু; resource খুঁজে পেতে আর পরিবর্তন নজরে রাখতে Firewall Manager এটা ব্যবহার করে (লেসন ১৯.৭)।
4. Network Firewall আর DNS Firewall policy-র জন্য AWS RAM দিয়ে resource sharing; third-party firewall-এর জন্য Marketplace subscription।

#Policy-র ধরন

Policy বানানো হয় Region-প্রতি (CloudFront-এর জন্য policy global)। প্রতিটা policy non-compliant resource নিজে থেকে ঠিক করতে পারে, বা শুধু জানাতে পারে। Firewall Manager-এর দাম policy-প্রতি Region-প্রতি মাসে প্রায় ১০০ USD, সাথে তার বানানো AWS Config rule আর নিচের service-গুলোর (WAF, Network Firewall…) খরচ; Shield Advanced customer-দের জন্য policy বিনা পয়সায়।

#WAF, Firewall Manager নাকি Shield?

এগুলো একসাথেই ব্যবহার হয়, কিন্তু প্রতিটা আলাদা প্রশ্নের উত্তর দেয় (slide p690):

Rule সবসময় লেখা হয় WAF-এই। Firewall Manager শুধু সেগুলো ছড়িয়ে দেয়, আর Shield Advanced তার চারপাশে যোগ করে detection, বিশেষজ্ঞ আর টাকার সুরক্ষা।

#DDoS ঠেকানোর best practice

AWS একটা whitepaper প্রকাশ করে, AWS Best Practices for DDoS Resiliency, যেখানে প্রতিটা অংশকে একটা best practice নম্বর দেওয়া। Slide p691–p694 এই label ব্যবহার করে, তাই পরীক্ষাতেও আসতে পারে:

#Edge-এই থামানো: BP1 আর BP3

প্রতিরক্ষার প্রথম ধাপ: application-কে কখনো সরাসরি খুলে রেখো না। Web application-এর সামনে CloudFront, TCP বা UDP application-এর (বা যে HTTP back end CloudFront-এর সাথে খাপ খায় না তার) সামনে Global Accelerator, আর DNS দাও Route 53 থেকে। তখন আক্রমণের traffic গিয়ে পড়ে AWS-এর global edge network-এ, যার capacity মাপা হয় terabit per second-এ আর যার ভেতরে Shield-এর ব্যবস্থা বসানো, আর সেখানেই শুষে নেওয়া বা ছেঁকে ফেলা হয়, তোমার origin থেকে অনেক দূরে। CloudFront বা WAF যে request ফিরিয়ে দেয়, তার জন্য CloudFront-এর data transfer-এর টাকা লাগে না।

#Scale করো, আলাদা করো, cache করো

কিছু traffic ছাঁকা যায় না, কারণ দেখতে হুবহু আসল user-এর মতো; আবার কোনো কোনো দিন আসল user-রাই flood। Design-কে সেটা সইতে হবে:

• Infrastructure scaling (BP6, BP7): একটা Auto Scaling group-এর সামনে একটা ALB (লেসন ৬.৫)। Load balancer নিজেই scale করে; বোঝা বাড়লে group instance যোগ করে। আক্রমণের সময় এই scaling-এ টাকা লাগে বলেই Shield Advanced-এর cost protection আছে।
• Decoupling: web tier আর ধীর back-end কাজের মাঝখানে SQS (বা Kinesis) বসাও (লেসন ১৩.১)। ঝাঁকটা ভরে যাওয়া database না হয়ে লম্বা একটা queue হয়ে থাকে, যেটা worker-রা স্থির গতিতে খালি করে।
• Edge-এ caching: CloudFront static content (আর cache করা যায় এমন API response) edge location থেকে পরিবেশন করে, তাই বেশিরভাগ request origin-এ পৌঁছায়ই না। অচেনা query string উপেক্ষা করা একটা cache policy আক্রমণকারীকে random URL দিয়ে cache ফাঁকি দিতে দেয় না।

#Application layer-এর প্রতিরক্ষা: BP1 আর BP2

Layer 7 আক্রমণ সূক্ষ্ম: একটা HTTP GET বা POST flood-এ প্রতিটা request আলাদা করে বৈধ, তাক করা হয় দামি page-এ (search, login, report বানানো), যাতে CPU আর memory ফুরিয়ে যায়। Shield Standard এগুলোকে আক্রমণ হিসেবে দেখে না। প্রতিরক্ষা হলো CloudFront বা ALB-তে AWS WAF:

• Rate-based rule বেশি request পাঠানো source-গুলোকে block বা challenge করে।
• Managed rule খারাপ IP reputation-ওয়ালা address বা anonymous source (VPN, Tor, hosting provider) থেকে আসা request block করে।
• WAF-এর geo rule, বা CloudFront-এর geographic restriction, এমন পুরো দেশ block করে যেখানে site-এর কোনো user নেই।
• CloudFront caching একই content-এর বারবার আসা request শুষে নেয়।
• Shield Advanced (BP1, BP2, BP6) যোগ করে automatic application layer mitigation, যেটা আক্রমণের সময় তোমার হয়ে WAF rule লিখে দেয়।

Rate-based rule খুঁটিয়ে

একটা rate-based rule প্রতিটা aggregation key-র (default-এ প্রতিটা source IP address) request একটা চলমান evaluation window ধরে গোনে, আর key-টা সীমা-র ওপরে থাকা পর্যন্ত তার পরের request-এ নিজের action চাপায়:

• সীমা: ১০টা request থেকে শুরু। Notes-এর “৫ মিনিটে ২,০০০ request” শুধু একটা উদাহরণ (একসময় এটাই ছিল সর্বনিম্ন, তারপর ১০০; আগস্ট ২০২৪ থেকে সর্বনিম্ন ১০, আর ১, ২ ও ১০ মিনিটের window এসেছে মার্চ ২০২৪-এ)।
• Evaluation window: ১, ২, ৫ বা ১০ মিনিট (৬০, ১২০, ৩০০ বা ৬০০ সেকেন্ড); default ৫ মিনিট। Window মানে প্রতিবার যাচাইয়ের সময় WAF কতটা পেছনে তাকায়, কত ঘনঘন যাচাই করে তা না।
• Aggregation: source IP; X-Forwarded-For-এর মতো header থেকে নেওয়া IP (WAF কোনো proxy-র পেছনে থাকলে); ASN; scope-down statement-এ মেলা সব request একসাথে গোনা; বা custom key, পাঁচটা পর্যন্ত একসাথে, header, cookie, একটা query argument, পুরো query string, URI path, HTTP method, label namespace, JA3 বা JA4 fingerprint আর IP থেকে। “IP + session cookie” দিলে একটা NAT address-এর পেছনে থাকলেও প্রতিটা login করা user আলাদা গোনা হয়।
• Scope-down statement: শুধু মিলে যাওয়া request গোনো, যেমন শুধু POST /login, যাতে login page-এর কড়া সীমা সাধারণ browsing-এ হাত না দেয়।
• Action: Block (403 বা নিজের বানানো 429 response), CAPTCHA, Challenge বা Count। Allow কখনো না।
• সময়: WAF সারাক্ষণ rate আন্দাজ করে, আর কোনো source সীমা পেরোলে সাধারণত ৩০ সেকেন্ডের মধ্যে আটকানো শুরু করে; rate আবার সীমার নিচে নামলে WAF নিজেই বাধা তুলে নেয়, সেটাও সাধারণত ৩০ সেকেন্ডের মধ্যে। এটা গতিসীমা, নিখুঁত counter না: সীমার ওপরের কয়েকটা request পার হয়ে যেতে পারে।

#আক্রমণের পথ কমানো: BP1, BP4, BP5, BP6

দরজা যত কম, আক্রমণকারীর কড়া নাড়ার জায়গাও তত কম:

• Back end লুকাও (obfuscation): user পৌঁছায় CloudFront, API Gateway বা load balancer-এ, কখনো সরাসরি instance বা Lambda function-এ না।
• Private subnet: application server আর database-এর কোনো public address নেই (লেসন ৩.৫)।
• Security group আর network ACL (BP5): শুধু যে port-এ সেবা দাও সেটাই খোলো (443, redirect-এর জন্য হয়তো 80), আর শুধু যাদের দরকার তাদের জন্য; network ACL subnet-এ নির্দিষ্ট address deny করতে পারে। Elastic IP-কে Shield Advanced রক্ষা করতে পারে।
• API endpoint রক্ষা (BP4): edge-optimized API Gateway endpoint ব্যবহার করো, বা বেশি নিয়ন্ত্রণের জন্য regional endpoint-এর সামনে নিজের CloudFront distribution (WAF-সহ); API-তে WAF, throttling আর burst limit, আর partner-দের জন্য usage plan-সহ API key যোগ করো।
• Origin-কে CloudFront-এর পেছনে তালাবন্ধ করো: যে আক্রমণকারী সরাসরি origin-এ পৌঁছাতে পারে, সে edge-এর cache, WAF আর Shield সব পাশ কাটিয়ে যায়।
  • S3 origin: Origin Access Control (OAC), সাথে এমন bucket policy যেটা শুধু distribution-কে allow করে (লেসন ১০.৯)।
  • ALB বা EC2 origin: এমন security group যেটা শুধু AWS managed prefix list com.amazonaws.global.cloudfront.origin-facing-কে allow করে, সাথে CloudFront-এর যোগ করা একটা গোপন custom header (যেমন X-Origin-Verify; নাম তোমার পছন্দ), যেটা ALB একটা listener rule বা WAF rule দিয়ে যাচাই করে। শুধু prefix list দিলে প্রতিটা CloudFront distribution ঢুকতে পারে, আক্রমণকারীর বানানোটাও; header সেই ফাঁক বন্ধ করে।
  • CloudFront VPC origin (নভেম্বর ২০২৪): ALB, NLB বা EC2 instance থাকে private subnet-এ, কোনো public address-ই নেই, আর CloudFront VPC origin দিয়ে সেখানে পৌঁছায়। এটা খিড়কি পাহারা না দিয়ে খিড়কিটাই তুলে দেয়।

#কোথায় গোলমাল হয়

• “Associate web ACL”-এ কোনো NLB দেখা যায় না: WAF NLB, CLB বা GWLB সমর্থন করে না। ALB ব্যবহার করো, বা সামনে CloudFront।
• কোনো resource-এর জন্য web ACL বাছাই করা যাচ্ছে না: সেটা ভুল Region-এ, বা সেটা CloudFront-এর (global) web ACL আর তুমি regional resource-এ লাগাতে চাইছ, বা resource-এ আগে থেকেই একটা web ACL আছে।
• Managed group চালুর পর আসল user block হচ্ছে: false positive (ঠিকানার ঘরে “--”, 8 KB body rule-এ আটকে যাওয়া বড় ছবি upload)। Count দিয়ে শুরু করো, log পড়ো, আলাদা আলাদা rule-কে Count-এ override করো বা scope-down দিয়ে সংকীর্ণ করো।
• আক্রমণের payload পরীক্ষার সীমার পরে লুকানো: 8 KB-র বড় body (ALB) পুরোটা পরীক্ষা হয় না। Oversize handling-কে match-এ রাখো, বা একটা size constraint যোগ করো।
• Rate rule-এ পুরো campus বা অফিস block: একটা NAT address-এর পেছনে অনেক user। ভালো একটা key দিয়ে গোনো, চেনা range আগে allow করো, বা rule-কে স্পর্শকাতর path-এ সীমিত করো।
• ALB-এর rate rule user না গুনে CloudFront গুনছে: forwarded IP header দিয়ে গোনো, বা CloudFront-এর web ACL-এ rate limit করো।
• WAF CloudFront রক্ষা করছে কিন্তু origin এখনো public: আক্রমণকারী পাশ দিয়ে যায়। Origin তালাবন্ধ করো (prefix list + header, OAC, VPC origin)।
• Shield Advanced subscribe করা, কিন্তু একটা resource অরক্ষিত: সেটা কখনো যোগই করা হয়নি। Resource সরাসরি যোগ করো, বা Firewall Manager-এর Shield Advanced policy দিয়ে।
• Layer 7 automatic mitigation হচ্ছে না: protected resource-এর সাথে কোনো web ACL associate করা নেই।
• Firewall Manager একটা account-কে অজানা দেখায় বা policy চাপায় না: সেখানে AWS Config record করছে না, account-টা policy-র scope-এর বাইরে, বা Organization-এ all features চালু নেই।
• Allowlist করা ALB IP আর কাজ করে না: ALB-এর address বদলায়। Global Accelerator ব্যবহার করো (বা ALB target-ওয়ালা NLB)।
• কোনো log আসছে না: destination-এর নাম aws-waf-logs- দিয়ে শুরু হয়নি।
• একটা খারাপ IP সব জায়গা থেকে block করা: request কোথায় থামানো হচ্ছে (NACL, security group, ALB, CloudFront-এর WAF) তার ওপর tool বদলায়; লেসন ২৪.৩-এ তুলনা আছে।

#System design-এ WAF আর Shield

মনে রাখার মতো pattern:

• Public web application: Route 53 → CloudFront + WAF → ALB (CloudFront-এ তালাবন্ধ) → private subnet-এ Auto Scaling group → private subnet-এ database।
• Allowlist-ওয়ালা partner API: Global Accelerator (২টা static IP) → ALB + WAF → target।
• Public API: API Gateway (edge-optimized, বা CloudFront + regional) + WAF + throttling আর usage plan → Lambda।
• অনেক account: WAF, security group আর Shield Advanced-এর জন্য Firewall Manager policy; finding আর compliance যায় Security Hub-এ (লেসন ২১.৭)।
• HTTP না এমন traffic (game, UDP-তে VoIP): Global Accelerator + Shield (Elastic IP আর accelerator-এর জন্য Advanced); WAF এখানে খাটে না। VPC-র ভেতরে packet খুঁটিয়ে দেখা হলো AWS Network Firewall (লেসন ২২.৭)।
• সব জায়গায় HTTPS: CloudFront আর ALB-এর TLS certificate আসে ACM থেকে (লেসন ২১.৪); CloudFront বা ALB-এ TLS খোলার পরে decrypt হওয়া request-টা WAF পরীক্ষা করে।

#নিজে করে দেখো

এখানে AWS CLI v2 ব্যবহার হয়েছে। WAF আর Firewall Manager-এ মাসে মাসে টাকা লাগে, আর Shield Advanced তোমাকে এক বছরের জন্য বেঁধে ফেলে, তাই চালানোর আগে পড়ে নাও, আর যা বানাও মুছে দাও।

এই rule-গুলো rules.json নামে রাখো, ap-southeast-1-এর একটা ALB রক্ষা করা regional web ACL-এর জন্য:

[
  { "Name": "block-scrapers", "Priority": 1,
    "Statement": { "IPSetReferenceStatement": { "ARN": "arn:aws:wafv2:ap-southeast-1:111122223333:regional/ipset/scrapers/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } },
    "Action": { "Block": {} },
    "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "block-scrapers" } },
  { "Name": "admin-only-from-bd", "Priority": 2,
    "Statement": { "AndStatement": { "Statements": [
      { "NotStatement": { "Statement": { "GeoMatchStatement": { "CountryCodes": ["BD"] } } } },
      { "ByteMatchStatement": { "FieldToMatch": { "UriPath": {} }, "PositionalConstraint": "STARTS_WITH",
          "SearchString": "/admin", "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ] } } ] } },
    "Action": { "Block": {} },
    "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "admin-geo" } },
  { "Name": "per-ip-limit", "Priority": 3,
    "Statement": { "RateBasedStatement": { "Limit": 300, "EvaluationWindowSec": 300, "AggregateKeyType": "IP" } },
    "Action": { "Block": { "CustomResponse": { "ResponseCode": 429 } } },
    "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "per-ip-limit" } },
  { "Name": "core-rule-set", "Priority": 4,
    "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesCommonRuleSet" } },
    "OverrideAction": { "None": {} },
    "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "crs" } },
  { "Name": "sql-database", "Priority": 5,
    "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesSQLiRuleSet" } },
    "OverrideAction": { "Count": {} },
    "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "sqli" } }
]

"OverrideAction": { "Count": {} } প্রথম সপ্তাহে পুরো SQL group-কে Count mode-এ চালায়; এর rule-গুলোকে block করতে দিতে এটা বদলে { "None": {} } করো।

# ১. Scraper-দের address-এর একটা IP set (প্রতি set-এ ১০,০০০ পর্যন্ত)
aws wafv2 create-ip-set --name scrapers --scope REGIONAL --region ap-southeast-1 \
  --ip-address-version IPV4 --addresses 203.0.113.77/32 198.51.100.0/26
# { "Summary": { "Name": "scrapers", "Id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
#   "ARN": "arn:aws:wafv2:ap-southeast-1:111122223333:regional/ipset/scrapers/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", ... } }

# ২. Web ACL (default Allow), আর একই Region-এর ALB-এর সাথে তার association
aws wafv2 create-web-acl --name results-acl --scope REGIONAL --region ap-southeast-1 \
  --default-action Allow={} --rules file://rules.json \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=results-acl
aws wafv2 associate-web-acl --region ap-southeast-1 \
  --web-acl-arn arn:aws:wafv2:ap-southeast-1:111122223333:regional/webacl/results-acl/f1e2d3c4-EXAMPLE \
  --resource-arn arn:aws:elasticloadbalancing:ap-southeast-1:111122223333:loadbalancer/app/results-alb/50dc6c495c0c9188

# ৩. পুরো log CloudWatch Logs-এ (নাম শুরু হতে হবে aws-waf-logs- দিয়ে)
aws logs create-log-group --log-group-name aws-waf-logs-results --region ap-southeast-1
aws wafv2 put-logging-configuration --region ap-southeast-1 --logging-configuration \
  ResourceArn=arn:aws:wafv2:ap-southeast-1:111122223333:regional/webacl/results-acl/f1e2d3c4-EXAMPLE,LogDestinationConfigs=arn:aws:logs:ap-southeast-1:111122223333:log-group:aws-waf-logs-results

# ৪. নিজের laptop থেকে পরীক্ষা: একটা injection, তারপর একটা ঝাঁক
curl -s -o /dev/null -w "%{http_code}\n" "https://results.example.com/result?roll=1%27%20OR%201=1--"
# 200   (SQL group এখনো Count mode-এ; None-এ বদলালে 403 আসে)
for i in $(seq 1 600); do curl -s -o /dev/null -w "%{http_code}\n" https://results.example.com/result?roll=482913; done | sort | uniq -c
#    341 200
#    259 429   (সীমাটা আন্দাজের: WAF সাড়া দেওয়ার আগে ৩০০-র ওপরে কয়েক ডজন পার হয়ে গেছে)

# ৫. Rate rule এই মুহূর্তে কোন কোন address আটকাচ্ছে?
aws wafv2 get-rate-based-statement-managed-keys --scope REGIONAL --region ap-southeast-1 \
  --web-acl-name results-acl --web-acl-id f1e2d3c4-EXAMPLE --rule-name per-ip-limit
# { "ManagedKeysIPV4": { "IPAddressVersion": "IPV4", "Addresses": [ "198.51.100.20/32" ] } }

# ৬. Shield Advanced (শুধু যদি তোমার organization সত্যিই subscribe করে: ১ বছরের চুক্তি)
aws shield describe-subscription --query 'Subscription.[SubscriptionLimits.ProtectionLimits,AutoRenew,TimeCommitmentInSeconds]'
aws shield create-protection --name results-cdn \
  --resource-arn arn:aws:cloudfront::111122223333:distribution/E1A2B3C4D5E6F7
# { "ProtectionId": "a1b2c3d4-EXAMPLE-protection" }
aws shield associate-health-check --protection-id a1b2c3d4-EXAMPLE-protection \
  --health-check-arn arn:aws:route53:::healthcheck/abcdef12-3456-7890-abcd-EXAMPLE22222
aws shield enable-application-layer-automatic-response \
  --resource-arn arn:aws:cloudfront::111122223333:distribution/E1A2B3C4D5E6F7 --action Count={}

# ৭. Firewall Manager (administrator account থেকে): Organization-এর প্রতিটা ALB-এর জন্য একটা WAF policy
aws fms put-policy --region ap-southeast-1 --policy '{
  "PolicyName": "org-baseline-waf",
  "SecurityServicePolicyData": { "Type": "WAFV2",
    "ManagedServiceData": "{\"type\":\"WAFV2\",\"preProcessRuleGroups\":[{\"managedRuleGroupIdentifier\":{\"vendorName\":\"AWS\",\"managedRuleGroupName\":\"AWSManagedRulesCommonRuleSet\"},\"overrideAction\":{\"type\":\"NONE\"},\"ruleGroupType\":\"ManagedRuleGroup\",\"excludeRules\":[]}],\"postProcessRuleGroups\":[],\"defaultAction\":{\"type\":\"ALLOW\"},\"overrideCustomerWebACLAssociation\":false}" },
  "ResourceType": "AWS::ElasticLoadBalancingV2::LoadBalancer",
  "ExcludeResourceTags": false, "RemediationEnabled": true }'
aws fms list-compliance-status --region ap-southeast-1 --policy-id 1a2b3c4d-EXAMPLE \
  --query 'PolicyComplianceStatusList[].[MemberAccount,EvaluationResults[0].ComplianceStatus]' --output text
# 111122223333    COMPLIANT
# 444455556666    NON_COMPLIANT   (নতুন একটা ALB, ঠিক করার কাজ চলছে)

Console-এও চেষ্টা করো: ৪ নম্বর ধাপের পরে SQL rule-এর Sampled requests খোলো, তারপর aws-waf-logs-results-এ CloudWatch Logs Insights চালিয়ে action = "BLOCK" দিয়ে filter করো। শেষে disassociate-web-acl, delete-web-acl, delete-ip-set আর aws fms delete-policy দিয়ে পরিষ্কার করো।

#সারসংক্ষেপ

মূল কথাগুলো

• AWS WAF = layer 7-এর firewall। একটা web ACL (priority ক্রমে rule + একটা default action) লাগে CloudFront-এ (global, বানাতে হয় us-east-1-এ), ALB, API Gateway REST API, AppSync, Cognito user pool, App Runner, Verified Access, Amplify-তে, resource-এর একই Region-এ। NLB, CLB বা EC2-তে কখনো না।
• Rule মেলায় IP set (প্রতি set-এ ১০,০০০ address), geo, SQL injection, XSS, size, string/regex, label, rate। Action: Allow, Block, Count (যাচাই থামায় না), CAPTCHA, Challenge। AWS managed rule group: core rule set, known bad inputs, SQL database, IP reputation, anonymous IP; টাকার Bot Control, Fraud Control, Anti-DDoS। আগে Count-এ পরীক্ষা। Log যায় CloudWatch Logs, S3 বা Firehose-এ (aws-waf-logs- নাম)।
• Rate-based rule: সীমা ১০ থেকে, window ১, ২, ৫ বা ১০ মিনিট (default ৫), IP বা forwarded IP, ASN, custom key (cookie, header, path…) ধরে, scope-down-সহ; action Block, CAPTCHA, Challenge বা Count, Allow কখনো না; WAF নিজেই বাধা তুলে নেয়। ৫ মিনিটে ২,০০০ শুধু একটা উদাহরণ।
• Fixed IP + WAF → Global Accelerator → WAF-ওয়ালা ALB (NLB WAF নেয় না; ALB-type target group-ওয়ালা NLB-ও কাজ করে)।
• Shield Standard: বিনা পয়সায়, নিজে থেকে, layer 3/4 (SYN, UDP, reflection)। Shield Advanced: organization-প্রতি মাসে ৩,০০০ USD, ১ বছরের চুক্তি + data transfer; CloudFront, Route 53, Global Accelerator, ALB, CLB, Elastic IP (EC2, NLB); মাপমতো আর health দেখে detection, WAF দিয়ে automatic layer 7 mitigation, SRT ২৪/৭, DDoS cost protection credit, protection group, WAF-এর খরচ ধরা।
• Firewall Manager: পুরো Organization জুড়ে এক জায়গা থেকে WAF, Shield Advanced, security group, network ACL, Network Firewall, DNS Firewall আর third-party firewall policy; নতুন account আর resource নিজে থেকে আওতায় আসে। লাগে Organizations, একটা administrator account আর AWS Config।
• DDoS best practice: BP1 CloudFront আর Global Accelerator, BP2 WAF, BP3 Route 53, BP4 API Gateway, BP5 security group আর NACL, BP6 ELB, BP7 Auto Scaling। Edge-এ শুষে নাও, scale করো (ALB + ASG), আলাদা করো (SQS), cache করো, layer 7 ছাঁকো (WAF rate rule), আর আক্রমণের পথ কমাও (private subnet, তালাবন্ধ origin: ALB-এর জন্য prefix list + header, S3-এর জন্য OAC, VPC origin)।

নিজেকে যাচাই করো: WAF, Shield আর Firewall Manager৩৩টি প্রশ্ন