Traffic Mirroring, IPv6 আর Network Firewall

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

• VPC Traffic Mirroring-এর চারটা অংশ (source ENI, target, filter, session) দিয়ে mirroring সাজাতে, UDP 4789-এ VXLAN-এ মোড়া কপির ব্যাপারটা বুঝিয়ে বলতে, আর এর সীমাগুলো জানতে: source হতে হবে Nitro-ভিত্তিক instance, এক ENI-তে সর্বোচ্চ তিনটা session, চাপ বাড়লে কপি পড়ে যায়, security group যে inbound packet ফেলে দেয় সেটা কখনো mirror হয় না।
• প্রশ্নে “deep packet inspection”, “IDS” বা “IPS” দেখলে VPC Flow Logs, Traffic Mirroring আর AWS Network Firewall আলাদা করে চিনতে।
• IPv6 address পড়তে, লিখতে আর ছোট করতে, আর বুঝিয়ে বলতে কেন AWS যে IPv6 address VPC-কে দেয় সেগুলো public আর সারা পৃথিবীতে অনন্য, আর ২০২৪-এ private IPv6 নিয়ে কী বদলাল।
• একটা dual-stack VPC চালাতে: /56 আর /64-এর default, IPAM দিয়ে কোন কোন size নেওয়া যায়, IPv4 কেন কখনো বন্ধ করা যায় না, আর “instance launch হচ্ছে না” ফাঁদটা।
• Egress-only internet gateway দিয়ে private IPv6 instance-কে শুধু বাইরে যাওয়ার internet দিতে, আর পরিচিত ভুলগুলো (::/0 থেকে NAT gateway, private subnet-এ ::/0 থেকে internet gateway) এড়িয়ে IPv6 route table সাজাতে।
• AWS Network Firewall দিয়ে পুরো একটা VPC রক্ষা করতে: stateless আর stateful rule group, domain list, Suricata-compatible IPS rule, firewall subnet আর endpoint, ingress routing, Transit Gateway দিয়ে এক জায়গায় পরীক্ষা, log আর দাম।

#VPC-র জন্য শেষ তিনটা হাতিয়ার

আগের লেসনগুলোতে আমরা VPC-কে অন্য VPC আর data centre-এর সাথে জুড়েছি। এই লেসন অধ্যায়টা শেষ করবে এমন তিনটা জিনিস দিয়ে, যেগুলো VPC-র ভেতরেই থাকে আর পরীক্ষায় অনেক প্রশ্নে আসে:

• আসল packet দেখা। Flow log (লেসন ২২.৩) বলে কে কার সাথে কথা বলল আর সেটা accept হলো কিনা। কিন্তু হামলা খুঁজতে নামা security দলের দরকার packet-এর ভেতরের payload। এর জন্য VPC Traffic Mirroring।
• IPv6। IPv4 address অনেক বছর আগেই ফুরিয়ে গেছে, আর AWS-এ এখন এর জন্য টাকাও দিতে হয় (লেসন ৩.৬)। বাংলাদেশে আর বাইরে mobile network phone-কে IPv6 address দিচ্ছে। একটা VPC IPv4 আর IPv6 পাশাপাশি চালাতে পারে, আর private IPv6 server-এর জন্য তার দরকার আরেক রকম “একমুখী দরজা”: egress-only internet gateway।
• পুরো VPC-তে firewall। Security group আর network ACL (লেসন ৩.৫) শুধু address আর port দেখে। একটা domain নাম ধরে আটকানো, বা packet-এর ভেতরে লুকানো exploit থামানোর জন্য লাগে AWS Network Firewall।

#VPC Traffic Mirroring

VPC Traffic Mirroring একটা EC2 instance-এর elastic network interface (ENI) দিয়ে যত packet যায়-আসে, হুবহু সেগুলোর কপি করে তোমার চালানো কোনো security বা monitoring appliance-এ পাঠিয়ে দেয়। Instance বা তার application টেরই পায় না।

#Flow log দেখে খাম, mirroring দেখে চিঠি

Flow log হলো courier company-র খাতার মতো: কে পাঠাল, কে পেল, ওজন কত, পৌঁছেছে নাকি ফেরত এসেছে। Traffic Mirroring পৌঁছে দেওয়ার আগে প্রতিটা চিঠির একটা photocopy করে রাখে। চিঠির ভেতরে জাল cheque ছিল কিনা, খাতা দেখে বোঝা যায় না; photocopy দেখে যায়।

#চারটা অংশ

1. Source

   যে ENI-র traffic কপি করতে চাও, সাধারণত একটা EC2 instance-এর প্রধান interface। Source হতে হবে Nitro-ভিত্তিক instance type-এ (সাথে C4, M4, R4, I3-এর মতো পুরোনো কয়েকটা non-Nitro family-র ছোট একটা তালিকা)। একটা ENI সর্বোচ্চ তিনটা session-এর source হতে পারে।

