Ky Su Tan Cong DDoS Vao HVA

Sau một thời gian vật lộn với việc chống đỡ các cuộc tấn công DDoS - Từ chối
dịch
vụ - từ những kẻ phá hoại. Nay chúng tôi xin được điểm lại các điểm chính về các
cuộc tấn công và cách thức chống đỡ qua từng giai đoạn để mọi người có thể có
được cái nhìn tổng quan hơn về cách thức tấn công và phòng thủ DDoS hiện nay
của HVA. Cũng có thể xem đây là kinh nghiệm để mọi người tự suy ngẫm và và bổ
sung cho kiến thức của riêng mình.
Dấu hiệu
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ú:
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)"
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)"
"-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322;
.NET CLR 1.0.3705)"
"-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"
"-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
"-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803
Firefox/0.9.3"
.NET CLR 1.0.3705)"
Firefox/0.9.3"
.NET CLR 1.0.3705)"
Firefox/0.9.3"
Chà, chẳng lẽ thành viên "hối hả" kéo vào diễn đàn và "POST" bài nhiều đến vậy sao?
hai mươi lăm cái "POST" trong một giây từ một vài IP? Cứ cho là hợp lệ vì thành viên ở
VN đi ra Internet, qua cùng một cửa ngõ -2- là chuyện bình thường. Nhưng, hẵng đã, vừa
rồi lại có một chùm đến hơn năm mươi cái "POST" đi đến trong một giây, cũng từ các IP
như trên. Bất thường hay bất tường?
Tôi để yên mấy "cái đuôi" chạy trên mấy console và mở trình duyệt của mình lên, thử log
vào HVA bằng nickname và password của tôi để xem thử "thái độ" POST từ máy của tôi
có tương tự như những cái POST tôi nhận được vài chục giây trước đây (xác thực là bạn
của nghề phân tích). Cha chả, cái POST của tôi nhìn hợp lệ hơn 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" của firewall log trên server xem có gì hấp dẫn không. Chà, log của
web server vẫn "POST" vào ầm ầm nhưng firewall log thì vẫn im ắng như đỉnh
Himalaya. Thôi rồi, chắc đây là một "kiểu chơi" rất hợp lệ nên firewall cho phép chúng
vào thả cửa. Tôi gởi nhanh một PM đến JAL, nhờ lão phóng cái sniffer lên để "hít" -3-
một ít gói tin và lưu lại một nơi thích hợp dùm tôi. Đêm đã khuya, tôi phải đi ngủ để mai
còn đi làm. Sáng mai sẽ copy mớ gói tin đã được lưu và sẽ phân tích xem sự thể ra sao.
Phân tích
Ngày 11/10
Trên tàu lửa đến sở làm, tôi hăm hở mở laptop ra và bắt tay vào xem xét thông tin "bắt"
được tối hôm qua. Chuyện đầu tiên đập vào mắt tôi là kích thước hồ sơ đã sniff, chà, sao
nó bé tí tẹo vậy nhỉ? Sáng nay lúc tôi log vào HVA server để copy hồ sơ này, tôi đã không
để ý đến kích thước (vì cứ nghĩ nó phải ít nhất là vài megabytes), tôi chỉ chạy lệnh scp và
bỏ đó rồi đi thay đồ đi làm. Lúc này mới nhận ra là nó bé tí tẹo, không biết có gì trong
này.
Tôi dùng Ethereal mở hồ sơ này ra, và.... đúng như dự phỏng, Ethereal phàn nàn "stream
not completed". Tôi bật cười và tự nhủ: "chà, chắc lão JAL sợ nó sniff lâu quá thành một
hồ sơ khổng tượng nên chỉ sniff một, hai giây rồi tắt liền". Thông tin "bắt" được từ sniffer
quá ít, chỉ vỏn vẹn hơn mười dòng, trong đó có được một cái SYN -4-, một cái ACK,PSH
từ một segment khác, một cái HTTP (POST) cộng thêm vài cái "continuation" từ các
segment trước và sau cái SYN ở trên không thấy gì đi theo.
Xếp laptop lại, tôi trầm ngâm vài phút, có vài chi tiết cần xem lại trong mớ packets ngắn
ngủi mà lão JAL đã cung cấp. Tôi lại mở laptop ra và đi xuyên qua mười mấy mảnh
packets rời rạc. Không thể "gom" các packets này thành một stream hoàn chỉnh, tôi đành
xem xét từng mảnh một lần nữa. Điểm lý thú đập ngay vào mắt tôi khi dò đến http packet
chứa mảng đầu của phần "POST". Cha chả, POST cái gì mà lắm thế?
- payload -5- của "POST" có đến 2205 bytes?

