Bảo mật máy chủ web — Reverse proxy và nơi trú ẩn DDoS

1. Tổng quan

A. Định nghĩa

Reverse proxy (proxy ngược) là thành phần đại diện phía máy chủ (server-side proxy) nằm giữa client và máy chủ web thực (máy chủ gốc, Origin), thay mặt tiếp nhận, kiểm tra, chuyển tiếp mọi yêu cầu và trả lại phản hồi; còn nơi trú ẩn mạng chống DDoS (Cyber Shelter / Scrubbing Center) là dịch vụ lọc sạch lưu lượng, khi xảy ra tấn công từ chối dịch vụ phân tán quy mô lớn sẽ chuyển hướng lưu lượng của tổ chức bị hại tới trung tâm lọc, loại bỏ lưu lượng độc hại rồi chỉ chuyển lưu lượng bình thường tới máy chủ gốc.

Ý tưởng căn bản của bảo mật máy chủ web là "đừng phơi máy chủ trực tiếp, hãy dựng một tầng đệm và lọc sạch ở phía trước". Nếu máy chủ web nối thẳng Internet bằng IP công cộng, thì cổng, banner, cấu trúc đường dẫn, lỗ hổng đều trở thành bề mặt tấn công (attack surface), và chỉ cần lưu lượng dồn lại một chút là tài nguyên cạn kiệt, dịch vụ ngừng. Reverse proxy giải quyết vấn đề này về mặt cấu trúc. Client chỉ biết địa chỉ của proxy, không biết vị trí, số lượng, cấu trúc nội bộ của máy chủ thực (che giấu); proxy nhận yêu cầu, thực hiện xác thực, lọc, lưu đệm, cân bằng tải rồi mới chuyển ra phía sau, nhờ đó máy chủ gốc được bảo vệ trong mạng nội bộ tin cậy.

DDoS là mối đe dọa có bản chất khác. Nếu reverse proxy xử lý "chất" ở tầng ứng dụng, thì DDoS làm tê liệt dịch vụ bằng "lượng" lưu lượng. Khi hàng chục nghìn đến hàng trăm nghìn PC zombie và botnet IoT đổ vào lưu lượng từ vài trăm Gbps đến cấp Tbps mỗi giây, thì bất kỳ reverse proxy hay tường lửa nào cũng bị vô hiệu hóa vì chính băng thông bị bão hòa. Lúc đó, phòng thủ phía trước của từng tổ chức không thể đối phó, nên lưu lượng được chuyển hướng tới các trung tâm lọc sạch quy mô lớn do nhà mạng, chính phủ (ví dụ: 'DDoS Cyber Shelter' của Cơ quan Internet và An ninh Hàn Quốc KISA) và nhà cung cấp đám mây vận hành để hấp thụ và lọc sạch thay. Tức là reverse proxy và nơi trú ẩn mạng không phải là công nghệ loại trừ nhau, mà là các tầng bổ trợ đảm nhận thu hẹp bề mặt tấn công (thời bình) và hấp thụ, lọc sạch dung lượng lớn (khi khẩn cấp).

B. Bối cảnh ra đời và sự cần thiết

Web là bộ mặt của tổ chức và là tài sản bị phơi nhiễm nhiều nhất. Không chỉ các tấn công ứng dụng như OWASP, SQLi, XSS mà DDoS theo từng tầng — volumetric (làm cạn băng thông), giao thức (TCP SYN Flood), ứng dụng (HTTP GET/POST Flood) — đều là mối đe dọa thường trực. Đặc biệt, tình huống botnet Mirai (2016, tối đa khoảng 1.2Tbps, làm tê liệt nhà cung cấp DNS Dyn) cùng xu hướng các tấn công dựa trên IoT ngày càng lớn sau đó, và các DDoS ứng dụng kiểu mới như HTTP/2 Rapid Reset (CVE-2023-44487, năm 2023 với hàng trăm triệu yêu cầu mỗi giây) đã bộc lộ giới hạn của "phòng thủ đơn lẻ phía trước". Do đó, phòng thủ theo chiều sâu (Defense in Depth) kết hợp phân tầng ① reverse proxy che giấu và chuyển tiếp máy chủ, ② WAF lọc tấn công web, ③ nơi trú ẩn mạng/CDN hấp thụ dung lượng lớn đã trở thành phương thức vận hành chuẩn.

