ระบบรักษาความปลอดภัยขอบเขตเครือข่าย

ทฤษฎีและกลไกการทำงาน (How it works):
ในขณะที่ Security Group (SG) และ Network ACL ตรวจสอบได้แค่ที่อยู่ IP ต้นทาง/ปลายทาง และพอร์ต (Layer 4) ทั้งสองเครื่องมือนี้ถือว่า "ตาบอด" ต่อเนื้อหาที่อยู่ภายในแพ็กเกจ หากแฮกเกอร์ส่งคำสั่งเจาะระบบแฝงมาในพอร์ต 443 (HTTPS) SG จะปล่อยผ่านทันที

เพื่ออุดช่องโหว่นี้ AWS Network Firewall จึงถูกสร้างขึ้นมาในฐานะไฟร์วอลล์ระดับองค์กรแบบ Managed Service ที่สามารถทำ Deep Packet Inspection (DPI) หรือการแกะกล่องพัสดุ (Packet) เข้าไปดูข้อมูลระดับแอปพลิเคชัน (Layer 7) ได้ กลไกเบื้องหลังขับเคลื่อนด้วยเอนจิน Suricata ซึ่งเป็น IPS (Intrusion Prevention System) แบบโอเพนซอร์สระดับโลก ทำให้สามารถจับคู่แพตเทิร์นของมัลแวร์ (Signatures) หรือทำ URL Filtering ขาออก (เช่น อนุญาตให้เซิร์ฟเวอร์ออกเน็ตไปแค่ github.com เท่านั้น) ได้อย่างแม่นยำ

สถาปัตยกรรมของมันทำงานร่วมกับ Route Table โดยคุณต้องสร้าง Firewall Subnet แยกออกมาต่างหาก และบิดเบือนเส้นทางจราจร (Ingress/Egress Routing) ให้วิ่งทะลุ Firewall Endpoint ก่อนที่จะไปถึงจุดหมายปลายทาง

# สร้าง Rule Group (Suricata format)
resource "aws_networkfirewall_rule_group" "block_cryptominer" {
  capacity = 100
  name     = "Block-CryptoMiners"
  type     = "STATEFUL"
  rule_group {
    rules_source {
      rules_string = <<-EOT
        drop tls $HOME_NET any -> $EXTERNAL_NET any (msg:"Blocked CryptoMining Pool"; tls.sni; content:"pool.minexmr.com"; sid:1000001; rev:1;)
      EOT
    }
  }
}

# สร้าง Firewall Policy
resource "aws_networkfirewall_firewall_policy" "main_policy" {
  name = "Enterprise-Egress-Policy"
  firewall_policy {
    stateless_default_actions          = ["aws:forward_to_sfe"] # โยนให้ Stateful (Suricata) จัดการต่อ
    stateless_fragment_default_actions = ["aws:forward_to_sfe"]
    stateful_rule_group_reference {
      resource_arn = aws_networkfirewall_rule_group.block_cryptominer.arn
    }
  }
}

# สร้างตัว Firewall ลงใน Firewall Subnet
resource "aws_networkfirewall_firewall" "main_fw" {
  name                = "Core-VPC-Firewall"
  firewall_policy_arn = aws_networkfirewall_firewall_policy.main_policy.arn
  vpc_id              = aws_vpc.main_vpc.id
  subnet_mapping {
    subnet_id = aws_subnet.firewall_subnet.id
  }
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
ในเซิร์ฟเวอร์คลังข้อมูล (Data Warehouse) ที่รันบน EC2 มีสิทธิ์ระดับสูงที่สามารถดึงข้อมูลบัตรเครดิตได้ หากเครื่องนี้โดนโจมตีช่องโหว่ Log4j แฮกเกอร์จะพยายามส่งคำสั่งให้เซิร์ฟเวอร์นี้ขว้างข้อมูลกลับไปยังเซิร์ฟเวอร์ของแฮกเกอร์ที่ IP 93.184.216.34 ด้วยการติดตั้ง AWS Network Firewall เป็นด่านตรวจขาออก (Egress Inspection) พร้อมกฎ "Allow-list Domain" (อนุญาตเฉพาะโดเมนของบริษัท) การส่งข้อมูลออกไปยัง IP แปลกหน้าจะถูกทำลายทิ้งทันที และแจ้งเตือนทีม SOC โดยที่ระบบยังทำงานตามปกติ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): วิศวกรหน้าใหม่มักเข้าใจผิดว่าการใส่ Firewall Endpoint เข้าไปเฉยๆ ทราฟฟิกจะวิ่งผ่านมันเอง ความจริงคือถ้าไม่แก้ Route Table บริเวณ Internet Gateway (IGW) แบบ "Ingress Routing" ทราฟฟิกจะวิ่งข้ามหัว Firewall เข้าสู่เครื่องเป้าหมายโดยตรง
* Mitigation (วิธีแก้): AWS มีฟีเจอร์ Gateway Route Table (Edge Association) ซึ่งเป็น Route Table พิเศษที่ผูกติดกับ IGW โดยตรง เราต้องเขียนกฎที่ IGW ว่า "เป้าหมาย 10.0.1.0/24 อย่าวิ่งไปตรงๆ นะ ให้ขว้างเข้า vpce-firewall-id ก่อนเสมอ" สถาปัตยกรรมนี้เรียกว่า Bump-in-the-wire

