Sáng 13/10: (tiếp theo)
Sau vài giờ giải quyết công việc ở sở, tôi quay lại với HVA server để xem xét tình hình kỹ lưỡng hơn. Tôi dán chặt vào màn hình như bị thôi miên, có quá nhiều "OVERCONNLIMIT" từ nhiều IP khác nhau trong mỗi giây. Tôi "ngắt" ngay một đoạn của firewall log và webserver log để so sánh xem sao. À ha, có một đoạn "x-flash" vẫn đi vào HVA server được:
Code:


Trong khi đó, firewall log lại ghi nhận:
Code:


Hai đoạn log trên chứng tỏ điều gì? Nếu bạn so sánh tỉ mỉ thời gian ghi nhận giữa hai đoạn log trên bạn sẽ thấy cái thú vị của nó.
- Lúc 10:34:22, IP 203.160.1.66 gởi thành công 1 cái POST đến HVA server và webserver của HVA ghi nhận điều này.
- Cũng trong lúc này, 10:34:22, nó gởi tiếp cái POST kế tiếp cũng thành công. Ở bước này, với chiều dài của HTTP POST cỡ trên 2000 bytes thì trình duyệt dùng để gởi đến HVA server hẳn đã mở ra thêm ít nhất là vài connection. Cả hai cú POST trên chắc chắn đã đụng đến giới hạn cho phép.
- 1 giây sau, lúc 10:34:23 firewall thông báo đã cản SYN request từ 203.160.1.66 vì tình trạng quá giới hạn đã xảy ra.
- Lúc 10:34:24, IP này lại gởi thành công thêm 1 POST khác vì chắc hẳn 2 cái POST đi trước đã trả lại vài connections và "connection pool" lúc này đã trống chỗ đủ để 203.160.1.66 gởi SYN và đi vào.
- Lúc 10:34:25, IP này tiếp tục gởi thêm 1 POST khác thành công nhưng đồng thời ngay lúc này firewall cũng đã cản một SYN packet của nó. Điều này có lẽ packetlength quá lớn nên nó phải mở thêm connection để đẩy tiếp payload. Tuy nhiên, đoạn đi sau đã bị cản.
- Lúc 10:34:26, chắc hẳn connection pool vẫn chưa trống chỗ nên nó lại bị firewall cản thêm lần nữa.
- Đến 10:34:27, lúc này hẳn connection pool đã trống vì các cú POST trên đã lần lượt hoàn tất nên nó lại POST thành công hai cái POST.
- Đến 10:34:28, hẳn IP này lại gởi một phần của gói POST dài thậm thượt kia và bị firewall cản ngay vì 2 cú POST trên chiếm hết chỗ của connection pool.

Qua đoạn trên, ta thấy rõ một điều, cứ trung bình sau 2 cú POST thành công lại có một cú cản và tiếp theo sau đó là một cú POST nữa nhưng bị cản phần "continuation". Như vậy, tạm hình dung là cứ 3 POST gởi đi thì bị cản 1 POST rưỡi. Nếu quả thật là vậy thì có ít nhất 50% các gói POST bị "huỷ" sau khi firewall ứng dụng giới hạn connection. Nếu tính theo số liệu ghi nhận được trước đây là có đến 12000 connections trong 2 giờ thì có đến 6000 "chú" bị rụng (?). Chà chà, thông tin này có vẻ khá phấn khởi đây. Không phấn khởi sao được khi 6000 "quả" x-flash nhường chỗ cho các truy cập hợp lệ?

Tôi tiếp tục theo dõi và phân tích mối tương quan giữa web server log và firewall log. Giờ này không phải là lúc cao điểm của các chú "x-flash" nên lâu lắm mới thấy một chùm vài chục "quả" đi vào. Tuy nhiên, logic "3 và 1 1/2" ở trên vẫn áp dụng đều đặn. Tôi nảy ra ý định giảm lượng "connection" cho phép từ một IP trong bất cứ lúc nào để xem firewall "xử lý" các chú "x-flash" tham lam ra sao. Hơn nữa, diễn đàn lúc này còn vắng lắm. Tôi chỉnh lại giá trị giới hạn connection từ 8 thành 6 và tái khởi động lại firewall (tất nhiên là vẫn thao tác mọi chuyện qua SSH).

