Tối 26/3/2005
Vừa xong một trận nhậu tưng bừng, khách khứa đã ra về. Mở FireFox ra để xem qua HVA có gì mới, tôi hết sức ngạc nhiên khi thấy truy cập vào HVA cực kỳ chậm; một trang load mất hơn 9.5s (?). Đây là dấu hiệu rất bất thường. Dù tôi đang "nửa say, nửa tỉnh" nhưng cũng cố login HVA server để xem qua tình hình. Việc đầu tiên tôi nhận thấy là log vào HVA server (xuyên qua SSH) cực kỳ chậm và bị "timeout" liên tục. HVA bị DoS rất nặng rồi! đây là chuyện không còn phải nghi ngờ gì nữa.

Sau vài lần thử log vào, rối cuộc tôi cũng vào được shell của HVA server. Xem thử tình hình tổng quát thế nào, tôi gõ:

# w
load average: 98.20, 120.75, 100.80

Ôi trời, cái gì mà kinh thế? Chẳng lẽ "hàng phòng thủ" của HVA đã vỡ sao? Tôi thử "tail" phần log của web server xem chuyện đây?
Code:


Ái chà, lại là mớ POST quỷ quái kia. Tất nhiên là không chỉ có 3 dòng đơn giản như trên mà các dòng tương tự như thế từ hàng trăm IP khác nhau hiển thị như... nước chảy trên màn hình. Tôi vò đầu, sao lạ nhỉ? làm sao mấy cú POST ngớ ngẩn này có thể "đột phá" HVA và làm cho server load tăng đến mức kinh khủng đến thế? Tôi xem lại cấu hình của firewall và thấy quả là firewall có phần dễ dãi. Tuy vậy, mức độ "mở cửa" của firewall lúc này cũng không thể dẫn đến tình trạng server load của HVA lên cao như thế được.

Tôi quyết định điều chỉnh lại firewall và tái khởi động nó rồi theo dõi cụ thể sau.

Năm phút sau,

# w
load average: 16.50, 78.65, 90.40

Hừm.... xem tạm chấp nhận được. Tôi thử dùng FireFox để vào lại diễn đàn HVA và thấy vận tốc truy cập khá hơn lúc nãy rất nhiều. Tôi quyết định "dump" một mớ packets để xem thử sự thể ra sao:

# tcpdump -s0 port 80 -w 26-03-2005

Chờ khoảng 60 giây, tôi ngưng tcpdump, zip hồ sơ "26-03-2005" và tải về laptop của tôi. Tuy nhiên, tôi lại gặp thêm một khó khăn khác. Bất cứ mọi phương tiện tôi dùng để tải hồ sơ trên về máy (scp, sftp hay rsync xuyên qua ssh....) -56- đều bị gián đoạn nửa chừng. Có lẽ do "timeout" giữa mỗi gói tin gởi nhận giữa laptop của tôi và HVA server (máy chủ HVA quá bận rộn vì đang bị DoS dồn dập). Tôi thở dài lẩm nhẩm "đành phải tạm ngưng web service thôi". Miệng nói, tay làm; tôi ngưng ngay apache và cũng không quên ngưng luôn monit (monit đã được đề cập trong một phần trước đây của loạt ký sự này) để nó khỏi tự động restart lại apache trước khi tôi hoàn tất chuyển tải hồ sơ 26-03-2005.gz về máy mình.

Voila, hồ sơ gần 3 Mb được chuyển về sau hơn 2 phút.

Tôi khởi động lại apache và monit ngay sau đó và liên tục kiểm tra server load suốt 15 phút sau khi khởi động lại apache. Server load lúc này đã giảm xuống đáng kể, không khi nào lên quá 5.0 load. Tôi logoff HVA server và đi ngủ (lượng alcohol trong máu không cho phép tôi ngồi lâu hơn nữa).

Trưa 27/03/2005
Tôi thức dậy hơi trễ so với thường ngày vì trận nhậu sáng hôm qua. Sáng nay lại có ít việc phải lo nên tôi không vào HVA suốt buổi sáng. Mãi đến sau buổi trưa, khi mọi chuyện đã đâu vào đấy, tôi mở máy lên, thử vào HVA forum bằng FireFox. Chà, trang web load chậm kinh khủng, tôi có cảm giác chậm hơn tối hôm qua nữa. Chuyện gì đây nhỉ?

Tôi log vào HVA server bằng SSH để xem xét tình hình. Sau 5 lần bị timeout (không connect được đến server), tôi tắc lưỡi than thầm "chết thật, server bị dội kinh thế này sao?". Lần thứ 6, tôi vào được. Việc đầu tiên tôi làm là kiểm tra ngay server load:

# w
load average: 55.30, 86.62, 85.43


