---
id: case-ddos
title: "Xử lý khi bị DDoS"
shortTitle: "DDoS"
track: cases
trackTitle: "Tình huống vận hành"
order: 16
level: core
status: published
estimatedMinutes: 35
prerequisites:
  - case-outage
next: case-cloudflare
reviewedAgainst: 2026-10-12
sources:
  - title: "Cloudflare DDoS protection"
    url: https://developers.cloudflare.com/ddos-protection/
  - title: "Under Attack mode"
    url: https://developers.cloudflare.com/fundamentals/reference/under-attack-mode/
  - title: "Azure DDoS Protection overview"
    url: https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview
---

# Xử lý khi bị DDoS

DDoS là khi lượng request hoặc gói tin quá lớn khiến dịch vụ không còn phục vụ được user thật. Bài này hướng dẫn ứng phó khi bạn đang bị tấn công, không hướng dẫn cách tấn công. Không có lệnh nào ở đây dùng để tấn công máy khác.

## Để làm gì

Bạn cần tách traffic bất thường ra khỏi một đợt tăng traffic hợp lệ, chặn ở lớp biên, và không để origin phải gánh toàn bộ. Nếu gói tin vẫn tới thẳng máy của bạn, scale vô hạn chỉ làm hóa đơn tăng.

## Gồm những gì

- Dấu hiệu phân biệt spike hợp lệ với traffic xấu.
- Việc cần làm ở CDN, WAF, rate limit và firewall của origin.
- Under Attack mode là biện pháp tạm thời, và có hại cho user thật.

Bài không đề cập tới cấu hình botnet, kỹ thuật khuếch đại hay công cụ tấn công.

## Dùng khi nào

Băng thông, số connection hoặc số request tăng đột ngột. CPU của origin đầy. User thật bị timeout. Log toàn một user-agent, một path, hoặc rất nhiều IP lạ.

Một đợt user tăng vì có bài báo dẫn link sẽ trông khác: có referrer, nhiều path khác nhau, có cookie và hành vi đọc trang bình thường. Đừng bật chế độ chặn mạnh chỉ vì thấy đồ thị đi lên.

## Kiến thức cốt lõi

Có hai lớp tấn công hay bị gộp làm một:

| Lớp | Bạn thấy | Chỗ chặn |
| --- | --- | --- |
| Volumetric, nhiều gói tin | Đường mạng đầy trước khi app kịp log | Nhà mạng và dịch vụ DDoS phía trước. Origin không nuốt được |
| Application, nhiều HTTP | Access log tăng, một số path như `/login` hoặc search | CDN, WAF, rate limit, cache |

Trước khi chặn, hãy xác nhận đây là tấn công: error rate và latency của user thật có tăng không, và traffic mới có hình dạng của user thật hay không. Nếu error rate không đổi và referrer đa dạng, nhiều khả năng đây là spike hợp lệ.

Khi đã xác nhận, làm theo thứ tự:

1. Kiểm tra origin có đang nhận traffic trực tiếp không. Bước này đứng đầu vì nếu IP máy chủ đã lộ, attacker bỏ qua Cloudflare và đánh thẳng vào origin, khi đó mọi rule ở biên đều vô ích. Cấu hình firewall của origin chỉ nhận dải IP của CDN, hoặc chỉ nhận kết nối đã xác thực.
2. Cache nội dung tĩnh. Request nào trúng cache thì không tới app.
3. Rate limit các path tốn tài nguyên: đăng nhập, quên mật khẩu, search, API không có cache. Chỉ limit theo IP là không đủ nếu attack dùng nhiều IP; hãy kết hợp path, ASN và rule WAF của nhà cung cấp.
4. Under Attack mode của Cloudflare hiện JS challenge cho visitor. Docs của Cloudflare nói đây là chế độ tạm thời. User gọi API, app mobile và health check có thể gãy. Bật khi đang bị tấn công, tắt khi đã hết, đừng để cả tháng.
5. Gọi nhà cung cấp nếu đường mạng đã đầy. Azure DDoS Protection và các dịch vụ tương đương xử lý volumetric ở tầng mạng. App của bạn không thể tự chặn loại này bằng một câu `if` trong code.
6. Duy trì một trang trạng thái đặt ở nơi khác origin, để user biết đang có sự cố.

