SECURITY VALIDATION

Kiểm thử DDoS scrubbing: BGP diversion, GRE return và tính đối xứng dịch vụ

29/8/2026 · 16

Lưu lượng Internet được BGP chuyển tới scrubbing center rồi trả traffic sạch qua GRE về data center
Mục lục bài viết 10 phần

Scrubbing center có thể nhận route và hiển thị mitigation “active” nhưng traffic sạch vẫn blackhole do GRE, MTU, route return, firewall state hoặc health check. Test plan phải bắt đầu từ service path, duy trì legitimate traffic và đối chiếu route, tunnel, packet cùng giao dịch ứng dụng.

ĐỌC NHANH

Bài viết giúp bạn

  • Scrubbing cần chứng minh điều gì?
  • Topology và trust boundary
  • Biến số phải kiểm soát
Tùy chỉnh đọc
01

Scrubbing cần chứng minh điều gì?

#

Tách bốn câu hỏi: route diversion có vào đúng phạm vi; traffic tới scrubbing center theo đúng đường; traffic sạch quay lại origin và giữ semantics; withdrawal/rollback trả route về baseline không để stale state. “BGP prefix đã được quảng bá” chỉ chứng minh một phần control plane.

Định nghĩa vector và mục tiêu hợp lệ trong lab: volumetric UDP, TCP state exhaustion hay application request stress cần test rig và giới hạn khác nhau. Không phát tán traffic spoofed hoặc tải ảnh hưởng Internet; dùng môi trường được phê duyệt, prefix/test endpoint riêng và hard cap.

02

Topology và trust boundary

#

Topology gồm client hợp lệ, attack generator an toàn, upstream/transit, scrubbing point, GRE/IPsec/direct-connect return, edge router, firewall/load balancer và application. Vẽ cả đường vào và đường phản hồi từ server tới client; asymmetric routing có thể đúng theo thiết kế nhưng stateful device phải hỗ trợ.

Thu BGP update/RIB, tunnel counter, packet trước/sau scrubber, firewall/LB state và application result. Dùng test ID, sequence và clock chung. Nếu dịch vụ anycast hoặc multi-region, ghi site selection trước và sau diversion; không gộp mọi POP vào một kết quả.

Topology DDoS scrubbing với BGP diversion và GRE return.
Topology DDoS scrubbing với BGP diversion và GRE return.
03

Biến số phải kiểm soát

#

Khóa prefix length, origin ASN, BGP community, local preference, MED, prepending, ROA/RPKI state, propagation scope, health trigger và hold-down. Với tunnel, ghi GRE key nếu dùng, outer/inner MTU, fragmentation/PMTUD, source/destination, redundancy, keepalive và route recursion.

Traffic profile phải có legitimate baseline liên tục, protocol/port mix, connection rate, packet size, IPv4/IPv6, source distribution và attack duty cycle. Ghi firewall/NAT/LB timeout, SYN proxy, TLS termination và source-IP preservation. Thay một biến mỗi run.

Biến · Ca thử · Điều có thể sai

Prefix/community · test prefix, phạm vi POP · Divert quá rộng/hẹp

BGP timing · inject, propagate, withdraw · Blackhole hoặc route oscillation

GRE/return · primary/backup, MTU · Clean traffic không về origin

Source identity · preserved/proxy header · ACL/log/rate-limit sai

Stateful tier · firewall/LB/NAT · Asymmetry làm reset session

Attack profile · vector, rate, burst · Kết luận vượt profile

04

KPI và chuỗi bằng chứng

#

KPI control plane: time-to-advertise, propagation coverage, route selection, time-to-withdraw và stale route. KPI data plane: diverted share, clean traffic delivery, dropped/mitigated test vector, false drop, legitimate transaction success, latency p95/p99, packet loss, throughput/goodput, tunnel loss và recovery.

Chuỗi bằng chứng: activation request → route advertisement → upstream selection → packet tại scrubber → clean packet tại tunnel egress → firewall/LB → application transaction. Pass/fail phải bảo vệ traffic hợp lệ trước, đồng thời ghi efficacy trong đúng corpus thử nghiệm.

KPI · Bằng chứng · Pass/fail cần chốt

Diversion time · BGP + probe path · Trong response budget

Clean delivery · capture/tunnel counter · Không gap ngoài ngưỡng

False positive · labeled legitimate set · Không chặn nhầm ngoài tolerance

Mitigation efficacy · labeled attack set · Theo vector/profile đã duyệt

Service continuity · transaction + p99 · SLO trong thời gian mitigation

Rollback · route/path + transaction · Không stale/loop; ổn định

05

Ma trận kịch bản quyết định

#

Kịch bản · Thao tác · Kỳ vọng · Rủi ro

Baseline · Không diversion · SLO và path chuẩn · Baseline đã nghẽn

Manual diversion · Quảng bá test prefix · Path đổi đúng scope · Route leak

Auto trigger · Vượt ngưỡng lab · Kích hoạt có audit · False trigger

GRE primary fail · Ngắt tunnel · Backup phục hồi · Recursive blackhole

MTU edge · Frame/packet theo bậc · PMTUD/drop có counter · Silent loss

