Những ngày cuối tháng 8, 2008, công việc chồng chất, mẹ tôi lại bệnh nặng nên tôi ít vào diễn đàn, ít theo dõi tình hình hệ thống máy chủ của diễn đàn.

Tối 25 tháng 8, tôi đăng nhập YIM để đọc offline messages và kiểm tra mail vì đã nhiều ngày không mó tới chúng, tôi nhận được một thông điệp của JAL như sau:
"Anh xem thử servers của mình thế nào đó. Mấy hôm nay cứ khoảng, 7, 8 giờ tối là servers, đường dây đều bị treo cứng cả tiếng đồng hồ mới chạy lại. Không biết có phải mình bị DDoS không nữa."

Tôi hồi báo JAL:
"Ừa, để anh sắp xếp thời gian xem thử chuyện gì xảy ra."

Trong lòng tôi nghĩ chắc là cái CSDL lại trở chứng deadlock đâu đó chớ gần hai năm nay, chưa có cú DDoS nào gọi là đáng kể hoặc đáng quan tâm cả.

Sau một ngày dài dằng dặc với ngập ngụa công việc, tôi đã mệt lắm rồi nên chẳng muốn đụng tới máy chủ hay máy con gì nữa. Định logoff nhưng nghĩ sao, tôi lại login máy chủ chạy web của HVA để xem qua. Theo phản xạ tự nhiên, tôi lướt qua mớ logs trên máy chủ với sed, awk, cat, sort, uniq..... -65- nhưng chẳng thấy gì đặc biệt. Tôi cố nán lại để xem thêm logs của vài ngày trước cho đến hôm nay hy vọng tìm ra chút manh mối nhưng hoàn toàn chẳng thấy gì bất thường hoặc ít nhất, chẳng có gì mang dấu hiệu web server đã bị DDoS.

Tôi gởi cho JAL một thông điệp báo rằng tôi sẽ cố gắng thu xếp thời gian để vào máy chủ khoảng 7, 8 giờ tối để theo dõi hiện trạng ngay lúc bị "DDoS" và logoff.


Tối 25/8/2008
Tôi pha một ly cà fê và login máy chủ HVA, mở mấy cái console lên và chạy vài cái "tail" rồi ngồi duyệt diễn đàn HVA. Không lâu sau đó, tình trạng duyệt diễn đàn càng lúc càng chậm. Tôi chuyển sang console đang "tail" access log của web server và thấy số lượng request / response ít lại từ từ nhưng chẳng thấy có gì khác lạ. Tôi quyết định chạy thử tcpdump để lấy một nhúm gói tin về phân tích:
# tcpdump -i eth0 -s0 -w 25-08-2008

Vội vã copy file 25-08-2008 về laptop và dùng wireshark (ethereal) mở ra, tôi phát hiện ngay máy chủ đang bị Syn Flood với vận tốc cực nhanh:





Tôi chép miệng: "Mấy cái quỷ synflood này làm sao làm các truy cập khác chậm hơn được cà? Chắc chắn phải có cái gì khác nữa."

Tôi tiếp tục duyệt qua mớ packets từ file 25-08-2008 ở trên và phát hiện ra thêm một số thông tin lý thú, ví dụ:





Ngoài tcp synflood còn có một mớ UDP fragmentation flood.

Kiểm tra lại kernel parameters cho IPV4, tôi thấy ngay số lượng SYN được nhận và giá trị TIME_OUT -66- của chúng không đủ để phục vụ. Điều này có nghĩa, những cú SynFlood kia quá nhiều và quá nhanh nên chúng chiếm hết chỗ cho các request hợp lệ (người dùng bình thường). Chuyện này không khó khắc phục mấy, đặc biệt memory còn dư giả. Tôi điều chỉnh ngay /etc/sysctl.conf -67- và áp dụng ngay lập tức, đồng thời cũng thắt chặt thêm vài chi tiết nhỏ trên firewall. Sau một phút, tình hình duyệt diễn đàn HVA thay đổi thấy rõ: duyệt nhanh hơn mặc dù lượng syn flood không hề giảm mà còn tăng hơn.