- đoạn đầu của mảnh "POST" này 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
- header của http packet này có thêm một thông tin xem ra hơi bất bình thường: x-flash-
version: 7,0,14,0. Tại sao "User-Agent" gởi http request đến HVA mà còn đính theo x-
flash là gì nhỉ?
Thử decode nhúm "urlencoded" ở trên xem nó ra "cái giống" gì:
CODE
hotlinks=Offical.com&comdoss=attack&port=80&url1=http://hvaonline.net:80&url2=htt
p://hvaonline.net:80/forum/&http://www.xxx.com/Forum/index.php=&act=Reg&CODE=
02&coppa_user=0&PassWo
. Lý thú nhỉ, lý thú nhưng cũng chưa có gì rõ ràng cho lắm. Tôi hơi ngạc nhiên là tại sao
mấy lão trên HVA lại để yên những http header và payload có dính ngổn ngang các "chú"
ampersand -6-. Có lẽ mấy lão cho phép vì đây là phần cần thiết cho forum? Tôi chưa nắm
được bao nhiêu các phần tố ngổn ngang giữa "Invision Board" và web server đứng trước,
cái này phải điều tra kỹ mới được.
Thiếu các mảnh tiếp theo của đoạn POST trên, tôi đành thở dài và dừng lại vì chẳng đi tới
đâu. Thôi vậy, đành phải sniff lại vì mớ thông tin này chẳng giúp được bao nhiêu.
Chú thích:
-1- "tail", một lệnh dùng để liên tục chuyển thông tin của log lên console để theo dõi.
-2- "gateway", cửa ngõ đi ra / đi vào giữa 2 network.
-3- "sniff", động tác hít nói theo tính sinh hoá, động tác "bắt lấy" các gói tin đi xuyên qua
đường dẫn nói theo tinh thần điện toán.
-4- "SYN, ACK, PSH...." là các tcp flags được dùng trong giao thức TCP.
-5- payload là dữ liệu trong gói tin (nói trên bình diện "mạng".
-6- ampersand (&) là dấu "và" trên keyboard.
-- Conmale --
HVA Admin
Sáng 12/10
Sáng nay công việc có phần thư thả hơn mọi ngày, tôi quyết đị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 gì để "trị" căn bệnh x-flash này. Tôi quên bẵng là firewall / proxy của
công ty không cho phép đi thẳng đến cổng 22 -
12-, bây giờ mới đớ người ra vì không vào HVA server được. Tôi đã "bị" kẹt vụ này đã
lâu cho nên phải biến cổng SSH trên firewall riêng ở nhà từ 22 thành 443 vì firewall của
hãng chỉ cho truy cập đến cổng 80 và 443 (xuyên qua proxy dùng HTTP CONNECT),
nhưng đây là chuyện khác, không khéo tôi lại lạc đề ở đây. Sau vài phút trầm ngâm, tôi
nảy ra ý tạo tunnel từ máy của mình đến firewall riêng ở nhà rồi mới tạo ssh connection
từ máy của mình đến HVA server xuyên qua tunnel này. Biết rằng "tunnel trong tunnel"
-13- chắc là chuối lắm vì chậm, nhưng không còn cách nào khác.
Sau một phút thử nghiệm, tôi thử:
CODE
$ ssh localhost -p 25250
(localhost của tôi lắng nghe trên cổng 25250 và forward thông tin đến firewall riêng của
tôi ở nhà, từ đó nó mới đi đến HVA server). Ái chà, nó chạy! Hơi chậm một tí nhưng
không sao cả. Tôi mở thêm một console khác cũng xuyên qua tunnel này. Tốt rồi, hai cái
shell là đủ làm việc.
Tôi tìm hồ sơ mà tôi đã hí hoáy ghi xuống chằng chịt ngày hôm trước rồi rà xuyên qua
nó. Đây rồi Hơn 15 ngàn request đến HVA server mỗi ngày. Tập trung khoảng 8 giờ đến
10 giờ tối VN, cao điểm là 9 giờ. Từ 8 giờ đến 10 giờ tối có độ chừng 10 ngàn đến 12
ngàn x-flash requests. Có khoảng 1 truy cập hợp lệ cho mỗi 30 giây (HTTP GET, HTTP
POST) của các thành viên duyệt diễn đàn khi diễn đàn đông nhất. Cứ cho là trong 2 giờ
cao điểm này 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 mỗi giây
Nói về mặt tầng số truy cập thì đây là một con số khá cao. Dựa trên số liệu thành viên
truy nhập diễn đàn và gởi / xem bài một cách hợp thức và bình thường (lấy từ log của
web server) xấp xỉ:
(200 thành viên sign-in mỗi giờ / 60 phút) / 60 giây = 0.05 request mỗi giây
So sánh hai con số trên thì tầng số "truy cập" bất hợp lệ (x-flash) gấp 32 lần tầng số truy
cập hợp lệ. Kinh nhể? greenwink.gif
Câu hỏi cũng như câu trả lời ở giai đoạn này trở nên quá hiển nhiên:
- hỏi: vô hiệu hoá các truy cập bất hợp lệ ra sao đây? trả lời: giới hạn các truy cập bất
hợp lệ.
- hỏi: vậy giới hạn là giới hạn thế nào? trả lời: hèm... cái này thì đang tính toán đây.
Phải hình thành một công thức để tạo giá trị trung bình của một kết nối bình thường và từ
đó mới có thể hình thành giới hạn hợp lý được. Vì HTTP là một giao thức có tính
stateless -14- cho nên, thông tin giữa client (trình duyệt) và server (web server) thường
được kết thúc càng nhanh càng tốt và connection này sẽ được tắt bỏ sau khi quy trình
chuyển gởi thông tin hoàn tất. Tuy nhiên, trong quá trình chuyển đổi, giữa client và server
sẽ mở thêm các connection nếu dữ liệu được truyền quá lớn hoặc cần chuyển tải thông tin
nhanh chóng. Mục đích là để đẩy thông tin đi đến client (hoặc server) càng nhanh càng
tốt (HTTP GET và HTTP POST). Hãy xem thử một x-flash stream xem sao. Tôi điều
chỉnh hai console đã được kết nối vào HVA server cho chúng nằm song song. Trên
console thứ nhất tôi "tail" web server log của HVA, trên console thứ nhì tôi chạy netstat.
À ha, có vài chú x-flash đang đi vào, tôi lấy ngay IP đang hiển thị trên console theo dõi
log của web server và chuyển sang console có chứa netstat. Hãy thử IP 221.132.39.253
xem sao:
CODE
[root@hvaonline httpd]# netstat -nat | grep 221.132.39.253

tcp 0 0 192.168.1.100:80 221.132.39.253:4548 SYN_RECV
tcp 0 1 192.168.1.100:80 221.132.39.253:4544 LAST_ACK
tcp 0 723 192.168.1.100:80 221.132.39.253:4545 ESTABLISHED
tcp 0 723 192.168.1.100:80 221.132.39.253:4546 ESTABLISHED
tcp 0 723 192.168.1.100:80 221.132.39.253:4547 ESTABLISHED
tcp 0 0 192.168.1.100:80 221.132.39.253:4523 TIME_WAIT
tcp 0 0 192.168.1.100:80 221.132.39.253:4526 CLOSE_WAIT
tcp 0 0 192.168.1.100:80 221.132.39.253:4527 CLOSE_WAIT
tcp 0 0 192.168.1.100:80 221.132.39.253:4494 TIME_WAIT
tcp 0 0 192.168.1.100:80 221.132.39.253:4504 TIME_WAIT
tcp 0 0 192.168.1.100:80 221.132.39.253:4505 TIME_WAIT
Cha chả, chú 221.132.39.253 này tham lam quá nhỉ? một mình chú đã có đến những 3 cái
"ESTABLISHED", lại thêm 1 cái "SYN_RECV" và một mớ "CLOSE_WAIT",
"TIME_WAIT". Dựa trên thông tin của hình minh hoạ ở trên thì "thái độ" tham lam này
hoàn toàn phù hợp, bởi lẽ, một HTTP POST có payload đến trên 2 ngàn bytes thì nó phải
đòi mở thêm connection để "đẩy" dữ kiện đến HVA server càng nhanh càng tốt mà (bạn
có để ý đến chi tiết ACK-PSH của TCP segment chứa HTTP POST đã nói trong bài trước
không?). Tôi tiếp tục theo dõi thì thấy chú 221.132.39.253 có đến những tám cái
"ESTABLISHED" cả thảy trong suốt quá trình chú hối hả POST lên server của HVA,
điều này có nghĩa là có ít nhất 8 cái SYN đã gởi đến HVA server và vì nó là legitimate
request (yêu cầu truy cập hợp pháp) cho nên HVA server không hề cản mà cho chúng đi
xuyên qua các bước TCP handshake rồi đi đến tình trạng "ESTABLISHED". Có thể 8 cái
"ESTABLISHED" này không dành riêng cho một stream mà có ai đó cũng dùng chung
cái IP này để truy cập HVA server. Có lẽ đường dẫn giữa IP này và HVA server hơi chuối,
cũng có lẽ chính chú bị nghẽn vì đồng đội của chú cũng đang hối hả flood HVA, cho nên,
chú phải đòi mở nhiều connection đến HVA server đến như vậy. Như vậy, tổng số socket
cần mở ra cho chú 221.132.39.253 và đồng đội của chú (từ nhiều IP khác) cho tất cả các
stream sẽ lớn lắm đây. Cứ cho rằng mỗi stream chứa HTTP POST mở ra 6 connections,
chúng ta có:
CODE
( 12000 requests tạo ) 12000 streams x 8 sockets = 72000 connections (cho mỗi giờ).
( 72000 connection / 120 ) / 60 = 10 connections cho mỗi giây.
Ôi giời ơi, sao mà kinh thế? Cho dù SYN state thoát ra rất nhanh, cho dù ESTABLISHED
state chỉ chiếm vài giây nhưng hậu quả của mớ "TIME_WAIT" và "CLOSE_WAIT" sau
khi "ESTABLISHED" tắt bỏ thật sự mới khinh khủng.
Tôi càng tin tưởng vào ý định dùng giới hạn connection thay vì giới hạn packet rate -15-.
Lý do hết sức đơn giản: người dùng bình thường chỉ cần 4 connections là nhiều (tôi
phỏng đoán với nội dung thông thường của 1 trang trên HVA forum). Chỉ có những chú
"x-flash" tham lam kia mới cần hơn 4 connections vì HTTP POST chứa payload quá lớn.
Để bảo đảm, tôi dùng chính trình duyệt của mình để thử truy cập vào một trang trên diễn
đàn HVA. Hèm, hãy thử netstat trên một console xem sao:
CODE
[root@hvaonline root]# netstat -nat | grep xxx.xx.xxx.98

tcp 0 0 192.168.1.100:80 grep xxx.xx.xxx.98:9322 SYN_RECV
tcp 0 1 192.168.1.100:80 grep xxx.xx.xxx.98:9313 LAST_ACK
tcp 0 198 192.168.1.100:80 grep xxx.xx.xxx.98:9307 ESTABLISHED
tcp 0 198 192.168.1.100:80 grep xxx.xx.xxx.98:9306 ESTABLISHED
tcp 0 0 192.168.1.100:80 grep xxx.xx.xxx.98:9303 TIME_WAIT
tcp 0 0 192.168.1.100:80 grep xxx.xx.xxx.98:9288 CLOSE_WAIT
tcp 0 0 192.168.1.100:80 grep xxx.xx.xxx.98:9292 TIME_WAIT
Rất tiếc tôi phải xoá cái IP của mình và thay thế bằng xxx.xx.xxx.98 vì IP này là IP toàn
thời (tôi muốn ăn ngon, ngủ yên greenwink.gif nên không thể tiết lộ IP của mình). Trở lại
câu chuyện chính, bất chấp tôi vào trang nào, bất chấp trang ấy có nhiều hay ít thông tin,
tôi không hề thấy có hơn 4 connection hiện diện cho mỗi lần. Tôi cũng thử lệnh netstat
ngay trên máy con của mình và xác nhận được điều này. Phần lớn là 3 connections cho
mỗi lần, ngoại trừ trang nào lớn lắm thì mới thấy có 4 connections nhưng tỉ lệ này chỉ
1/100 (xấp xỉ 100 lần duyệt mới có một lần). Một chi tiết đáng nêu ra nữa là: thời gian
một socket nằm ở vị trí "ESTABLISHED" chưa bao giờ lâu hơn 2 giây, phần lớn chỉ 1/2
giây hoặc 1 giây là tối đa. Điều này giúp chúng ta rút ra vài điều rất lý thú:
- mỗi trình duyệt cần tối đa 4 connection để duyệt 1 trang.
- 4 connections này không ở tình trạng "ESTABLISHED" cùng 1 lúc, chỉ tối đa 2 sockets
ở tình trạng "ESTABLISHED" cho mỗi lần.
Giả sử 200 thành viên của HVA đang có mặt trên diễn đàn và cho rằng có 1/10 số lượng
người đang bấm vào một số trang nào đó (đây là trường hợp cực đoan vì theo thông tin
của web server log, thì trung bình mỗi 30 giây có một "GET" trong khoảng thời gian
server bận rộn), và số lượng 1/10 này ít nhất là dùng 5 IP (5 proxy khác nhau) để truy cập
HVA server:
(( 200 / 10 ) x 2 "ESTABLISHED") / 1 giây = 40 "ESTABLISHED"
40 "ESTABLISHED" / 5 IP = 8 "ESTABLISHED" connections là số connection hợp lệ
cho mỗi IP tại bất kì thời điểm nào.
8 "ESTABLISHED" connections tối đa cho mỗi IP một lần, con số này trông rất vừa
phải. Nếu quy định cho firewall chỉ cho phép tiếp nhận tối đa 8 connections đến web
server một lần thì nó đã dư sức phục vụ cho 200 thành viên có mặt trên diễn đàn cùng
một lúc. Đó là chưa kể trường hợp khi một thành viên thứ nhất cần duyệt 1 trang nào đó,
nếu nó bị xếp vào dạng quá connection thì trình duyệt của thành viên ấy sẽ tiếp tục gởi
request đến HVA server để "thử lại", cơ hội "thử lại" lần thứ nhì này tạo connection trong
phạm vi giới hạn 8 connections rất cao. Đối với người dùng bình thường, sự chậm trễ do
"thử lại" này chỉ là một chậm trễ rất nhỏ. Tại sao tôi chọn tình trạng TCP
"ESTABLISHED" để biểu thị cho "connection"? -16- lý do rất đơn giản là một kết nối đã
đi đến tình trạng "ESTABLISHED" thì kết nối đó đã thành công, đã có thông tin qua lại
giữa 2 đầu. Phải đi qua được giai đoạn TCP handshake thành công thì mới đến tình trạng
"ESTABLISHED".
Cũng nên đào sâu thêm một tí về giới hạn 8 connections đã nêu ra ở trên về mặt logic.
Giả sử chúng ta đã hình thành chế độ firewall được ấn định cho phép truy cập đến HVA
web server từ bất cứ nơi đâu, miễn sao mỗi IP chỉ được phép dùng tối đa là 8
connections. 8 connections này có dạng na ná như một loại connection pools. Ví dụ, IP
203.162.5.100 là IP của một proxy server nào đó, đằng sau IP này có 10 người đang dùng
để truy cập HVA server:
- người dùng thứ nhất chiếm 3 connections (nếu truy cập bình thường như tôi đã thử từ
trình duyệt của tôi ở trên) --> "pool" còn lại 5 connections
- người dùng thứ hai chiếm 3 connections --> trong khi đó, người dùng thứ nhất đã trả lại
2 connection --> (5 + 2) - 3 = "pool" còn lại 4 connections
- ngay khi người thứ ba chiếm 3 connection nữa thì 3 connections của người dùng thứ
nhất đã hoàn thành và đã trả lại 1, người dùng thứ hai trả lại 2 --> ( 4 + 2 + 1 ) - 3 =
"pool" còn 4 connections
Và cứ thế mà xoay tròn. Đây là nói theo tình trạng truy cập sequential (theo chu trình) hết
người này đến người khác, còn nếu tình trạng truy cập đồng thời thì sao? Cũng 10 người
dùng proxy trên để truy cập HVA server:
- hai người 1 và 2 cùng truy cập một lúc, chiếm 6 connections --> "pool" còn 2
connections
- người thứ 3 và 4 kế tiếp cùng truy cập, chiếm 6 connections --> 1 và 2 ở trên trả lại ít
nhất 4 connections --> ( 4 + 2 ) - 6 = "pool" còn 0 connection
- người thứ 5 và 6 cùng truy cập, chiếm 6 connections --> 1 và 2 trả lại hết các
connection còn lại (2), 3 và 4 trả lại ít nhất 4 connections --> ( 2 + 4 ) - 6 = "pool" còn 0
connection
Theo phân tích trên, ngay cả trường hợp 2 người dùng cùng truy cập một lượt và dùng
chung 1 IP (1 proxy server) để truy cập thì vẫn không bị ảnh hưởng gì từ chế độ cản của
firewall (với ấn định tối đa 8 connections).
Nếu như kế tiếp có người thứ 7, 8 và 9 cùng truy cập thì sao? Chắc chắn là thiếu 2
connection. Tuy nhiên, anh chàng nào hơi chậm chân một tí thì trình duyệt sẽ "retry"
ngay sau đó và khi "retry" packet này đụng đến server thì cơ hội có connection để vào rất
cao vì khi ấy người thứ 3, 4, 5, 6 đã trả lại một loạt connection rồi. Đối với người dùng
bình thường, đây là một "delay" rất nhỏ và có thể tiếp nhận được. Trên thực tế, chuyện
này hiếm xảy ra. Theo thông tin đã thâu thập được từ log của web server thì cứ 30 giây
mới có một xuất truy cập mới. Quy định 8 connections một lúc cho mỗi IP thật sự còn
quá thư giãn so với hoàn cảnh thực tế. Tuy nhiên, cứ tạm dùng con số này làm điểm khởi
đầu rồi chỉnh sửa sau vậy.
Vậy nếu HVA server bị "flood" liên tục và chiếm hết connections, làm cho người dùng
bình thường không vào được thì sao? Đây là điểm đòi hỏi phải chỉnh sửa các thông số
tcp/ip trên kernel để điều tiết cho thích hợp hơn. Nếu các giá trị ấn định cho tcp/ip cho
phép "backlog" -17- thì vẫn giải quyết được trường hợp bị "flood". Tất nhiên là máy con
truy cập sẽ bị chậm hơn nhưng vẫn còn tốt hơn là hoàn toàn bị "từ chối". Một ưu điểm rất
lớn mà tôi tìm thấy được qua nhiều lần "táy máy" là trong trường hợp bị "flood", backlog
queue này còn giúp cho IDS (Intrusion Detection System) kịp thời gởi gói tin xử lý đến
những gói tin vi phạm với hiệu quả cao hơn-18-.
Dựa trên những điểm đã phân tích ở trên, tôi thấy rõ phương pháp dùng "connection
pool" ở trên có hai điểm ưu việt hơn dùng phương pháp packet rates:
- giới hạn connection tính theo biên độ và trường độ truy cập cho phép người dùng có thể
truy cập với băng thông tối đa và loại bỏ những truy cập "tham lam", không thực tế.
- với giới hạn này, nó giúp giới hạn tài nguyên cho máy chủ (và những bộ phận gắn liền
với máy chủ), ví dụ như backend database chẳng hạn. Connection limit bảo đảm tối đa
chỉ có 8 xuất query đến database một lần nếu những connection này đụng chạm đến
database server (nên nhớ: truy nhập và lấy dữ kiện từ database tốn tài nguyên hơn bất cứ
giai đoạn nào khác trên hệ thống).
Trong khi đó, packet rate giới hạn số packets trong một đơn vị thời gian nào đó, cái này
chỉ làm chậm mọi quy trình lại nhưng không áp đặt một giới hạn nào rõ ràng. Nếu dùng
packet rate, số xuất truy cập vào database có thể lên đến số lượng đã áp đặt trên chính cấu
hình database mà thôi và đây là điều rất kẹt vì rất tốn kém tài nguyên của máy chủ. Đến
một mức độ nào đó, đường truyền sẽ bị dung hoà (saturated) và các client hợp pháp sẽ
vào được nhưng cực kỳ chậm nhưng để đạt tới mức độ này, ít nhất đường truyền dùng để
tấn công phải hơn đường truyền của máy chủ HVA ít nhất là 3 lần. Giới hạn connection
bảo đảm một điều tối quan trọng, cho dù máy chủ bị "flood" cỡ nào cũng không thể
"giết" được nó.
Được rồi, hãy quyết định khai triển hướng giới hạn connection trước để cắt bỏ phần lớn
khối 20 connections / 1 giây của các con bọ "x-flash" kia trước rồi tiếp tục khai triển
bước "triệt tiêu" chúng hoàn toàn sau.
Chuyển sang console thứ nhất đã được kết nối vào HVA server, tôi chạy một loạt lệnh để
kiểm tra:
CODE
# lsmod
Hèm... không thấy mấy cái modules mình muốn greensad.gif, hẳn là như vậy vì module
mình muốn đâu nằm trong "base modules" của kernel.
CODE
# ls /proc/sys/net/ipv4/netfilter
Hèm... quả thật mấy cái modules mình muốn chưa hề có trong kernel, cũng nên xác định
cho rõ.
CODE
# sysctl -a | grep net
Whoa... đa số là giá trị mặc định, chi tiết này phải ghi xuống để chỉnh lại sau, không thì
quên nữa.
CODE
# iptables -L -v | more
Nhìn ok nhưng... còn thắt lại được nhiều lắm.
Chà chà, lão JAL và mấy lão BQT "hiền" quá, mấy cái rules này của firewall không dễ để
"đột phá" nhưng nó có quá ít ảnh hưởng đến mớ x-flash quái đản kia. "Packet rate" cũng
đã áp đặt nhưng với tầng số 1.6 request / 1 giây thì.... bó tay, hơn nữa, áp đặt này chỉ làm
cho bà con thành viên truy cập vào diễn đàn chậm hơn. Kernel hiện tại cần thiết lập vài
modules quan trọng để thực sự giới hạn truy cập. Tôi chưa muốn xem xét các tầng cao
hơn vì kế hoạch mà tôi đã hình thành trong đầu là: thắt từ dưới lên và hiện nay tôi đang ở
tầng dưới cùng trong các tầng giao thức, những tầng kia sẽ xét sau.
Tôi gởi ngay cho JAL một PM về việc tái biên dịch kernel để thêm vài modules quan
trọng cho kernel cũng như loại bỏ nhiều modules không cần thiết. Mười lăm phút trôi
qua, rồi một giờ trôi qua. Chà, sao không thấy tăm hơi lão JAL đâu nhỉ? Tôi quyết định
bắt tay vào thực hiện ý định của mình rồi sẽ thông báo để lão tái khởi động máy sau vậy.
Tôi dùng wget, tiện ích tôi rất ưa thích để lấy mã nguồn của kernel và các bản vá cần
thiết. Trong khi wget tải những thứ lỉnh kỉnh kia về, tôi vi ngay hồ sơ cấu hình biên dịch
của kernel (tiết kiệm thời gian mà lị greenwink.gif ). Hèm.... mười lăm phút đầy những Y,
N và M trên một hồ sơ cấu hình biên dịch của kernel, hơi oải... nhưng biết sao hơn? Băng
thông khá tốt nên mới sau vài phút thì những thứ tôi cần đã được tải hết về máy. Tôi xả
nén mã nguồn kernel, vá và bắt tay vào chuyện biên dịch.
Tôi rà kỹ qua hồ sơ cấu hình biên dịch kernel một lần cuối... ok, mọi chuyện đâu vào đó.
Một, hai, ba... chạy. Hơn ba mươi phút trôi qua với hàng loạt thông điệp chạy vi vút trên
màn hình. Kinh khủng, kinh khủng, kernel được biên dịch xong dưới ba mươi lăm phút,
đúng là dual CPU có khác, đây là không kể đến hoàn cảnh server hiện nay đang phải
dùng sức để đối phó với đám loạn quân "x-flash" kia. Kernel đã xong nhưng vẫn chưa
thấy tăm hơi lão JAL đâu. Thôi vậy, để xem thêm thử có gì khác cần phải làm nhưng chắc
để lúc khác, đã đến lúc phải giải quyết vài công chuyện ở sở không thì bê trễ cả ra.
Sáng 13/10
Đang trên tàu lửa trên đường đi làm, tôi trầm ngâm lượt qua các chi tiết đã phân tích hôm
qua. Vẫn chưa thấy JAL hồi đáp, cha chả, lão này đi chơi đâu mà bặt vô âm tín vậy nhỉ?
Tôi chợt nhớ là kernel đã tái biên dịch xong nhưng firewall rules mới chưa hề có một
mảnh. Tôi mở laptop lên, phóng ngay chú "vim" lên màn hình và bắt đầu gõ.
Tôi khá chắc là HVA cần dùng bấy nhiêu dịch vụ nên tôi quyết định dùng kiểu block
function (hàm theo nhóm) để hình thành các phần logic của firewall rules. Ba mươi lăm
phút trôi qua, chà tôi phải đổi sang chuyến tàu thứ nhì (tôi cần phải đổi tàu 2 lần mới đến
sở làmgreenwink.gif ). Nhìn xuyên qua đoạn script, tôi khá hài lòng vì nó đã gần như
hoàn tất, chỉ cần điểm xuyết thêm, thắt chặt dăm ba điểm và tạo một số thông điệp thông
báo khi chạy firewall script (để lão nào chạy nó thì còn biết chuyện gì xảy ra). Rất tiếc tôi
không thể trình bày chi tiết firewall rules này có những gì ở đây vì lý do... bảo mật.
Lên chuyến tàu thứ nhì, tôi mở laptop ra và tiếp tục hoàn tất những thứ đã dự định trong
đầu. Tôi ngẩng lên nhìn đồng hồ, chà! còn đến 15 phút nữa mới đến sở. Tôi quyết định rà
lại từng dòng một trên cái firewall script. Mèn... tưởng đã hoàn chỉnh, hoá ra rà qua lại
"nẻ" ra lỗi, rà lại cũng "nẻ" ra lỗi. Còn 10 phút... tôi nảy ra ý định tạo thêm một lớp safe-
guard (bảo kê) cho mỗi truy cập đến dịch vụ đã được cho phép. Xong xuôi, tôi khá hài
lòng vì sáu mươi phút đồng hồ trôi qua khá bổ ích. Thôi được, thử upload cái script này
lên và chạy thử trên HVA server xem sao. Nếu có gì kẹt thì "đì bấc" tại chỗ chớ làm sao
hơn được?
Sau mấy giờ đồng hồ liên tục làm việc, tôi đã hoàn tất cả đống công việc. Giờ này lão
JAL bên Nhật chắc cũng đã có mặt ở sở, để xem lão có hồi báo gì không. Tôi log vào
diễn đàn, khè khè "Bạn có 3 PM", chắc là của lão JAL chớ không ai vào đây. Quả thật,
lão JAL "mê" chơi đâu quá nên tối hôm qua về trễ. Tôi upload cái firewall script lên HVA
server, xem xét mọi thứ một lần nữa. Rồi, gởi cho JAL một cái PM thông báo chuyện
khởi động lại server.
Lão JAL hồi đáp trong tích tắc. Lão cho biết sẽ khởi động server lúc "vắng vẻ" một tí.
Mèn.... sau vài phút cái SSH console của tôi chợt báo "socket error", lão JAL này nói
"đợi khi nào server vắng vẻ một tí rồi restart" vậy mà làm liền vậy sao cà? Quả thật lão
"làm liền". Chưa đầy 2 phút sau, tôi hối hả thử log vào HVA server, vào được ngay! Tôi
phóng ngay mấy cái lệnh:
CODE
# less /var/log/boot
CODE
# lsmod
CODE
# /usr/local/sbin/iptables -L -v | more
CODE
# tail -f /var/log/messages
"I can't believe it", tôi thốt lên một mình. "First hit wonder!" tôi lẩm nhẩm tiếp. Firewall
chạy như ý muốn ngay lần đầu tiên. Mọi chuyện đều ổn từ kernel lên tới firewall và các
dịch vụ khác (Vậy mà ngày hôm ấy lão thần bài phát hiện ngay ra một lỗi, lỗi gì vậy lão
thần bài?greenwink.gif ). Nhìn cái "đuôi"
CODE
# tail -f /var/log/messages
tôi muốn ngộp thở:
CODE
Oct 13 07:12:44 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT=

SRC=221.132.49.131 DST=192.168.1.100 LEN=48 TOS=0x00
PREC=0x00 TTL=113 ID=22369 DF PROTO=TCP SPT=50257 DPT=80
WINDOW=64240 RES=0x00 SYN URGP=0
SRC=221.132.49.131 DST=192.168.1.100 LEN=48 TOS=0x00
SRC=203.113.160.94 DST=192.168.1.100 LEN=48 TOS=0x00
SRC=221.132.49.131 DST=192.168.1.100 LEN=48 TOS=0x00
SRC=221.132.49.131 DST=192.168.1.100 LEN=48 TOS=0x00
SRC=203.113.160.94 DST=192.168.1.100 LEN=48 TOS=0x00
SRC=203.113.135.196 DST=192.168.1.100 LEN=48 TOS=0x0
0 PREC=0x00 TTL=110 ID=43299 PROTO=TCP SPT=42913 DPT=80
SRC=203.113.135.196 DST=192.168.1.100 LEN=48 TOS=0x0
0 PREC=0x00 TTL=110 ID=43764 PROTO=TCP SPT=42913 DPT=80
Vâng vâng và vâng vâng..... Chuyện gì đây? Hồi sau sẽ rõ greensmile.gif
Chú thích:
-13- Bạn có thể tạo secure tunnel (đường ống) từ máy của mình đến một máy chủ nào đó
bằng cách dùng SSH. Bên trong tunnel này, các thông tin chuyển lưu hoàn toàn được mã
hoá. Tuy chậm nhưng khá an toàn nếu dùng SSH2. Nếu thích bạn nên thử đọc tài liệu và
tải software từ openssh ở http://www.openssh.org.
-14- HTTP là một giao thức stateless, sau khi thông tin giữa hai đầu server và client hoàn
tất, connection này được tắt bỏ.
-15- Giới hạn connection là giới hạn bao nhiêu sockets được mở ra để phục vụ một IP nào
đó. Ví dụ, tối đa 4 connections từ một IP nào đó. Nếu IP này "đòi" mở thêm 1 connection
thứ 5 thì connection này bị loại bỏ.
Giới hạn packet rates là giới hạn số packet đường truyền tải trong một đơn vị thời gian
nào đó. Ví dụ: giới hạn 100 packets / 1 giây từ một IP nào đó chỉ cho phép server nhận tối
đa là 100 packets 1 giây, packet thứ 101 trở đi sẽ bị loại bỏ.
-16-Tôi dùng thuật ngữ "connection" ở đây là để chỉ chung cho các giai đoạn: SYN từ
client, SYN-ACK từ HVA server, ACK-ACK từ hai đầu client và HVA server và sau đó là
ACK-PSH hay bất cứ gì khác từ client cho đến khi "ESTABLISHED" trở thành
"TIME_WAIT". Giới hạn connection ở đây thật sự là giới hạn SYN. ESTABLISHED chỉ
dùng để biểu thị connection đã hình thành một cách hợp lệ và đúng quy định mà thôi.
Nếu truy cập từ cùng một IP mà quá giới hạn 8 "connections", có nghĩa là SYN vẫn được
gởi nhưng nếu hiện đã có 8 ESTABLISHED connections thì SYN đứng đó chờ hoặc
SYN bị huỷ. ESTABLISHED dùng để đo lường số connection hiệu hữu và SYN dùng để
cản (hoặc cho phép) các truy cập tiếp theo dựa trên số connection đã hiện hữu
-17- "backog" là số lượng công việc bị dồn ứ lại. Với TCP connections, ví dụ nếu chỉ
định 100 "backlog" chẳng hạn thì gói SYN thứ 101 trở đi sẽ bị hủy bỏ, dẫn đến tình trạng
người dùng không truy cập được. Nếu chỉnh định 10000 "backlog" thì vẫn tạo cơ hội cho
các truy cập đang đợi có thể vào thay vì bị huỷ.
-18- Hầu hết các IDS hiện đại đều có khả năng tác ứng đến các gói tin mang tính vi
phạm. Riêng trong trường hợp này, tôi dùng snort vì nó miễn phí. Nó có thể gởi nhiều gói
RST đến cả client lẫn server cùng một lúc để "xé" ngang đường nối hiện hữu giữa client
và server.
Cập nhật:
10/11/2004: chỉnh sửa các chi tiết tính toán bị sai lẫn do morro tìm thấy trong bài tường
trình và thêm chi tiết giải thích cho khái niệm "connection".
Còn tiếp
Conmale
HVA admin

Ky Su Tan Cong DDoS Vao HVA

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ky Su Tan Cong DDoS Vao HVA

Uploaded by

Copyright:

Available Formats

Sau một thời gian vật lộn với việc chống đỡ các cuộc tấn công DDoS - Từ chối

210.245.31.246 - - [10/Oct/2004:06:57:19 -0400] "POST /forum/ HTTP/1.0" 200

xxx.xx.xxx.98 - - [10/Oct/2004:07:11:25 +0900] "POST

- payload -5- của "POST" có đến 2205 bytes?

Thử decode nhúm "urlencoded" ở trên xem nó ra "cái giống" gì:

Sau một phút thử nghiệm, tôi thử:

(12000 requests / 120 phút) / 60 giây = 1.6 request mỗi giây

[root@hvaonline httpd]# netstat -nat | grep 221.132.39.253

[root@hvaonline root]# netstat -nat | grep xxx.xx.xxx.98

Nhìn ok nhưng... còn thắt lại được nhiều lắm.

Oct 13 07:12:44 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT=

You might also like