2. Tổng quan cấu trúc phòng thủ

Trước hết, dùng sơ đồ cấu trúc để nhìn tổng thể cách các tầng bảo mật máy chủ web ăn khớp với nhau, sau đó xem xét các thành phần chi tiết từ góc nhìn quy trình.

flowchart LR
  C["Client<br/>(người dùng bình thường)"] --> E["Tầng biên<br/>(CDN·trung tâm lọc)"]
  B["Botnet<br/>(nguồn tấn công DDoS)"] --> E
  E --> RP["Reverse proxy<br/>(che giấu·cân bằng tải·SSL·lưu đệm)"]
  RP --> WAF["WAF<br/>(chặn tấn công ứng dụng)"]
  WAF --> W1["Máy chủ web 1<br/>(máy chủ gốc·được che giấu)"]
  WAF --> W2["Máy chủ web 2<br/>(máy chủ gốc·được che giấu)"]
  E -. "Lọc sạch·chặn lưu lượng độc hại" .-> X["Loại bỏ<br/>(scrubbing)"]
  style E fill:#fde8e8,stroke:#d64545,stroke-width:2px
  style RP fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style WAF fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

Cốt lõi của cấu trúc này là đa tầng hóa các cửa ải. Lưu lượng càng đi từ ngoài vào trong thì càng qua lối đi hẹp và tinh lọc hơn. Tầng biên (CDN, trung tâm lọc) hấp thụ và loại bỏ trước tiên các tấn công volumetric dung lượng lớn, reverse proxy che giấu máy chủ và phân tán tải, WAF chặn các yêu cầu độc hại ở tầng ứng dụng, rồi mới tới được máy chủ gốc. Mỗi tầng chuyên biệt hóa cho mối đe dọa mà nó chặn tốt nhất, nên dù một tầng bị xuyên thủng thì tầng tiếp theo vẫn tiếp tục phòng thủ.

3. Reverse proxy

A. Nguyên lý hoạt động

Reverse proxy "đại diện cho máy chủ", ngược hẳn với forward proxy đại diện cho client. Nhìn từ bên ngoài, proxy chính là máy chủ web, còn máy chủ gốc thực sự ẩn sau proxy. Các hiện thực tiêu biểu là Nginx, HAProxy, Envoy, Apache (mod_proxy); trên đám mây, AWS ALB, GCP Cloud Load Balancing… đảm nhận vai trò tương tự. Khi yêu cầu đến, proxy kết thúc TLS (giải mã), kiểm tra header, đường dẫn, phương thức, rồi trả lời ngay nội dung tĩnh từ bộ đệm và chỉ định tuyến các yêu cầu động tới máy chủ phía sau.

sequenceDiagram
  participant C as Client
  participant RP as Reverse proxy
  participant Cache as Bộ đệm
  participant W as Máy chủ gốc (được che giấu)
  C->>RP: Yêu cầu HTTPS (TLS)
  RP->>RP: Kết thúc TLS·kiểm tra header/đường dẫn·bộ lọc WAF
  alt Trúng bộ đệm nội dung tĩnh
    RP->>Cache: Tra cứu
    Cache-->>RP: Phản hồi đã lưu đệm
    RP-->>C: Phản hồi ngay (không chạm máy chủ gốc)
  else Yêu cầu động
    RP->>W: Chuyển qua mạng nội bộ (cân bằng tải)
    W-->>RP: Phản hồi
    RP->>Cache: (khi cần) lưu đệm
    RP-->>C: Phản hồi
  end

B. Che giấu máy chủ và thu hẹp bề mặt tấn công

