DDOS - TƯ DUY PHÒNG THỦ

Khi nói đến an ninh mạng, phần lớn chúng ta sẽ nghĩ ngay đến những Hacker với
những pha tấn công “nghẹt thở” kèm theo những sự ngưỡng mộ nhất định. Tuy nhiên,
bên kia chiến tuyến, câu chuyện của những “blue team”, người bảo vệ hệ thống cũng ly
kỳ không kém nhưng lại rất ít được biết đến. Với những “red team”, họ có thể tấn công
1000 lần và chỉ cần 1 lần thành công thì được xem là thành công. Còn với “blue team”,
họ có thể thành công chống lại 1000 cuộc tấn công, nhưng chỉ cần thất bại 1 lần thì bị
xem là thất bại. It's true!

Vậy nên, hôm nay tôi sẽ chia sẻ câu chuyện từ góc nhìn của 1 người phòng thủ khi
đối mặt với các cuộc tấn công, hy vọng các bạn sẽ hiểu hơn về công việc của những
người bảo vệ hệ thống. Câu chuyện được tổng hợp từ những đợt chống tấn công DDoS
của tôi và các attacker - tôi đặt tên là Mr.Tèo (vì cứ gặp hắn thì có khả năng “tèo” cao),
các tình tiết trong câu chuyện đều có thật và các kỹ thuật áp dụng cũng đều là thực tế, các
bạn có thể áp dụng cho hệ thống của mình.

NGÀY THỨ NHẤT: CHÀO SÂN

Cạch cạch cạch … enter - Mr.Tèo nhập tên miền của tôi vào tool tấn công DDoS và
nhấn nút khai hoả. Sau vài lần F5, hắn nhận thấy website bắt đầu phản hồi chậm dần, lỗi
"502 Bad Gateway" bắt đầu xuất hiện nhiều hơn. Vài phút sau, hắn nhoẻn miệng cười khi
server đã không còn phản hồi. Mr. Tèo đã ghi bàn thắng đầu tiên, tỉ số là 1-0.

Bên kia chiến tuyến, tôi - anh IT culi kiêm quản trị server - nhận được điện thoại
của sếp: “Em à, khách hàng báo website không truy cập được, kiểm tra gấp cho anh”.
Công nhận, khách hàng là tool monitor trên cả realtime, còn ông sếp là công cụ notify
được tích hợp AI xịn sò nhất cái xứ Đông Lào này. Tôi móc điện thoại truy cập vào
website, mọi thứ cứ xoay tròn trong vô vọng và không có tín hiệu trả lời, giống như cái
cách mà tôi nhắn tin cho crush vậy! Xác định hệ thống có vấn đề, tôi lật đật SSH vào
server để kiểm tra.

Việc SSH vào server lúc này cũng khá lag, từng dòng chữ hiện ra chậm chạp như
xem phim full HD bằng mạng GPRS vậy. Chuyện quá gì đang xảy ra vậy - tôi thầm
nghĩ? Màn hình command line đã load xong và sẵn sàng chạy lệnh, tôi thực hiện ngay các
thao tác kiểm tra tài nguyên hệ thống để có cái nhìn tổng quan:
 - Tải (Load Average) của server đang cao ngút trời.

- CPU: tất cả các core đang chạy 100%

- RAM: Đã sử dụng toàn bộ, swap cũng đã được sử dụng.

- Disk IO: tăng cao bất thường.

Vậy đã rõ, hệ thống bị quá tải dẫn đến không thể xử lý request (truy cập) của người
dùng. Vậy điều gì đã gây ra tình trạng này? Tôi chạy lệnh “top" để kiểm tra danh sách
process đang chạy trên server. Thật kỳ lạ, tại sao lại có quá nhiều process “httpd”
(process của web server Apache) đang chạy thế này? Và mỗi process đang sử dụng 100%
CPU. Rõ ràng, đây chính là nguyên nhân khiến hệ thống bị quá tải. Không biết, web
server đang xử lý cái gì nhỉ - tôi băn khoăn.

Process httpd được sinh ra để xử lý request của người dùng, vì thế khi hệ thống có
nhiều process httpd chạy cùng lúc đồng nghĩa đang có lượng truy cập lớn đổ về website.
Tôi kiểm tra ngay access_log của server để xác định các truy cập đó là gì.

Hừm, log truy cập quá nhiều, nhìn hoa cả mắt nhưng rõ ràng có sự bất thường:

- Các truy cập đến từ rất nhiều IP khác nhau, đa phần là IP nước ngoài. (Xem hình
1)

- Các IP truy cập phần lớn là đến từ nước ngoài

- Cùng truy cập vào duy nhất trang chủ.

- Các IP chỉ access vào trang chủ và không tải các static resource (như javascript,
CSS, image …), điều này cho thấy đây không phải là các client bình thường và không
được truy cập bằng browser. (Xem hình 2)

=> Nhiều truy cập dồn về trang chủ nhưng nhìn rất bất thường

Đến đây, tôi nhận ra mình đang là nạn nhân của một cuộc tấn công DDoS nhắm vào
tầng ứng dụng (Layer 7 - Application Layer). Mục tiêu của kẻ tấn công là tạo thật nhiều
request khiến server xử lý đến cạn kiệt tài nguyên. Do đó, các client hợp lệ sẽ không sử
dụng được dịch vụ trên server.