2. Target

   কপি কোথায় যাবে: আরেকটা ENI (একটা appliance instance), UDP port 4789-এ listener-ওয়ালা একটা Network Load Balancer, অথবা একটা Gateway Load Balancer endpoint (অন্য VPC-তে, প্রায়ই একটা security account-এ রাখা appliance; লেসন ৬.৩)। High availability-র জন্য AWS NLB বা GWLB endpoint-ই সুপারিশ করে। Target peering বা Transit Gateway দিয়ে জোড়া অন্য VPC-তে থাকতে পারে, অন্য account-এও।

3. Filter

   কোন packet কপি হবে: accept বা reject-ওয়ালা inbound আর outbound rule, যেগুলো protocol, source আর destination CIDR, আর port range মেলায় (এক filter-এ সর্বোচ্চ ১০টা rule)। যেমন: শুধু TCP 80 আর 443 কপি করো, বা শুধু database subnet-এ যাওয়া traffic। কোনো accept rule না মিললে কিছুই কপি হয় না। Filter আসল traffic-এর ভাগ্যে কিছুই বদলায় না।

4. Session

   Source, target আর filter-কে এক সুতোয় বাঁধে, সাথে থাকে একটা priority (এক source-এ কয়েকটা session থাকলে), ঐচ্ছিক packet length (প্রতিটা packet-এর প্রথম কয়েক byte কপি করো, যেমন শুধু header) আর একটা VXLAN network identifier, মানে VNI, যাতে tool আলাদা আলাদা session চিনতে পারে।

#কপিটা কীভাবে যায়

কপি বানায় ENI চালানো Nitro card, operating system না: কোনো agent বসাতে হয় না, আর application-এর CPU বা memory বাড়তি কোনো কাজ করে না। প্রতিটা কপি VXLAN-এ (UDP port 4789) মুড়ে অন্য যেকোনো packet-এর মতোই VPC-র route ধরে target-এ পাঠানো হয়, তাই:

• target-এর security group-কে source থেকে UDP 4789 খোলা রাখতে হবে, আর VPC-র route table থেকে target-এ পৌঁছানোর পথ থাকতে হবে;
• monitoring software-কে VXLAN বুঝতে হবে (Suricata, Zeek, Wireshark আর বেশিরভাগ বাণিজ্যিক tool বোঝে);
• কপিটা out of band: কেউ এর জন্য অপেক্ষা করে না, তাই monitoring tool alert দিতে পারে, কিন্তু কখনো block করতে পারে না।

#যে সীমাগুলো জানা দরকার

• Instance-এর জন্য এটা একেবারে ফ্রি না। Mirror করা packet source instance-এর network bandwidth-এর হিসেবেই পড়ে: ১ Gbps ঢোকা আর ১ Gbps বেরোনো mirror করলে তার network card দিয়ে যায় ৪ Gbps। Instance তার bandwidth বা প্রতি সেকেন্ডে packet-এর সীমায় পৌঁছালে AWS আগে mirror করা packet ফেলে দেয়, যাতে আসল traffic অগ্রাধিকার পায়। Notes-এ বলা “performance-এ কোনো প্রভাব নেই” কথাটা CPU আর latency-র বেলায় ঠিক; তবে কপির কথা মাথায় রেখে instance-এর size ঠিক করো।
• আটকে যাওয়া inbound traffic mirror হয় না। Source-এর inbound security group বা network ACL যে packet ফিরিয়ে দেয়, তার কোনো কপি হয় না। অন্যদিকে outbound কপির ওপর outbound security group rule খাটে না।
• সবকিছু কপি হয় না। ARP, DHCP, instance metadata service, NTP আর Windows activation-এর traffic কখনো mirror হয় না, আর flow log mirror করা কপিগুলো নিজে লিখে রাখে না।
• বড় packet কেটে যায়, যখন target একটা মাত্র instance আর কপির সাথে VXLAN-এর ৫৪ byte (IPv6-এ ৭৪ byte) মিলে target-এর MTU ছাড়িয়ে যায়। IPv6-only subnet-এ এটা চলে না।
• খরচ: active session-ওয়ালা প্রতিটা source ENI-র জন্য ঘণ্টায় একটা চার্জ (us-east-1-এ প্রায় ০.০১৫ USD), সাথে কপিগুলোর সাধারণ data transfer, যেমন target অন্য AZ-এ থাকলে cross-AZ।
• Encryption: আজকাল বেশিরভাগ traffic TLS। IDS-এর হাতে server-এর key দিতে হয়, অথবা VPC-র ভেতরে যেখানে traffic এখনো খোলা (load balancer TLS খোলার পরে) সেখান থেকে mirror করতে হয়, নইলে শুধু header আর TLS-এর metadata নিয়েই সন্তুষ্ট থাকতে হয়।

#Flow log, mirroring নাকি Network Firewall?

Notes-এ “deep packet inspection” keyword Traffic Mirroring-এর জন্য দেওয়া আছে, পরে আবার Network Firewall-এর জন্যও। দুটোই ঠিক, কারণ দুজন আলাদা জায়গায় পরীক্ষা করে:

প্রশ্নের ক্রিয়াপদটা পড়ো: monitor, analyse, detect, capture থাকলে mirroring; block, prevent, filter, allow only থাকলে Network Firewall।

