Khi báo một đợt tấn công, điều đầu tiên hay được hỏi là “lưu lượng bao nhiêu”. Phần lớn câu trả lời là một con số Gbps. Con số đó cần thiết nhưng không đủ, và nhiều đợt tấn công gây thiệt hại nặng lại có số Gbps rất nhỏ.

Bài này giải thích ba con số thật sự quyết định, và cách đo chúng trên máy của quý Khách hàng.

1. Ba con số, ba kiểu tấn công khác nhau

Ba con số này không tỷ lệ với nhau. Đây là chỗ gây nhầm nhiều nhất.

Hai ví dụ cho thấy vì sao:

Đợt A: 20 Gbps, gói tin cỡ lớn. Nhìn con số thì đáng sợ, nhưng đây là kiểu dễ nhận và dễ lọc nhất, vì nội dung gói tin vô nghĩa và chặn được ở lớp mạng trước khi tới máy chủ. Đợt B: 0,2 Gbps, nhưng là hàng chục nghìn lượt gọi mỗi giây vào trang tìm kiếm. Con số băng thông nhỏ tới mức không ai để ý, nhưng mỗi lượt gọi làm cơ sở dữ liệu chạy một truy vấn nặng. Máy chủ sập trong vài phút.

Đợt B khó hơn đợt A, dù số Gbps nhỏ hơn một trăm lần. Lý do: lưu lượng ấy trông giống khách thật, nên không chặn được bằng cách lọc đơn giản.

Nên khi báo sự việc, gửi đủ cả ba con số. Chỉ gửi Gbps thì bên nhận chưa biết đang đối phó với loại nào.

2. Đo bps: khối lượng dữ liệu

# Can goi sysstat
# Lay mau moi giay, 10 lan, tren moi card mang
sar -n DEV 1 10

Kết quả cho hai cột đáng chú ý:

Đổi sang Gbps: lấy rxkB/s nhân 8 rồi chia một triệu.

Không có sar thì đo bằng công cụ có sẵn:

# Doc hai lan cach nhau 1 giay roi tru. Thay eth0 bang ten card mang that
# Xem ten card mang: ip -br link
C=eth0
A=$(cat /sys/class/net/$C/statistics/rx_bytes)
sleep 1
B=$(cat /sys/class/net/$C/statistics/rx_bytes)
echo "nhan vao: $(( (B - A) * 8 / 1000000 )) Mbps"

⚠️ Giới hạn quan trọng: con số đo trên máy chủ là lưu lượng đã tới được máy. Khi đường truyền bị nghẽn, phần lớn lưu lượng tấn công bị chặn hoặc rơi ở trước đó, nên máy chủ thấy con số nhỏ hơn thực tế rất nhiều. Số đo thật của đợt tấn công nằm ở lớp mạng, và đó là số Cloudzone đo được.

Nói cách khác: máy chủ đo thấy 0,5 Gbps không có nghĩa đợt tấn công chỉ 0,5 Gbps. Nó có thể nghĩa là đường truyền đã đầy và phần còn lại không vào được, kể cả lưu lượng của khách thật.

3. Đo pps: số gói tin

Đây là con số bị bỏ qua nhiều nhất, và là con số làm thiết bị mạng quá tải.

sar -n DEV 1 10

Hai cột cần nhìn:

Hoặc không có sar:

C=eth0
A=$(cat /sys/class/net/$C/statistics/rx_packets)
sleep 1
B=$(cat /sys/class/net/$C/statistics/rx_packets)
echo "goi tin nhan vao: $(( B - A )) pps"

Cách đọc: chia rxkB/s cho rxpck/s để biết kích cỡ gói tin trung bình.

Vì sao gói tin nhỏ lại nguy hiểm hơn: thiết bị mạng và nhân hệ điều hành xử lý theo từng gói. Mỗi gói đều phải được xem xét, dù nó chứa 40 byte hay 1500 byte. Nên một triệu gói nhỏ mỗi giây tốn sức xử lý hơn nhiều so với cùng khối lượng dữ liệu đóng trong các gói lớn.

Cũng kiểm số gói bị rơi:

ip -s link show eth0

Dòng RX: ... dropped khác không và đang tăng là dấu hiệu máy không kịp xử lý lượng gói tin đang vào.

4. Đo cps và rps: số kết nối và số yêu cầu

Số kết nối đang mở, theo trạng thái:

ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn

Các trạng thái đáng chú ý:

Rất nhiều SYN-RECV là một trong vài dấu hiệu gần như kết luận được ngay: trong trao đổi bình thường, trạng thái này chỉ tồn tại vài phần nghìn giây.

Số yêu cầu mỗi giây vào ứng dụng web:

# Dem so dong nhat ky trong mot phut gan nhat roi chia 60
# Thay dinh dang ngay cho dung may cua ban: xem mot dong bang
#   tail -1 /var/log/nginx/access.log
awk -v moc="$(date -d '1 minute ago' '+%d/%b/%Y:%H:%M')" \
    '$4 ~ moc' /var/log/nginx/access.log | wc -l

Hoặc đơn giản hơn, đếm theo từng giây để thấy mức cao nhất:

awk '{print substr($4, 2, 20)}' /var/log/nginx/access.log \
  | uniq -c | sort -rn | head -10

Lệnh này cho mười giây có nhiều yêu cầu nhất trong cả tệp nhật ký, kèm con số. Đây chính là rps ở lúc cao điểm.

5. Gửi gì cho Cloudzone

Bảng này điền xong là đủ để bên kỹ thuật biết đang đối phó loại nào.

Cột “lúc bình thường” là cột quan trọng nhất và cũng là cột hay bị để trống. Không có nó thì con số bên phải không nói lên điều gì: 5000 yêu cầu mỗi giây là tấn công với một website nội bộ, nhưng là một buổi chiều bình thường với một sàn thương mại.

Vì vậy hãy đo và lưu cột bên trái ngay hôm nay, lúc hệ thống còn bình thường.

Kèm thêm:

• Thời điểm bắt đầu, càng chính xác càng tốt.
• Hai mươi địa chỉ gọi nhiều nhất và hai mươi đường dẫn bị gọi nhiều nhất, xem bài “Phân biệt bị tấn công DDoS với quá tải do chính hệ thống”.
• Dịch vụ nào bị ảnh hưởng và biểu hiện ra sao: chậm, hay không vào được hẳn.

6. Ba con số còn cho biết tấn công nhắm vào lớp nào

Đây là cách dùng ba con số để suy ra lớp bị nhắm, từ đó biết việc xử lý nằm ở đâu.

Hàng cuối là hàng cần phối hợp nhiều nhất. Lưu lượng ở đó là các yêu cầu hợp lệ về mặt giao thức, nên phân biệt được hay không phụ thuộc vào hiểu biết về chính ứng dụng: đường dẫn nào khách thật hay gọi, gọi với nhịp nào, tham số nào là hợp lý. Đó là thông tin chỉ phía quý Khách hàng có.

7. Khi cần hỗ trợ

Nhắn qua khung chat ở góc phải màn hình, gửi bảng ở mục 5. Đang trong lúc sự cố thì cứ gửi phần nào có trước, không cần chờ điền đủ.

Hai bài liên quan:

• “Phân biệt bị tấn công DDoS với quá tải do chính hệ thống” để xác định có đúng là tấn công không.
• “Nghi bị tấn công DDoS: cần làm gì và báo gì cho Cloudzone” cho các bước xử lý.