ทฤษฎีและกลไกการทำงาน (How it works):
หากองค์กรของคุณเป็นลูกค้าระดับ Enterprise ที่ใช้ Next-Generation Firewalls (NGFW) อย่าง Palo Alto, Check Point หรือ Fortinet อยู่แล้ว และไม่ต้องการเปลี่ยนมาใช้ AWS Network Firewall คุณจะประสบปัญหาว่า "จะเอา Firewall เหล่านี้ไปวางดักทราฟฟิกตรงไหนให้สามารถ Auto-Scale ได้?"

AWS จึงเปิดตัว Gateway Load Balancer (GWLB) ซึ่งทำงานที่ Layer 3 (Network Layer) เป็นเครื่องมือมหัศจรรย์ที่ทำงานแบบ "โปร่งใส (Transparent)" มันรับแพ็กเกจมาและห่อหุ้มมันด้วยโปรโตคอล GENEVE (Generic Network Virtualization Encapsulation) บนพอร์ต UDP 6081 จากนั้นโยนแพ็กเกจนี้ข้ามไปยังกลุ่มเครื่อง Virtual Appliance (Palo Alto) ที่ซ่อนอยู่หลัง GWLB ทันที

เมื่อ Firewall ของ Palo Alto ตรวจสอบเสร็จและอนุญาตให้ผ่าน มันจะส่งแพ็กเกจกลับมาที่ GWLB ในรูปแบบที่ยังคงรักษา Source IP และ Destination IP แบบดั้งเดิมไว้ทุกประการ (ไม่มีการทำ SNAT เปลี่ยน IP ต้นทาง) ทราฟฟิกจึงไหลต่อไปยังเป้าหมายได้อย่างแนบเนียน

# สร้าง Gateway Load Balancer
resource "aws_lb" "gwlb" {
  name               = "security-appliance-gwlb"
  load_balancer_type = "gateway"
  subnets            = [aws_subnet.appliance_subnet.id]
}

# สร้าง Target Group สำหรับ GWLB (สังเกตว่าโปรโตคอลคือ GENEVE)
resource "aws_lb_target_group" "gwlb_tg" {
  name     = "ngfw-targets"
  port     = 6081 # GENEVE Port
  protocol = "GENEVE"
  vpc_id   = aws_vpc.security_vpc.id
  
  health_check {
    port     = 80
    protocol = "HTTP"
    path     = "/healthz"
  }
}