Chà, không bằng tối qua nhưng sao chậm thế nhỉ? Tôi hình dung ngay lượng connection đến database, nơi duy nhất có thể tạo ra tình trạng chậm lê thê thế này. Tôi thử kiểm tra ngay số lượng process dùng để truy cập đến database:

# ps -ef | grep mysqld | wc -l
200

Ôi, ôi, ôi! 200 process cho mysql? Như vậy có nghĩa là mysql đang ngập ngụa, lết thếch với lượng connection đang diễn ra. Cũng ngay khi đó, Firefox báo lỗi "server bị sự cố, không thể truy cập vào database". Tôi gật gù, "hẳn nhiên là thế rồi". Câu hỏi tiếp theo nảy ra trong đầu "lý do tại sao các cú x-flash có thể vượt qua được hàng phòng thủ?". Tôi kiểm tra log của firewall, log của snort và log của apache trong cùng một khoảng thời gian (từ 11 giờ sáng đến 11:15 sáng giờ máy chủ) để tìm câu trả lời tổng quát cho thắc mắc ở trên. Sau 15 phút grep, awk, sort.... -57- tôi nhận ra một điều tối yếu: hàng phòng thủ không cáng đáng nổi lượng x-flash ập vào server.

Tôi vò đầu lẩm nhẩm "cho đến lúc này đã có hơn 3 triệu 9 trăm ngàn cú POST đi vào, tính từ nửa đêm, giờ máy chủ. Vậy có nghĩa suýt soát 45 cú POST mỗi giây". Dựa trên thông tin của apache và firewall, tôi ước tính firewall chỉ cản được 2/3 số lượng này, như vậy cứ mỗi giây có chừng 15 cú POST đi vào. Mỗi cú POST kích động ít nhất 4 queries đến database server, mỗi query mất chừng 0.05 giây. Vậy, 15 POST sẽ cần:
Code:


để giải quyết request, dọn dẹp và trở lại tư thế sẵn sàng phục vụ. Bạn có thể hình dung chuyện gì đã xảy ra rồi chớ? Hèm, cứ mỗi giây lại có một khối lượng requests cần đến 3 giây để giải quyết (tính trung bình), vậy cứ mỗi giây đi qua thì có chừng 2 giây cấp số đến khối lượng công việc.

Đã có nhận định tổng quát tình hình, tôi cần phải giải quyết ngay 2 điều:
1) giảm thiểu số lượng POST càng nhiều càng tốt để lấy lại mức độ quân bình
2) điều tra xem lý do tại sao chỉ có 2/3 số lượng x-flash POST bị cản thành công

Tôi dừng ngay apache, mysqld và monit. Chỉnh lại firewall và ấn định connection limit ở mức tối thiểu và khởi động các dịch vụ trở lại. Vừa theo dõi mức biến thiên của server load, tôi vừa mở mớ packet dump tôi lấy được tối hôm qua.

Hãy thử so sánh payload của x-flash POST lần này và lần trước
Code:


phần payload được decode như thế này:
Code:


Phần POST xảy ra trước đây như sau:

