Mấy tuần lễ gần đây, đột nhiên lượng tải trên máy chủ HVA tăng vọt trong khi số lượng thành viên chính thức truy nhập diễn đàn vẫn ở mức bình thường. DoS? hay DDoS? Lượng tải này tăng vọt khá đều đặn vài giờ trong mỗi ngày. Lượng thành viên gia tăng nên có quá nhiều người cùng truy cập? không phải. HVA đang có đề tài gì hấp dẫn nên thiên hạ ùn ùn kéo vào? cũng không phải. Dấu vết Tôi nhận công tác điều tra và xử lý tình trạng bất bình thường này, trong đầu đã phần nào đoán sự thể do DoS. Khuya ngày 10 tháng 10, tôi log vào server của HVA và tạo ra vài console, mở ra vài cái đuôi -1-, làm một ấm trà và ngồi đó nhâm nhi... một mình. Không cần phải đợi lâu, hàng loạt thông tin từ log của web server hiện lên màn hình với một số chi tiết rất lý thú:
1 Dấu hiệu Mấy tuần lễ gần đây, lượng tải máy chủ HVA tăng vọt số lượng thành viên thức truy nhập diễn đàn mức bình thường DoS? hay DDoS? Lượng tải tăng vọt đặn vài ngày Lượng thành viên gia tăng nên có nhiều người truy cập? khơng phải HVA có đề tài hấp dẫn nên thiên hạ ùn ùn kéo vào? Dấu vết Tôi nhận công tác điều tra xử lý tình trạng bất bình thường này, đầu phần đoán thể DoS Khuya ngày 10 tháng 10, log vào server HVA tạo vài console, mở vài -1-, làm ấm trà ngồi nhâm nhi Khơng cần phải đợi lâu, hàng loạt thông tin từ log web server lên hình với số chi tiết lý thú: Code: 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 211.199.192.157 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; iebar)" 203.162.3.148 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FunWebProducts)" 203.162.3.148 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FunWebProducts)" 80.170.198.46 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1617 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; NET CLR 1.1.4322; NET CLR 1.0.3705)" 81.66.147.0 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1615 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; NET CLR 1.1.4322)" 211.199.192.157 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; iebar)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 203.162.3.148 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1614 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 24.17.150.114 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1504 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3" 203.162.3.148 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1614 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 203.162.3.148 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FunWebProducts)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 203.162.3.148 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FunWebProducts)" 81.66.147.0 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1615 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; NET CLR 1.1.4322)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 80.170.198.46 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1617 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; NET CLR 1.1.4322; NET CLR 1.0.3705)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 203.162.3.148 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1614 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)" 211.199.192.157 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; iebar)" 211.199.192.157 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; iebar)" 24.17.150.114 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1504 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3" 81.66.147.0 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1615 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; NET CLR 1.1.4322)" 203.162.3.148 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1614 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 80.170.198.46 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1617 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; NET CLR 1.1.4322; NET CLR 1.0.3705)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 203.162.3.148 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FunWebProducts)" 211.199.192.157 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; iebar)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 211.199.192.157 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; iebar)" 203.162.3.148 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1619 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FunWebProducts)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 203.162.3.148 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1614 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)" 81.66.147.0 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.1" 200 1615 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; NET CLR 1.1.4322)" 210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200 1618 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 24.17.150.114 - - [10/Oct/2004:06:57:20 -0400] "POST /forum/ HTTP/1.1" 200 1504 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3" Chà, thành viên "hối hả" kéo vào diễn đàn "POST" nhiều đến sao? hai mươi lăm "POST" giây từ vài IP? Cứ cho hợp lệ thành viên VN Internet, qua cửa ngõ -2- chuyện bình thường Nhưng, đã, vừa lại có chùm đến năm mươi "POST" đến giây, từ IP Bất thường hay bất tường? Tôi để yên "cái đuôi" chạy console mở trình duyệt lên, thử log vào HVA nickname password để xem thử "thái độ" POST từ máy tơi có tương tự POST nhận vài chục giây trước (xác thực bạn nghề phân tích) Cha chả, POST tơi nhìn hợp lệ nhiều: Code: xxx.xx.xxx.98 - - [10/Oct/2004:07:11:25 +0900] "POST /forum/act_Login_CODE_01.html HTTP/1.0" 200 7405 "http://www.hvaonline.net/forum/act_Login_CODE_00.html" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510" Tôi thử mở "cái đuôi" firewall log server xem có hấp dẫn khơng Chà, log web server "POST" vào ầm ầm firewall log im ắng đỉnh Himalaya Thơi rồi, "kiểu chơi" hợp lệ nên firewall cho phép chúng vào thả cửa Tôi gởi nhanh PM đến JAL, nhờ lão phóng sniffer lên để "hít" -3- gói tin lưu lại nơi thích hợp dùm tơi Đêm khuya, tơi phải ngủ để mai cịn làm Sáng mai copy mớ gói tin lưu phân tích xem thể Phân tích Ngày 11/10 Trên tàu lửa đến sở làm, hăm hở mở laptop bắt tay vào xem xét thông tin "bắt" tối hôm qua Chuyện đập vào mắt tơi kích thước hồ sơ sniff, chà, bé tí tẹo nhỉ? Sáng lúc log vào HVA server để copy hồ sơ này, tơi khơng để ý đến kích thước (vì nghĩ phải vài megabytes), tơi chạy lệnh scp bỏ thay đồ làm Lúc nhận bé tí tẹo, khơng biết có Tôi dùng Ethereal mở hồ sơ ra, dự phỏng, Ethereal phàn nàn "stream not completed" Tôi bật cười tự nhủ: "chà, lão JAL sợ sniff lâu thành hồ sơ khổng tượng nên sniff một, hai giây tắt liền" Thông tin "bắt" từ sniffer ít, vỏn vẹn mười dịng, có SYN -4-, ACK,PSH từ segment khác, HTTP (POST) cộng thêm vài "continuation" từ segment trước sau SYN khơng thấy theo Xếp laptop lại, trầm ngâm vài phút, có vài chi tiết cần xem lại mớ packets ngắn ngủi mà lão JAL cung cấp Tôi lại mở laptop xuyên qua mười mảnh packets rời rạc Không thể "gom" packets thành stream hồn chỉnh, tơi đành xem xét mảnh lần Điểm lý thú đập vào mắt tơi dị đến http packet chứa mảng đầu phần "POST" Cha chả, POST mà thế? - payload -5- "POST" có đến 2205 bytes? - đoạn đầu mảnh "POST" có thơng tin: Code: hotlinks=Offical%2Ecom&comdoss=attack&port=80&url1=http%3A%2F%2Fhvaonline%2Enet %3A80&url2=http%3A%2F%2Fhvaonline%2Enet%3A80%2Fforum%2F&http%3A%2F%2Fwww%2Exxx %2Ecom%2FForum%2Findex%2Ephp=&act=Reg&CODE=02&coppa%5Fuser=0&PassWo Lý thú nhỉ, lý thú chưa có rõ ràng cho Tơi ngạc nhiên lão HVA lại để n http header payload có dính ngổn ngang "chú" ampersand -6- Có lẽ lão cho phép phần cần thiết cho forum? Tơi chưa nắm phần tố ngổn ngang "Invision Board" web server đứng trước, phải điều tra kỹ Thiếu mảnh đoạn POST trên, đành thở dài dừng lại chẳng tới đâu Thơi vậy, đành phải sniff lại mớ thơng tin chẳng giúp Chú thích: -1- "tail", lệnh dùng để liên tục chuyển thông tin log lên console để theo dõi -2- "gateway", cửa ngõ / vào network -3- "sniff", động tác hít nói theo tính sinh hố, động tác "bắt lấy" gói tin xuyên qua đường dẫn nói theo tinh thần điện toán -4- "SYN, ACK, PSH " tcp flags dùng giao thức TCP -5- payload liệu gói tin (nói bình diện "mạng") -6- ampersand (&) dấu "và" keyboard Phân tích (tiếp theo) Tối 11/10 Tơi gởi PM cho lão JAL để "hít" thêm gói tin, lần tơi nắm phải có vài megabytes packets để nghịch Khơng lâu sau đó, tơi nhận hồi đáp từ JAL thơng báo mảnh packets có sẵn server Tôi log vào HVA server tải chúng xuống Hăm hở mở đoạn "hit" thứ nhất, rà xuyên qua trọn gói tin bắt nhóm thứ để tìm dấu hiệu bật dấu hiệu có liên quan đến đoạn payload HTTP POST Quá nhiều! có nhiều "stream" -7- từ nhiều nguồn khác mang đặc tính Thử xem "stream" client IP 203.210.233.28, dùng proxy server 203.162.3.148 để "POST" vào server HVA: Code: POST /forum/ HTTP/1.1 Accept: */* x-flash-version: 7,0,19,0 Content-Type: application/x-www-form-urlencoded Content-Length: 2387 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Cookie: session_id=433ab8bcc276414badb0e83891bbb9a6 Host: www.quangvinhonline.info X-Forwarded-For: 203.210.233.28 Connection: Keep-Alive Cache-Control: no-cache, bypass-client=203.210.233.28 hotlinks=Offical%2Ecom&comdoss=attack&port=80&url1=http%3A%2F%2Fwww%2Ehvaonline %2Enet%2Fforum%2F&url2=http%3A%2F%2Fwww%2Ehvaonline%2Enet%2Fforum %2F&http%3A%2F%2Fwww%2Exxx%2Ecom%2FForum%2Findex%2Ephp=&act=Reg&code=02&coppa %5Fuser=0&PassWord=123456&PassWord%5FCheck=123456&agree=1&imie=Only +U&nazwisko=Frem\ &kraj=AG&adres1=Hien+kem&adres2=&miasto=Hiam+city&kod=51451&HT=Hacker %5FVietNam&EM=gianghomang%40yahoo%2Ecom&PW=123456&rPW=123456 &DangKy=nananaBD&telefon%5Fa=574&telefon=52415487&mail1=jand%40yahoo %2Ecom&mail2=jand%40yahoo%2Ecom&pass1=jand%40yahoo%2Ecom&pass2=jand%40yahoo %2Ecom&ret=0&question=jand%40yahoo%2Ecom&answer=jand%40&s=&do=addmember&url=http %3A%2F%2F64%2E207%2E189%2E5&password%5Fmd5=&passwordconfirm%5Fmd5 =&passwordconfirm=123456&referrername=Nokia&timezoneoffset=0&dst=2&options %5Badminemail%5D=1&options%5Bshowemail%5D=1%24%23%24%40%24%5E%24%40%23 %21%40%23%24%21%40%23%24%40%21&1+42A3KCT%2ENET%2E+%0D%0A2+BAODIENTUVN%2ECOM%2E+ %0D%0A3+CANDYKID%2ENET%2E+%0D%0A4+CVK3N%2ECOM%2E+%0D%0A5+CVK3N%2ENET %2E+%0D%0A6+DIEMTUYENSINH%2ECOM%2E+%0D%0A7+DNSTBVN%2ENET%2E+%0D%0A8+HACKER4A %2ECOM%2E+%0D%0A9+HOAIANH%2ECOM%2E+%0D%0A10+LAMHONGHUYEN%2ECOM%2E+%0D %0A11+LAMHONGHUYEN%2EINFO%2E+%0D%0A12+LAMHONGHUYEN%2ENET%2E+%0D%0A13+MUSIC4VN %2ECOM%2E+%0D%0A14+NVBH7%2ECOM%2E+%0D%0A15+THANGKCT%2ENET%2E+%0D %0A16+TINHBANVIETNAM%2EORG%2E+%0D%0A17+TUOITRE%2EINFO%2E+%0D%0A18+VIETSTAR %2EINFO%2E+%0D%0A=%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%0D %0A1+4RTRITHUC%2ECOM%2E+%0D%0A2+ANHEMCLUB%2EORG%2E+%0D%0A3+r u crazy???%2ECOM %2E+%0D%0A4+BARIA%2DCLUB%2ECOM%2E+%0D%0A5+CANHHAO%2ECOM\ %2E+%0D%0A6+DONGTRANG %2ECOM%2E+%0D%0A7+HOAHOCBKHN%2ECOM%2E+%0D%0A8+INTELNEW%2ECOM%2E+%0D %0A9+KHUCTINHCA%2ECOM%2E+%0D%0A10+LAONHAO%2ENET%2E+%0D%0A11+LYSOCHANTHUYEN%2EORG %2E+%0D%0A12+NHANVAN%2EORG%2E+%0D%0A13+NHIPDIEUVN%2ECOM%2E+%0D %0A14+NHUNGANHSAOBANG%2ECOM%2E+%0D%0A15+NTQUOCKHAI%2ECOM%2E+%0D%0A16+PHAMLUYEN %2ENET %2E+%0D%0A17+RADUONG%2ENET%2E+%0D%0A18+SAIGONMARK%2ECOM%2E+%0D%0A19+TEMP4YOU %2ENET%2E+%0D%0A20+THANHKY%2ENET%2E+%0D%0A21+TINHCAVN%2ECOM%2E+%0D %0A22+TRUCXANHVN%2ENET%2E+%0D%0A23+TUOITRETAIHOA%2ECOM%2E+%0D%0A24+TUTHIENONLINE %2ECOM%2E+%0D%0A25+VUIVOINET%2ECOM%2E+%0D%0A26+XLUKE%2ENET%2E+%0D %0A%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D %3D&UserName=782313927&EmailAddress=112156084%40&EmailAddress%5Ftwo=112156084\ %40&user=782313927&Email=112156084 %40&emailconfirm=112156084%40&timeonl=2847 Uh oh! Cái đây? Thử decode xem chứa gì, %2, %3 xem tổ mù mắt: Code: POST /forum/ HTTP/1.1 Accept: */* x-flash-version: 7,0,19,0 Content-Type: application/x-www-form-urlencoded Content-Length: 2387 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Cookie: session_id=433ab8bcc276414badb0e83891bbb9a6 Host: www.quangvinhonline.info X-Forwarded-For: 203.210.233.28 Connection: Keep-Alive Cache-Control: no-cache, bypass-client=203.210.233.28 hotlinks=Offical.com&comdoss=attack&port=80&url1=http://www.hvaonline.net/forum/ &url2=http://www.hvaonline.net/forum/ &http://www.xxx.com/Forum/index.php=&act=Reg&code=02&coppa_user=0&PassWord=12345 6&PassWord_Check=123456&agree=1&imie=Only U&nazwisko=Frem\ &kraj=AG&adres1=Hien kem&adres2=&miasto=Hiam city&kod=51451&HT=Hacker_VietNam&EM=gianghomang@yahoo.com&PW=123456&rPW=123456&D angKy=nananaBD\ &telefon_a=574&telefon=52415487 &mail1=jand@yahoo.com&mail2=jand@yahoo.com&pass1=jand@yahoo.com&pass2=jand@yahoo com&ret=0&question=jand@yahoo.com&answer=jand@ &s=&do=addmember&url=http://64.207.189.5&password_md5=&passwordconfirm_md5=&pass wordconfirm=123456&referrername=Nokia&timezoneoffset=0 &dst=2&options[adminemail]=1&options[showemail]=1$#$@$^$@#!@#$!@#$@!&1 42A3KCT.NET BAODIENTUVN.COM CANDYKID.NET CVK3N.COM \ CVK3N.NET DIEMTUYENSINH.COM DNSTBVN.NET HACKER4A.COM HOAIANH.COM 10 LAMHONGHUYEN.COM 11 LAMHONGHUYEN.INFO 12 LAMHONGHUYEN.NET \ 13 MUSIC4VN.COM 14 NVBH7.COM 15 THANGKCT.NET 16 TINHBANVIETNAM.ORG 17 TUOITRE.INFO 18 VIETSTAR.INFO ==================1 4RTRITHUC.COM \ ANHEMCLUB.ORG r u crazy???.COM BARIA-CLUB.COM CANHHAO.COM DONGTRANG.COM HOAHOCBKHN.COM INTELNEW.COM KHUCTINHCA.COM \ 10 LAONHAO.NET 11 LYSOCHANTHUYEN.ORG 12 NHANVAN.ORG 13 NHIPDIEUVN.COM 14 NHUNGANHSAOBANG.COM 15 NTQUOCKHAI.COM 16 PHAMLUYEN.NET \ 17 RADUONG.NET 18 SAIGONMARK.COM 19 TEMP4YOU.NET 20 THANHKY.NET 21 TINHCAVN.COM 22 TRUCXANHVN.NET 23 TUOITRETAIHOA.COM 24 TUTHIENONLINE.COM \ 25 VUIVOINET.COM 26 XLUKE.NET ====================&UserName=782313927&EmailAddress=112156084@ &EmailAddress_two=112156084@&user=782313927&Email=112156084@&emailconfirm=112156 084@&timeonl=2847 Cái bật hai đoạn trên? Đúng rồi: x-flash Tại lại có chuyện dùng flash để "duyệt" HVA forum? Ngồi x-flash cịn có bật? Có q nhiều điểm bật payload Tuy nhiên, ứng dụng yếu tố định phải chọn đâu payload Hãy thử "dựng" lại gói tin thuộc "stream" tương tự để xét xem chúng có đặc biệt mặt chuyển gởi chuyển nhận gói tin: {link ảnh die} Những điểm khoanh lại điểm xem "bắt mắt" Trước tiên thấy packets xử dụng TCP sequence, gởi SYN, gởi ACK, sau tiếp tục gởi tới ACK,PSH có encapsulated -8- HTTP Sở dĩ có mảnh "continuation" contentlength có chiều dài đến 2205 bytes, lớn để khít vào MTU -9- phải gói gói tin tcp ACK,PSH muốn mảng thơng tin đến HVA server nhanh tốt (càng nhanh HVA server mau chết) Sau đuôi RST (hiển thị hình [TCP ZeroWindow] Nhìn xuyên qua hợp lệ xét cho kỹ "stream" lại kết thúc RST thay FIN? Hơn nữa, sau hồn tất mảng "continuation" thứ nhì thuộc sequence 240 (xem cột bên tay trái), đến sequence thứ 1154 gởi RST packet đến HVA server? Điều có nghĩa HVA server phải "ngóng chờ" nguồn tin từ IP tiếp tục hiệu, khơng server đợi "time out" Đợi đến lúc "time out" hay đợi đến sau gần 1000 sequence khác gởi RST khơng khác nhiều cho (đặc biệt kernel HVA server chỉnh sẵn TCP time out ngắn) Đây ứng dụng flash "chuối chiên" tơi khơng tin người tạo flash ấn định nên gởi FIN hay nên khởi RST? Cũng nguồn nguyên thủy (máy đó) chạy flash xuyên qua đường dẫn tệ nên TCP sequences cách xa? Có thể kẻ tạo flash chẳng thèm để ý đến "phương hại" tinh vi này, dội HVA server nhiều, tốt Sau xem xét hàng loạt stream có lồng mảng "HTTP POST" hình thành số liệu thống kê, ghi lại giá trị HEX -10- số chi tiết bật, bất biến vị trí offset (khung màu đỏ hình) chúng từ TCP "stream" để dành cho bước ngăn chặn sau Tôi không dành nhiều thời gian để tẳn mẳng nội dung POST payload nhìn sơ qua thấy "chủ nhân" mớ x-flash để lộ nhiều chi tiết giúp truy danh tánh Đây lại chuyện khác, thật khơng hứng thú tìm hiểu "chủ nhân" mớ x-flash Tôi log vào HVA server lần "grep" -11- xuyên qua vài log cũ web server chạy HVA Ái chà, "bệnh" x-flash xảy nhiều ngày HVA không "chết" nổi, chậm lại lúc cao điểm, chứng tỏ chiến thuật x-flash không hữu hiệu? Hay "chủ nhân" mớ x-flash cài chúng "sống chết mặc bây"? Tơi tiếp tục đào sâu mớ log cũ HVA để hình thành vài số thống kê Sau "chọc ngoáy" log files ghi thành trang notepad chi chít chi tiết, tơi hình thành nhiều thơng tin lý thú, Những thông tin phức tạp tế nhị nên công bố rộng rãi cho độc giả Tơi đành phải tạm tóm lược sau: - bệnh x-flash xảy nhiều tháng - trung bình ngày có khoảng +- 15,000 requests dùng x-flash vào HVA forum - request thường tập trung từ khoảng chiều khuya VN - cao điểm request "đụng" vào HVA khoảng tối Có thể rút tỉa điều thuộc phương diện kỹ thuật từ thơng tin nhỉ? - đám "x-flash" xếp loại vào dạng DDoS chúng đến từ nhiều nguồn (IP) khác lúc - chúng có đặc tính (nói mặt giao thức, kích thước thái độ) - có số "stream" vào có tính chất x-flash phá hoại không mang "x-flash" header HTTP POST, có lẽ chúng proxy server "lột" header? - chúng hoàn toàn hợp lệ mặt giao thức cấu hình server HVA tiếp nhận chúng với "vòng tay rộng mở" - dường chúng gởi đến từ máy thời điểm duyệt Internet cao độ ngày Với nhận định trên, tin "con" x-flash không chủ nhân điều tác theo kiểu master / zombies thơng thường mà cách cài "x-flash" diễn đàn tương tự HVA Khi người dùng duyệt trang web có gắn "x-flash" này, chúng dùng làm phương tiện để gởi request đến HVA server Số lượng người truy cập diễn đàn nhiều số lượng request gởi đến HVA cao Vậy, HVA phải đối phó sao? - cản? cản ai? cản gì? phải cản cản mớ IP gateway proxy server từ VN (là chủ yếu) chuyện xảy ra? Đúng vậy! "x-flash" "deny service" thành cơng buộc HVA phải cản ln "kẻ vô can" chơi quái dị - không cản? "căn bệnh" đeo đuổi sao? để chuyện xảy ra? tất nhiên HVA server "chết" ảnh hưởng đến thành viên (và khách) truy cập đến diễn đàn HVA ảnh hưởng tiêu cực (chậm, đứt qng, phí tài ngun, phí băng thơng ) Có đầy đủ kiện cần thiết, tơi bắt đầu hình thành chiến thuật "trị" "trị" xin độc giả đón xem phần Các bạn theo dõi tiếp phần http://hvaonline.net/hvaonline/posts/list/177.hva Chú thích: -7- stream chuỗi tin khởi đầu từ SYN kết thúc FIN theo quy trình Một stream chứa gói tin / vào từ mở connection đến connection tắt bỏ (vì lý đó) -8- encapsulated "lồng" gói tin thuộc tầng vào gói tin thuộc tầng (HTTP giao thức tầng application lồng vào TCP giao thức tầng transport) -9- MTU Maximum Transmission Unit, giá trị quy định tối đa có bytes chứa mảng tin bao gồm header, thông tin trải từ link layer trở lên Nếu gói tin q giới hạn MTU phải bẻ nhỏ thành nhiều mảng (fragmentation) Ethernet có MTU 1500 bytes tối đa cho mảng, IEEE 802.2/802.3 có MTU 1492 tối đa cho mảng, FDDI (optic fibre) có MTU 4352 tối đa MTU đạt 65535 cho Hyperchannel Xem thêm chi tiết từ sách chuyên TCP/IP -10- HEX viết tắt hexadecimal -11- grep lệnh phổ biến *nix dùng để tìm đoạn chữ có dạng mẫu hồ sơ (chú thích dành cho chưa dùng *nix) Sáng 12/10 Sáng cơng việc có phần thư thả ngày, định log vào server HVA để bắt đầu xem xét cẩn thận cấu hình kernel / firewall / web server xem thử cần phải làm để "trị" bệnh x-flash Tôi quên bẵng firewall / proxy công ty không cho phép thẳng đến cổng 22 -12-, đớ người không vào HVA server Tôi "bị" kẹt vụ lâu phải biến cổng SSH firewall riêng nhà từ 22 thành 443 firewall hãng cho truy cập đến cổng 80 443 (xuyên qua proxy dùng HTTP CONNECT), chuyện khác, lại lạc đề Sau vài phút trầm ngâm, nảy ý tạo tunnel từ máy đến firewall riêng nhà tạo ssh connection từ máy đến HVA server xuyên qua tunnel Biết "tunnel tunnel" -13- chuối chậm, khơng cịn cách khác Sau phút thử nghiệm, tơi thử: Code: $ ssh localhost -p 25250 (localhost lắng nghe cổng 25250 forward thông tin đến firewall riêng tơi nhà, từ đến HVA server) Ái chà, chạy! Hơi chậm tí khơng Tơi mở thêm console khác xuyên qua tunnel Tốt rồi, hai shell đủ làm việc Tơi tìm hồ sơ mà tơi hí hốy ghi xuống chằng chịt ngày hơm trước rà xun qua Đây Hơn 15 ngàn request đến HVA server ngày Tập trung khoảng đến 10 tối VN, cao điểm Từ đến 10 tối có độ chừng 10 ngàn đến 12 ngàn x-flash requests Có khoảng truy cập hợp lệ cho 30 giây (HTTP GET, HTTP POST) thành viên duyệt diễn đàn diễn đàn đông Cứ cho cao điểm có 12 ngàn x-flash requests đến HVA server, số "lẻ tẻ" cịn lại khơng đáng kể (12000 requests / 120 phút) / 60 giây = 1.6 request giây Nói mặt tần số truy cập số cao Dựa số liệu thành viên truy nhập diễn đàn gởi / xem cách hợp thức bình thường (lấy từ log web server) xấp xỉ: (200 thành viên sign-in / 60 phút) / 60 giây = 0.05 request giây So sánh hai số tần số "truy cập" bất hợp lệ (x-flash) gấp 32 lần tần số truy cập hợp lệ Kinh nhể? Câu hỏi câu trả lời giai đoạn trở nên hiển nhiên: - hỏi: vơ hiệu hố truy cập bất hợp lệ đây? trả lời: giới hạn truy cập bất hợp lệ - hỏi: giới hạn giới hạn nào? trả lời: hèm tính tốn Phải hình thành cơng thức để tạo giá trị trung bình kết nối bình thường từ hình thành giới hạn hợp lý Vì HTTP giao thức có tính stateless -14- cho nên, thơng tin client (trình duyệt) server (web server) thường kết thúc nhanh tốt connection tắt bỏ sau quy trình chuyển gởi thơng tin hồn tất Tuy nhiên, q trình chuyển đổi, client server mở thêm connection liệu truyền lớn cần chuyển tải thông tin nhanh chóng Mục đích để đẩy thơng tin đến client (hoặc server) nhanh tốt (HTTP GET HTTP POST) Hãy xem thử x-flash stream xem Tôi điều chỉnh hai console kết nối vào HVA server cho chúng nằm song song Trên console thứ "tail" web server log HVA, console thứ nhì tơi chạy netstat À ha, có vài xflash vào, lấy IP hiển thị console theo dõi log web server chuyển sang console có chứa netstat Hãy thử IP 221.132.39.253 xem sao: Code: [root@hvaonline tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp httpd]# netstat -nat | grep 221.132.39.253 192.168.1.100:80 221.132.39.253:4548 192.168.1.100:80 221.132.39.253:4544 723 192.168.1.100:80 221.132.39.253:4545 723 192.168.1.100:80 221.132.39.253:4546 723 192.168.1.100:80 221.132.39.253:4547 192.168.1.100:80 221.132.39.253:4523 192.168.1.100:80 221.132.39.253:4526 192.168.1.100:80 221.132.39.253:4527 192.168.1.100:80 221.132.39.253:4494 192.168.1.100:80 221.132.39.253:4504 192.168.1.100:80 221.132.39.253:4505 SYN_RECV LAST_ACK ESTABLISHED ESTABLISHED ESTABLISHED TIME_WAIT CLOSE_WAIT CLOSE_WAIT TIME_WAIT TIME_WAIT TIME_WAIT Cha chả, 221.132.39.253 tham lam nhỉ? có đến "ESTABLISHED", lại thêm "SYN_RECV" mớ "CLOSE_WAIT", "TIME_WAIT" Dựa thông tin hình minh hoạ "thái độ" tham lam hoàn toàn phù hợp, lẽ, HTTP POST có payload đến ngàn bytes phải địi mở thêm connection để "đẩy" kiện đến HVA server nhanh tốt mà (bạn có để ý đến chi tiết ACK-PSH TCP segment chứa HTTP POST nói trước khơng?) Tơi tiếp tục theo dõi thấy 221.132.39.253 có đến tám "ESTABLISHED" thảy suốt trình hối POST lên server HVA, điều có nghĩa có SYN gởi đến HVA server legitimate request (u cầu truy cập hợp pháp) HVA server không cản mà cho chúng xuyên qua bước TCP handshake đến tình trạng "ESTABLISHED" Có thể "ESTABLISHED" không dành riêng cho stream mà có dùng chung IP để truy cập HVA server Có lẽ đường dẫn IP HVA server chuối, có lẽ bị nghẽn đồng đội hối flood HVA, cho nên, phải đòi mở nhiều connection đến HVA server đến Như vậy, tổng số socket cần mở cho 221.132.39.253 đồng đội (từ nhiều IP khác) cho tất stream lớn Cứ cho stream chứa HTTP POST mở connections, có: Code: ( 12000 requests tạo ) 12000 streams x sockets = 72000 connections (cho giờ) ( 72000 connection / 120 ) / 60 = 10 connections cho giây Ôi giời ơi, mà kinh thế? Cho dù SYN state thoát nhanh, cho dù ESTABLISHED state chiếm vài giây hậu mớ "TIME_WAIT" "CLOSE_WAIT" sau "ESTABLISHED" tắt bỏ thật khinh khủng Tôi tin tưởng vào ý định dùng giới hạn connection thay giới hạn packet rate -15- Lý đơn giản: người dùng bình thường cần connections nhiều (tơi đốn với nội dung thơng thường trang HVA forum) Chỉ có "x-flash" tham lam cần connections HTTP POST chứa payload q lớn Để bảo đảm, tơi dùng trình duyệt để thử truy cập vào trang diễn đàn HVA Hèm, thử netstat console xem sao: Code: [root@hvaonline root]# netstat -nat | grep xxx.xx.xxx.98 tcp 0 192.168.1.100:80 grep xxx.xx.xxx.98:9322 SYN_RECV tcp 192.168.1.100:80 grep xxx.xx.xxx.98:9313 LAST_ACK tcp 198 192.168.1.100:80 grep xxx.xx.xxx.98:9307 ESTABLISHED tcp 198 192.168.1.100:80 grep xxx.xx.xxx.98:9306 ESTABLISHED tcp 0 192.168.1.100:80 grep xxx.xx.xxx.98:9303 TIME_WAIT tcp 0 192.168.1.100:80 grep xxx.xx.xxx.98:9288 CLOSE_WAIT tcp 0 192.168.1.100:80 grep xxx.xx.xxx.98:9292 TIME_WAIT Rất tiếc tơi phải xố IP thay xxx.xx.xxx.98 IP IP tồn thời (tôi muốn ăn ngon, ngủ yên nên tiết lộ IP mình) Trở lại câu chuyện chính, bất chấp vào trang nào, bất chấp trang có nhiều hay thơng tin, tơi khơng thấy có connection diện cho lần Tơi thử lệnh netstat máy xác nhận điều Phần lớn connections cho lần, ngoại trừ trang lớn thấy có connections tỉ lệ 1/100 (xấp xỉ 100 lần duyệt có lần) Một chi tiết đáng nêu là: thời gian socket nằm vị trí "ESTABLISHED" chưa lâu giây, phần lớn 1/2 giây giây tối đa Điều giúp rút vài điều lý thú: - trình duyệt cần tối đa connection để duyệt trang Bạn thử "decode" hai signatures để xem làm cho nhộn snort signature , không mở rộng thêm - nhóm GET khơng có "x-flash" header, thật khơng cần phải thay đổi thêm khơng ảnh hưởng nặng nề POST đến HVA server cú GET lấy static images không "đụng" mảy may đến database query nên ảnh hưởng đáng kể ảnh hưởng socket Đối với web server, số MaxRequestPerChild cần thay đổi để child process tiếp nhận nhiều request bình thường (xem trước) Mục đích để tránh trường hợp chúng bị hủy nhanh (vì có q nhiều GET request vào) lần bị hủy, mother process phải tạo thêm child process làm gia tăng server load chúng tạo thường xuyên Đối với kernel socket, giá trị max_orphan, syn_back_log, timeout, tcp_mem, keepalive_time cần điều chỉnh để gia tăng hội nhận SYN giải SYN Server load tăng việc cần thiết để bảo toàn hội truy cập cho người dùng hợp lệ (ở mức tối đa tài nguyên cho phép) Ngồi thay đổi này, tơi cịn có thêm giải pháp phịng bị tơi khơng ứng động mà cài sẵn để yên miễn bàn thêm giải pháp phịng bị Trong GET ví dụ có GET đặc biệt: Code: GET /forum/?&time=0.13435 HTTP/1.1 Accept: */* x-flash-version: 7,0,19,0 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; Hotbar4.5.3.0) Host: quangvinh-vn.net X-Forwarded-For: 203.210.194.254 Connection: Keep-Alive Cache-Control: bypass-client=203.210.194.254 Trong tcp stream, xuất "anh chàng" Nó chẳng GET static images cú GET mà lại GET URI kỳ quái: /forum/?&time=0.13435 Cú GET thuộc sequence tiếp nối tcp stream lại forward cho máy có IP 203.210.194.254 qua gateway có IP 203.160.1.66 Bởi lẽ sequence thuộc tcp stream hợp lệ (và cho phép vào theo quy chế connection limit) nên cú GET đụng đến web server Chuyện hiển nhiên xảy web server HVA báo lỗi "khơng tìm thấy" cú GET trỏ vào URI khơng tồn Cũng cú GET khác tcp stream, cú GET có dụng đích khơng khác việc tạo thêm socket HVA server Đi xuyên qua tcp stream phân tích, tơi thấy lác đác chừng tá cú GET tương tự Tôi không cho cú GET quan trọng lần tơi phán đốn sai kể từ lúc bắt tay vào phân tích dạng DoS HVA Từ kết phán đốn sai, tơi khơng phịng thủ trước Trong suốt vài ngày kế tiếp, HVA server bị công với loại GET có URI "/forum/? &time" Tơi học học không bỏ qua chi tiết đáng ngờ mà lần sai phạm nguyên tắc để vất vả ngày tới Sự thể sao, mời bạn xem tiếp kỳ sau Các bạn theo dõi tiếp phần http://hvaonline.net/hvaonline/posts/list/209.hva Chú thích: -48- "tcp stream", bạn hẳn nắm tcp stream Tuy nhiên, để tránh nhầm lẫn nhiều khái niệm thuật ngữ bài, tơi định đưa thêm thích "tcp stream" tcp stream "xuất" giao tiếp client server Nó bắt đầu SYN request từ client kết thúc FIN từ client "xuất" giao tiếp thực quy cách "Xuất" giao tiếp chứa nhiều sequences mang tcp flags khác trình trao đổi client server sequence từ phía (client server) "entry" tcp stream -49- SYN FLOOD dạng denial of service phổ biến từ đến cuối thập niên 90 Cho đến nay, SYN FLOOD xuất rải rác hệ điều hành, routers, firewall ngày nâng cao để loại trừ dạng DoS cổ điển Tổng quát mà nói, dạng SYN FLOOD "truyền thống" lợi dụng tính chất (và điểm yếu) giao thức TCP IPv4 để công Kẻ công gởi hàng loạt SYN request đến máy chủ nạn nhân sau nhận SYNACK từ máy chủ, khơng gởi gói ACK để hồn tất 3-way handshake Điều làm cho máy chủ tiếp nhận thêm connection sau khoảng thời gian ngắn connection queue bị đầy ứ chờ đợi gói ACK hồi đáp từ client Trong trường hợp SYN FLOOD kéo dài, hệ thống bị cạn tài nguyên (bộ nhớ) phải huy động nhiều memory cho socket pool connection queue -50- đọc thêm RFC 2068 RFC 2616 website http://www.rfc.org bạn muốn sâu vào chi tiết tính tác dụng HTTP headers -51- Keep-alive connection theo tiêu chuẩn đưa RFC phương tiện để biến tính "stateless" giao thức HTTP trở nên hiệu ứng Đúng theo nguyên tắc, objects request đến server trả từ server cần phải có connection Ví dụ, trang có 10 hình gif, thơng thường trình duyệt web server phải tạo 10 connection riêng biệt cho cú GET để lấy hình (vì hình có href (đường dẫn) riêng trình duyệt, chúng có URI khác nhau) Tuy nhiên, "keep-alive" đòi hỏi server client giữ nguyên connection hình thành từ đầu để tiếp tục chuyển gởi gif files thay phải mở thêm connection Làm giúp giảm thiểu quy đoạn tạo thêm sockets cho trang web lớn, có nhiều hình ảnh Làm có hại với connection thiết lập, client request hàng "tấn" liệu server phải ngoan ngỗn phục vụ khơng ngừng nghỉ (tương tự tình trạng dùng teleport wget để "rút ruột" trang web), dẫn đến tình trạng tải máy chủ trình "rút ruột" tác động trực tiếp đến dịch vụ xung quanh web service Giá trị "keep-alive" nên cân nhắc kỹ muốn tối ưu hoá web server dao hai lưỡi - Nếu bạn cho phép mở nhiều socket server (không dùng quy chế connection limit đó) khơng nên dùng "keep-alive" tạo load theo mức cấp số đến server (vì nhiều sockets + nhiều keep-alive) - Nếu bạn giới hạn sockets server (dùng quy chế connection limit đó) bạn dùng "keep-alive" phải tính tốn giá trị thời gian thích hợp để "keep-alive" tùy theo nội dung độ lớn (chữ hình ảnh) trang Cách tối ưu hố hay tính cho trang duyệt cần socket đủ thời gian "keepalive" để trình duyệt tải -52- Có hai khái niệm "anonymous proxy": - dạng proxy client dùng để duyệt web "lột" bỏ hết header cá biệt trình duyệt mà client (có / dùng) gởi đến proxy server Các gói tin xuyên dạng proxy khơng cịn đặc tính cá biệt ngồi proxy trang bị cho - khái niệm khác anonymous proxy không thuộc tinh thần "anonymous" đề cập viết Đó dạng proxy dùng khơng cần phải khai báo tên người dùng mật Loại proxy tương phản với "user proxy", buộc người dùng phải khai báo Loại "anonymous proxy" "user proxy" có tính "lột bỏ" header cá biệt trình duyệt dạng Chiều 2/11: Hôm bận rộn kinh khủng nên không vào HVA Mãi đến lúc gần tan sở, log vào diễn đàn để lướt nhanh qua xem có mục hấp dẫn khơng Điều tơi nhận truy cập đến diễn đàn HVA cực chậm Tơi nhận vài PM có hai từ JAL JAL cho biết diễn đàn bị DoS liên tục từ khuya hôm qua đến bây giờ, JAL nhận định cú GET dạng /forum/?&time=0.13435 có lẽ cơng xảy diễn đàn Tôi vội log vào HVA server để xem xét tình hình Ngay tạo đuôi tail đến web server log HVA, tơi chống váng tốc độ dồn dập loại GET Bởi web server log khơng có khả tường trình chi tiết cần thiết để đánh giá loạt công xảy ra, chạy phát tcpdump chọn option lệnh cho tcpdump ghi nhận đầy đủ hết tất thông tin hàm chứa tầng giao thức -53- Sau vài phút, hối tải mớ "dump" laptop, tiện tay chép log web server Sau đó, tơi điều chỉnh cho firewall giảm bớt số lượng connection cho phép để tạm giảm thiểu độ tải server phóng cửa cho kịp chuyến tàu nhà Trên tàu lửa, mở đoạn dump vừa tạo để xem xét thể Dán chặt đơi mắt vào hình laptop, tơi thật chống nhìn thấy nội dung mớ tcpdump vừa lấy lúc Tơi tự rủa khơng ngớt xem nhẹ /forum/?&time=0.xxxxx ngày hơm qua lại tự an ủi thắt chặt connection limit trước rời sở Dẫu HVA server không bị "xụm" bà thành viên muốn vào diễn đàn khổ sở số lượng GET theo dạng có số kinh khủng Theo tính tốn sơ khởi, tơi ước tính có chừng xấp xỉ 1200 SYN request giây đến HVA server cú SYN hoàn toàn hợp lệ hồi báo cú ACK tiếp tục dùng ASK-PSH để đẩy cú GET đến web server Điều đáng nói nửa request dạng hồn tồn khơng có "x-flash" header cấu trúc HTTP header gởi đến đơn giản: Code: GET /forum/?&time=0.05536 HTTP/1.1 Accept: */* Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Host: quangvinh-vn.net Connection: Keep-Alive Có điều đáng nói cách tổng quát là: Giá trị /forum/?&time=x.xxxxx hoàn toàn ngẫn nhiên (random) Tơi cho tính random có dụng ý để đánh lừa chế detect dựa pattern Nếu chế cản lọc cụ thể cho URI dạng /forum/?&time=0.05535 trở nên vơ ích chẳng "match" chúng tự vào Giá trị Connection: Keep-alive lần có tác dụng rõ rệt khơng cần mở nhiều sockets, cần dùng socket mở mà gởi /forum/?&time=x.xxxxx với giá trị x.xxxxx thay đổi ngẫu nhiên Điểm ảnh hưởng nặng nề firewall HVA chỗ IP cần connection (trong connection cho phép) đủ để liên tục gởi GET request Giới hạn connections trở nên thừa thãi dựa nguyên tắc Thật tế connection cho phép tận dụng triệt để Bởi có 1200 SYN xảy giây Tôi không rõ giá trị "keep-alive" "chủ nhân" chúng ấn định rõ ràng hay vơ tình mà gán cho chúng Nếu thật dụng ý cụ thể phải nói khả cân nhắc chuẩn bị cho việc công HVA lần khác xa lần trước Các cú GET khơng mang "x-flash" header qua khỏi snort mod_security dễ dàng Tôi không rõ chúng có bị proxy server đứng trước "lột" header hay khơng khơng có chứng điều Tuy nhiên, chuyện có việc thực "anonymize" -54- proxy "lột" header đến mức độ khơng cịn dấu tích (ngay dấu tích proxy server thực chuyện "lột") Song song với cú GET với URI "ngẫu nhiên" trên, hàng loạt cú GET đến banner swf đồng thời xảy có GET banner mà Theo tôi, đợt công tổng hợp, liên hồn, cố tình làm tê liệt tài nguyên máy chủ HVA: GET HVA banner để tạo load bình diện static image chiếm socket, GET URI "ngẫu nhiên" để tạo load máy chủ bình diện tác động đến database Đối với shared hosting server bình thường đó, cần 1/3 khối lượng "cơn lũ" đủ đưa server nghỉ mát chế phịng thủ server khơng chặt chẽ Có lẽ bạn cịn thắc mắc điểm lại kinh khủng đến vậy? Tơi cố gắng giải thích giới hạn cho phép sau: ảnh hưởng URI ngẫu nhiên: Một request dạng http://www.hvaonline.net/forum/?&time=0.05536 qua ba giai đoạn: - qua FW: passed - hồn tồn hợp lệ - qua snort: passed - khơng match - qua mod_security: passed - khơng match ln Khi lên đến tầng web server, có chuyện xảy ra: - trước tiên web server vui vẻ tiếp nhận nhận thấy cú request chẳng có sai cả, có lẽ request dạng thuộc phần hành php lo Bởi thế, web server nhận lấy chuyển đến php - php giao cho request từ web server, tiếp nhận Để hồn tất request này, liên hệ database để xem cú GET nên dùng "skin" để hiển thị - nhận cú request chẳng ăn nhập vào đâu, tạo trang mặc định với tài khoản guest trả lại cho web server - bước kế tiếp, web server trả kết cho trình duyệt gởi request, đồng thời tường trình access status 200 web log, cộng thêm dăm ba error 404 có vài gif khơng tồn (khi dùng trang mặc định) Một cú GET vào lưu lại log web server sau: Code: xxx.xxx.xxx.xxx - - [02/Nov/2004:06:26:32 -0500] "GET /forum/?&time=0.13435 HTTP/1.0" 200 12933 "-" "Mozilla/4.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)" Bạn thấy: * status 200 dòng log biểu thị web server tiếp nhận cú GET * biểu thị "-" đứng trước "Mozilla/4.0" cho thấy, web server, cú request trực tiếp từ bên mà chẳng "refer" từ link diễn đàn HVA Kết cục, GET ngẫu nhiên hồn tồn thành cơng phương diện tạo load cho máy chủ tầng Hạn chế rõ rệt URI ngẫu nhiên giá trị bất biến đứng trước dấu = Đối với snort, detect giá trị đơn giản, dạng HEX có giá trị: 2F 3F 26 74 69 6D 65 thuộc vị trí offset 0040 - 0050 gói HTTP chứa cú GET Đối với mod_security, regex (xem thích 42) dễ dàng bắt cản trước sâu vào bên Điều cần nêu lên sáng kiến tạo giá trị ngẫu nhiên cho URI "tác giả" cú GET nhằm phần gây khó khăn việc cản trở chúng Nếu web admin dựa web log mà đánh giá thể khó lịng nắm bắt vấn đề ảnh hưởng giá trị connection: keep-alive: Giá trị keep-alive có tác dụng trực tiếp hỗ trợ xảy phần Cứ cú truy cập thành công dựa vào địi hỏi "keep-alive" này, nắm giữ socket liên tiếp gởi hết cú GET đến cú GET khác xuyên qua ESTABLISHED connection Bởi lẽ có nhiều cú gởi từ IP (IP proxy server chẳng hạn) đến q dồn dập, nên khơng có khoảng thời gian gián đoạn, "keep-alive" hoàn toàn bền bỉ trường hợp Từ máy con, trình duyệt không cần phải tạo thêm connection mà đặn đẩy GET đến HVA server Nếu connection có khả "keep-alive" liên tục gởi hàng trăm cú GET giới hạn connections cho phép chúng gởi hàng ngàn cú GET mức độ bền bỉ thật bền bỉ (xem thích 51) May thay, đường dẫn từ gateway cú GET đến HVA server khơng tình trạng tuyệt hảo Có cú GET gởi đến, có ấn định "keep-alive", chúng bị gián đoạn bị nghẽn mạng Thời gian gián đoạn dài thời gian ấn định để "keep-alive" nên chúng phải tạo connection để tiếp tục vào HVA web server lần gián đoạn xảy ra, dường gián đoạn tạo nên ảnh hưởng dây chuyền Các cú GET khác nối đuôi vào bị chậm lại có trường hợp hồn tồn bị tan biến (dựa theo thông tin từ tcp stream lấy qua tcpdump) Mỗi phương tiện "keep-alive" gián đoạn, chúng lại bị rơi vào vòng quản chế firewall connection limit phải tạo socket Giả sử cú GET không ấn định giá trị "keep-alive" đặc biệt HVA web server không hỗ trợ tính chất "keep-alive" sao? Thì cú GET vào phải tạo socket riêng cho Với giới hạn connection limit, IP dùng để gởi cú HTTP GET gởi tối đa cú GET lúc Tính chất "keep-alive" hỗ trợ web server HVA lúc khơng ngồi lý cải thiện vận tốc truy cập cho người dùng, cú "bấm" trình duyệt cho phép họ tải trọn trang HVA xuyên qua socket hình thành Vì lý "cải thiện" cho người dùng hợp lệ mà HVA web server phải rơi vào tình trạng "è lưng chịu đấm" DoS Hạn chế ấn định "keep-alive" đâu? Hiển nhiên phụ thuộc vào hỗ trợ web server Để giới hạn nhiều cú GET xuyên qua ESTABLISHED connection, "keep-alive" web server HVA phải hồn tồn tắt bỏ Chỉ với cách "ép" điều tác theo quy chế connection limit từ firewall ảnh hưởng HTTP header khơng có "x-flash": Bởi cú GET ngẫu nhiên hoàn toàn khơng có dấu hiệu thuộc "x-flash" (tơi nghi ngờ chuyện vơ tình x-flash bị proxy server anonymize), chế cản lọc HVA hoàn toàn mở ngỏ cho chúng vào Cái dễ hiểu chúng hồn tồn hợp lệ bình diện giao thức Điểm ảnh hưởng thứ hồn tồn tương thích với hai ảnh hưởng Tơi khơng thể tìm cớ chứng tỏ cú GET dạng khơng có "x-flash" header vào cố tình khơng có header hay vơ ý bị proxy server "lột" Ngay việc truy ngược lại IP gởi cú GET tiết lộ hops xuyên qua thông tin thu lượm mơ hồ để xác định rõ ràng tạo cách có chủ định hay khơng Cho dù tơi xác định đường đến HVA server phải qua proxy server để xác định có chức "anonymize" hay khơng khơng thể Dù nữa, gần nửa số lượng GET vào với URI ngẫu nhiên hồn tồn khơng mang "x-flash" header hiển nhiên chế cản trở có HVA server khơng có tác dụng hiển nhiên chúng đóng góp khơng đến việc làm cho HVA server đứ đừ Nói mặt hạn chế cú GET khơng có "x-flash" header trước điều chỉnh lại firewall, snort, mod_security số chế khác chúng khơng bị hạn chế Những cú request tương tự cú request "vơ tội" đến từ trình duyệt người dùng bình thường mang theo thơng tin sai sót địa Theo nguyên tắc, web server phải tiếp nhận thông báo đến trình duyệt khơng thoả mãn request (tường trình error status đó) Kiện tồn "cơn lũ" hai điểm tự nhiên khắc phục ảnh hưởng thứ ảnh hưởng cú GET đến HVA banner: Tôi cho cú GET đến HVA banner (swf file) vơ ích trường hợp Ấn định "keep-alive" tạo socket để lấy swf file hiển nhiên proxy server đứng trước client gởi GET request tự động dùng có cache để cung cấp cho client Đối với HVA server, số lượng sockets tạo cho cú GET tạo ảnh hưởng "chen lấn" đến cú GET với URI ngẫu nhiên không mang lại tác dụng rõ rệt Thực tế, chúng cịn tạo ảnh hưởng đối nghịch với cú GET với URI ngẫu nhiên chúng làm giảm hội mở thêm socket cú GET với URI ngẫu nhiên Đặc biệt phương tiện "keep-alive" khơng thể trì đường dẫn xấu bị gián đoạn lý Nói mặt ảnh hưởng cú GET banner chẳng so với cú GET với URI ngẫu nhiên Lý do: - cú GET lấy static image server cú request đơn giản: client hỏi, server trả lời, hoàn tất phủi tay Nếu client hỏi tiếp, server trả lời tiếp hình static tiếp tục xuyên qua socket có sẵn Dịch vụ dạng hoàn toàn static giới hạn đơn tầng - cú GET dùng URI ngẫu nhiên khơng ấn định cụ thể cần "lấy" lại tạo ảnh hưởng đa tầng (như phân tích phần phiá trên) Sau phân tích kỹ lưỡng điểm lợi hại, tơi định hình thành sẵn "rules" để đối phó Tiếc thay, mười lăm phút tàu lửa trơi qua nhanh chóng Tơi đến nhà, đành phải xếp laptop lại tiếp tục sau bữa tối Tối 2/11: Ăn tối xong, hăm hở mở laptop Tôi đâu nhỉ? À, phần snort signature dang dở Phần không nhiều thời gian, phải đưa lên HVA server chạy thử chỉnh chỗ Tuy nhiên cần hồn tất cần "cut & paste" lên server cho nhanh Tơi dành thời gian để hình thành vài filters cho mod_security theo tơi, cửa ngõ tối hậu sau cú GET có URI ngẫu nhiên lọt qua khỏi quy định connection limit firewall Rất tiếc đưa filter vào viết tính nhạy cảm Bạn cần biết tinh thần cản lọc áp đặt để tạo hiệu cao đủ Chưa hồn tất điều tơi muốn bíp bíp bíp Đúng "phước bất trùng lai, hoạ vơ đơn chí", tơi nhận cú gọi khẩn cấp từ sở server quan trọng ngưng hoạt động Tơi lẩm nhẩm: "sorry hva, work comes first!" Tôi logoff HVA server, logon VPN sở trận DoS tuôn vào ạt Tôi biết "cơn lũ" không đủ để "giết chết" HVA server chắn có nhiều người khơng thể vào diễn đàn Tôi phải giải công việc sở xong quay lại Hơn ba đồng hồ trôi qua, rốt tơi hồn tất cơng việc sở, tìm ra, khắc phục cố đưa máy chủ bị ngưng hoạt động trở lại bình thường Tôi lẩm bẩm: "mẹ khỉ, ngày mai lại đồng hồ để viết tường trình rồi." Tôi vội vã log vào HVA server Chậm quá! Cực kỳ chậm! sau hai lần thử tơi log vào Console hiển thị thông tin chậm thể chiếu chậm đoạn phim đen chữ trắng Tôi cảm thấy mệt mỏi lắm, nửa đêm sau ngày làm việc dài dằng dặt từ sáng Tôi định tắt bỏ ấn định "keep-alive" HVA web server để khắc chế điểm phân tích phần Tái khởi động web server ba phút có q nhiều processes connections cịn hoạt động Web server phải đợi cho connection hoàn tất tắt bỏ khởi tạo mother process / child processes từ đầu Cố gắng nán thêm vài phút để xem server log, tơi hài lịng thấy tình hình cải thiện rõ rệt sau "keep-alive" khơng cịn tác dụng Server load xuống thấy rõ truy cập vào diễn đàn nhanh Tôi vương vai, ngáp dài logoff khỏi HVA server Tôi lẩm bẩm: "phải ngủ khơng ngày mai dậy khơng Có chuyện ngày mai tính tiếp." Các bạn theo dõi tiếp phần 10 http://hvaonline.net/hvaonline/posts/list/211.hva Chú thích: -53- tcpdump cho phép sniff tường trình gói tin vào nhiều chế độ Chế độ dùng để bắt lấy gói tin lần dùng snaplen có giá trị (-s0): # tcpdump -s0 port 80 -w /tmp/dump Căn mà nói, snaplen số bytes liệu gói tin Theo mặc định, snaplen có giá trị 68 bytes (riêng SunOS có giá trị tối thiểu 96 bytes) Với giá trị mặc định nhỏ bé này, không xác định snaplen gói tin capture bị "xén" (truncated) Bởi thế, -s0 ấn định dùng giá trị thích hợp để bắt lấy trọn gói tin Chỉ nên dùng chọn lựa trường hợp cần thiết hồ sơ "dump" tạo với chọn lựa lớn -54- anonymize "vơ danh hố", xem thêm thích 52 10 Sáng 3/11: Sáng vào sở trễ thường ngày tối qua thức q khuya Nói trễ thật 30 sáng Tôi định dành riêng 30 phút để "thanh tra" HVA server hồn tất tơi bỏ dở trước bắt tay vào chuyện viết báo cáo cố xảy server công ty tối hôm qua Việc thử truy cập diễn đàn HVA trình duyệt Dự tưởng đầu chậm thử hoàn toàn trái ngược với điều nghĩ; vào diễn đàn HVA nhanh bình thường Tuy nhiên, trình duyệt thơng báo "database is not available" Tôi thầm nghĩ: chẳng thèm DoS bên VN 30 sáng database khơng có có lẽ server sống database chết tiêu." Tôi log vào HVA server thật, server HVA vắng hoe; server load nằm mức 0.02 Tôi kiểm tra nhanh qua tình hình server xem có "bị" restart tối hôm qua hay không: $ uptime 05:49:08 up 19 days, 10:04, users, load average: 0.02, 0.02, 0.25 server cịn sống sót sau "cơn bão" kinh hoàng Chạy thử vài lệnh để kiểm tra process rõ ràng database "chết" tự Tôi không rõ database bị "down" từ lúc cần rõ điều Chạy thêm vài lệnh grep đến log, xác định database bị down từ 10 22 phút server, có nghĩa khoảng 22 phút nơi cư ngụ khoảng 22 phút VN Tơi vị đầu lẩm bẩm: "chỉ có vài phút sau logoff HVA server tối hôm qua! không restart lại database server sau restart lại web server nhỉ?" Dù Có lẽ lý HVA server sống sót tối hơm qua database server bị down suốt đêm (?) Tối hôm qua, login HVA server điều chỉnh web service để tháo bỏ ấn định "keep-alive", có lẽ lúc database server tràn ngập QUERY tình trạng "sống dở, chết dở" lại không để tâm đến Có lẽ não bị mụ mẫm sau ngày làm việc dài dằng dặt hơm qua nên khơng cịn sáng suốt để suy xét vấn đề Tôi định để yên database server tình trạng "down" để tiện làm việc - trước tiên, tiện tay kiểm tra cấu hình database xét qua số lượng connection cho phép Giá trị ấn định cao, nên điều chỉnh để giảm bớt số lượng connection tương thích với lượng connection limit ấn định firewall - tơi kiểm tra lại cấu hình web server, điều chỉnh vài giá trị quan trọng ấn định process fork để phục vụ requests (xem lại thích 45) đồng thời đưa vào chuỗi filter cho mod_security - tiếp tục chuyển xuống tầng snort đưa vào signatures dang dở; điều chỉnh thêm vài chi tiết nhỏ để cố gắng tạo hiệu xuất tái khởi động snort Sau tái khởi đông, Snort hoạt động bình thường chưa thơng báo thơng tin vấn đề DoS dạng URI ngẫu nhiên Điều hiển nhiên tơi chẳng thấy dấu hiệu DoS từ lúc logon HVA server - xem xét lại firewall Lần định mở rộng connection limit firewall tương phản với việc thắt chặt nhiều điểm quan trọng web server Sở dĩ tơi làm muốn tạo hội cho người dùng truy cập Làm server load gia tăng giá phải tạo hội cho người dùng hợp pháp truy cập đến diễn đàn Sau hồn chỉnh firewall, tơi tái khởi động (kẻo lại quên) - cuối cùng, dành phần lớn thời gian 30 phút ngắn ngủi để điều chỉnh tất giá trị liên quan đến tcp stack kernel xử lý khối lượng request khổng lồ tương tự tối hôm qua Nguyên tắc điều chỉnh giá trị kernel đơn giản: tơi muốn có tối đa lượng memory phép số lượng socket khổng lồ mở khơng có tệ tình trạng socket bị DoS chiếm hết người dùng hợp lệ vào muốn thời gian cú SYN tồn ngắn bình thường cú SYN dời khỏi hàng đợi (queue) nhanh hội server tiếp nhận thêm SYN nhiều muốn thời gian chờ đợi FIN RST hoàn tất (các giá trị biểu thị TIME_WAIT, FIN_WAIT ) ngắn bình thường cú đợi kéo dài, lượng memory bị chiếm giữ cho socket hồn tất lâu tình trạng ứ đọng DoS kéo dài thay vào việc giảm thiểu thời gian gói tin dạng SYN, gia tăng số lượng SYN tiếp nhận nằm connection queue Tôi muốn số lượng request vào chưa xử lý có hội chờ đợi lâu (trước chúng bị huỷ); tơi khơng muốn trình duyệt người dùng hợp lệ phải "retry" nhiều để vào diễn đàn khoảng thời gian server bị DoS Nên biết syn_timeout khác với syn_backlog, phần ứng dụng cho syn_timeout phần ứng dụng cho syn_backlog (số lượng gói SYN chờ để xử lý) Xét lại phận lần nữa, tơi cảm thấy hài lịng tiến hành khởi động database dịch vụ cần thiết khác Mọi thứ chạy ngon lành từ lượt thử Tôi tạo thêm console đến HVA server hình phóng "đi" tail thứ để theo dõi snort log, thứ nhì để theo dõi thơng báo mod_security tạm ngưng việc "táy máy" với HVA server để bắt đầu vào công việc sở Trưa, chiều 3/11: Suốt bốn vừa qua, lúc có dịp tơi chuyển sang hai console xem chừng có biến cố server hay khơng? Thỉnh thoảng có vài loạt URI ngẫu nhiên vào bị hai phận snort, mod_security tóm chúng cách đặn sau thoả mãn điều kiện connection limit firewall (mặc dù lúc sáng bên VN) Tôi an tâm tiếp tục làm việc Mãi đến chiều, số lần cú DoS vào thường xuyên server load chưa lên khỏi mức 1.0 Tôi mở trình duyệt thử truy cập vào diễn đàn HVA: thơng suốt, nhanh chóng Tơi thử nhấn Ctl-F5 -55- liên tục vài cái: "đồng hồ chờ đợi" lâu Càng nhấn nhiều Ctl-F5, chờ đợi lâu Lý thử nghiệm cách này? Bởi lúc web server HVA khơng cịn chế độ "keep-alive" nữa, cú "refresh" trình duyệt tạo dăm ba sockets với HVA server để tải nội dung diễn đàn trình duyệt Trong lúc loạt connections cú nhấn Ctl-F5 cịn tồn tại, tơi tiếp tục nhấn sockets tạo thêm bị "vướng" vào quy định connection limit firewall tơi tạo thêm connection vượt giới hạn cho phép lúc Nếu thong thả duyệt trang một, trang dừng lại tối thiểu vài mươi giây (trong khoảng thời connection trình duyệt tơi HVA server kết thúc) tơi khơng gặp cản trở Đây tình trạng duyệt web bình thường người dùng hợp lệ Biết ấn định connection limit + "no keep-alive" làm việc "hài hoà" với Tôi an tâm xếp laptop lại chuẩn bị rời sở Tôi tự nhủ tối dành đồng hồ theo dõi chuyện xảy HVA server Tối 3/11: Ăn tối xong, sau hoàn tất chuyện lặt vặt, bắt tay vào việc "thanh tra" HVA server 30 tối nơi cư ngụ 30 chiều VN thử xem Tôi mở laptop lên, phóng trình duyệt để vào diễn đàn HVA: khởi tạo trang chủ chậm sau chuyện bình thường tơi biết lý khởi tạo lại chậm, mỉm cười mở hai console vào HVA server Nhưng thường lệ, xem qua server load: $w bình thường, giá trị server load trung bình 1.1, tốt! Tôi xem qua số lượng SYN hữu server: $ netstat -nat | grep SYN | wc -l 72 nhiều bình thường chắn q so với lũ hơm qua Tôi xem qua số lượng GET dùng URI random mà snort bắt từ lúc signature đưa vào từ sáng nay: # grep -i "random" $SNORT_LOG/alert | wc -l 317476 Kinh nhỉ? Gần 32 ngàn cú vịng 12 qua Tơi muốn xem số lượng GET dùng URI random mà mod_security tóm từ sáng nay: grep -i "?&time" $HTTP_LOG/mod_sec.log | wc -l 17749 Nhiều thật! không hẳn server yên tĩnh nghĩ qua vài lần kiểm tra ngày rõ ràng server load không lên cao từ sáng sau lúc điều chỉnh lại cấu hình server lúc 17749 lần ghi nhận mod_sec.log tương đương với 17749 cú QUERY đến database server chúng không chặn lại từ bên web server Nếu quy thành giá trị server load, số hẳn kinh khủng Thảo đêm qua database serve không chết đứ đừ Tơi phóng thử "đi" tail đến firewall log để xem tình hình Lác đác có dăm ba cú URI random vào vài chục cú request đến server Tôi thầm nghĩ: "nếu DoS kiểu đến tết Ma-rốc khơng xước vảy." Chắc cịn q sớm Tơi tị mị muốn xem thử có cú x-flash thuộc dạng POST vào từ khuya hôm qua hay không: # grep "POST" $SNORT_LOG/alert Hồn tồn khơng có Thế x-flash dạng GET? # grep "GET" $SNORT_LOG/alert | wc -l 34153 Whoa! có lẽ số bao gồm cú GET đến HVA banner lẫn cú GET với URI ngẫu nhiên Táy máy với log chừng nửa giờ, tơi đâm chán chẳng có đáng phải quan tâm Tơi định chơi bóng bàn quay lại sau đồng hồ 25 phút 3/11: Tôi trở lại hai console nối vào HVA server tình trạng "chảy" cuồn cuộn thông tin cú GET hăm hở đổ vào HVA server Hãy xem vào diễn đàn trình duyệt Tơi khởi động trình duyệt vào chọn địa HVA forum từ bookmark: chậm lúc đầu sau vào diễn đàn lướt trang thơng suốt Tơi chuyển qua hai console in hàng tràng log hình xem thử có cú SYN ập vào: # netstat -nat | grep SYN | wc -l 173 Thử lại lần nữa: 176 Thêm lần xem sao: 169 Tôi lẩm nhẩm, với số lượng log đổ cuồn cuộn hình mà có trung bình từ 160 đến 180 cú SYN lúc giá trị ấn định SYN timeout kernel có hiệu rõ rệt Điều nào? Như nói điểm thứ trên, tơi cố tình chỉnh định để SYN timeout ngắn bình thường kiến cho cú truy cập giải nhanh chóng Phải thử "dump" đoạn packets xem Tôi chạy lệnh: # tcpdump -s0 port 80 -w /tmp/dump-03-11-2004 Trong đoạn dump chạy, tơi muốn xác định có ESTABLISHED connections có server: # netstat -nat | grep ESTABLISHED | wc -l 283 Tôi chạy thêm lệnh đưa kết hồ sơ tạm thời để phân tích kỹ hơn: # netstat -nat | grep ESTABLISHED | sort > /tmp/conn.txt Đúng dự đoán, sau connection lựa theo thứ tự, IP chiếm từ đến connections Chờ vài phút, dừng cú tcpdump tải hồ sơ xuống laptop tơi để phân tích Thơng tin từ đoạn packets rõ điều: - IP lại hình thành trung bình connections, nhiên chúng kết thúc nhanh chóng cú GET với URI random mod_security phát chúng thuộc diện vi phạm, báo lỗi ngược chủ nhân cú GET huỷ bỏ connection - có vơ số gói tin vào thuộc diện vi phạm bị snort RST bắt gặp gói tcp ACKPSH có chứa thơng tin cú GET dùng URI ngẫu nhiên - có tcp stream nối tiếp từ IP bao gồm connections chứa thông tin truy cập hợp lệ lẫn thông tin thuộc cú GET công HVA Điều chứng tỏ nguồn công nguồn người dùng xuyên qua IP (có thể proxy, NAT server đâu đó) chúng xảy lúc (hoặc trước sau tíc tắc) Đối với tơi, nhiêu thơng tin q đủ để xác định tình sau: - trận DoS tiếp diễn đặn Tuy nhiên, chắn gói tin "tàn phá" khơng cịn có hội dùng ESTABLISHED connection để đẩy cú GET dồn dập đến HVA server ngày hôm trước mà phải tuân thủ theo nguyên tắc "xong request, mở socket mới" nguyên tắc connection limit điều tác triệt để - cú SYN khơng tồn lâu bình thường nên server có hội tài nguyên tiếp nhận nhiều SYN bình thường Mọi connection biến chuyển từ SYN_RECV sang ESTABLISHED đến TIME_WAIT nhanh chóng Điều tạo hội cho người dùng hợp lệ "chen chân" với lũ DoS - snort đóng góp lớn vấn đề hủy bỏ socket tạo từ request "tàn phá" cách RST chúng Đối với tôi, cách hữu hiệu việc ổn định connection queue server - khơng có cú GET dùng URI ngẫu nhiên qua khỏi cửa ngỏ mod_security (nếu chúng có lọt qua cửa ngỏ snort) chúng không tạo ảnh hưởng đến database server - server load hồn tồn bình thường xê dịch mức 0.9 - 2.8 tối đa Tôi nán thêm nửa để theo dõi tình hình HVA server Số lượng SYN có gia tăng không đủ dồn dập để phương hại đến server Tuy nhiên, điều lo lắng số lượng log tạo trận DoS tiếp diễn Mặc dù sức chứa HVA server chứa hàng chục gigabytes logs điểm quan trọng hao tổn tài nguyên chế I/O Tôi định điều chỉnh firewall, web server, mod_security phận log khác giảm thiểu mức độ log khởi động lại dịch vụ 10 phút trôi qua Rồi 15 phút trôi qua 20 phút trôi qua, khối lượng DoS gia tăng qua biểu thị số lượng SYN_RECV netstat Tơi nhấn Ctl-F5 trang web HVA diễn đàn tải nhanh chóng Để xác định xác cú SYN vào giây lúc này, định "dump" thêm mớ packets Tôi viết đoạn script đơn giản để chạy tcpdump buộc phải ngưng lại sau 60 giây Kết cho thấy có đến 1300 cú SYN đến HVA server giây phần lớn bị loại bỏ firewall q giới hạn cho phép Phẩn cịn lại bị "time-out" bị hủy phải đợi lâu mức ấn định connection queue Phần lại bị snort RST trước firewall quản chế Các cú SYN thành công (vào được) thuộc diện "bất hợp lệ" bị web server trả lại thông báo lỗi 403 Tôi gật đầu thoả mãn với kết logoff HVA server Những ngày đó, dạng DoS dùng URI ngẫu nhiên tiếp diễn nhiên chúng thưa dần tắt hẳn Mãi đến ngày 13 tháng 11, lần server lại "bị nạn" Ngày 13/11 không vào net Đến ngày 14/11, không log vào HVA server được, gởi e-mail đến JAL để hỏi thăm tình hình Sau hơm đó, JAL cho biết HVA server bị DoS kinh khủng tạo cố cho card mạng bị dịch vụ cung cấp đường dây Internet than phiền khối lượng traffic khổng lồ vào HVA server server hồn tồn bình thường, khơng bị cố Bởi thế, JAL phải cho diễn đàn tạm ngưng hoạt động vài ngày để xếp đưòng dây tạm thời trước tìm dịch vụ thích hợp Điều đáng tiếc JAL quên không tạo cú packet "dump" HVA bị công lần này, tơi khơng đốn chuyện xảy tin rằng, dạng DoS Dù khơng triệt HVA server tạo khơng phiền toái cho vấn đề xếp dịch vụ cung cấp Internet khối lượng thơng tin tràn ngập đường dẫn Cho đến nay, HVA server dời sang đường dẫn "tạm thời" thứ nhì sau biến cố ngày 13/11 bị DoS đặn (nhưng không kinh khủng) trước Bởi tơi có thời gian để viết phân tích cho bạn đọc, đồng thời suy nghĩ phân tích sâu thêm biến thái đợt cơng xảy để điều chỉnh lại server cho thích hợp Tính từ ngày logon HVA server (xuyên qua SSH) nay, có 30 lần điều chỉnh lớn, bé để thích ứng với hồn cảnh Điều tơi muốn nói là: để bảo vệ máy chủ đến mức độ tối đa hoàn cảnh điều kiện cho phép, điều phải hiểu rõ bảo vệ gì, hiểu rõ điểm yếu đâu hiểu rõ dụng ý đối phương Khơng có cơng thức kỳ diệu dùng để ứng dụng cho trường hợp khơng thể có software hoàn toàn bảo vệ vững hệ thống làm việc Bảo mật công tác lâu dài bền bỉ, địi hỏi quan tâm thường xun, khả phán đốn tình hình phản ứng kịp thời Để nhận điểm yếu điểm mạnh khơng địi hỏi kiến thức mà cịn địi hỏi khả tưởng tượng Tơi mong bạn rút tỉa điều bổ ích lý thú loạt "ký sự" để tự ứng dụng cho mơi trường Liệu loạt "ký sự" có tiếp tục hay khơng? Tơi khơng rõ Hy vọng khơng khơng có biến cố đáng phân tích Chúc bạn Noel năm 2005 vui tươi Chú thích: -55- tơi dùng laptop cơng ty duyệt web Internet Explorer Ctl-F5 để buộc trình duyệt lấy phiên từ web server thay dùng cached Tương phản với F5, trình duyệt dùng cached Các bạn theo dõi tiếp phần 11 http://hvaonline.net/hvaonline/posts/list/212.hva ... "bắt" tối hôm qua Chuyện đập vào mắt tơi kích thước hồ sơ sniff, chà, bé tí tẹo nhỉ? Sáng lúc log vào HVA server để copy hồ sơ này, tơi khơng để ý đến kích thước (vì nghĩ phải vài megabytes),... thuật từ thơng tin nhỉ? - đám "x-flash" xếp loại vào dạng DDoS chúng đến từ nhiều nguồn (IP) khác lúc - chúng có đặc tính (nói mặt giao thức, kích thước thái độ) - có số "stream" vào có tính chất... POST to DoS by flash] [Priority: 1] {TCP} 43.244.38.14:2387 -> 192.168.1.100:80 10/13-11:02:22.000189 [**] [1:0:0] POST Null frag1 - Flash attack HVA[**] [Classification: using POST to DoS by