Với kiểu tấn công ở tầng ứng dụng, yêu cầu các IP tham gia tấn công phải là client
thật, nghĩa là chúng phải hoàn thành được bắt tay 3 bước (3 way handshake) ở tầng TCP
mới có thể gửi payload lên tầng Application. Do đó, số lượng IP tấn công là hữu hạn.
Nếu số lượng IP tấn công ít thì yêu cầu tần số tấn công trên mỗi IP phải cao mới đủ sức
làm quá tải server. Ngược lại, nếu số lượng IP đủ nhiều mới có thể cho phép tần số tấn
công trên mỗi IP thấp mà vẫn hạ gục được server. Vậy nên, với tấn công ở Layer 7, rate
limit (giới hạn tần số) trên mỗi IP là một phương pháp có thể áp dụng để giảm thiểu tác
hại của DDoS và lọc ra danh sách botnet.

Nghĩ là làm, việc quan trọng nhất cần ưu tiên bây giờ là nhanh chóng đưa website
trở lại hoạt động. Tôi áp giới hạn tần số truy cập của từng IP lên trang chủ, nếu IP nào
truy cập vượt quá tần số quy định thì sẽ từ chối phục vụ, đồng thời lưu log lại IP vi phạm.
Nếu IP nào vi phạm từ 3 lần trở lên (nghĩa là cố tình vi phạm - khả năng là bot cao) thì
đưa vào Firewall để block luôn IP, giảm tải cho tầng ứng dụng. Thời gian đầu, server vẫn
còn phải gồng mình phục vụ các request vì IP chưa đạt tới ngưỡng quy định, nhưng dần
dần server đã bắt được nhiều IP botnet cho vào firewall và ổn định dần. Sau tầm 5p,
website đã có thể truy cập trở lại, mặc dù vẫn phải thở oxy 1 chút.

Website truy cập lại được phần nào giúp tôi giảm áp lực với sếp. Lúc này tôi mới có
nhiều thời gian phân tích kỹ hơn đặc điểm của cuộc tấn công. Tôi capture 10,000 raw
packet để nhìn rõ hơn mặt mũi của bọn chúng:

[root@server]# tcpudmp -i any -nn -c 10000 port 80

Ồ, phát hiện thêm một đặc điểm mới của đám botnet này. Request của chúng phần
lớn mang theo các header như:

- X-Forwarded-For

- X-Real-IP

- X-Via

(Xem hình 3)

HTTP Header chứa X-Forwarded-For mang theo IP của máy chạy tool DDoS

Các header này cho thấy Mr.Tèo đã sử dụng các proxy public làm trung gian tấn
công hệ thống. Ngoài ra, giá trị IP nằm trong các header kia cũng chính là IP của Mr.Tèo.

(Xem hình 4)

Dựa vào đặc điểm này, tôi tiến hành cấu hình server siết chặt hơn các truy cập có
mang các header proxy. Người dùng bình thường nếu sử dụng mạng công ty có cấu hình
proxy thì request của họ cũng có thể mang các header trên. Nên việc chặn hoàn toàn các
request mang header proxy sẽ dễ chặn nhầm người dùng thật.

Do đó, tôi chỉ giới hạn tần số của chúng mà không chặn hẳn. Ngoài ra, tôi còn giới
hạn sâu hơn 1 chút:

Nếu IP là IP quốc tế và mang header proxy: giới hạn chỉ cho phép truy cập 2
lần/giây

Nếu IP là IP Việt Nam và mang header proxy: giới hạn cho phép truy cập 5
lần/giây.

Pseudo code:

if (request == “GET /”) {

if ( IP not in VN AND proxy is in http.headers ) {

limit_rate 2/s;

if (request_rate > limit_rate) {

log_ip(“attack_ip.log");

if ( IP is in VN AND proxy is in http.headers ) {

limit_rate 5/s;

if (request_rate > limit_rate) {

log_ip(“attack_ip.log”);

list_attack_ip = read(“attack_ip.log");

foreach ip in list_attack_ip {

if ( count(ip) > 3) {
 firewall_block(ip);

Vì phần lớn IP tấn công là IP quốc tế nên rule như trên đã cản lọc gần như toàn bộ
cuộc tấn công. Và tôi cũng không phải quá lo lắng chặn nhầm người dùng thật vì khách
hàng của tôi phần lớn là ở Việt Nam, và IP Việt Nam nếu có sử dụng proxy thì cũng được
limit tương đối thoải mái, đủ để truy cập bình thường!

Sau khi áp rule, tải của server đang giảm dần, danh sách IP proxy bị đưa vào
Firewall càng ngày càng tăng lên rồi dừng hẳn. Có lẽ, toàn bộ IP proxy đã bị nhận diện
và block bởi firewall. Website đã truy cập ổn định lại. Tôi thở phào nhẹ nhõm vì đã vượt
qua thử thách đầu tiên, tuy nhiên tôi biết rằng cuộc chiến chỉ vừa mới bắt đầu, càng về
sau trận chiến sẽ càng ác liệt hơn.

Tổng kết ngày 1:

- Tấn công:

. HTTP Flood sử dụng public proxy. Mục tiêu làm tiêu hao tài nguyên (CPU,
RAM, Disk …) của máy chủ, quá tải web server.

- Phòng thủ:

. Dấu hiệu nhận biết: tài nguyên bị cạn kiệt bởi các process liên quan đến xử lý web
request. access_log tràn ngập các log entry với pattern tương tự nhau.

. Giới hạn tần số truy cập vào URL bị tấn công.

. Phân tích kỹ header của request để tìm dấu hiệu bất thường.

. Phát hiện tấn công ở Layer 7 nhưng ghi log lại để đẩy dần xuống chặn IP ở Layer
3 cho tối ưu.

Tỉ số tạm thời là 1-1 nghiêng về 2 đội. Bên kia chiến tuyến, Mr.Tèo đang bày binh
bố trận cho trận đánh tiếp theo! À mà Mr.Tèo, khi dùng tool DDoS sử dụng public proxy,
các proxy sẽ Forward IP máy chạy tool của ông cho tôi đấy nhé, hãy cẩn thận!