#এক পাতায় IPv6

#কেন IPv6

IPv4 address ৩২ bit লম্বা: মোটামুটি ৪৩০ কোটি, আর আঞ্চলিক registry-গুলো শেষ খালি block বিলিয়ে দিয়েছে বহু বছর আগে। IPv6 address ১২৮ bit, মোটামুটি ৩.৪ × ১০^৩৮ টা address, notes যেমন বলছে, পৃথিবীর প্রতিটা বালুকণাকে বহুবার করে একটা দেওয়া যায়।

#Address কীভাবে লেখে

IPv6 address লেখা হয় চার hexadecimal অঙ্কের আটটা group দিয়ে, মাঝে colon, প্রতিটা group ১৬ bit (0000 থেকে ffff):

2001:0db8:85a3:0000:0000:8a2e:0370:7334

দুটো নিয়মে এটা ছোট হয়:

১. প্রতিটা group-এর শুরুর শূন্য বাদ দেওয়া যায়: 0db8 → db8, 0370 → 370, 0000 → 0।

২. পরপর যতগুলো group পুরো শূন্য, তার একটা টানা অংশকে :: দিয়ে বদলানো যায়, পুরো address-এ একবারই (নইলে কোন :: কয়টা group লুকিয়ে রেখেছে বোঝা যেত না)।

তাহলে উদাহরণটা দাঁড়ায় 2001:db8:85a3::8a2e:370:7334। আরও কয়েকটা:

2001:db8::/32 documentation-এর জন্য সংরক্ষিত, তাই এই course-এর বানানো সব address এখান থেকেই। Prefix কাজ করে IPv4 CIDR-এর মতোই (লেসন ৩.১): একটা /56 প্রথম ৫৬ bit বেঁধে দেয়, network-এর জন্য বাকি থাকে ৭২ bit।

#AWS-এ IPv6 কেন “public”

IPv4-এর আছে RFC 1918-এর private range (10.x, 172.16.x, 192.168.x), আর public address ভাগ করে নেওয়ার জন্য NAT। IPv6-এর নকশাই এমন যে প্রতিটা device একটা সারা পৃথিবীতে অনন্য address পাবে, NAT লাগবে না। Amazon VPC-কে যে IPv6 block দেয়, সেগুলো সাধারণ global unicast address (GUA), internet-এ advertise করা: Amazon-এর দেওয়া প্রতিটা IPv6 address public আর internet থেকে route হয়। তাই IPv6 instance রক্ষা করা মানে routing আর filtering-এর প্রশ্ন, NAT-এর পেছনে লুকানোর না।

এই block-গুলো Amazon নিজের pool থেকে বরাদ্দ করে, তাই এগুলো অন্য কোনো VPC বা তোমার data centre-এর সাথে কখনো overlap করে না: “এমন একটা সারা পৃথিবীতে অনন্য address দরকার যেটা কখনো অন্য network-এর সাথে overlap করবে না” প্রশ্নের উত্তর IPv6।

#VPC-তে IPv6: dual stack

একটা VPC dual stack-এ চলতে পারে: একই VPC আর একই subnet-এ IPv4 আর IPv6 একসাথে। VPC-র সাথে একটা IPv6 block associate করো, প্রতিটা subnet-কে তার একটা টুকরো দাও, ব্যস, instance তার private IPv4-এর পাশে একটা IPv6 address-ও পায়।

#Size

একটা /56-এ /64-এর ২৫৬টা subnet ধরে, আর প্রতিটা /64-এ 2^64, মানে প্রায় ১৮ কুইন্টিলিয়ন address। IPv4-এর মতোই AWS প্রতিটা IPv6 subnet-এ পাঁচটা address রেখে দেয় (লেসন ৩.২)। Notes-এর “/56, বদলানো যায় না” আর “প্রতিটা subnet /64 হতেই হবে” কথাগুলো Amazon-এর দেওয়া default-এর কথা, পরীক্ষাও সেটাই বোঝায়।

#IPv4 বন্ধ করা যায় না

• প্রতিটা VPC-র একটা IPv4 CIDR থাকতেই হবে; IPv6 তার সাথে বাড়তি। শুধু IPv6-ওয়ালা VPC বানানো যায় না।
• Dual-stack subnet-এ প্রতিটা instance তবুও একটা private IPv4 address পায়। তারপর instance একই internet gateway দিয়ে যেকোনো protocol-এ internet-এর সাথে কথা বলতে পারে, gateway দুটোই সামলায়।

এখান থেকেই আসে পরীক্ষার troubleshooting প্রশ্নটা (slide p765): dual-stack subnet-এ instance launch করা যাচ্ছে না। কারণটা কখনোই IPv6 ফুরিয়ে যাওয়া না; একটা /64 কার্যত অফুরন্ত। কারণ হলো subnet-এ কোনো খালি IPv4 address নেই। সমাধান আরও IPv4 জায়গা: VPC-তে একটা secondary IPv4 CIDR যোগ করো আর সেখান থেকে নতুন একটা subnet বানাও (একটা subnet-এর নিজের IPv4 range বড় করা যায় না)।

#Egress-only internet gateway