Voila! phóng lại cái "đuôi" tail để xem firewall log. Im ắng quá nhỉ? trong log của web server thỉnh thoảng ghi nhận vài truy cập, firewall log thì thông báo nhiều hơn. Nào là những "quả" FIN đi sau SYN rồi lại RST đi sau SYN -19- đều bị firewall tóm cổ và cho vào /dev/null, nào là những cú truy cập thiếu bình thường như "NEW" connection nhưng không mang flag SYN -20- v..v... Những thông tin trên chỉ để minh hoạ sơ qua một số trách nhiệm khác của firewall và chắc chắn không có liên quan gì đến những chú "x-flash" ở đây vì "x-flash" có mục đích rõ ràng lắm. Nếu "x-flash" thay đổi thái độ gởi gói tin thì hẳn đã bị firewall cản ngay vòng ngoài vì bị xếp dạng vô giá trị, vả lại "x-flash" nằm ở tầng application, công cụ cho phép tạo ra nó chắc đã không cho chọn những thứ tỉ mỉ ở transport layer (như chọn flag nào cho gói tin TCP ở giai đoạn nào, các TCP options ra sao....) để có thể thay đổi thái độ được. Nói cho cùng "x-flash" là một phương tiện phục vụ cho multimedia, nó không phải là phương tiện dùng để thực hành các mục đích mờ ám trong lĩnh vực bảo mật. Bởi vậy, phải công nhận một điều là tác giả mấy con "flash" này rất sáng tạo. May thay, x-flash để lại quá nhiều dấu vết đặc thù và chính nó không phải là công cụ "thứ thiệt" để tạo packets, cho nên việc nhận diện và loại bỏ nó không quá phức tạp.

Trở lại với giới hạn 6 connections, tôi thấy có những chùm cản trên firewall tương ứng với những thông báo trên web server log:
Code:


Và firewall log lại ghi nhận:
Code:


Với hai đoạn logs trên, chúng ta thấy ngay sự khác biệt giữa số lượng gói tin "được vào" và số lượng "bị cản" so với lần trước (dùng giới hạn 8 connections):
- Lúc 10:59:34, 203.160.1.66 gởi thành công một POST đến HVA server.
- Sau đó, trên firewall log tường trình 203.160.1.66 bị cản lúc 10:59:35, có thể đây là cú POST tiếp theo vì giới hạn 6 connections vẫn có thể vừa khít cho cú POST đầu.
- Tiếp theo sau đó, lúc 10:59:36, firewall lại tường trình cản 203.160.1.66, có lẽ đây là đoạn "continuation" của cú POST ngay ở trên và vì quá giới hạn nên bị cản.
- Lúc 10:59:41, 203.160.1.66 lại gởi thành công một POST khác nhưng tiếp theo sau đó lúc 10:59:42 và 10:59:43, firewall lại liên tiếp báo nó đã cản 2 "cú" từ 203.160.1.66
- Đến 10:59:45, 203.160.1.66 gởi thành công thêm một cái POST nhưng lại tiếp tục bị firewall cản vào 10:59:46 và các gói tiếp theo diễn tiến y hệt chu trình trên.

Điều này cho thấy, cứ 3 "cú" 203.160.1.66 dội vào thì có hết 2 "cú" bị cản một cách khá đều đặn. Nếu vậy, thì với 12000 "cú" trong 2 giờ thì có 8000 cú bị cản (?). Không tệ lắm. Lúc này HVA server không bận rộn lắm nên khó có thể đoán giới hạn 6 connection có tạo ảnh hưởng "xấu" đến các thành viên muốn truy cập một cách hợp pháp. Tuy nhiên, cũng với lượng truy cập khá tương tự trước khi khởi động lại server và kernel cũ, mức "load" của server lúc này giảm xuống chỉ còn 1/3 lúc trước (từ 1.5 - 1.6 load xuống còn 0.4 - 0.5 load). Đây là dấu hiệu tốt.

Thôi, vậy là tạm đủ với firewall log lúc này. Tôi phải tiếp tục bước kế tiếp. Để tối nay, khi đợt "tấn công" hàng đêm lên cao điểm, tôi sẽ theo dõi sau.