POST /forum/ HTTP/1.1
Accept: */*
x-flash-version: 7,0,19,0
Content-Type: application/x-www-form-urlencoded
Content-Length: 712
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FunWebProducts)
Host: 219.207.204.25
Connection: Keep-Alive
Cache-Control: no-cache

total=23&Submit=Submit&attack=1&diachi=http%3A%2F%2Fviemarket%2Ecom%2F&url1=
http%3A%2F%2F219%2E207%2E204%2E25%2Fforum%2F&url2=http%3A%2F%2F219%2
E207%2E204%2E25%2Fforum%2F&url3=http%3A%2F%2F219%2E207%2E204%2E25%2F
forum%2F&option=search&s=&do=login&url=http%3A%2F%2Fvikhoa%2Ecom&agree=1&
password%5Fmd5=&passwordconfirm%5Fmd5=&username=Tintucvietnam&password=
thangcho&passwordconfirm=thangcho&email=admin%40tintucvietnam%2Ecom&emailconfirm=
admin%40tintucvietnam%2Ecom&imagestamp=tintuc&imagehash=47b4a32f7767bfc7b83f8f3e
cf2e8c66&timezoneoffset=8&dst=2&options=&adminemail=1&vb%5Flogin%5Fusername=Hoanghiep
&cookieuser=1&vb%5Flogin%5Fpassword=dumemaykhoa&forcewwwect=1&vb%5Flogin%5Fmd5
password=&%5F%5FOoO%5F%5F=1&1=

Phần payload ở trên được decoded như sau:
Code:



Chúng khác nhau không? Chắc chắn là khác rồi. Chúng có những điểm giống nhau? hiển nhiên là thế. Xem kỹ phần payload mới của các cú x-flash POST:

/forum/&search_key...1&search_time=0
&search_fields=all&search_cat=1&sort_by=0&sort_dir=DESC&show_results=topics&return_chars=200&act=Reg&termsread=1
&agree_to_terms=1&CODE=02&coppa_user=0&UserName=abcxyzmanginternet&PassWord=123456&PassWord_Check=123456
&EmailAddress=thienthan@hvaonline.net&EmailAddress_two=binhquamit@cuchuoi.com&allow_admin_mail=1&allow_member_mail=1
&time_offset=7&dst=1®id=cfdcc4645bbf06325a1680e405e4edb9®_code=4754125&page=search_result&catid=0
&search_qkeywords=Thang Beo&category_id=0

Tôi phải gật gù tán thưởng với mức sáng tạo lần này của kẻ tấn công HVA. Bạn nói sao? tại sao phải gật gù? . Đúng vậy, tôi gật gù vì ý định "tàn phá" trong payload của các cú POST lần này không chỉ POST khơi khơi mà có dụng đích rõ ràng, mặc dù dụng đích này không có tác dụng gì ngoài việc "buộc" code của forum phải tạo 4, 5 cái query đến database server cho mỗi cú POST. Những query này dừng lại ở mức độ thâu thập thông tin để hiển thị kết quả cú POST (mặc dù chẳng có kết quả gì để hiển thì ngoài một mớ sườn của diễn đàn). Ý định của các cú POST trên là thực thi lệnh "search" và từ khoá để search là một "wild card" * nhằm lấy về càng nhiều kết quả càng tốt. Nếu ý định này thành công thì chẳng mấy chốc diễn đàn HVA chết đứ đừ vì database server phải làm việc ở mức căng thẳng nhất. May thay, nội dung payload này khá vô ích và không "hiệu năng" gì hơn lần trước. Rõ ràng nội dung payload nhắm đến hvaonline.net nhưng cú pháp thì không mảy may tương ứng với hàm "search" của hva.

Trong 30 phút vừa qua, server load chưa hề lên quá 3.0. Tôi thử vào diễn đàn HVA bằng FireFox; có vẻ chậm hơn bình thường nhưng không ở tình trạng trì trệ như một giờ trước đây. Được rồi, hãy bắt tay vào phân tích xem cái firewall bị gì mà không cản hết những cú POST kia. Tôi mở hồ sơ cấu hình của firewall lên và tập trung vào "bộ luật" dành riêng cho HTTP. Tôi dò từng dòng, từng chữ của nhóm luật này và chỉ sau một phút, tôi nhận ra ngay "độ hở" của một số luật dùng để đối phó với x-flash. Hãy xem thử syslog báo những gì, tôi cần xác nhận điều tôi vừa tìm ra hoàn toàn đúng:

Code:


Quả vậy, quả vậy. Tôi tìm ra không chỉ một mà là hai điểm hở khiến cho các cú x-flash có thể vuột qua hàng phòng thủ nếu như số lượng x-flash đạt tới mức dồn dập nào đó và nếu như apache đã cho phép "keep-alive". Thực trạng lúc này đều thoả mãn cả hai điểm nếu như ở trên. Có lẽ bạn cũng thấy vào lúc 12:48:34 có đến 19 thông điệp ngay trong cùng một lúc (và kernel chỉ tường trình một thông điệp và cho biết có 19 thông điệp khác y hệt). Đây là một chi tiết minh hoạ rõ ràng nhất mức độ "dội" của x-flash đến HVA trong lúc này.

Điểm nổi bật trong cuộc tấn công của x-flash lần này là số lượng IP được huy động làm nguồn gởi x-flash đến HVA, cho đến lúc này ít nhất gấp 3 lần đợt tấn công vừa rồi (đầu năm 2005).

Ngay khi tôi chuẩn bị bắt tay vào điều chỉnh lại firewall thì có khách đến. Kẹt nhỉ? Tôi nghĩ thầm "cứ để tạm như vậy, hiện giờ server load không hề lên cao, chỉ hơi chậm một tí, từ từ fix sau". Tôi xếp laptop lại.

Chú thích:
-56- scp (Secure Copy) và sftp (Secure ftp) thuộc bộ Open-SSH. Dùng các phương tiện này để chuyển tải dữ liệu giữa các máy xuyên qua Internet an toàn hơn ftp và rcp (remote copy) cổ điển hơn rất nhiều. rsync xuyên qua ssh (hay còn gọi là "rsync over ssh" theo thuật ngữ tiếng Anh). Đây là một phương pháp để chuyển tải dữ liệu giữa các máy xuyên qua ssh tunnel. Theo tôi, đây là cách hiệu xuất và an toàn nhất.

-57- các lệnh thông dụng trên *nix dùng để tách lọc thông tin trong các log files để phân tích.

Các bạn có thể theo dõi tiếp phần 16 tại http://hvaonline.net/hvaonline/posts/list/320.html