IPv4-এ একটা private server internet-এ যায় NAT gateway দিয়ে (লেসন ৩.৪): তার শুধু private address আছে, NAT gateway সেটা অনুবাদ করে, তাই বাইরের কেউ তার সাথে connection শুরু করতে পারে না। IPv6-এ server-এর address আগে থেকেই public, আর NAT নেই। তাহলে তাকে উন্মুক্ত না করে patch নামাতে দেবে কীভাবে?

উত্তর egress-only internet gateway (EIGW):

• এটা কাজ করে শুধু IPv6-এর জন্য।
• এটা instance-কে IPv6-এ internet-এর দিকে connection শুরু করতে দেয়, আর তার reply ভেতরে ঢুকতে দেয়: এটা stateful, বেরিয়ে যাওয়া connection-গুলো মনে রাখে।
• Internet থেকে কেউ connection শুরু করতে চাইলে সেটা ফেলে দেয়।
• এটা কিছুই অনুবাদ করে না: packet instance-এর নিজের IPv6 address নিয়েই যায়।
• VPC-র সাথে attach হয় আর ব্যবহার হয় একটা route দিয়ে: private subnet-এর route table-এ ::/0 → eigw-…।
• এর ঘণ্টার কোনো ভাড়া নেই; দিতে হয় শুধু সাধারণ data transfer। এর কোনো security group নেই; instance-এর security group আর subnet-এর network ACL তবুও খাটে।

#IPv6 routing

IPv6 routing চলে IPv4 routing-এর মতোই (লেসন ৩.৩), শুধু IPv6-এর default route লেখা হয় ::/0 (দুটো colon আর একটা শূন্য), 0.0.0.0/0-এর বদলে। একটা dual-stack VPC-তে প্রতিটা CIDR-এর জন্য একটা local route আর প্রতিটা protocol-এর জন্য একটা default route থাকে:

Screenshot-ওয়ালা প্রশ্নের ফাঁদ: NAT gateway কখনো ::/0-এর target হয় না। Target-এ NAT gateway থাকলে destination অবশ্যই একটা IPv4 range (সাধারণত 0.0.0.0/0)। আরেকটা ফাঁদ চুপচাপ থাকে: “private” subnet-এ ::/0 → igw-… দিলে download ঠিকই চলে, তাই কেউ খেয়াল করে না যে server-গুলো এখন IPv6 দিয়ে internet থেকে পৌঁছানো যায়। আর মনে রাখো, security group আর network ACL-এ IPv6-এর আলাদা rule লাগে: 0.0.0.0/0-এর rule ::/0-কে ঢাকে না।

#পুরো একটা VPC রক্ষা করা

এ পর্যন্ত দেখা সুরক্ষাগুলোর প্রত্যেকটা একটা স্তর বা একটা resource পাহারা দেয়:

এদের কেউই বলতে পারে না “এই server-গুলো *.ubuntu.com-এ যেতে পারবে, আর কোথাও না”, বা “এই exploit বহন করা যেকোনো packet ফেলে দাও, port যা-ই হোক”, তাও একটা VPC-তে ঢোকা-বেরোনো সব traffic-এর জন্য: internet থেকে আর internet-এ, অন্য VPC, Direct Connect আর Site-to-Site VPN। এই ফাঁকটাই ভরায় AWS Network Firewall।

#AWS Network Firewall

AWS Network Firewall হলো VPC-র জন্য একটা managed, stateful network firewall আর intrusion prevention system (IPS), যেটা layer 3 থেকে layer 7 পর্যন্ত পরীক্ষা করে। চালানো আর বড়-ছোট করার দায়িত্ব AWS-এর; তুমি rule লেখো আর route table দিয়ে traffic এর ভেতর দিয়ে পাঠাও। এটা যেকোনো দিকের traffic দেখতে পারে: VPC থেকে VPC, internet-এর দিকে বাইরে যাওয়া, internet থেকে ভেতরে আসা, আর Direct Connect ও Site-to-Site VPN-এ যাওয়া-আসা।

ভেতরে ভেতরে প্রতিটা firewall endpoint আসলে AWS-এর চালানো একটা fleet-এর সামনের একটা Gateway Load Balancer endpoint (লেসন ৬.৩), তাই capacity আর high availability-র মাথাব্যথা AWS-এর, তোমার না। এভাবে ভাবতে পারো: “appliance-সহ GWLB, শুধু appliance-গুলো AWS নিজে দেয় আর চালায়”।

#অংশগুলো