Mục tiêu kế tiếp tôi đã hình thành (trong đầu) là xét phần IDS của server. Qua vài phút dò xét, tôi khám phá snort -21- đã được cài sẵn. Phiên bản không được cập nhật lắm nhưng cũng thuộc diện "new generation", đặc biệt các signature -22- thì mới toanh. Nhóm signatures của snort trên server này được điều chỉnh để tự động cập nhật các signature mới nhất trong ngày. Kèm theo đó là tiện ích dùng để đọc và lý giải log của snort cho mỗi giờ, kết quả lý giải này có thể xem ở dạng "web". Quả là tiện dụng. Tuy nhiên, snort chỉ dừng lại ở cấp độ theo dõi và tường trình các gói tin "trùng" với signature mà không có phản ứng trực tiếp gì đến các gói tin vi phạm. Tôi quyết định tải phiên bản mới nhất của snort và tái biên dịch nó để đưa vào một số chức năng "phản ứng trực tiếp" để đáp ứng với kế hoạch tôi ngầm định sẵn.

Phần biên dịch snort không có gì lý thú ngoài việc phải chuẩn bị một số thư viện "cấp thấp" cần thiết để snort có thể sniff và việc chỉnh định thêm chọn lựa "--enable-flexresp" để cho phép snort ứng động đến các packet vi phạm. Gói mã nguồn của snort khá nhỏ nên thời gian biên dịch chỉ mất có vài phút là xong. Hồ sơ cấu hình của snort -23- đã có sẵn, init của snort -24- đã có sẵn, tôi chỉ cần điều chỉnh một số chi tiết cần thiết để buộc binary mới của snort chạy trên hệ thống và dùng hồ sơ cấu hình có sẵn.

Bước kế tiếp là bước tôi cho là lý thú nhất vì nó trực tiếp ứng dụng những gì tôi đã phân tích trong phần đầu của bài. Đúng vậy! chính là "x-flash" POST payload và những thông tin hết sức đặc thù của chúng. Tôi hình thành "signature" đầu tiên cho HVA server như sau:
Code:


Tôi không có dự định phân tích và giả thích kỹ lưỡng signature ở trên trong bài viết này, nếu bạn thật sự thích thú với snort thì trên website của snort có đầy đủ các thông tin chi tiết để có thể hiểu nó. Tuy nhiên, tôi muốn nêu ra vài chi tiết quan trọng (và lý thú) về signature. Signature là "kim chỉ nam" cho snort làm việc, cho nên chúng rất đa dạng và phức tạp. Trong trường hợp này, tôi muốn snort làm cách nào ít tốn thời gian và tài nguyên nhất để phản ứng kịp thời đến các packets có tính chất như tôi đưa ra trong signature trên:
- flags: PA: tôi nắm chắc là các gói tin "x-flash" có TCP flag là ACK-PSH nên chỉ định snort tập trung vào các gói mang flag PA (PSH ACK) thay vì mất thời gian và tài nguyên với mọi gói tin đi vào.
- flow:to_server: tôi muốn snort chỉ kiểm tra các gói tin đi vào server và không mất thời gian với gói tin đi ra vì HVA sever không dùng "x-flash" để "chơi" ai cả
- content: "|50 4f 53 54|"; content:"|78 2d 66 6c 61 73 68|";: tôi muốn snort chỉ kiểm tra các gói tin có nội dung như đã chỉ định trong "content" này, và nếu quả thật chúng là như vậy thì mới có thêm phản ứng.
- offset:30; depth:80;: tôi muốn thâu hẹp phạm vi tìm kiếm dấu hiệu đặc thù để snort không mất thời gian đi lục tìm trong suốt một payload dài thậm thượt.
- resp:rst_all và react:block: tôi muốn snort phải có phản ứng đến các gói tin có tính chất như trên. Phản ứng bằng cách là liên tiếp gởi 3 gói RST đến cả hai đầu truy cập (giữa máy chạy "x-flash" và HVA servers) để tắt ngang đường lưu thông và sau đó, cản luôn gói tin nào tiếp tục đi tới từ nguồn mang gói tin vi phạm này.

