প্রতিটা স্তরে একটা IP Address Block করা

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

• যেকোনো architecture-এ প্রতিটা ধাপ source হিসেবে কোন address দেখে তা বলতে: NACL, security group, ALB, NLB আর তার target, AWS WAF, CloudFront, আর CloudFront-এর পেছনের origin।
• Public IP-ওয়ালা একটা EC2 instance-এ একটা IP block করতে: allow-এর আগের নম্বরে NACL deny, security group কেন পারে না, আর host firewall-এর দাম কী।
• ALB-এর পেছনে ALB-এর subnet-এর NACL দিয়ে বা fixed 403 response-ওয়ালা source-ip listener rule দিয়ে IP block করতে, আর ALB-এর পেছনের কেউ কেন পারে না তা বোঝাতে।
• NLB-এর পেছনে NACL দিয়ে IP block করতে, আর NLB-এর শুধু-allow security group, client IP preservation আর WAF না থাকা কী বদলায় তা বোঝাতে।
• তালিকা লম্বা হলে, বা সাথে SQL injection, XSS আর rate limiting লাগলে ALB + WAF বেছে নিতে, আর কোন NACL আর listener rule quota-র কারণে সেটা লাগে তা জানতে।
• সামনে CloudFront থাকলে edge-এই block করতে (us-east-1-এ WAF, geo restriction), সেখানে NACL কেন “not helpful” তা বোঝাতে, আর CloudFront prefix list, গোপন header বা VPC origin দিয়ে origin-এ তালা দিতে।

#একটা address, পাঁচটা architecture

শিক্ষা বোর্ডের পরীক্ষার result-এর site-এ প্রতি result-এর দিন একই ঝামেলা: 203.0.113.50 থেকে একটা scraper সব result নামিয়ে নেয়, কোচিং সেন্টারের কাছে বেচবে বলে। “ওই IP-টা block করে দাও” শুনতে একটা কাজ। AWS-এ এটা আসলে পাঁচটা আলাদা কাজ, কারণ ঠিক যন্ত্রটা নির্ভর করে client আর server-এর মাঝখানে কী কী দাঁড়িয়ে আছে তার ওপর, আর মাঝের প্রতিটা জিনিস পরের স্তর যে source address দেখবে সেটা বদলে দিতে পারে।

এই লেসনে slide p813–p817-এর পাঁচটা design একটা একটা করে ধরব:

1. Public IP-ওয়ালা একটা EC2 instance।
2. ALB-এর পেছনে EC2 instance।
3. NLB-এর পেছনে EC2 instance।
4. AWS WAF-সহ ALB।
5. CloudFront-এর পেছনে ALB, সাথে WAF।

প্রায় প্রতিটা ইট আগেই শেখা হয়ে গেছে: network ACL আর security group লেসন ৩.৫-এ, ALB-এর source-ip rule, X-Forwarded-For আর NLB-এর client IP preservation লেসন ৬.৩-এ, CloudFront-এর geo restriction আর origin-এ তালা দেওয়া লেসন ১১.২-এ, WAF-এর IP set আর rate-based rule লেসন ২১.৬-এ। এখানে আমরা এগুলো জোড়া লাগাব, আর প্রতিটা ধাপে একটাই প্রশ্ন করব: এই স্তর আসলে কোন IP address দেখছে?

#যন্ত্রগুলো, আর কে কী দেখে

দ্বিতীয় column-টাই আসল কথা। পথের প্রতিটা proxy (ALB, CloudFront) client-এর connection নিজের কাছে শেষ করে, তারপর নিজের address থেকে নতুন একটা খোলে। ওই proxy-র পরের প্রতিটা স্তর দেখে proxy-কে, client-কে না। যে load balancer packet শুধু পার করে দেয় (instance target-ওয়ালা NLB), সে connection শেষ করে না, তাই address টিকে থাকে।

#Network ACL ঝালিয়ে নিই: ক্রম, state আর আকার

লেসন ৩.৫ থেকে চারটা কথা, যার ওপর এই লেসন দাঁড়িয়ে:

• যেটা আগে মেলে সেটাই চূড়ান্ত, ছোট নম্বর আগে। Deny-এর নম্বর হতে হবে সেই প্রতিটা allow-এর চেয়ে ছোট, যাকে তার হারাতে হবে। সবাইকে allow করা 100-এর পেছনে 200 নম্বরের deny কখনো পড়াই হয় না।
• Stateless। একজন client-কে থামাতে inbound block-ই যথেষ্ট, কিন্তু বাকি সবার reply-র জন্য তোমার allow rule-এ outbound ephemeral port (1024–65535) লাগবেই।
• প্রতি subnet-এ একটা NACL। একটা deny শুধু সেই subnet-গুলোকে রক্ষা করে যাদের সাথে ওই NACL জোড়া। ALB বা NLB যে কয়টা AZ ব্যবহার করে তার প্রতিটায় একটা node থাকে, তাই ওই প্রতিটা subnet-এ rule লাগবে।
• ছোট। প্রতি NACL-এ default-এ ২০টা inbound আর ২০টা outbound rule, বাড়িয়ে বড়জোর ৪০টা করে, আর AWS সাবধান করে যে এত বড় হলে network performance কমতে পারে। NACL হাতে গোনা কয়েকটা address বা range-এর যন্ত্র, শত শত address-এর blocklist-এর না।

#Security group: শুধু allow

Security group-এ কোনো Action column নেই। প্রতিটা rule একটা source থেকে একটা protocol আর port allow করে; যা কোনো rule allow করেনি, তা বাদ। Allow-এর তালিকা ছোট করতে পারো (শুধু অফিসের range, শুধু CloudFront prefix list, শুধু ALB-এর security group), কিন্তু “203.0.113.50 ছাড়া সবাই” কখনো লিখতে পারবে না। Public site-কে 443-এ 0.0.0.0/0 allow করতেই হয়, আর তার মধ্যে আক্রমণকারীও পড়ে।

#Design 1: public IP-ওয়ালা একটা EC2 instance

Slide p813: client → NACL → public subnet-এ public IP-ওয়ালা EC2 instance। মাঝখানে কেউ address বদলায় না, তাই প্রতিটা স্তর client-এর আসল IP দেখে, আর তার মধ্যে তিনটা কিছু করতে পারে:

• NACL deny (মূল উত্তর): rule 90 Deny 203.0.113.50/32, rule 100 Allow 0.0.0.0/0 TCP 443। Instance একটা cycle খরচ করার আগেই packet subnet-এর সীমানায় মারা যায়।
• Security group: deny করতে পারে না (ওপরে দেখো)।
• Host firewall (slide-এ optional): operating system-এর ভেতরের firewall software, Linux-এ iptables বা nftables, Windows-এ Windows Defender Firewall। Source address অক্ষত থাকায় এটা কাজ করে, কিন্তু ততক্ষণে packet network পেরিয়ে instance-এ পৌঁছে গেছে, rule প্রতিটা server-এ আলাদা করে থাকে, আর AMI বা user data যোগ না করলে নতুন instance rule ছাড়াই চালু হয় (লেসন ৪.৩)।

#Design 2: Application Load Balancer-এর পেছনে

Slide p814: client → NACL → public subnet-এ ALB → private subnet-এ EC2। ALB একটা layer 7 proxy: সে client-এর TCP আর TLS connection নিজের কাছে শেষ করে, HTTP request পড়ে, তারপর নিজের private IP থেকে target-এর দিকে নতুন একটা connection খোলে (slide-এর “connection termination”)। Client-এর address target-এ পৌঁছায় শুধু X-Forwarded-For header-এর ভেতরে (লেসন ৬.৩)।

Block করার জন্য এর মানে:

তাই ভালো জায়গা দুটো, slide-এর NACL আর ALB নিজে:

• ALB-এর subnet-এর NACL। চুপচাপ (client দেখে timeout), বিনা পয়সায়, আর আগেভাগে: packet ALB পর্যন্ত পৌঁছায়ই না। পরীক্ষার ভাষায়: “নির্দিষ্ট একটা IP address subnet level-এ block করো”, “কোনো বাড়তি খরচ ছাড়া traffic স্পষ্টভাবে deny করো”।
• ALB listener rule। একটা rule, যার condition source-ip = 203.0.113.50/32 (CIDR আকারে), আর action fixed-response, status 403 আর তোমার বাছা body। Client একটা সত্যিকারের উত্তর পায়: “access denied, support-এ যোগাযোগ করুন”। পরীক্ষার ভাষায়: “block করা নির্দিষ্ট একটা IP-কে নিজের মতো error message দেখাও”। সীমা: প্রতি rule-এ পাঁচটা condition value আর default-এ প্রতি ALB-তে ১০০টা rule, আর প্রথম ১০টার পরের rule evaluation ALB-এর capacity unit (LCU) চার্জে যোগ হয়। হাতে গোনা কয়েকটা address, হাজারটা না।

source-ip condition ব্যবহার করে connection-এর address, X-Forwarded-For header না। এখানে এটাই একে বিশ্বাসযোগ্য করে, আর এটাই CloudFront-এর পেছনে একে অকেজো করে দেয় (Design 5)।

#Design 3: Network Load Balancer-এর পেছনে

Slide p815: client → NACL → NLB → EC2। NLB কাজ করে layer 4-এ (TCP, UDP, TLS), খুব কম latency-তে। সে HTTP পড়ে না, তাই:

• Condition-ওয়ালা কোনো listener rule নেই: source-ip rule নেই, fixed response নেই।
• AWS WAF নেই: WAF NLB-এর সাথে associate করা যায় না (লেসন ২১.৬)।
• আগস্ট ২০২৩ থেকে security group: optional, তৈরির সময়েই বাছতে হয় (লেসন ৬.৩), আর অন্য সব security group-এর মতো শুধু allow। এরা NLB-কে চেনা partner-দের allowlist বানাতে পারে; একটা address deny করতে পারে না।

NLB যেটা রাখে, সেটা client-এর address। Instance target-এ target আসল client IP দেখে; TCP বা TLS-এর IP target-এ client IP preservation default-এ বন্ধ, তাই preservation চালু না করলে বা Proxy Protocol v2 ব্যবহার না করলে target দেখে NLB-এর private IP। PrivateLink দিয়ে আসা traffic-এ সবসময় NLB-এর address দেখা যায়।

তাই:

• NLB-এর subnet-এ NACL deny পরীক্ষার উত্তর: “NLB-এর জন্য একটা IP block করো”, “high-performance TCP traffic-এর জন্য IP block করো”, “layer 4 IP blocking”। Address অক্ষত থাকায় target-এর subnet-এর NACL-এ deny দিলেও মিলত, তবে NLB-এর subnet আগেই থামিয়ে দেয়।
• Target-এ host firewall কাজ করে যখন address অক্ষত থাকে (instance target), আর যখন থাকে না তখন কিছুই করে না।
• AWS Network Firewall, VPC-র ভেতরে একটা managed stateful firewall, এটাও address-টা ফেলে দিতে পারে; এটা লেসন ২২.৭-এর বিষয়।

#Design 4: ALB + WAF

Slide p816 ALB-এর সাথে “IP address filtering”-এর জন্য AWS WAF যোগ করে। তুমি খারাপ address-গুলোর একটা IP set বানাও, web ACL-এর একটা rule থেকে Block action দিয়ে সেটার দিকে ইঙ্গিত করো, আর web ACL-টা ALB-এর সাথে associate করো (একই Region-এ)। ALB route করার আগে প্রতিটা request WAF-এর হাতে দেয়; তালিকার address পায় 403 Forbidden (বা নিজের মতো response), target-এ কখনো পৌঁছায় না। ALB-এর WAF client-এর আসল address দেখে, কারণ ALB যে connection পেয়েছে সেটাই সে পড়ে।

Web application-এর জন্য এটাই কেন আধুনিক default:

Web ACL-এর rule চলে priority ক্রমে (ছোটটা আগে), আর একটা Block যাচাই থামিয়ে দেয়: সাধারণ ক্রম হলো IP set, তারপর rate-based rule, তারপর managed rule group। Web ACL, rule action, managed group আর rate-based rule-এর খুঁটিনাটি লেসন ২১.৬-এ; এই লেসনের শুধু এটুকু দরকার যে IP set বড় হতে পারে, আর একই web ACL এমন সুরক্ষা যোগ করে যা NACL দিতে পারে না।