• একটা firewall একটা VPC-তে বসে, প্রতিটা Availability Zone-এ একটা করে firewall endpoint, প্রতিটা একটা ছোট নিজস্ব firewall subnet-এ (একটা /28-ই যথেষ্ট)। ওই subnet-এ নিজের workload রেখো না।
• একটা firewall policy বলে কোন rule group চলবে, কোন ক্রমে, আর কোনো rule না মিললে traffic-এর কী হবে।
• Rule group দুই রকম:
  • Stateless rule group প্রতিটা packet আলাদা করে দেখে, 5-tuple (আর TCP flag) ধরে, priority ক্রমে। Action: pass, drop, বা stateful engine-এ পাঠাও। দ্রুত, মোটা দাগের filter-এর জন্য; সাধারণ default হলো “সবকিছু stateful-এ পাঠাও”।
  • Stateful rule group connection মনে রাখে, তাই reply ঠিকঠাক সামলায়। লেখার তিনটা উপায়: 5-tuple rule (security group-এর মতো, কিন্তু deny আর log-সহ), domain list (*.ubuntu.com, .facebook.com… allow বা deny, মেলায় TLS-এর SNI বা HTTP-র Host header দেখে, কিছু decrypt না করে), আর Suricata-compatible rule (open-source IPS rule-এর ভাষা: payload-এর pattern, protocol, যেমন বাইরে যাওয়া SMB বন্ধ করা, regular expression)। Action: pass, drop, reject (drop করে একটা TCP reset পাঠায়), alert।
• AWS managed rule group: চেনা malware আর botnet host-এর domain আর IP তালিকা, আর threat signature group (exploit, malware, scanner), যেগুলো AWS হালনাগাদ রাখে, তুমি নিজের group-এর মতোই যোগ করো।
• Log: alert log (কোন rule-এ মিলল), flow log (firewall যত flow দেখেছে) আর TLS log, পাঠানো যায় S3, CloudWatch Logs বা Amazon Data Firehose-এ (slide-এ পুরোনো নাম Kinesis Data Firehose)।

#Endpoint দিয়ে traffic পার করানো

Network Firewall শুধু সেটাই পরীক্ষা করে যা routing তার কাছে পাঠায়। Internet-ওয়ালা একটা VPC-তে তিনটা route table কাজটা করে:

তৃতীয়টার নাম ingress routing: internet gateway-এর সাথেই associate করা একটা route table, যাতে internet থেকে আসা traffic-কেও firewall পার হতে হয়। প্রতিটা AZ-এ একটা firewall endpoint রাখো, আর প্রতিটা AZ-এর route তার নিজের endpoint-এ পাঠাও: একটা flow-এর দুই দিককেই একই endpoint পার হতে হবে, নইলে যে অর্ধেক stateful engine চেনে না সেটা drop হয় (asymmetric routing)। Network Firewall address অনুবাদ করে না; private instance-এর internet লাগলে NAT gateway বসে firewall-এর পরে, আর protected subnet-এর 0.0.0.0/0 তখনো firewall-এর দিকেই থাকে।

#সামলানো আর খরচ

• Firewall Manager একটা Organization-এর সব account আর VPC জুড়ে Network Firewall policy আর endpoint বানায়, notes যেমন বলছে (কীভাবে, সেটা লেসন ২১.৬-এ)।
• দাম, us-east-1-এ আন্দাজের জন্য: প্রতিটা firewall endpoint-এর জন্য ঘণ্টায় প্রায় ০.৩৯৫ USD (প্রতি AZ), সাথে প্রতি GB process-এ ০.০৬৫ USD। Firewall-এর পেছনে NAT gateway জোড়া থাকলে, মিলে যাওয়া endpoint-ঘণ্টার জন্য তার ঘণ্টার আর প্রতি GB-র চার্জ মাফ। দুটো AZ পুরো মাস চালালে traffic ছাড়াই মোটামুটি ৫৭৫ USD, তাই সবার জন্য একটা কেন্দ্রীয় firewall রাখাই প্রচলিত।

#Transit Gateway দিয়ে এক জায়গায় পরীক্ষা

অনেকগুলো VPC থাকলে প্রতিটায় একটা করে firewall দামি, আর সবগুলো এক রকম রাখাও কঠিন। প্রচলিত নকশা হলো একটা inspection VPC: প্রতিটা spoke VPC, Site-to-Site VPN আর Direct Connect একটা Transit Gateway-তে attach হয় (লেসন ২২.৬); spoke route table সবকিছু inspection VPC attachment-এ পাঠায়; firewall east-west (VPC থেকে VPC) আর north-south (internet-এর দিকে) traffic পরীক্ষা করে, আর একটা কেন্দ্রীয় NAT gateway পুরো company-কে বাইরে যাওয়ার এক সেট address দেয়। Inspection VPC-র Transit Gateway attachment-এ appliance mode চালু থাকে, যাতে একটা flow-এর দুই দিকই একই AZ-এর endpoint-এ থাকে।

#কোন হাতিয়ার?

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