Vậy, điều lý thú là ở đâu? theo tôi, đó là ở chi tiết hình thành một signature sao cho snort có thể ứng hoạt ở mức độ nhanh nhất có thể được. Chi tiết content ở trên có thể không cần thiết phải mang giá trị HEX mà có thể ở dạng ASCII bình thường (bạn thử đổi giá trị HEX trong ví dụ trên xem nó là gì). Tuy nhiên, làm như vậy là làm cho snort chậm thêm một tí vì nó phải chuyển đổi từ ASCII thành HEX rồi mới xem gói tin có dấu hiệu trùng với đã ấn định hay không. Chi tiết offset cũng hết sức lý thú vì nếu thiếu chi tiết này, snort sẽ đi suốt một dải thông tin của cả gói tin để tìm xem có cái gì trùng hay không, làm thế thì rất mất thời gian. Tuy nhiên, điểm tối quan trọng ở đây là để giúp snort phản ứng kịp thời đến gói tin vi phạm (thực thi resp:rst_all và react:block) trước khi nó đã đi vào đến tận web server thành công.

Chúng ta có thể điều chỉnh snort để nó "gọi" firewall và cản hẳn IP nào vi phạm, nhưng làm như thế thì quá nguy hiểm vì nếu có nhiều người dùng vô tội cùng chia xẻ IP đó thì sẽ bị cản chung ---> mục đích tạo "denial of service" đã thành công. Nói cho cùng, nạn "x-flash" xảy ra với HVA thuộc dạng "slash-dot effect" -25- vì các "x-flash" chỉ đơn thuần tạo ra quá nhiều requests, và những request này hoàn toàn hợp lệ (mặc dù chủ đích lại đen tối). Thay vì dùng phương pháp cản IP, bất cứ phương pháp nào cụ thể loại bỏ các gói tin có tính đặc thù như "x-flash" (và tương tự) đều là giải pháp khả thi. Bởi lẽ, cản IP là cản những cá nhân vi phạm lẫn những người vô can. Hơn nữa, chiến thuật cài "x-flash" vào một trang nào đó để người dùng duyệt trang ấy sẽ "vô tình" gởi requests đến HVA là chiến thuật dùng tay những kẻ vô can để thực hiện ý định. Đây chính là lý do càng không nên cản IP.

Dùng snort signature ở trên, tôi có hai mục đích chính (và rất cụ thể):
1. Bất cứ khi nào snort thấy một packet có tính chất như đã phân tích ở những phần trên --> reset nó, kết liễu nó, kết liễu cả đường nối giữa HVA và nó. Điểm này đơn giản và dễ hiểu.

2. Nếu một chùm gói tin đi vào thuộc dạng vi phạm mà snort không cản được thì ít nhất cũng tạo điều kiện cho firewall cản. Điều này có nghĩa, một stream được tạo ra một cách hợp pháp, đến lúc nào đó sẽ thuộc tình trạng "ESTABLISHED", firewall sẽ không cản trở các packets ra vào nếu chúng đã thuộc một xuất truy cập thuộc tình trạng này. Tuy nhiên, nếu một (và chỉ một packet) trong stream này bị chuyển thành tình trạng nào khác (do snort can thiệp) thì sẽ bị firewall cản trọn bộ các gói tin còn lại của stream vi phạm.

Hãy thử đào sâu một chút khía cạnh này, giả sử một request đi từ IP xxx.xxx.xxx.xxx đến HVA server:
- mở đầu bằng SYN --> OK, hoàn toàn hợp lệ, chưa có dấu hiệu gì về đặc tính "x-flash", snort sẽ không có phản ứng gì cả.
- tiếp theo HVA server trả lời request này bằng SYN-ACK --> OK, hoàn toàn hợp lệ, HVA server chỉ tiếp nhận và cho đầu bên kia biết là nó đã tiếp nhận truy cập, snort sẽ không can thiệp vì signature ở trên ấn định rất rõ là nó chỉ kiểm tra nguồn đi vào máy chủ (flow:to_server) và không cần phải làm gì với gói tin đi ra.
- packet kế tiếp đi vào hẳn là ACK-PSH và bắt đầu có chứa payload --> có chuyện xảy ra vì snort đã kiểm tra. Ngay lúc nó nhận đủ thông tin và nhận diện được gói tin này vi phạm, snort sẽ tạo báo động đến log, thực thi các lệnh đã ấn định. Chuyện gì xảy ra ở đây? Có hai trường hợp:
a) gói tin vi phạm này lọt vào thành công vì đến khi snort thực thi xong các lệnh trên thì gói tin đã hoàn tất. Snort bị rơi vào tình trạng "đánh gió" .

