Hệ thống chậm hẳn hoặc không truy cập được. Câu hỏi đầu tiên không phải “chống đỡ thế nào” mà “có đúng là bị tấn công không”. Trả lời sai câu này thì mọi việc sau đó đi lệch hướng, và mất thêm thời gian trong lúc dịch vụ đang dừng.

Bài này đưa ra cách phân biệt dựa trên số đo, không dựa trên cảm nhận.

1. Vì sao câu hỏi này quan trọng

Hai loại sự cố, hai cách xử lý ngược nhau:

Đưa một đợt quá tải nội bộ qua lớp chống tấn công thì lưu lượng vẫn tới, vì nó là lưu lượng thật. Ngược lại, thêm máy chủ cho một đợt tấn công thật chỉ là trả thêm tiền để bị đánh sập chậm hơn một chút.

2. Bốn trường hợp thường gặp, không chỉ hai

Thực tế không chỉ có “bị đánh” hay “tự quá tải”. Có bốn trường hợp, và hai trường hợp giữa hay bị nhận lầm là tấn công:

Trường hợp thứ hai và thứ ba không phải tấn công, nhưng cũng làm dịch vụ không truy cập được. Xử lý chúng như tấn công là chặn mất khách thật.

3. Bước một: lưu lượng vào có tăng không

Đây là câu hỏi phân nhánh quan trọng nhất. Lưu lượng không tăng mà hệ thống vẫn chậm thì gần như chắc chắn không phải tấn công.

# Luu luong tren card mang, lay mau moi giay
# Can goi iproute2 va sysstat
sar -n DEV 1 10

# Hoac xem nhanh, lap lai hai lan roi tru
cat /proc/net/dev

Xem số kết nối đang mở:

# Dem ket noi theo trang thai
ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn

# Dem ket noi theo dia chi nguon, 20 dia chi nhieu nhat
ss -ant | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Cách đọc kết quả lệnh cuối:

4. Bước hai: lưu lượng tăng, nhưng của ai

Lưu lượng có tăng thì chưa kết luận được. Phải xem nó trông như thật hay không.

Đếm theo địa chỉ trong nhật ký máy chủ web:

# Hai muoi dia chi goi nhieu nhat trong nhat ky
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Hai muoi duong dan bi goi nhieu nhat
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Dau nhan dang trinh duyet, xem co giong nhau bat thuong khong
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -15

Trên Apache, đổi đường dẫn thành /var/log/apache2/access.log hoặc /var/log/httpd/access_log.

Bốn dấu hiệu cho thấy lưu lượng không phải khách thật:

1. Dấu nhận dạng trình duyệt giống hệt nhau trên hàng nghìn yêu cầu, hoặc để trống, hoặc là tên một thư viện lập trình.
2. Yêu cầu tập trung vào đúng một đường dẫn, thường là trang tìm kiếm, trang đăng nhập, hoặc một đường dẫn không tồn tại.
3. Không tải tài nguyên kèm theo. Khách thật mở một trang thì tải theo hàng chục tệp ảnh, kiểu chữ, mã lệnh. Rô bốt chỉ gọi đúng trang đó.
4. Phân bố theo vùng bất thường so với tập khách hàng thật.

Ngược lại, bốn dấu hiệu cho thấy lưu lượng là thật:

1. Dấu nhận dạng trình duyệt đa dạng, đúng tỷ lệ các loại thiết bị quen thấy.
2. Có tải tài nguyên kèm theo, tỷ lệ gần như mọi khi.
3. Đường dẫn đa dạng, giống thói quen bình thường.
4. Có lý do giải thích được: vừa chạy quảng cáo, vừa gửi thư hàng loạt, có bài được chia sẻ nhiều.

Dấu hiệu thứ tư ở nhóm sau là dấu hiệu bị bỏ qua nhiều nhất. Trước khi kết luận bị tấn công, hãy hỏi bộ phận kinh doanh và bộ phận nội dung xem hôm nay có chiến dịch gì không.

5. Khi lưu lượng không tăng: tìm chỗ nghẽn bên trong

Lưu lượng bình thường mà hệ thống vẫn chậm thì nguyên nhân nằm bên trong. Bốn chỗ cần soi, theo thứ tự này.

a. CPU

top -bn1 | head -20

Một tiến trình chiếm gần hết CPU thì đó là manh mối. Hay gặp: một truy vấn cơ sở dữ liệu thiếu chỉ mục, một tác vụ theo lịch chạy trùng giờ cao điểm, một vòng lặp trong mã nguồn vừa triển khai.

b. Đĩa

iostat -x 5 3
# Hoac xem tien trinh nao doc ghi nhieu
sudo iotop -o

await cao kèm %util gần một trăm nghĩa là đĩa đang nghẽn. Thường vì nhật ký ghi quá nhiều, hoặc cơ sở dữ liệu phải đọc cả bảng.

c. RAM và phần đổi ra đĩa

free -h
vmstat 5 5

Nếu cột si và so trong vmstat khác không liên tục thì hệ thống đang đổi dữ liệu ra đĩa. Đây là nguyên nhân làm chậm rất nặng mà nhìn vào CPU không thấy.

d. Cơ sở dữ liệu

-- MySQL, MariaDB: xem truy van dang chay
SHOW FULL PROCESSLIST;

-- PostgreSQL
SELECT pid, now() - query_start AS chay_bao_lau, state, query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY chay_bao_lau DESC;

Thấy truy vấn chạy hàng chục giây, hoặc nhiều truy vấn cùng chờ nhau, thì đây là chỗ nghẽn. Trường hợp này thêm tài nguyên chỉ giúp tạm thời, phải sửa truy vấn hoặc thêm chỉ mục.

Một nguyên nhân đơn giản hay bị bỏ sót: hết chỗ trên đĩa. Đầy đĩa làm nhiều phần mềm hỏng theo cách rất khó hiểu.

df -h
df -i   # het so luong tep cung gay loi tuong tu

6. Bảng tra nhanh

Dùng bảng này trong lúc đang có sự cố.

7. Việc nên làm trước, lúc hệ thống còn bình thường

Việc phân biệt ở trên chỉ nhanh nếu có số liệu nền để so. Không biết lúc bình thường lưu lượng là bao nhiêu thì không biết hôm nay có bất thường hay không.

Ba việc đáng làm ngay khi chưa có sự cố:

Ghi mức nền không cần hệ thống giám sát phức tạp. Chạy vài lệnh ở mục 3 và mục 4 vào một ngày bình thường, lưu kết quả lại kèm ngày tháng, là đã có cái để so.

8. Khi cần hỗ trợ

Chưa phân biệt được là loại nào, hãy nhắn qua khung chat ở góc phải màn hình và gửi kèm:

1. Kết quả sar -n DEV 1 10 hoặc số liệu lưu lượng của card mạng.
2. Kết quả lệnh đếm kết nối theo địa chỉ ở mục 3.
3. Hai mươi dòng đầu của hai lệnh đếm nhật ký ở mục 4.
4. Thời điểm bắt đầu có hiện tượng.
5. Có thay đổi gì trên hệ thống trong hai mươi bốn giờ trước đó không: triển khai mã mới, đổi cấu hình, chạy chiến dịch.

Thông tin thứ năm thường giải quyết được sự việc nhanh hơn bốn thông tin đầu cộng lại.

Nếu đã xác định là tấn công thì xem bài “Nghi bị tấn công DDoS: cần làm gì và báo gì cho Cloudzone” để biết gửi gì và chờ gì.