Thế còn cái mớ UDP fragmentation flood thì sao? Lúc ấy, tôi cho rằng chúng không tạo mấy dung hại bởi lẽ chúng là những gói UDP bất hợp lệ (bạn thử xem chúng bất hợp lệ ở điểm nào từ bức ảnh kèm theo? ), vả lại chẳng có bao nhiêu gói tin UDP để đủ quan tâm (và đây là điều khiến tôi phải nhức đầu vài ngày sau đó).

Tôi quá mệt nên logoff sau khi gởi JAL một thông điệp ngắn gọn rằng mọi chuyện đã tạm ổn.


Ngày 26/8/2008
Sáng sớm ngày 26/8/2008, tôi vẫn bị cảm giác có gì đó chưa hoàn toàn an tâm. Tôi đăng nhập vào máy chủ của HVA và rà xuyên các logs một lần nữa. Không có dấu hiệu gì khác thường (tôi đã điều chỉnh firewall để báo cáo thêm chi tiết các hoạt động đêm trước). Dành khoảng nửa giờ với mấy cái máy chủ HVA, tôi đành phải xếp chúng qua một bên vì công việc đang bề bộn.

Tối hôm ấy, JAL lại gởi thêm cho tôi mấy cái e-mail và offline messages thông báo rằng tình trạng máy chủ bị "đơ" vẫn tiếp tục xảy ra. Tôi rất ngạc nhiên và không hiểu chuyện gì đã xảy ra. Ngay lúc nhận được e-mail của JAL, tôi thử vào diễn đàn và quả thật, truy cập rất trì trệ.

Đăng nhập vào máy chủ HVA, tôi phóng nhanh vài cái "tail" để theo dõi và chẳng thấy gì lạ. Kiểm tra netstat, kiểm tra top, kiểm tra firewall logs, kiểm tra web logs.... mọi chuyện đều bình thường, vậy cái gì đang xảy ra đây? Tôi quyết định chạy thử tcpdump để xem chuyện gì xảy ra:
# tcpdump -i eth0 tcp port 80

và chính cái lệnh trên đã... hại tôi. . Có lẽ bạn không thể đoán ra tại sao nó hại tôi nhưng sự thể rất đơn giản: tôi đòi tcpdump bắt lấy các gói tin đụng đến cổng 80 và dùng giao thức tcp. Điều này có nghĩa tôi hoàn toàn không thấy được các gói tin khác (có thể) đang tấn công máy chủ HVA. Dạng SYN Flood tối hôm qua hoàn toàn biến mất, biên độ các gói tin ra vào cổng 80 rất bình thường. Tôi ngớ ra vì chẳng biết sự thể thế nào nữa. Tôi gởi cho JAL một e-mail và bảo JAL kiểm tra xem phần cứng hoặc đường truyền có gì bất thường hay không bởi vì trên máy chủ mọi sự đều "bình thường".

Tôi logoff, mệt lả sau một ngày bận rộn.

Chú thích:
-65-: Các "lệnh" thông thường trên *nix để đọc và phân tích ASCII files.

-66-: Hai giá trị tối quan trọng cần theo dõi và điều chỉnh là:
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv và net.ipv4.tcp_max_orphans. Không có giá trị nào là tối ưu cho mọi hệ thống mà giá trị này phải được tính toán và điều chỉnh cho thích hợp tùy hoàn cảnh. Nếu net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv quá lớn, số lượng SYN sockets sẽ ngập ngụa trên server dẫn đếnt tình trạng người dùng hợp lệ không có cơ hội truy cập. Nếu như giá trị này quá thấp, SYN sockets sẽ bị triệt tiêu nhanh chóng khiến cho người dùng hợp lệ sẽ bị tình trạng chập chờn khi truy cập. Giá trị net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv này nên đủ thấp và tương quan với giá trị net.ipv4.tcp_max_orphans để cho phép người dùng hợp lệ có cơ hội truy cập. Điều này có nghĩa, net.ipv4.tcp_max_orphans cần được gia tăng (và tất nhiên, physical memory trên máy chủ phải được gia tăng để tránh tình trạng hết memory và treo máy).

-67-: Hồ sơ cấu hình cho kernel parameters trên Linux. Hồ sơ này có thể được điều chỉnh và áp dụng bằng lệnh sysctl -p thay vì dùng phương pháp điều chỉnh trực tiếp vào /proc filesystem. Tìm hiểu thêm /proc filesystem trên Linux để nắm sâu hơn.