b) gói tin vi phạm bị snort "reset", theo những tôi theo dõi trước đây, snort vẫn có thể thực thi lệnh kịp thời và gói tin này bị cắt đứt giữa đường. Khi snort gởi lệnh rst_all nó thông báo cùng một lúc đến máy từ nguồn xxx.xxx.xxx.xxx và HVA server rằng: "xong, chấm dứt, kết thúc, không còn gì để tiếp tục" và hai đầu truy cập bị ngắt. Chuyện gì xảy ra ở giai đoạn này? socket trên HVA server đóng xuất truy cập này và đối với hệ thống cũng như firewall, xuất truy cập này không còn nữa. Nếu từ phía xxx.xxx.xxx.xxx vẫn tiếp tục gởi gói tin còn lại của stream đến HVA server, chắc chắn nó sẽ bị huỷ bỏ vì HVA firewall sẽ thấy gói tin này hoàn toàn mới, không thuộc xuất truy cập nào hết nhưng lại mang flag ACK-PSH (không phải là SYN để khởi tạo một xuất mới). Lý do rất đơn giản: HVA firewall là stateful firewall, nó theo dõi tình trạng mỗi gói tin ra vào. Nói theo thuật ngữ firewall thì gói tin tiếp tục đi vào này bị xếp vào dạng "lost state" hay "invalid state" nên không được tiếp nhận theo đúng quy định của firewall.

- nếu gói tin ở trên đi qua được vì trường hợp a) xảy ra thì gói tin kế tiếp sẽ tiếp tục được gởi (ở dạng continuation nếu gói tin trên quá lớn). Cũng như trên snort tiếp tục theo dõi, nếu có thêm một signature bổ sung cho signature trên thì nó sẽ ứng động và xử lý gói tin tiếp theo này và một trong 2 trường hợp a) hoặc b) sẽ xảy ra. Một trong những signature đi theo mà tôi đã hình thành để xử lý các gói "continuation" có dạng tương tự như sau:
Code:


Signature này chỉ định cho snort tiếp tục theo dõi và phản ứng đến các gói tin mang tính chất như trên. Nếu thích thú thì bạn thử chuyển đổi giá trị HEX -26- ở trên để xem giá trị ASCII là gì (?)

Vậy ngoài giới hạn connection đã bàn ở trên, snort có thể gián tiếp giúp cho công tác cản trở thêm các gói tin vi phạm. Nếu chủ quan thì có thể cho rằng có cơ hội 50/50 cho mỗi gói tin vi phạm bị cản theo phương thức trên. Nếu dè dặt thì có thể cho rằng ít ra cũng có 1/3 cơ hội gói tin vi phạm bị cản theo cách này. Như vậy, trong 12000 "quả" đi vào thì có 6000 "quả" bị cản nếu dùng phương thức giới hạn 8 connections ở trên, cộng thêm 1/3 số lượng các "quả" bị snort cản với số 6000 còn lại thì tổng số lên đến:
Code:


Sau khi tái biên dịch snort, chỉnh sửa các hồ sơ cấu hình và thêm vào các signature cần thiết (có nhiều hơn 2 signatures cho x-flash vì có những biến đổi trong các gói tin vi phạm này), tôi tái khởi động snort và dành vài phút để điều theo dõi log của snort, sau đây là một đoạn ngắn mà snort (phiên bản mới) đã "báo cáo" sau khi được tải thêm những signature cụ thể cho "x-flash":
Code:


Chuyện gì xảy ra với cơn lũ "x-flash" hàng đêm? Bạn muốn biết tiếp à? vậy thì đón xem bài kế tiếp vậy.

Chú thích:
-19- FIN đi sau SYN và RST đi sau SYN có nghĩa là máy con gởi SYN để truy cập đến server, server trả lại SYN-ACK và thay vì máy con tiếp tục gởi ACK để tiếp nối 3-way handshaking thì nó lại gởi RST hoặc FIN ở bước này để kết thúc xuất truy cập với server. Đây là kỹ thuật tấn công SYN-FIN hoặc SYN-RST nhằm tạo ra hàng "tấn" "TIME_WAIT" sockets trên server (để tiêu hao memory của server).