• IDS কিছুই পাচ্ছে না: NLB-এ UDP 4789 listener নেই, target-এর security group UDP 4789 আটকাচ্ছে, source subnet-এর route table থেকে target-এ পৌঁছানো যায় না, অথবা filter-এ কোনো accept rule নেই। Mirroring চুপচাপ ব্যর্থ হয়।
• Mirror session বানানো যাচ্ছে না: source instance type সমর্থিত না (Nitro-ভিত্তিক না, non-Nitro-র ছোট তালিকাতেও নেই), অথবা ENI-তে আগেই তিনটা session আছে।
• ব্যস্ত সময়ে IDS আক্রমণ ধরতে পারছে না: source instance তার bandwidth-এর সীমায়, তাই mirror করা packet আগে পড়ে যাচ্ছে। বড় instance নাও, বা আরও কড়া filter দাও।
• IDS শুধু হিজিবিজি দেখছে: traffic-টা TLS। TLS যেখানে খোলে তার পরে mirror করো, নয়তো tool-কে key দাও।
• Dual-stack subnet-এ “instance launch হচ্ছে না”: subnet-এ IPv4 address ফুরিয়েছে, IPv6 না। VPC-তে একটা IPv4 CIDR আর একটা নতুন subnet যোগ করো।
• IPv4 চলছে কিন্তু IPv6 client-এর timeout হচ্ছে: security group বা network ACL 0.0.0.0/0 খুলেছে কিন্তু ::/0-এর কোনো rule নেই, অথবা subnet-এ ::/0 route নেই, অথবা DNS-এ কোনো AAAA record নেই।
• ::/0 → nat-… নিচ্ছে না: NAT gateway শুধু IPv4। Egress-only internet gateway ব্যবহার করো (বা NAT64-এর জন্য 64:ff9b::/96)।
• “Private” IPv6 server internet থেকে পৌঁছানো যাচ্ছে: তাদের subnet-এ ::/0 → igw-…। ওটা egress-only gateway-তে দাও।
• IPv6 range আলাদা হলেও peering হচ্ছে না: IPv4 CIDR overlap করছে; IPv6 peering বাঁচায় না।
• Network Firewall-এর rule কোনো কাজ করছে না: কোনো route firewall endpoint-এ traffic পাঠাচ্ছে না, অথবা workload বসে আছে firewall subnet-এর ভেতরেই।
• Routing বদলানোর পর connection ঝুলে থাকছে: asymmetric routing; এক দিকের traffic firewall এড়িয়ে যাচ্ছে বা অন্য AZ-এর endpoint পার হচ্ছে। Route ঠিক করো; Transit Gateway attachment-এ appliance mode চালু করো।
• ভেতরে আসা traffic পরীক্ষা হচ্ছে না: internet gateway-এর সাথে edge-associate করা এমন কোনো route table নেই, যেটা subnet-এর CIDR firewall endpoint-এ পাঠায়।

#System design-এ

মনে রাখার মতো নকশা:

• বাইরে যাওয়ার filter: workload subnet → Network Firewall (domain allow list) → NAT gateway → internet gateway। অচেনা site-এ data পাঠানো আর malware-এর “বাড়িতে ফোন করা” বন্ধ হয়।
• ভেতরে আসার পরীক্ষা: IGW edge route table → firewall endpoint → public subnet (HTTP-র জন্য WAF-ওয়ালা ALB)।
• Hub-and-spoke পরীক্ষা: spoke → Transit Gateway → inspection VPC (appliance mode) → ফেরত, অথবা কেন্দ্রীয় NAT gateway দিয়ে বাইরে।
• Out-of-band নজরদারি: Traffic Mirroring → NLB বা GWLB endpoint → একটা security account-এর IDS fleet; সস্তা, স্থায়ী রেকর্ডের জন্য flow log।
• IPv6-এ যাওয়া: আগে dual stack (IPv4 থেকে যায়), প্রতি VPC Amazon-এর /56, প্রতি subnet /64, private subnet-এ ::/0 → eigw, security group আর network ACL-এ আলাদা IPv6 rule; যেখানে IPv4 টানাটানি, সেখানে DNS64 আর NAT64-সহ IPv6-only subnet।

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

এই command-গুলো ap-south-1-এ AWS CLI v2 দিয়ে। Traffic Mirroring, NAT gateway আর Network Firewall endpoint ঘণ্টা ধরে বিল হয়: যা বানাবে মুছে ফেলো।

# 1. Traffic Mirroring: target (an NLB with a UDP 4789 listener), filter, rule, session
aws ec2 create-traffic-mirror-target \
  --network-load-balancer-arn arn:aws:elasticloadbalancing:ap-south-1:111122223333:loadbalancer/net/ids-nlb/0a1b2c3d4e5f6789 \
  --description "IDS fleet"
# { "TrafficMirrorTarget": { "TrafficMirrorTargetId": "tmt-0a1b2c3d4e5f67890", "Type": "network-load-balancer", ... } }

aws ec2 create-traffic-mirror-filter --description "HTTPS only"
# { "TrafficMirrorFilter": { "TrafficMirrorFilterId": "tmf-0b1c2d3e4f5a67890", ... } }

aws ec2 create-traffic-mirror-filter-rule --traffic-mirror-filter-id tmf-0b1c2d3e4f5a67890 \
  --traffic-direction ingress --rule-number 100 --rule-action accept --protocol 6 \
  --destination-port-range FromPort=443,ToPort=443 \
  --source-cidr-block 0.0.0.0/0 --destination-cidr-block 0.0.0.0/0
aws ec2 create-traffic-mirror-filter-rule --traffic-mirror-filter-id tmf-0b1c2d3e4f5a67890 \
  --traffic-direction egress --rule-number 100 --rule-action accept --protocol 6 \
  --source-port-range FromPort=443,ToPort=443 \
  --source-cidr-block 0.0.0.0/0 --destination-cidr-block 0.0.0.0/0