#Design 5: ALB, CloudFront আর WAF

Slide p817 ALB-এর সামনে CloudFront বসায়। এখন প্রতিটা request আগে edge location-এ যায়। Cache-এ না পেলে CloudFront তার একটা origin-facing public IP থেকে ALB-এর দিকে নিজের connection খোলে। এতে Region-এর ভেতরের সবকিছু বদলে যায়:

• ALB-এর subnet-এর NACL দেখে CloudFront-এর address। 203.0.113.50-এর deny কখনো মেলে না, আর একটা CloudFront address deny করলে হাজার হাজার আসল user আটকে যাবে। Slide NACL-কে বলেছে “NOT helpful”।
• ALB-এর source-ip listener rule-ও একইভাবে ব্যর্থ: connection আসে CloudFront থেকে।
• ALB-এর WAF web ACL-ও default-এ CloudFront-এর address মেলায়। একে বলে দেওয়া যায় client IP পড়তে X-Forwarded-For header থেকে (IP set rule-এর forwarded IP configuration), কিন্তু ততক্ষণে request edge আর Region পেরিয়ে এসেছে, আর header-টা বিশ্বাসযোগ্য শুধু তখনই যখন তোমার distribution ছাড়া কেউ ALB-এ পৌঁছাতে পারে না।

Client-এর address দেখা যায় শুধু edge-এ, তাই block-ও করতে হবে সেখানেই:

• CloudFront-এ AWS WAF: global (CloudFront) scope-এর একটা web ACL, তার IP set-সহ us-east-1-এ তৈরি, distribution-এর সাথে associate করা। তালিকার address edge location থেকেই 403 পায়; VPC-তে কিছুই পৌঁছায় না, তাতে চাপ আর খরচ দুটোই বাঁচে, আর আক্রমণের traffic origin থেকে অনেক দূরে থাকে। Notes-এর best practice এটাই: WAF লাগাও CloudFront-এ, ALB-এ না।
• CloudFront geo restriction: দেশের একটা allow list বা block list, বিনা পয়সায়, ভেতরেই তৈরি, edge-এ 403 দিয়ে উত্তর দেয় (লেসন ১১.২)। একটা address-কে আলাদা করে ধরতে পারে না; তার জন্য, বা শুধু /admin-এ একটা দেশের জন্য, WAF ব্যবহার করো।
• একটা CloudFront Function-ও viewer-এর address পড়ে তাকে ফিরিয়ে দিতে পারে (লেসন ১১.৩), তবে পরীক্ষা যে managed উত্তর চায় সেটা WAF।

#খিড়কি বন্ধ করা: origin-এ তালা

আক্রমণকারী যদি edge-কে পাশ কাটাতে পারে, তাহলে edge-এ block করার কোনো দাম নেই। Public ALB-এর একটা public DNS নাম আছে, আর block হওয়া scraper সেটাই চেষ্টা করবে। দুটো স্তর দরজাটা বন্ধ করে (লেসন ১১.২ এগুলো ধাপে ধাপে বানায়):

1. ALB-এর security group শুধু CloudFront-কে allow করে: port 443-এ একটা inbound rule, যেটা AWS managed prefix list com.amazonaws.global.cloudfront.origin-facing-এর দিকে ইঙ্গিত করে। অন্য যেকোনো address থেকে সরাসরি connection বাদ পড়ে। এখানে শুধু-allow security group-ই একদম ঠিক যন্ত্র, কারণ তুমি একটা চেনা তালিকা allow করছ, একটা address deny করছ না। Security group-এর quota-য় এই prefix list ৫৫টা rule হিসেবে গোনা হয়।
2. একটা গোপন custom header: তোমার distribution X-Origin-Verify: <লম্বা random value>-এর মতো একটা origin header জুড়ে দেয়; ALB-এর listener rule শুধু সেই value-ওয়ালা request forward করে, আর default rule 403 ফেরত দেয়। এটা সেই আক্রমণকারীকে থামায় যে তোমার ALB-এর দিকে নিজের একটা CloudFront distribution বানায়: তার request-ও আসে CloudFront-এর address থেকে আর prefix list পেরিয়ে যায়, কিন্তু তাতে তোমার গোপন value থাকে না। মাঝে মাঝে value বদলাও, আর log আর code repository থেকে দূরে রাখো।