-20- Đối với giao thức TCP, một xuất truy cập mới toanh phải bắt đầu từ gói tin mang flag SYN (để đi qua 3 bước bắt tay). Nếu xuất truy cập mà bắt đầu bằng flag nào khác thì có thể là chủ nhân của nó không có thiện ý hoặc cũng có trường hợp gói SYN đã gởi trước đó 10 phút chẳng hạn và bị time-out vì lý do gì đó, mãi sau 10 phút sau khi server đã trả lời SYN-ACK nó mới "lồm cồm" đi ngược lại và hồi đáp với gói tin ACK để tiếp tục xuất truy cập. Lúc này, nếu server được chỉnh để "time-out" sớm hơn 10 phút thì gói tin hồi đáp trên trở nên vô nghĩa đối với firewall. Firewall sẽ cho rằng đây là gói tin hoàn toàn mới nhưng lại mang flag ACK. Trên thực tế, loại packets này chỉ thấy ở một số phiên bản cũ của MS (như Windows 9x) hoặc chỉ thấy khi chủ nhân của nó cố tình gởi gói tin loại này với mục đích không chính đáng cho lắm.

-21- một "open source" NIDS (Network Intrusion Detection System) được phát triển rất mạnh. Hiện snort đã được ứng dụng trong rất nhiều sản phẩm bảo mật hạng nặng. Xem thêm chi tiết ở: http://www.snort.org

-22- snort là một loại IDS dùng signature. Signature là một dạng rule được khảo sát và hình thành từ những bằng chứng và dấu hiệu thâu thập được từ các gói tin có tính dung hại và có tính đặc thù. Dựa vào signature, snort sẽ báo động (hoặc ứng tác nếu chỉnh định cho nó) nếu nó tìm thấy gói tin được "sniff" mang tính thất trùng hợp với signature có sẵn.

-23- có nhiều cách chạy "snort" nhưng cách biến nó thành một daemon (một dịch vụ của hệ thống) thì nên dùng một hồ sơ cấu hình hoàn chỉnh vì có quá nhiều chi tiết cần chỉnh định để snort có thể hoạt động như một IDS... thứ thiệt.

-24- để khởi động snort như một daemon khi máy chủ khởi động, cần phải có init script để nó được khởi động đúng run level (cho các hệ thống *nix thuộc nhánh SysV). Vấn đề này thuộc phạm trù chuẩn bị hệ thống. Để biết thêm chi tiết, bạn nên tham khảo về "run level of SysV).

-25- "slashdot effect" là thành ngữ ám chỉ hiện tượng một website quá sức phổ biến và được ưa thích nên lượng truy cập cao hơn mức hệ thống có thể đảm đương. Điều này dẫn đến kết quả người dùng vào website này đều bị trì trệ như nhau. Cụm "slashdot effect" đi từ hiện tượng các trang liên mạng của nhóm "slashdot" trở nên quá phổ biến trước đây do có nhiều đường dẫn từ nhiều site khác dùng để đi ngược lại site của slashdot, dẫn đến tình trạng webserver của slashdot bị quá tải. Tình trạng quá tải này không phải do bị DoS vì các truy cập đa số đều ở dạng hợp lệ và tình trạng này không xảy ra do một hoặc nhiều người cố tình tạo ra.

-26- hex convertor, công cụ dùng để chuyển đổi giá trị từ HEX thành ASCII; một thứ đồ nghề không thể thiếu được nếu bạn thật sự muốn chuyên sâu trong lãnh vực phân tích bảo mật (security analysis). Tính chất gói tin là nền tảng của kỹ thuật phân tích bảo mật và từ kết quả phân tích này, các biện pháp khắc phục sẽ được hình thành. Có rất nhiều hex convertor cho mọi hệ điều hành. Một trong những hex convertor tôi thường dùng trên hệ điều hành Windows là HEXwrite, một freeware gọn nhẹ do David De Groot viết. Có thể tìm thấy HEXwrite ở http://bluefive.pair.com. Trên *nix tôi dùng "heme" có thể tải từ http://heme.sourceforge.net/, heme dùng thư viện curses cho việc hiển thị và nhập dữ liệu cho nên muốn dùng nó, bạn cần thư viện curses trên hệ thống. Có thêm một công cụ chuyển đổi hex rất hay viết bằng Java gọi là DataWorkshop, bạn có thể download từ http://www.dataworkshop.de/

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


Điều chỉnh:
- 17/11/2004: điều chỉnh chi tiết snort là NIDS (theo yêu cầu của ngoluoc)