Mixed traffic · Attack + legitimate · Good traffic giữ SLO · False positive

Withdrawal · Gỡ mitigation · Route ổn định · Flap/stale state

Scrubber unavailable · Mất POP · Failover/fail-safe đúng · Chuyển sang POP quá xa

06

Test plan kích hoạt và phục hồi

#

Pha A baseline path, MTU và transaction. Pha B manual diversion không attack để cô lập routing/tunnel. Pha C chạy legitimate mix và kiểm tra source/state. Pha D thêm từng vector ở rate thấp rồi tăng theo bước có hard cap. Pha E fail tunnel/POP và đo continuity. Pha F withdraw, theo dõi route, state drain và latency đến khi ổn định.

Mỗi pha có owner, maintenance window, abort threshold và out-of-band access. Không đồng thời đổi BGP policy, firewall và mitigation signature. Lặp activation/withdrawal để phát hiện stale route hoặc configuration drift, nhưng tránh flap ảnh hưởng upstream.

Timeline kiểm thử DDoS scrubbing từ diversion tới service recovery.
Timeline kiểm thử DDoS scrubbing từ diversion tới service recovery.
07

Legitimate traffic, MTU và state

#

Corpus hợp lệ nên gồm TCP, UDP/QUIC, TLS, request nhỏ/lớn, long-lived connection và client nhiều vùng. Đo session reset, source address, MSS, fragmentation, PMTUD và header/proxy semantics. Scrubber có thể thay đổi path latency, TTL và đôi khi transport behavior; application phải được kiểm chứng chứ không suy luận.

GRE thêm overhead, làm effective MTU nhỏ hơn. Thử DF set/unset trong lab, ICMP Packet Too Big/Fragmentation Needed và thiết bị chặn ICMP. Với stateful firewall, xác minh hai chiều nhìn thấy state hoặc có kiến trúc symmetry phù hợp. Tunnel counter tăng không chứng minh application nhận payload.

08

Checklist vận hành an toàn

#
  • [ ] Prefix/ASN/community thử nghiệm và phê duyệt đã chốt.
  • [ ] ROA/RPKI, route filter và max-prefix được kiểm tra.
  • [ ] Legitimate baseline chạy liên tục trước khi activation.
  • [ ] GRE return, backup tunnel và MTU/PMTUD đã test không attack.
  • [ ] Hard rate cap, duration, abort threshold và liên hệ NOC/SOC rõ.
  • [ ] Không dùng traffic độc hại hoặc spoofing ngoài lab được phép.
  • [ ] Thu route, tunnel, packet, firewall/LB và application cùng clock.
  • [ ] Kiểm tra IPv4/IPv6 riêng nếu đều cung cấp.
  • [ ] Withdrawal/rollback và state drain được xác minh.
  • [ ] Báo cáo nêu vector, profile và phạm vi; không tuyên bố “chống mọi DDoS”.
09

Giới hạn của kết luận

#

Lab không tái tạo đầy đủ Internet path, attack source diversity hoặc upstream saturation. Kết quả của một POP/prefix không đại diện mọi khu vực. Detection/mitigation thay đổi theo rule set, capacity, license, route policy và ngày thử.

Efficacy với một vector không chứng minh chống multi-vector hoặc application abuse. Bài đo không thay threat intelligence, capacity planning và diễn tập phối hợp nhà cung cấp. Không công bố capacity nếu thiếu legitimate mix, packet size, duration, ingress distribution và bottleneck đầu tiên.

10

Khái niệm cần nhớ

#
  • Scrubbing center: Điểm xử lý để tách traffic bị đánh giá xấu khỏi traffic sạch.
  • BGP diversion: Thay đổi quảng bá/ưu tiên route để đưa traffic qua mitigation path.
  • GRE return: Tunnel trả traffic sạch về mạng origin.
  • Asymmetric routing: Hai chiều của flow đi qua các đường khác nhau.
  • False positive: Traffic hợp lệ bị mitigation xử lý nhầm.
  • PMTUD: Cơ chế phát hiện MTU phù hợp trên đường đi.
  • Service restoration: Giao dịch hợp lệ trở lại trạng thái mục tiêu.
THUẬT NGỮ NHANH

Khái niệm cần nhớ

Security efficacy
Mức độ phát hiện hoặc ngăn chặn đúng nội dung kiểm thử trong phạm vi đã xác định.
Goodput
Lưu lượng ứng dụng hữu ích tới đích, không tính phần truyền lại hoặc overhead không tạo giá trị.
False positive
Lưu lượng hợp lệ bị nhận diện hoặc xử lý nhầm như một mối đe dọa.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo5 nguồn

Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.

Nguyên tắc biên tập

NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.

Thông số và khả năng sản phẩm có thể thay đổi theo phiên bản. Hãy đối chiếu tài liệu chính thức trước khi xây dựng cấu hình hoặc tiêu chí nghiệm thu.
BẮT ĐẦU TỪ BÀI TOÁN

Cần chuyển kiến thức thành test plan?

Chia sẻ mục tiêu, topology và ràng buộc kỹ thuật. NetVali sẽ cùng bạn xác định bài đo phù hợp.

Trao đổi yêu cầu kỹ thuật