# แปลง GWLB ให้เป็น VPC Endpoint Service เพื่อแชร์ข้าม VPC ได้
resource "aws_vpc_endpoint_service" "gwlb_service" {
  acceptance_required        = false
  gateway_load_balancer_arns = [aws_lb.gwlb.arn]
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
บริษัทข้ามชาติที่มีนโยบายความมั่นคงระดับโลก (Global Security Mandate) บังคับว่าทุกทราฟฟิกต้องถูกแสกนด้วย Palo Alto Panorama ทีม Cloud Architect จะใช้ GWLB เป็นพระเอกในการรวมศูนย์ Firewall Appliance ทั้งหมดไว้ใน VPC เดียวเรียกว่า "Security VPC" และใช้ GWLB Endpoint Service กระจายไปติดตั้งฝัง (Inject) ไว้ใน VPC ย่อยๆ ของแต่ละแผนก (Spoke VPCs) เมื่อมีแฮกเกอร์ยิงเจาะเข้ามาจาก VPC แผนกเซลส์ ทราฟฟิกจะถูกดูดผ่าน GWLB Endpoint ลอยข้ามอากาศมาเข้าเครื่อง Palo Alto ใน Security VPC เพื่อประหารทิ้งทันที โดยที่ทีมเซลส์ไม่จำเป็นต้องลง Palo Alto เอง

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): โปรโตคอล GENEVE ที่ห่อหุ้มแพ็กเกจ มีการเพิ่ม Header เข้าไป ทำให้ขนาดของแพ็กเกจ (MTU - Maximum Transmission Unit) ใหญ่ขึ้น หากเครือข่ายต้นทางและปลายทางตั้งค่า MTU ไว้ที่ 1500 (Standard Ethernet) แพ็กเกจจะถูกหั่น (Fragmentation) หรือถูกดรอป (Dropped) ทำให้แอปพลิเคชันค้าง
* Mitigation (วิธีแก้): ต้องตั้งค่า Jumbo Frames (MTU 8500 หรืออย่างน้อย 9000) ในระดับอินสแตนซ์ของ EC2 ทั้งฝั่งรับ ฝั่งส่ง และบน Virtual Appliance เพื่อรับรองขนาดของ GENEVE Header ที่บวกเพิ่มเข้ามา หรือหลีกเลี่ยงการเปิดใช้งาน Path MTU Discovery (PMTUD) ที่ตั้งค่าเคร่งครัดเกินไป

ทฤษฎีและกลไกการทำงาน (How it works):
หาก Network Firewall ป้องกัน Layer 3/4 ได้อย่างยอดเยี่ยม AWS WAF (Web Application Firewall) คือผู้พิทักษ์ด่านหน้าในระดับ Layer 7 (HTTP/HTTPS) มันไม่ได้ทำงานร่วมกับ VPC Route Table แต่มันจะไป "เกาะ (Attach)" อยู่ที่หน้าประตูของ Application Load Balancer (ALB), Amazon API Gateway, หรือ CloudFront

WAF ช่วยปกป้องการโจมตีระดับเว็บเบราว์เซอร์ เช่น SQL Injection (SQLi), Cross-Site Scripting (XSS), และแก๊ง Botnet ต่างๆ ด้วยการสแกนเนื้อหาใน HTTP Request Headers, URI, และ Body

ควบคู่กับ WAF คือ AWS Shield ซึ่งเป็นบริการป้องกัน DDoS (Distributed Denial of Service) รุ่น Standard จะฟรีและเปิดใช้งานอยู่ตลอดเวลา แต่รุ่น Shield Advanced (ราคาแพงลิ่ว 3,000 USD ต่อเดือน) จะมาพร้อมกับทีมสนับสนุนฉุกเฉิน (AWS SRT - Shield Response Team) ที่สามารถเขียน WAF Rules ดักจับทราฟฟิก DDoS แบบพฤติกรรมแปลกประหลาดได้แทนคุณแบบ Real-time พร้อมกับการรับประกันจ่ายเงินคืนกรณี AWS บิลล์พุ่งสูงจากการถูกโจมตี (Cost Protection)

resource "aws_wafv2_web_acl" "alb_waf" {
  name        = "Enterprise-ALB-WAF"
  description = "Block OWASP Top 10 and known bad IPs"
  scope       = "REGIONAL" # ใช้ REGIONAL สำหรับ ALB / ใช้ CLOUDFRONT สำหรับ Edge

  default_action {
    allow {} # ค่าเริ่มต้นให้ผ่าน
  }

  # กฎที่ 1: ใช้ Managed Rules ป้องกันช่องโหว่เว็บทั่วไป (SQLi, XSS)
  rule {
    name     = "AWSManagedRulesCommonRuleSet"
    priority = 10
    override_action {
      none {}
    }
    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesCommonRuleSet"
        vendor_name = "AWS"
      }
    }
    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "CommonRuleSetMetric"
      sampled_requests_enabled   = true
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "WebACLMetric"
    sampled_requests_enabled   = true
  }
}