#আসল client IP কে দেখে?

এভাবে পড়ো: যে প্রথম ধাপ client-কে দেখে সেখানেই block করো, যত আগে সম্ভব, এমন যন্ত্র দিয়ে যেটা তালিকার আকার সামলাতে পারে।

এবার নিজে চেষ্টা করো। একটা design আর একটা control বাছো, আর দেখো block কাজ করে, নাকি এমন কিছু থাকতেই পারে না, নাকি চুপচাপ কিছুই করে না।

#কোথায় ভুল হয়

• NACL-এ deny আছে, তবুও আক্রমণকারী ঢুকছে: deny-এর নম্বর এমন একটা allow-এর চেয়ে বড়, যেটা আগে মিলে যায়। Allow-এর নিচের নম্বরে সরাও (100-এর আগে 90)।
• NACL বদলানোর পর সবার timeout: NACL stateless, আর outbound ephemeral port (1024–65535)-এর rule মুছে ফেলা হয়েছে বা কখনো যোগই হয়নি।
• Block মাঝে মাঝে কাজ করে: ALB বা NLB কয়েকটা subnet জুড়ে, যাদের NACL আলাদা, আর deny পেয়েছে শুধু একটা। Load balancer-এর সব subnet-এ একটা NACL ব্যবহার করো, বা প্রতিটায় rule যোগ করো।
• Application server-এর subnet-এ deny কিছুই করে না: server-গুলো ALB-এর পেছনে, তারা দেখে তার private IP। Block করো ALB-এর subnet-এ, ALB-এ, বা WAF-এ।
• Security group-এ “deny” খোঁজা: এমন কিছু নেই। NACL, listener rule বা WAF ব্যবহার করো।
• NACL-এর rule ফুরিয়ে গেছে: default-এ ২০টা, বড়জোর ৪০টা। তালিকাটা WAF IP set-এ সরাও।
• NLB-এ “Associate web ACL” খোঁজা: WAF NLB সমর্থন করে না। NACL ব্যবহার করো, বা traffic HTTP হলে সামনে ALB বা CloudFront বসাও।
• NLB target-এর host firewall কিছুই মেলায় না: client IP preservation ছাড়া IP target NLB-এর address দেখে। Preservation চালু করো বা Proxy Protocol v2 পড়ো।
• Application X-Forwarded-For দিয়ে block করে, আর একটা bot পাশ কাটিয়ে চলে যায়: code সবচেয়ে বাঁয়ের entry বিশ্বাস করে, যেটা client জাল করতে পারে। তোমার নিজের proxy-র সবচেয়ে ডানের entry বিশ্বাস করো।
• CloudFront-এর পেছনে NACL বা ALB rule কিছুই করে না: তারা দেখে CloudFront-এর address। CloudFront-এর web ACL-এ block করো।
• Associate করার সময় CloudFront-এর web ACL খুঁজে পাওয়া যায় না: সেটা ALB-এর Region-এ বানানো হয়েছে; CloudFront-এর web ACL আর তার IP set থাকে us-east-1-এ (global scope)।
• CloudFront-এ WAF আছে, তবুও scraper ডেটা পাচ্ছে: ALB internet-এর জন্য খোলা। তার security group CloudFront prefix list-এ সীমিত করো, গোপন header বাধ্যতামূলক করো, বা VPC origin-এ সরে যাও।
• IPv4-এর block কাজ করে, আক্রমণকারী IPv6 দিয়ে ফিরে আসে: dual-stack site-এ IPv6 address-টাও একটা IPv6 IP set-এ লাগবে (একটা IP set একটাই address version রাখে), বা NACL-এ একটা IPv6 rule।

#System design-এ IP block করা

একটা address block করা প্রায় কখনোই পুরো design না। যে pattern-গুলো বারবার ফিরে আসে:

• যে সবচেয়ে বাইরের স্তর client-কে দেখে সেখানে block করো: CloudFront-ওয়ালা site-এ edge, regional site-এ load balancer বা তার subnet। প্রতিটা পরের ধাপে খরচ বাড়ে, দেখা কমে।
• তালিকার মাপে যন্ত্র বাছো: কয়েকটা address-এর জন্য বিনা পয়সার NACL, client-কে message দিতে হলে ALB rule, লম্বা বা বদলাতে থাকা তালিকার জন্য WAF IP set। আক্রমণকারী যদি কোনো provider-এর block-এর ভেতরে address বদলায়, একক address-এর বদলে CIDR range দাও।
• শুধু IP তালিকা যথেষ্ট না: আক্রমণকারী address বদলায়। IP set-এর সাথে জোড়ো rate-based rule, IP reputation আর anonymous IP managed rule group, আর managed SQL injection আর XSS rule (লেসন ২১.৬)।
• তালিকা স্বয়ংক্রিয় করো: detection service তালিকা ভরতে পারে। চেনা pattern: একটা GuardDuty finding (লেসন ২১.৭) বা WAF log-এর ওপর একটা CloudWatch alarm, একটা EventBridge rule সেটা ধরে (লেসন ১৯.৫), আর একটা Lambda function চালায় যে address-টা WAF IP set-এ (বা NACL entry-তে) যোগ করে, আর এক দিন পর সরিয়ে দেয়।
• অনেক account: Firewall Manager একই WAF rule, security group policy আর network ACL baseline একটা Organization-এর প্রতিটা account-এ চাপিয়ে দেয় (লেসন ২১.৬)।
• VPC-র ভেতরের non-HTTP traffic, যার NACL-এর চেয়ে বেশি কিছু লাগে (stateful rule, domain তালিকা, intrusion prevention): AWS Network Firewall, লেসন ২২.৭।
• প্রতিটা origin-এ তালা দাও: public ALB-এর জন্য prefix list + গোপন header, S3-এর জন্য OAC, private-এর জন্য VPC origin। Origin খোলা রেখে edge-এ block করা মানে চারপাশে দেয়াল ছাড়া একটা দরজা।

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

এই command-গুলো AWS CLI v2-এর, বানানো ID দিয়ে। NACL আর security group বদলাতে কোনো খরচ নেই; WAF-এর web ACL, rule আর পরীক্ষা করা request-এ টাকা লাগে, তাই যা বানাবে মুছে ফেলো।

# Design 1-3: allow-এর আগের নম্বরে NACL deny (load balancer-এর প্রতিটা subnet-এর NACL-এ আবার করো)
aws ec2 describe-network-acls --network-acl-ids acl-0a1b2c3d4e5f67890 \
  --query 'NetworkAcls[0].Entries[?Egress==`false`].[RuleNumber,CidrBlock,RuleAction,PortRange.From]' --output text
# 100     0.0.0.0/0          allow   443
# 32767   0.0.0.0/0          deny    None
aws ec2 create-network-acl-entry --network-acl-id acl-0a1b2c3d4e5f67890 \
  --ingress --rule-number 90 --protocol -1 --cidr-block 203.0.113.50/32 --rule-action deny

# Block করা address থেকে: চুপচাপ ফেলে দেওয়া দেখতে timeout-এর মতো
curl -m 5 -s -o /dev/null -w "%{http_code}\n" https://portal.example.com/
# 000   (৫ সেকেন্ড পর curl হাল ছেড়ে দিল: কোনো উত্তরই নেই)

# Security group-এ deny নেই: এখানে --rule-action বলে কিছুই নেই
aws ec2 authorize-security-group-ingress --group-id sg-0123456789abcdef0 \
  --ip-permissions 'IpProtocol=tcp,FromPort=443,ToPort=443,IpRanges=[{CidrIp=0.0.0.0/0}]'
# শুধু allow rule আছে। "Block" করতে হলে 0.0.0.0/0 সরিয়ে ছোট একটা তালিকা allow করা ছাড়া উপায় নেই।