Hiệu quả bảo mật bản chất nhất mà reverse proxy mang lại là che giấu máy chủ gốc. Client chỉ biết IP của proxy, không biết địa chỉ thực, số lượng, hệ điều hành, phiên bản middleware của máy chủ gốc. Kẻ tấn công khó xác định mục tiêu, và độ khó của quét cũng như tấn công trực tiếp vào lỗ hổng tăng lên đáng kể. Trong thực tế, máy chủ gốc được đặt ở dải IP riêng, và tường lửa chỉ cho phép yêu cầu đến từ proxy (danh sách trắng), chặn tận gốc việc truy cập vòng. Loại bỏ banner máy chủ, trang lỗi, header phản hồi (Server, X-Powered-By) tại proxy cũng giảm lộ lọt thông tin.

C. Cân bằng tải, hiệu năng, kết thúc SSL

Reverse proxy phân phối yêu cầu tới nhiều máy chủ gốc (round-robin, ít kết nối nhất, IP hash) để ngăn quá tải một máy chủ, và khi một máy chủ chết thì phát hiện qua health check và tự động cách ly. Điều này đồng thời nâng cao tính sẵn sàng và năng lực phòng thủ. Ngoài ra, nếu proxy đảm nhận kết thúc TLS (SSL Offloading), máy chủ gốc giảm được gánh nặng tính toán mã hóa/giải mã, và việc quản lý chứng chỉ cũng tập trung một nơi. Xử lý lưu đệm nội dung tĩnh và nén gzip/Brotli ở phía trước có thể giảm lưu lượng tới máy chủ gốc đến vài chục phần trăm, bản thân nó đã đóng vai trò đệm trước các tấn công gây tải mức độ vừa phải.

D. Lọc bảo mật (liên kết WAF)

Reverse proxy kết hợp với WAF (Web Application Firewall) để lọc các tấn công ứng dụng như SQL injection, XSS, duyệt đường dẫn bằng chữ ký và luật (ví dụ: OWASP ModSecurity Core Rule Set). Giới hạn tốc độ (Rate Limiting), chặn theo vùng (GeoIP), phát hiện bot cũng được thực hiện ở tầng proxy, đảm nhận giảm nhẹ bước đầu DDoS tầng ứng dụng (HTTP Flood).

4. Nơi trú ẩn mạng chống DDoS

A. Các loại DDoS theo tầng

DDoS có bản chất và cách phòng thủ khác nhau tùy tầng tấn công. Tấn công volumetric (UDP/ICMP Flood, khuếch đại DNS·NTP) làm cạn chính băng thông, đạt từ vài trăm Gbps đến Tbps mỗi giây. Tấn công giao thức (SYN Flood, ACK Flood) làm cạn bảng trạng thái kết nối của máy chủ, tường lửa. Tấn công ứng dụng (HTTP GET/POST Flood, Slowloris, HTTP/2 Rapid Reset) dù băng thông nhỏ vẫn giả dạng yêu cầu bình thường để làm cạn tài nguyên máy chủ nên khó phát hiện nhất. Nơi trú ẩn mạng đặc biệt mạnh ở khả năng hấp thụ dung lượng lớn các tấn công volumetric và giao thức mà từng tổ chức không thể tự chống đỡ.

B. Nguyên lý chuyển hướng và lọc sạch lưu lượng

Hoạt động của nơi trú ẩn mạng gồm ba bước. ① Chuyển hướng (Diversion): khi phát hiện tấn công, lưu lượng được dẫn vào trung tâm lọc bằng thay đổi DNS (đổi bản ghi A của tên miền sang IP của nơi trú ẩn) hoặc thay đổi định tuyến BGP (quảng bá đường đi của dải IP bị tấn công về nơi trú ẩn). ② Lọc sạch (Scrubbing): trung tâm lọc nhận diện lưu lượng botnet bằng chữ ký, phân tích hành vi, danh tiếng (Reputation), thử thách (ví dụ: JS/CAPTCHA) rồi loại bỏ, chỉ giữ lại lưu lượng bình thường. ③ Chuyển lại (Re-injection): chỉ lưu lượng bình thường đã tinh lọc được gửi trở lại máy chủ gốc qua đường hầm GRE, kênh thuê riêng…