# ผูก WAF เข้ากับ ALB
resource "aws_wafv2_web_acl_association" "waf_alb_assoc" {
  resource_arn = aws_lb.main_app_alb.arn
  web_acl_arn  = aws_wafv2_web_acl.alb_waf.arn
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
ในช่วงแคมเปญการขายตั๋วคอนเสิร์ตศิลปินระดับโลก ระบบจะถูกรุมถล่มด้วย Scalper Bots (บอทกว้านซื้อตั๋ว) นับล้านตัว การใช้ WAF ร่วมกับฟีเจอร์ Bot Control และ Rate-based Rules (เช่น บล็อก IP ที่เรียกหน้าชำระเงินเกิน 100 ครั้งใน 5 นาที) จะช่วยสกัดกั้นทราฟฟิกขยะเหล่านี้ตั้งแต่ระดับ Edge Network (ขอบเครือข่ายของ AWS) ก่อนที่โหลดจะทะลุเข้ามากิน CPU ของ EC2 ใน VPC นอกจากนี้ หากมีการโจมตีระดับ DDoS ระดับชาติ Shield Advanced จะทำการซับแรงกระแทกผ่านโครงข่ายแบนด์วิดท์มหาศาลของ AWS อัตโนมัติ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): การเปิดใช้ WAF Rule อย่างบุ่มบ่ามในโหมด "Block" โดยไม่ได้ทดสอบ ทำให้ผู้ใช้งานจริง (Legitimate users) ถูกปฏิเสธการเข้าถึง (False Positives) เช่น การอัปโหลดไฟล์ที่มีวงเล็บเยอะๆ อาจถูกมองว่าเป็น SQL Injection และโดนตีตก
* Mitigation (วิธีแก้): เสมอปรับใช้ WAF ในโหมด "Count" (โหมดนับ/บันทึกผลเท่านั้น ไม่บล็อกจริง) เป็นเวลาอย่างน้อย 1-2 สัปดาห์ และวิเคราะห์ Logs ใน CloudWatch หรือ Athena หากมั่นใจว่าไม่มี Request ของลูกค้าจริงติดเข้ามาในกฎ จึงค่อยสลับโหมดเป็น "Block" อย่างเต็มตัว (Shadow mode deployment)

ทฤษฎีและกลไกการทำงาน (How it works):
เมื่อองค์กรมีจำนวน VPC แตะระดับ 20-50 VPCs การปล่อยให้แต่ละ VPC มี Internet Gateway (IGW) และ NAT Gateway เป็นของตัวเอง ถือเป็นฝันร้ายทางด้าน Security Compliance เพราะ Audit ไม่สามารถควบคุมได้ว่าใครออกอินเทอร์เน็ตไปไหนบ้าง และต้องมาตามตั้งค่า Network Firewall ทุกวง (ค่าใช้จ่ายกระฉูด)

สถาปัตยกรรมระดับ Enterprise จึงถือกำเนิดคอนเซปต์ Egress VPC หรือ VPC ทางออกส่วนกลาง กลไกของมันคือ การลบ IGW ออกจาก Spoke VPC ทุกวง (ทำให้เป็น Private 100%) แล้วสั่งให้ทุก VPC โยนทราฟฟิกที่มุ่งสู่อินเทอร์เน็ต (0.0.0.0/0) ลงไปที่ศูนย์กลางอย่าง AWS Transit Gateway (TGW)

TGW จะถูกกำหนด Route ให้เหวี่ยงทราฟฟิกทั้งหมดพุ่งเข้าไปที่ "Egress VPC" วงเดียวเท่านั้น ภายใน Egress VPC นี้จะมี AWS Network Firewall หรือ GWLB (Palo Alto) และ NAT Gateway วางขวางทางอยู่ ทุกซองข้อมูลที่จะออกอินเทอร์เน็ตต้องผ่านจุดนี้ ทำให้บริษัทสามารถรวมศูนย์นโยบายความปลอดภัย (Centralized Egress Filtering) ได้เบ็ดเสร็จในที่เดียว