# Design 2: একটা address-এর জন্য নিজের মতো 403-ওয়ালা ALB listener rule
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:ap-south-1:111122223333:listener/app/portal-alb/50dc6c495c0c9188/f2f7dc8efc522ab2 \
  --priority 1 \
  --conditions Field=source-ip,SourceIpConfig='{Values=["203.0.113.50/32"]}' \
  --actions Type=fixed-response,FixedResponseConfig='{StatusCode=403,ContentType=text/plain,MessageBody="Automated access is not allowed. Contact admission@example.com"}'

curl -s -w "\n%{http_code}\n" https://portal.example.com/seats   # 203.0.113.50 থেকে
# Automated access is not allowed. Contact admission@example.com
# 403

# Design 3: IP target-ওয়ালা NLB target group - client IP কি অক্ষত থাকছে?
aws elbv2 describe-target-group-attributes \
  --target-group-arn arn:aws:elasticloadbalancing:ap-south-1:111122223333:targetgroup/erp-ip-tg/73e2d6bc24d8a067 \
  --query 'Attributes[?Key==`preserve_client_ip.enabled` || Key==`proxy_protocol_v2.enabled`]' --output text
# preserve_client_ip.enabled   false
# proxy_protocol_v2.enabled    false

# Design 4: ALB-এর জন্য regional IP set, পরে rule না ছুঁয়েই আরও address যোগ
aws wafv2 create-ip-set --name scrapers --scope REGIONAL --region ap-south-1 \
  --ip-address-version IPV4 --addresses 203.0.113.50/32 198.51.100.128/25
# { "Summary": { "Name": "scrapers", "Id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "LockToken": "0f1e2d3c-EXAMPLE", ... } }
aws wafv2 get-ip-set --name scrapers --scope REGIONAL --region ap-south-1 \
  --id a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 --query LockToken --output text
# 0f1e2d3c-EXAMPLE
aws wafv2 update-ip-set --name scrapers --scope REGIONAL --region ap-south-1 \
  --id a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 --lock-token 0f1e2d3c-EXAMPLE \
  --addresses 203.0.113.50/32 198.51.100.128/25 192.0.2.77/32
# update-ip-set পুরো তালিকা বদলে দেয়: যা রাখতে চাও, প্রতিবার সব address পাঠাও।

# Design 5: CloudFront-এর web ACL থাকে us-east-1-এ, scope CLOUDFRONT
aws wafv2 create-ip-set --name scrapers-edge --scope CLOUDFRONT --region us-east-1 \
  --ip-address-version IPV4 --addresses 203.0.113.50/32
aws wafv2 create-web-acl --name results-edge --scope CLOUDFRONT --region us-east-1 \
  --default-action Allow={} --rules file://edge-rules.json \
  --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=results-edge
# Distribution config-এ WebACLId (web ACL-এর ARN) বসিয়ে web ACL লাগানো হয় (update-distribution)।

# ALB-এ তালা: CloudFront-এর origin-facing prefix list খুঁজে 443-এ শুধু সেটাই allow
aws ec2 describe-managed-prefix-lists \
  --filters Name=prefix-list-name,Values=com.amazonaws.global.cloudfront.origin-facing \
  --query 'PrefixLists[].[PrefixListId,PrefixListName,MaxEntries]' --output text
# pl-3b927c52   com.amazonaws.global.cloudfront.origin-facing   55
aws ec2 revoke-security-group-ingress --group-id sg-0alb1234567890abc \
  --ip-permissions 'IpProtocol=tcp,FromPort=443,ToPort=443,IpRanges=[{CidrIp=0.0.0.0/0}]'
aws ec2 authorize-security-group-ingress --group-id sg-0alb1234567890abc \
  --ip-permissions 'IpProtocol=tcp,FromPort=443,ToPort=443,PrefixListIds=[{PrefixListId=pl-3b927c52}]'

# গোপন header: মিললে তবেই forward, default action 403
aws elbv2 create-rule --listener-arn arn:aws:elasticloadbalancing:ap-south-1:111122223333:listener/app/results-alb/6d0ecf831eec9f09/0f1a2b3c4d5e6f70 \
  --priority 1 \
  --conditions 'Field=http-header,HttpHeaderConfig={HttpHeaderName=X-Origin-Verify,Values=[EXAMPLE-long-random-value]}' \
  --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:ap-south-1:111122223333:targetgroup/results-tg/943f017f100becff