aws ec2 create-traffic-mirror-session --network-interface-id eni-0c1d2e3f4a5b67890 \
  --traffic-mirror-target-id tmt-0a1b2c3d4e5f67890 --traffic-mirror-filter-id tmf-0b1c2d3e4f5a67890 \
  --session-number 1 --virtual-network-id 101
# { "TrafficMirrorSession": { "TrafficMirrorSessionId": "tms-0d1e2f3a4b5c67890", "VirtualNetworkId": 101, ... } }

# On an IDS instance: the copies arrive as VXLAN on UDP 4789
sudo tcpdump -ni eth0 -c 2 udp port 4789
# 10:42:07.112 IP 10.20.1.15.61253 > 10.20.3.40.4789: VXLAN, flags [I] (0x08), vni 101
# IP 198.51.100.20.53122 > 10.20.1.15.443: Flags [S], seq 2087316431, win 64240, length 0

# 2. Dual stack: an Amazon-provided /56 for the VPC, a /64 for a subnet
aws ec2 associate-vpc-cidr-block --vpc-id vpc-0a1b2c3d4e5f67890 --amazon-provided-ipv6-cidr-block
# { "Ipv6CidrBlockAssociation": { "Ipv6CidrBlock": "", "Ipv6CidrBlockState": { "State": "associating" } }, ... }
aws ec2 describe-vpcs --vpc-ids vpc-0a1b2c3d4e5f67890 \
  --query 'Vpcs[0].Ipv6CidrBlockAssociationSet[0].Ipv6CidrBlock' --output text
# 2001:db8:1234:1a00::/56
aws ec2 associate-subnet-cidr-block --subnet-id subnet-0b1c2d3e4f5a67890 \
  --ipv6-cidr-block 2001:db8:1234:1a02::/64
aws ec2 modify-subnet-attribute --subnet-id subnet-0b1c2d3e4f5a67890 --assign-ipv6-address-on-creation

# 3. Egress-only internet gateway and the private subnet's IPv6 default route
aws ec2 create-egress-only-internet-gateway --vpc-id vpc-0a1b2c3d4e5f67890
# { "EgressOnlyInternetGateway": { "EgressOnlyInternetGatewayId": "eigw-0a9b8c7d6e5f43210", ... } }
aws ec2 create-route --route-table-id rtb-0c1d2e3f4a5b67890 \
  --destination-ipv6-cidr-block ::/0 --egress-only-internet-gateway-id eigw-0a9b8c7d6e5f43210

# The classic mistake, refused by the API
aws ec2 create-route --route-table-id rtb-0c1d2e3f4a5b67890 \
  --destination-ipv6-cidr-block ::/0 --nat-gateway-id nat-0f1e2d3c4b5a69780
# An error occurred (InvalidParameterValue) ... (a NAT gateway takes only IPv4 routes, or 64:ff9b::/96 for NAT64)

# From the private instance
curl -6 -s -o /dev/null -w "%{http_code}\n" https://archive.ubuntu.com/
# 200
ping -6 -c 2 2001:db8:1234:1a02::456      # from a laptop on the internet
# 2 packets transmitted, 0 received, 100% packet loss

এটা domains.json নামে save করো (একটা stateful domain allow list):

{
  "RulesSource": {
    "RulesSourceList": {
      "Targets": [".ubuntu.com", ".microsoft.com", "rajshahi-college.example"],
      "TargetTypes": ["TLS_SNI", "HTTP_HOST"],
      "GeneratedRulesType": "ALLOWLIST"
    }
  }
}

# 4. Network Firewall: rule group, policy, firewall with one endpoint per AZ
aws network-firewall create-rule-group --rule-group-name lab-allowed-domains --type STATEFUL \
  --capacity 100 --rule-group file://domains.json
aws network-firewall create-firewall-policy --firewall-policy-name lab-policy --firewall-policy '{
  "StatelessDefaultActions": ["aws:forward_to_sfe"],
  "StatelessFragmentDefaultActions": ["aws:forward_to_sfe"],
  "StatefulRuleGroupReferences": [
    { "ResourceArn": "arn:aws:network-firewall:ap-south-1:111122223333:stateful-rulegroup/lab-allowed-domains" },
    { "ResourceArn": "arn:aws:network-firewall:ap-south-1:aws-managed:stateful-rulegroup/ThreatSignaturesExploitsStrictOrder" } ],
  "StatefulEngineOptions": { "RuleOrder": "STRICT_ORDER" },
  "StatefulDefaultActions": ["aws:drop_established", "aws:alert_established"] }'
aws network-firewall create-firewall --firewall-name lab-fw --vpc-id vpc-0a1b2c3d4e5f67890 \
  --firewall-policy-arn arn:aws:network-firewall:ap-south-1:111122223333:firewall-policy/lab-policy \
  --subnet-mappings SubnetId=subnet-0f1a2b3c4d5e67890 SubnetId=subnet-0e1f2a3b4c5d67890