flowchart TB
  subgraph NORMAL["Thời bình (Off-ramp)"]
    C1["Lưu lượng bình thường"] --> W1["Máy chủ web"]
  end
  subgraph ATTACK["Khi xảy ra tấn công"]
    A["Lưu lượng hỗn hợp<br/>tấn công lớn+bình thường"] --> D["Chuyển hướng<br/>(thay đổi DNS/BGP)"]
    D --> SC["Trung tâm lọc<br/>(Scrubbing)"]
    SC -->|"Loại bỏ độc hại"| X["Chặn"]
    SC -->|"Chỉ chuyển lại lưu lượng bình thường"| W2["Máy chủ web"]
  end
  style SC fill:#fde8e8,stroke:#d64545,stroke-width:2px

C. Nơi trú ẩn mạng tại Hàn Quốc và hệ thống vận hành

Tại Hàn Quốc, KISA cung cấp miễn phí 'DDoS Cyber Shelter' cho các doanh nghiệp vừa và nhỏ…, liên kết trước tên miền trong thời bình rồi khi xảy ra tấn công thì chuyển hướng lưu lượng tới nơi trú ẩn để lọc sạch. Các nhà mạng (KT, SK Broadband…) và nhà cung cấp đám mây, CDN (Cloudflare, AWS Shield, Akamai Prolexic…) cũng vận hành dịch vụ scrubbing thương mại. Cốt lõi là chuẩn bị trước. Nếu đến khi tấn công bắt đầu mới vội vàng liên kết thì dịch vụ đã tê liệt, nên phải thiết lập sẵn liên kết DNS/BGP, danh sách trắng, ngưỡng lưu lượng bình thường (baseline) trong thời bình và diễn tập để có thể chuyển đổi nhanh.

5. Chuyên sâu — Phòng thủ tích hợp đám mây/CDN và xu hướng mới nhất

Gần đây, trọng tâm phòng thủ đang chuyển từ thiết bị tại chỗ (on-premise) sang biên đám mây/CDN. Các nhà cung cấp như Cloudflare, Akamai, AWS (CloudFront+Shield Advanced), Fastly cung cấp reverse proxy, WAF, lọc sạch DDoS, lưu đệm CDN như một dịch vụ tích hợp tại các POP (Point of Presence) biên quy mô lớn phân tán khắp thế giới. Vì lưu lượng được hấp thụ và lọc sạch ở biên gần người dùng, tấn công volumetric dung lượng lớn được xử lý phân tán trước khi tới gần máy chủ gốc. Các nhà cung cấp quảng bá năng lực lọc sạch quy mô hàng chục Tbps, và thực tế trong các tấn công thuộc họ HTTP/2 Rapid Reset (CVE-2023-44487) năm 2023–2024 đã có báo cáo về việc chặn hàng trăm triệu yêu cầu mỗi giây tại biên (số liệu cụ thể dựa trên tài liệu công khai của nhà cung cấp và có thể thay đổi theo thời điểm).

Đồng thời, phòng thủ tầng ứng dụng ngày càng tinh vi. Phát hiện lưu lượng bất thường dựa trên AI/học máy, quản lý bot (Bot Management) phân biệt bot hợp lệ (công cụ tìm kiếm) với bot độc hại, và kết hợp với Zero Trust, SASE đang tăng cường nguyên tắc "chỉ cho phép truy cập máy chủ gốc từ biên tin cậy". Ngoài ra, để ngăn sự cố IP máy chủ gốc bị lộ qua lịch sử DNS cũ hoặc cấu hình sai khiến biên bị vượt qua, 'che giấu nguồn gốc (Origin Cloaking)' — buộc tường lửa máy chủ gốc chỉ cho phép dải CDN/proxy — đã trở thành thực tiễn vận hành mẫu mực.

6. Lưu ý và hàm ý (góc nhìn Kỹ sư chuyên nghiệp)