# 1. TGW Route Table สำหรับ Spoke VPCs (แผนกต่างๆ)
resource "aws_ec2_transit_gateway_route_table" "spoke_rt" {
  transit_gateway_id = aws_ec2_transit_gateway.tgw.id
  tags = { Name = "Spoke-VPCs-Route-Table" }
}

# 2. บังคับเส้นทาง: ถ้าไปออกเน็ต (0.0.0.0/0) ให้พุ่งไปที่ Egress VPC Attachment
resource "aws_ec2_transit_gateway_route" "default_to_egress" {
  destination_cidr_block         = "0.0.0.0/0"
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.egress_vpc.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.spoke_rt.id
}

# (ฝั่ง Egress VPC จะมี NAT Gateway และ Network Firewall วางอยู่ก่อนออก IGW)
        

Use Case ในชีวิตจริง (Real-world Scenario):
บริษัทโรงพยาบาลที่มีกฎควบคุมข้อมูลคนไข้ (HIPAA) ขั้นสูงสุด หากระบบคลังข้อมูลใน VPC A โดนโจมตี แฮกเกอร์พยายามส่งข้อมูล 50GB ออกไปที่เซิร์ฟเวอร์ในรัสเซีย เนื่องจาก VPC A ไม่มีทางออกเน็ต มันจึงต้องส่งข้อมูลเข้า Transit Gateway ทะลุมาที่ Egress VPC ทันทีที่ข้อมูลมาถึง AWS Network Firewall ที่ด่านนี้ กฎระดับภูมิภาค (Geo-IP blocking) หรือระบบเตือนภัย Data Loss Prevention (DLP) จะจับพฤติกรรมการส่งข้อมูลแปลกปลอมออกนอกประเทศได้และดรอปทราฟฟิกทิ้งทันที นี่คือพลังของการรวมศูนย์ (Centralized Inspection Point)

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): หากวางสถาปัตยกรรมผิด เช่น เปิดใช้งาน Inspection (GWLB) แล้วทราฟฟิกขากลับไม่ได้วิ่งกลับมาผ่านร่องทางเดิมที่มันมา (Asymmetric Routing) ไฟร์วอลล์ที่เป็น Stateful จะทำการทิ้งแพ็กเกจ (Drop) ทันที เพราะมองว่านี่คือแพ็กเกจเถื่อนที่อยู่ดีๆ ก็โผล่มา ไม่ได้เริ่มจากการทำ Three-way handshake
* Mitigation (วิธีแก้): เมื่อเปิดใช้ TGW ร่วมกับ Firewall หรือ GWLB ในลักษณะ Egress VPC ต้องเปิดการตั้งค่า Appliance Mode Support บน Transit Gateway VPC Attachment ของ VPC ที่เป็นศูนย์กลาง (Egress VPC) เสมอ ฟีเจอร์นี้จะบังคับให้ TGW จดจำว่าทราฟฟิกวิ่งผ่าน AZ (Availability Zone) ไหนออกไป และตอนขากลับจะลากทราฟฟิกให้วิ่งกลับมาที่ AZ เดิมเสมอเพื่อไม่ให้ Firewall สับสน (Prevent Asymmetric Routing)

ทฤษฎีและกลไกการทำงาน (How it works):
แม้คุณจะมีไฟร์วอลล์ระดับแพ็กเกจ (L3/L4) และระดับเว็บ (L7) สุดยอดแค่ไหน แต่ถ้าขบวนการ "หาป้ายบอกทาง (DNS)" ของเครือข่ายถูกสวมรอย ระบบคุณก็พังพินาศได้ การโจมตีเช่น DNS Spoofing หรือ DNS Cache Poisoning คือการหลอกให้เซิร์ฟเวอร์ของคุณเชื่อว่า IP ของ api.bank.com คือ IP ของแฮกเกอร์

