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)" 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à, 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" -3mộ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-flashversion: 7,0,14,0. Tại sao "User-Agent" gởi http request đến HVA mà còn đính theo xflash 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 tcp tcp tcp tcp tcp tcp tcp tcp tcp tcp

0 0 0 0 0 0 0 0 0 0 0

0 192.168.1.100:80 1 192.168.1.100:80 723 192.168.1.100:80 723 192.168.1.100:80 723 192.168.1.100:80 0 192.168.1.100:80 0 192.168.1.100:80 0 192.168.1.100:80 0 192.168.1.100:80 0 192.168.1.100:80 0 192.168.1.100:80

221.132.39.253:4548 221.132.39.253:4544 221.132.39.253:4545 221.132.39.253:4546 221.132.39.253:4547 221.132.39.253:4523 221.132.39.253:4526 221.132.39.253:4527 221.132.39.253:4494 221.132.39.253:4504 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ả, 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 tcp 0 1 192.168.1.100:80 grep xxx.xx.xxx.98:9313 tcp 0 198 192.168.1.100:80 grep xxx.xx.xxx.98:9307 tcp 0 198 192.168.1.100:80 grep xxx.xx.xxx.98:9306 tcp 0 0 192.168.1.100:80 grep xxx.xx.xxx.98:9303 tcp 0 0 192.168.1.100:80 grep xxx.xx.xxx.98:9288 tcp 0 0 192.168.1.100:80 grep xxx.xx.xxx.98:9292

SYN_RECV LAST_ACK ESTABLISHED ESTABLISHED TIME_WAIT CLOSE_WAIT 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 safeguard (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 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=22379 DF PROTO=TCP SPT=50258 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 Oct 13 07:12:44 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT= SRC=203.113.160.94 DST=192.168.1.100 LEN=48 TOS=0x00 PREC=0x00 TTL=111 ID=7049 DF PROTO=TCP SPT=2370 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 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=22381 DF PROTO=TCP SPT=50257 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 Oct 13 07:12:45 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=22382 DF PROTO=TCP SPT=50258 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 Oct 13 07:12:45 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT= SRC=203.113.160.94 DST=192.168.1.100 LEN=48 TOS=0x00 PREC=0x00 TTL=111 ID=7070 DF PROTO=TCP SPT=2370 DPT=80 WINDOW=64240 RES=0x00 SYN URGP=0 Oct 13 07:12:45 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT= 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 WINDOW=16384 RES=0x00 SYN URGP=0 Oct 13 07:12:45 hvaonline kernel: OVERCONNLIMIT: IN=eth0 OUT= 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 WINDOW=16384 RES=0x00 SYN URGP=0

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