aws network-firewall describe-firewall --firewall-name lab-fw \
  --query 'FirewallStatus.SyncStates.*.Attachment.EndpointId'
# [ "vpce-0123456789abcdef0", "vpce-0fedcba9876543210" ]

# 5. Steer traffic: protected subnet → firewall, IGW edge route back through the firewall
aws ec2 create-route --route-table-id rtb-0aaa1111bbbb22223 \
  --destination-cidr-block 0.0.0.0/0 --vpc-endpoint-id vpce-0123456789abcdef0
aws ec2 associate-route-table --route-table-id rtb-0ccc3333dddd44445 --gateway-id igw-0a1b2c3d4e5f67890
aws ec2 create-route --route-table-id rtb-0ccc3333dddd44445 \
  --destination-cidr-block 10.0.1.0/24 --vpc-endpoint-id vpce-0123456789abcdef0

# 6. Test from a lab server
curl -s -o /dev/null -w "%{http_code}\n" https://archive.ubuntu.com/
# 200
curl -s -m 5 https://bet.example/ || echo "blocked"
# blocked

Console-এও চেষ্টা করো: ৬ নম্বর ধাপের পরে firewall-এর Monitoring tab খোলো, তারপর alert log একটা CloudWatch Logs group-এ পাঠিয়ে Logs Insights দিয়ে query করো (লেসন ১৯.৪)। পরিষ্কার করো delete-traffic-mirror-session, delete-firewall (তার endpoint-এর দিকের route সরানোর পরে) আর delete-egress-only-internet-gateway দিয়ে।

#সারসংক্ষেপ

মূল কথা

• Traffic Mirroring একটা source ENI (Nitro-ভিত্তিক instance) থেকে পুরো packet (payload-সহ) কপি করে একটা target-এ (ENI, UDP 4789-ওয়ালা NLB, বা GWLB endpoint) পাঠায়, বাছাই করে একটা filter, সব বাঁধা থাকে একটা session-এ (priority, packet length, VNI)। কপি যায় VXLAN, UDP 4789-এ, বানায় Nitro card: কোনো agent নেই, CPU খরচ নেই, out of band (alert দিতে পারে, block কখনো না)। সীমা: এক ENI-তে ৩টা session, কপি instance-এর bandwidth খায় আর আগে পড়ে যায়, SG বা NACL যে inbound packet ফেলে দেয় সেটা mirror হয় না।
• Flow log = metadata, Traffic Mirroring = passive কপি, Network Firewall = পথের মাঝে, আটকাতে পারে। “DPI” মেলে mirroring-এর সাথে (ধরা) আর Network Firewall-এর সাথে (থামানো)।
• IPv6: ১২৮ bit, আটটা hex group; শুরুর শূন্য বাদ, এক address-এ একটাই ::; ::/0 default route; উদাহরণের জন্য 2001:db8::/32। Amazon-এর দেওয়া IPv6 public আর সারা পৃথিবীতে অনন্য (পরীক্ষার উত্তর); ২০২৪ থেকে IPAM দিয়ে private IPv6 (ULA, advertise না করা GUA) পাওয়া যায়।
• Dual stack: default-এ VPC /56, subnet /64 (IPAM বা BYOIP দিয়ে /44–/60 আর /44–/64)। IPv4 বন্ধ করা যায় না: dual-stack subnet-এ launch ব্যর্থ মানে খালি IPv4 নেই, তাই একটা IPv4 CIDR যোগ করো। Peering-এ তবুও IPv4 overlap চলে না। IPv6-only subnet আছে (পাশের কথা)।
• Egress-only internet gateway: শুধু IPv6, stateful, বাইরে যাওয়া connection আর তার reply চলে, ভেতরে আসা connection drop, কোনো অনুবাদ নেই, ঘণ্টার ভাড়া নেই। IPv4 → NAT gateway, IPv6 → EIGW।
• Route: public-এ ::/0 → igw, private-এ ::/0 → eigw; NAT gateway কখনো ::/0 নেয় না (শুধু 0.0.0.0/0, বা DNS64-এর সাথে NAT64-এর জন্য 64:ff9b::/96)। Security group আর NACL-এ ::/0-এর আলাদা rule লাগে।
• AWS Network Firewall: managed, stateful, layer 3–7 firewall + IPS; stateless আর stateful rule group (5-tuple, SNI/Host ধরে domain list, Suricata rule), AWS-এর managed threat signature, TLS inspection; প্রতি AZ-এ নিজস্ব subnet-এ firewall endpoint, route table (IGW edge ingress routing-সহ) traffic পার করায়, routing হতে হবে symmetric; ভিত্তি GWLB; log যায় S3, CloudWatch Logs, Firehose-এ; Transit Gateway-সহ কেন্দ্রীয় inspection VPC (appliance mode; ২০২৫ থেকে native attachment); সব account জুড়ে সামলায় Firewall Manager; endpoint-ঘণ্টায় ~০.৩৯৫ USD + প্রতি GB ০.০৬৫ USD।

নিজেকে যাচাই করো: Traffic Mirroring, IPv6 আর Network Firewall৩০টি প্রশ্ন