Những việc không nên làm:

- Mở autoscale không có trần. Mỗi instance mới là thêm tiền, trong khi attack vẫn lấp đầy chúng.
- Tắt hẳn logging. Bạn cần mẫu request để viết rule. Có thể bớt log body, nhưng đừng tắt access log.
- Chặn nguyên cả một quốc gia có khách hàng của bạn chỉ vì một đồ thị. Rule sai làm mất doanh thu không kém gì chính cuộc tấn công.

Bạn coi là đã kiểm soát được khi error rate và latency của user thật về lại mức bình thường, và CPU của origin hạ xuống trong khi traffic ở biên vẫn cao. Khi đó lượng request xấu đã bị chặn trước khi tới origin.

Sau sự cố, giữ lại những rule vẫn đúng, gỡ những rule quá rộng, và kiểm tra xem IP origin có còn lộ trong lịch sử DNS hoặc trong repo không.

## Lệnh và code mẫu

Đếm nhanh mẫu trong access log của lab. Đừng chạy lệnh này trên file log của người khác:

```bash
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
```

Path nào tăng đột biến là ứng viên để đặt rate limit. Lệnh này chỉ đọc file mà bạn đã có quyền. Nếu không có file, bỏ qua bước này, đừng tự tạo traffic để có log.

Trên Cloudflare, Under Attack mode được bật trong dashboard hoặc qua API của zone. Không có lệnh local nào thay được việc đó. Hãy đọc trang Under Attack mode trước khi bật trên một zone đang có user.

## Thực hành

1. Đồ thị request tăng gấp 20 lần sau khi một bài viết được chia sẻ, referrer đa dạng, error rate không đổi. Giải thích vì sao chưa nên gọi đó là DDoS.
2. `/login` tăng mạnh, POST lặp đi lặp lại, không có cookie hợp lệ. Viết ra tầng cần chặn: rate limit và WAF ở biên, không phải thêm Pod vô hạn.
3. Origin vẫn quá tải dù Cloudflare đã bật. Viết giả thuyết: IP origin đã lộ, và firewall chưa chặn các nguồn không phải CDN.

## Kết quả mong đợi

Bạn có ít nhất một biện pháp ở biên và một biện pháp khóa origin. Bạn không dùng scale làm biện pháp duy nhất.

## Checklist

- [ ] Phân biệt được spike hợp lệ với một path bị gọi lặp.
- [ ] Cache nội dung public; không cache response có cookie đăng nhập.
- [ ] Origin không nhận HTTP từ cả Internet khi đã có CDN.
- [ ] Under Attack mode có giờ tắt cụ thể.
- [ ] Autoscale có trần.

## Lỗi thường gặp

**Chỉ thêm replica.** Attack ở tầng application vẫn tới được từng Pod, và bạn hết tiền trước khi attacker hết request. Hãy chặn ở CDN và đặt trần cho scale.

**Để nguyên chế độ challenge.** User thật và cả monitor đều bị challenge, sinh ra alert giả. Hãy tắt khi request xấu đã giảm, và giữ lại rate limit ở phạm vi hẹp hơn.

**Chặn IP ngay trong ứng dụng bằng một danh sách dài.** Mỗi request tốn CPU để so với danh sách, đúng vào lúc bạn đang thiếu CPU. Hãy để danh sách ở firewall hoặc WAF phía trước process app.

## Nguồn

1. [Cloudflare DDoS protection](https://developers.cloudflare.com/ddos-protection/) — lớp bảo vệ phía trước origin.
2. [Under Attack mode](https://developers.cloudflare.com/fundamentals/reference/under-attack-mode/) — challenge tạm thời và hệ quả với visitor.
3. [Azure DDoS Protection overview](https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview) — bảo vệ volumetric ở tầng mạng.

## Tiếp theo

[Cloudflare đứng trước app](./17-cloudflare.md)