aws elbv2 modify-listener --listener-arn arn:aws:elasticloadbalancing:ap-south-1:111122223333:listener/app/results-alb/6d0ecf831eec9f09/0f1a2b3c4d5e6f70 \
  --default-actions Type=fixed-response,FixedResponseConfig='{StatusCode=403,ContentType=text/plain,MessageBody=Forbidden}'

# পরীক্ষা: scraper থেকে CloudFront দিয়ে, তারপর সরাসরি ALB-এ
curl -s -o /dev/null -w "%{http_code}\n" https://results.example.com/result?roll=482913   # 203.0.113.50 থেকে
# 403   (web ACL edge-এই block করল)
curl -m 5 -s -o /dev/null -w "%{http_code}\n" https://results-alb-1234567890.ap-south-1.elb.amazonaws.com/
# 000   (security group ফেলে দিল: CloudFront-এর address না)

edge-rules.json-এ একটাই rule, যার IPSetReferenceStatement scrapers-edge-এর ARN-এর দিকে ইঙ্গিত করে আর "Action": { "Block": {} }, লেসন ২১.৬-এর মতো। শেষে delete-network-acl-entry, delete-rule, delete-web-acl আর delete-ip-set দিয়ে পরিষ্কার করো।

#সারসংক্ষেপ

মূল কথা

• Block করো যে প্রথম ধাপ client-এর address দেখে সেখানে। Proxy (ALB, CloudFront) connection শেষ করে আর তার পেছনের প্রতিটা স্তর থেকে client-কে আড়াল করে; NLB (instance target) address পার করে দেয়।
• Security group শুধু allow করে: “একটা IP deny করো”-র উত্তর কখনোই না। Allowlist-এ মানায় (চেনা partner, CloudFront prefix list)।
• NACL: allow আর deny, ছোট নম্বর আগে (deny allow-এর আগে), stateless (outbound ephemeral port), load balancer-এর প্রতিটা subnet-এ, প্রতি দিকে ২০টা rule (সর্বোচ্চ ৪০), বিনা পয়সায়। পরীক্ষা: “subnet level”, “কোনো বাড়তি খরচ ছাড়া”, “NLB”, “layer 4”।
• Public IP-ওয়ালা EC2 (p813): NACL deny; optional host firewall (কাজ করে, তবে প্রতি instance-এ আলাদা আর packet পৌঁছানোর পরে)।
• ALB (p814): ALB-এর subnet-এ NACL, বা নিজের মতো message-এর জন্য source-ip listener rule → fixed-response 403 (প্রতি rule-এ ৫টা value)। Target দেখে ALB-এর private IP; client থাকে X-Forwarded-For-এ (সবচেয়ে ডানের entry বিশ্বাস করো)।
• NLB (p815): পরীক্ষার উত্তর NACL; WAF নেই, listener rule নেই; security group (২০২৩ থেকে) তবুও শুধু allow; instance target-এ client IP অক্ষত (IP target-এ preservation বা Proxy Protocol v2 লাগে)।
• ALB + WAF (p816): Block action-ওয়ালা web ACL rule-এ IP set (১০,০০০ entry); সাথে managed SQLi/XSS rule আর rate-based rule। পরীক্ষা: “IP block আর SQL injection/XSS”, “অতিরিক্ত request”।
• CloudFront + ALB + WAF (p817): NACL আর ALB rule দেখে CloudFront-এর IP (“not helpful”)। Block করো CloudFront-এ WAF (তৈরি us-east-1-এ) বা geo restriction (দেশ) দিয়ে। Origin-এ তালা: ALB-এর SG শুধু com.amazonaws.global.cloudfront.origin-facing allow করে, সাথে listener rule-এ যাচাই করা গোপন header; অথবা internal ALB-সহ VPC origin (২০২৪)।

নিজেকে যাচাই করো: একটা IP address block করা৩০টি প্রশ্ন