1. Kết hợp phòng thủ đa tầng và phân chia vai trò theo tầng: Phòng thủ tại một điểm duy nhất chắc chắn sẽ bị xuyên thủng. Cần kết hợp phân tầng biên (hấp thụ volumetric), reverse proxy (che giấu, cân bằng tải), WAF (tấn công ứng dụng), nơi trú ẩn mạng (lọc sạch dung lượng lớn), nhưng thiết kế để mỗi tầng đảm nhận mối đe dọa chuyên biệt mà không trùng lặp. Đây vừa là vấn đề đào sâu phòng thủ, vừa là vấn đề tối ưu nút thắt và chi phí.

2. Chuẩn bị thời bình và chuyển đổi nhanh (tối thiểu hóa RTO): Với nơi trú ẩn mạng và scrubbing, tốc độ chuyển hướng sau khi tấn công xảy ra quyết định quy mô thiệt hại. Trong thời bình cần chuẩn bị rút ngắn TTL DNS, liên kết BGP, baseline và ngưỡng lưu lượng bình thường, danh sách trắng, đồng thời diễn tập định kỳ. Then chốt là tự động hóa (orchestration) chuỗi phát hiện-chuyển hướng-lọc sạch để giảm độ trễ do con người can thiệp.

3. Đánh đổi giữa báo động sai (False Positive) và trải nghiệm người dùng: Tăng cường độ lọc thì cả người dùng bình thường cũng bị thử thách, chặn và rời bỏ. Ngược lại nới lỏng thì tấn công lọt vào. Cần tinh chỉnh luật phù hợp đặc tính ứng dụng (mẫu lưu lượng đăng nhập, thanh toán) và thiết kế cân bằng để giảm thiểu ma sát người dùng của CAPTCHA, thử thách JS.

4. Quản lý rủi ro vượt biên (Origin Exposure): Dù bọc bằng CDN, proxy đến đâu, nếu IP máy chủ gốc bị lộ thì kẻ tấn công sẽ bỏ qua biên để đánh trực tiếp. Phải buộc tường lửa máy chủ gốc chỉ cho phép dải CDN/proxy, và định kỳ kiểm tra các đường rò rỉ IP qua lịch sử DNS cũ, tên miền phụ, máy chủ thư.

5. Cân bằng chi phí, hiệu năng và chủ quyền (Sovereignty): Phòng thủ tích hợp trên đám mây rất mạnh nhưng kèm theo vấn đề chi phí lưu lượng, phụ thuộc (lock-in), chủ quyền dữ liệu. Cần chiến lược kiến trúc phù hợp tính chất dịch vụ, chẳng hạn lĩnh vực nhạy cảm với chuyển dữ liệu ra nước ngoài như công quyền, tài chính thì chọn tổ hợp trung tâm lọc và reverse proxy trong nước, còn dịch vụ toàn cầu thì chọn phòng thủ biên CDN.

Tài liệu tham khảo

• KISA Boho.or.kr, hướng dẫn dịch vụ DDoS Cyber Shelter: https://www.boho.or.kr/
• Cloudflare Learning Center, "What is a reverse proxy?": https://www.cloudflare.com/learning/cdn/glossary/reverse-proxy/
• Cloudflare, phân tích HTTP/2 Rapid Reset (CVE-2023-44487): https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• OWASP ModSecurity Core Rule Set (CRS): https://coreruleset.org/
• AWS, "AWS Best Practices for DDoS Resiliency": https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/

Tóm tắt một câu: Bảo mật máy chủ web dùng reverse proxy để che giấu và bảo vệ máy chủ gốc (cân bằng tải, kết thúc SSL, lưu đệm, lọc WAF), còn DDoS dung lượng lớn thì chuyển hướng và lọc sạch lưu lượng qua nơi trú ẩn mạng/trung tâm scrubbing (chuyển DNS/BGP → loại bỏ botnet → chuyển lại lưu lượng bình thường), kết hợp phòng thủ đa tầng với biên, CDN, Zero Trust để thu hẹp bề mặt tấn công thời bình và hấp thụ dung lượng lớn khi khẩn cấp, hiện thực dịch vụ ổn định.