เพื่ออุดช่องโหว่นี้ที่ระดับ VPC คุณจำเป็นต้องมี 2 อาวุธหลัก:
1. DNSSEC (Domain Name System Security Extensions): ป้องกันฝั่ง Inbound/External โดยการเซ็นลายเซ็นดิจิทัล (Cryptographic Signatures) กำกับลงในทุกๆ DNS Record ที่ AWS ถือครอง หากมีคนพยายามปลอมตัวขั้นกลาง (Man-in-the-middle) ลายเซ็นจะไม่ตรงและเครื่องปลายทางจะปฏิเสธข้อมูลนั้นทันที
2. Route 53 Resolver DNS Firewall: ป้องกันฝั่ง Outbound/Internal หากมีมัลแวร์พยายามติดต่อไปหา C&C Server (Command and Control) ชื่อ evil-hacker.com ตัว DNS Firewall จะดักจับกระบวนการ Resolve ภายใน VPC และทำลายทิ้งก่อนที่เครื่อง EC2 จะทันรู้ว่า IP เป้าหมายคือเบอร์อะไรด้วยซ้ำ

# 1. นำเข้าบัญชีรายชื่อโดเมนอันตรายที่ AWS เตรียมไว้ให้ (AWS Managed Domain Lists)
data "aws_route53_resolver_firewall_domain_list" "aws_malware" {
  name = "AWSManagedDomainsMalwareDomainList"
}

# 2. สร้าง Rule Group
resource "aws_route53_resolver_firewall_rule_group" "vpc_dns_shield" {
  name = "Block-Malware-Domains"
}

# 3. สร้างกฎ บล็อกการเข้าถึงโดเมนอันตราย
resource "aws_route53_resolver_firewall_rule" "block_malware_rule" {
  action                  = "BLOCK"
  block_response          = "NODATA" # ไม่ตอบข้อมูลกลับ หลอกว่าหาไม่เจอ
  firewall_domain_list_id = data.aws_route53_resolver_firewall_domain_list.aws_malware.id
  firewall_rule_group_id  = aws_route53_resolver_firewall_rule_group.vpc_dns_shield.id
  priority                = 100
}

# 4. ผูกเข้ากับ VPC
resource "aws_route53_resolver_firewall_rule_group_association" "vpc_assoc" {
  firewall_rule_group_id = aws_route53_resolver_firewall_rule_group.vpc_dns_shield.id
  name                   = "Protect-Main-VPC"
  priority               = 101
  vpc_id                 = aws_vpc.main_vpc.id
}
        

Use Case ในชีวิตจริง (Real-world Scenario):
มัลแวร์ยุคใหม่ (เช่น ตัวล็อกข้อมูลเรียกค่าไถ่ Ransomware) ใช้วิธี DGA (Domain Generation Algorithm) ในการเปลี่ยนชื่อโดเมนรับคำสั่งนับพันชื่อต่อนาที (เช่น xqz12as.com, b2c3d4.net) ทำให้การบล็อกด้วย IP Address บน Security Group ไม่มีวันตามทัน การใช้ Route 53 DNS Firewall ช่วยให้คุณสามารถนำบัญชีดำ (Threat Intel Blacklist) หรือแม้กระทั่งกำหนดว่า "อนุญาตให้ Resolve ได้เฉพาะโดเมนในเครือบริษัท *.pipecraft.com นอกนั้นทิ้งหมด" ช่วยสกัดกั้นการเชื่อมต่อ (Call-home) ของ Ransomware ในระดับรากฐานเครือข่าย

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations):
* Pitfall (ปัญหา): ถ้าทีมพัฒนาแอปพลิเคชันของคุณเขียนโค้ดตั้งค่า DNS ไว้ให้ชี้ไปที่ 8.8.8.8 (Google DNS) แทนที่จะใช้ 10.0.0.2 (AmazonProvidedDNS) ในเครื่อง EC2 การร้องขอ DNS จะหลบหลีก (Bypass) Route 53 DNS Firewall โดยสมบูรณ์!
* Mitigation (วิธีแก้): DNS Firewall มีจุดบอดหากลูกค้าไม่ใช้ Resolver ของมัน คุณต้องตั้งค่า Network ACL (NACL) หรือ Security Group บล็อกการรับส่งข้อมูลผ่านพอร์ต 53 (UDP/TCP) ที่มุ่งสู่โลกภายนอก (Internet) เสมอ บังคับให้การสอบถาม DNS ทั้งหมดในบริษัท ต้องวิ่งเข้าหา x.x.x.2 (AmazonProvidedDNS) เท่านั้น จึงจะสามารถบังคับใช้นโยบายความปลอดภัยแบบเบ็ดเสร็จได้