Ký sự các vụ DDoS đến HVA - Phần 12

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận bảo mật

Ký sự các vụ DDoS đến HVA - Phần 12

[Article] Ký sự các vụ DDoS đến HVA - Phần 12	22/06/2006 14:38:02 (+0700) \| #1 \| 639

prof
Moderator

Joined: 23/11/2004 01:08:55
Messages: 205
Offline

Tối 21/01/2005

Ăn tối xong, tôi log vào HVA server. Việc đầu tiên tôi làm là tải về một bản snort ổn định và biên dịch nó với những chọn lựa cụ thể và cá biệt cho nhu cầu trên HVA server. Thực hiện trọn bộ công việc tải nguồn của snort và các nguồn của các thư viện cần thiết cho snort cũng như quy trình biên dịch, cài đặt chỉ mất chưa tới ba mươi phút.

Tôi quyết định dùng các hồ sơ cấu hình có sẵn của snort và chỉ dùng binaries mới vừa biên dịch bởi vì snort đã từng hoạt động trên server này (ở mức căn bản). Trên đường về nhà chiều hôm nay, tôi đã hình thành xong mấy cái signature mới cho snort. Tôi copy chúng vào nhóm luật "chống x-flash" trước đây và khởi động snort. Syslog thông báo snort khởi động thành công, không hề có sự cố nào. Tôi "tail" vào log của snort để xem tình hình ra sao. Tôi dự phỏng sẽ thấy hàng tràng thông tin chạy trên màn hình nhưng thật lạ lùng, snort hoàn toàn im ắng. Lạ nhỉ? hay là mấy cái signature bị sai? không thể nào vì dẫu signatures của tôi tạo ra có sai thì một số các signatures do snort cung cấp phải hoạt động và thông báo tình hình.

Tôi kiểm tra lại từ đầu từng phần một trong cấu hình của snort và khám phá ra rằng: chỉ một con số sai trong subnet được ấn định cho snort "lắng nghe" làm cho nó không hề thấy bất cứ thông tin nào đi xuyên qua hệ thống (vì snort bị áp đặt lắng nghe trên một subnet không tồn tại). Loay hoay tìm kiếm và điều chỉnh cho trục trặc này làm mất thêm mười lăm phút nữa. Cuối cùng, tôi khởi động snort lại và phóng một cái "tail" đến snort log. Tôi gật đầu hài lòng khi thấy trên màn hình hiện ra vun vút những dòng log của snort:

01/21-19:37:28.369857 [**] [1:0:0] POST Null - Flash attack HVA [**] [Classification: POST-attack] [Priority: 1] {TCP 221.132.48.226:15283 -> 219.207.204.25:80
01/21-19:37:28.369857 [**] [1:0:0] POST Null - Flash attack HVA [**] [Classification: POST-attack] [Priority: 1] {TCP} 221.132.48.226:15283 -> 219.207.204.25:80
01/21-19:37:28.399600 [**] [1:0:0] POST Null - Flash attack HVA [**] [Classification: POST-attack] [Priority: 1] {TCP} 203.162.123.197:64104 -> 219.207.204.25:80
01/21-19:37:28.399600 [**] [1:0:0] POST Null - Flash attack HVA [**] [Classification: POST-attack] [Priority: 1] {TCP} 203.162.123.197:64104 -> 219.207.204.25:80
01/21-19:37:28.406221 [**] [1:0:0] POST Null - Flash attack HVA [**] [Classification: POST-attack] [Priority: 1] {TCP} 203.210.212.141:35762 -> 219.207.204.25:80
01/21-19:37:28.406221 [**] [1:0:0] POST Null - Flash attack HVA [**] [Classification: POST-attack] [Priority: 1] {TCP} 203.210.212.141:35762 -> 219.207.204.25:80
01/21-19:37:28.441929 [**] [1:0:0] POST Null - Flash attack HVA [**] [Classification: POST-attack] [Priority: 1] {TCP} 211.198.94.249:4859 -> 219.207.204.25:80
01/21-19:37:28.441929 [**] [1:0:0] POST Null - Flash attack HVA [**] [Classification: POST-attack] [Priority: 1] {TCP} 211.198.94.249:4859 -> 219.207.204.25:80
01/21-19:37:28.485582 [**] [1:0:0] POST Null - Flash attack HVA [**] [Classification: POST-attack] [Priority: 1] {TCP} 203.162.169.142:1501 -> 219.207.204.25:80
01/21-19:37:28.485582 [**] [1:0:0] POST Null - Flash attack HVA [**] [Classification: POST-attack] [Priority: 1] {TCP} 203.162.169.142:1501 -> 219.207.204.25:80
01/21-19:37:28.507376 [**] [1:0:0] POST Null - Flash attack HVA [**] [Classification: POST-attack] [Priority: 1] {TCP} 203.162.169.142:1317 -> 219.207.204.25:80
01/21-19:37:28.507376 [**] [1:0:0] POST Null - Flash attack HVA [**] [Classification: POST-attack] [Priority: 1] {TCP} 203.162.169.142:1317 -> 219.207.204.25:80

Nếu bạn xem kỹ phần thời gian của mỗi biến cố xảy ra (màu đỏ), bạn hẳn sẽ thấy mức độ x-flash dồn dập đổ vào HVA server thế nào. Số liệu ở trên chỉ là một đoạn tượng trưng. Ở chế độ fast log và logging theo dạng binaries, snort ghi nhận một số lượng x-flash "đụng" đến NIC của HVA server kinh khủng hơn như thế rất xa.

Cũng trong khi đó, web server của HVA thông báo các thông tin như sau:

220.79.101.75 - - [21/Jan/2005:19:37:28 +0900] "POST /forum/ HTTP/1.1" 403 327 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
220.79.101.75 - - [21/Jan/2005:19:37:28 +0900] "POST /forum/ HTTP/1.1" 403 327 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
210.245.57.38 - - [21/Jan/2005:19:37:28 +0900] "GET /favicon.ico HTTP/1.1" 404 331 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0"
217.29.82.40 - - [21/Jan/2005:19:37:22 +0900] "GET /forum/index.php?act=Reg&CODE=00 HTTP/1.1" 200 6317 "/forum/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
222.252.232.163 - - [21/Jan/2005:19:37:28 +0900] "GET /forum/jscripts/ipb_forum.js HTTP/1.1" 304 - "/forum/index.php?showforum=87&prune_day=100&sort_by=Z-A&sort_key=last_post&topicfilter=all&st=30" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
221.132.48.226 - - [21/Jan/2005:19:37:28 +0900] "POST /forum/ HTTP/1.1" 403 327 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
203.162.123.197 - - [21/Jan/2005:19:37:28 +0900] "POST /forum/ HTTP/1.1" 403 327 "-" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)"

Đoạn màu đỏ chính là đoạn các cú x-flash đi vào và web server log ghi nhận chúng. Điều cần chú ý ở đây là status 403 cho mỗi x-flash log (xem lại chú thích -27-).

Hai đoạn log ở trên cho thấy:
- trong khoảng thời khắc 19:37:28-xx có khoảng 12 cú x-flash đi vào (snort log ghi nhận được, log ở dạng binaries ghi nhận nhiều hơn gấp bội). Tuy nhiên, lên đến web server (application layer) thì có 4 cú x-flash xuất hiện nhưng lại bị dính status 403.

- điều này chứng tỏ có ít nhất là 8 cú x-flash bị loại bỏ trước khi chúng có thể đi lên đến web server (có thể do firewall loại bỏ từ vòng ngoài vì quá connection limit, có thể do snort bắt gặp và gởi các gói RST để cắt đứt chúng...). Khi đến web server, một lần nữa 4 cú x-flash sống sót ở mức này lại bị loại bỏ vì mod_security phát hiện và trả ngược về nguồn gởi đi cú x-flash bằng status 403. Chúng đã không có cơ hội đi sâu hơn.

- điều này cũng cho thấy web server phải nhận số lượng tải cao hơn bình thường (vì vẫn có những cú x-flash vượt qua, và vì chúng hoàn toàn hợp lệ về mặt giao thức). Tuy nhiên, mức độ gia tăng trên web server thật sự không đáng kể bởi vì lúc này snort và iptables đã "hoá giải" ít nhất 80% cơn lũ x-flash. Sở dĩ server load đã lên tới con số kỷ lục chiều nay là vì firewall đã mở cổng một cách dễ dãi. Nó cho phép một số lượng truy cập khá lớn đến từ mỗi client (x-flash hoàn toàn không bị loại trừ vì chúng hợp pháp trên mặt giao thức). Người dùng cảm thấy chậm ngay lúc ấy là vì các socket đóng / mở hoàn toàn phụ thuộc và quy định tiêu chuẩn của kernel (nên thời gian TIME_WAIT và FIN_WAIT kéo dài theo đúng quy định). Ngay khi snort hoạt động, các cú RST của nó hủy bỏ những truy cập từ x-flash và có đến ít nhất 50% số lượng socket được tái dụng.

- nói về mặt tài nguyên (CPU, RAM), máy chủ HVA thừa sức để cung cấp cho web service hoạt động cao tải hơn. Nói về mặt băng thông, vì những cú POST trên "bị" cắt xén nhỏ đi (để vừa khít trong một cú chuyển gởi) nên hoá ra những cú POST này chẳng nặng nề hơn những cú GET bình thường. Tài nguyên được dùng chủ yếu trong hoàn cảnh này là tài nguyên cho mod_security; nó cần phải kiểm tra các gói tin (giao thức HTTP) và xử lý theo các luật đã định.

Mười lăm phút sau khi snort hoạt động, tôi xem lại server load:

# w
load average: 0.78, 1.04, 8.75

Trong vòng 5 phút vừa qua, server load chỉ còn 0.78
Trong vòng 15 phút vừa qua, server load chỉ còn 1.04
Trong vòng 30 phút trước đây, server load nằm ở mức 8.75 (tương đương như hồi chiều).

Snort log vẫn ghi nhận cơn lũ x-flash ùn ùn tuôn vào. Server log vẫn lác đác ghi nhận các x-flash bị status 403 và ngay lúc ấy, tôi log vào diễn đàn HVA bằng trình duyệt. Tình hình được cải thiện thấy rõ so với chiều nay. Tôi duyệt qua các trang trong diễn đàn và cảm thấy tốc độ truy cập hoàn toàn có thể chấp nhận. Ngay trong khoảng thời gian này tôi bắt đầu thấy lác đác một số GET request (cụ thể) đến cái banner chính của hva với URI như sau:

GET /forum/style_images/fusion[1]/banner.swf HTTP/1.1. Điều này chứng tỏ kẻ tấn công HVA vừa dàn dựng loạt GET này mới toanh (bởi vì HVA vừa nâng cấp phiên bản diễn đàn và cấu trúc URI dùng để chứa các bức hình đã thay đổi). URI trên chỉ vừa được cập nhật mấy ngày trước đây. Tôi bèn tail cái log của snort để kiểm nghiệm sự hiện diện các cú GET này như sau:

# tail -f /var/log/snort/alert | grep GET

Quả thật cứ mỗi giây lại có dăm ba "quả" GET đi vào. Tôi quyết định "dump" một mớ packets để phân tích xem các cú GET này có những thay đổi gì hay không. Sau hai phút, tôi tắt bỏ tcpdump và tải gói dump này về laptop của tôi. Tôi tự nhủ "chuyện phân tích này có thể để dành cho sáng mai, trên đường đi làm".

Tôi dành khoảng thời gian ngắn ngủi còn lại của ngày 21/1 để thực hiện một loạt penetrating test đến HVA server ở tầng thấp (bao gồm scanning, flooding và gởi một loạt các gói tin "bất hợp lệ") để kiểm tra "thái độ" của máy chủ HVA. Tôi không tiện nêu ra kết quả ở đây vì nó quá... tế nhị. Điều tôi có thể tiết lộ với bạn là sau khi khởi động snort, nó đã cảnh báo đến vài chục loại tấn công đến HVA server (nhiều loại, nhiều kiểu, nhiều mức độ khác nhau).

Mười lăm phút sau nữa, tôi kiểm tra lại server load và thấy các con số trung bình không thay đổi gì mấy (vẫn ở mức 0.7 - 1.0 0.8 ). Tôi lẩm bẩm "chỉ tại snort vắng mặt và firewall quá dễ chịu mà ra nông nổi" và log off HVA server.

Kinh nghiệm đáng nêu lên ở đây (cho những ai có trách nhiệm bảo mật cho các máy chủ):
- môi trường máy chủ càng ổn định thì máy chủ càng vững vàng. Càng nhiều dời đổi, càng tạo nên những thiếu sót (khó thấy).
- mọi thay đổi trên máy chủ (như cập nhật phiên bản, thay đổi cấu hình hoạt động, thay đổi địa chỉ...) đều phải được ghi nhận trong một hồ sơ nào đó để tiện theo dõi và xử lý khi cần.
- tạo một "check list" để kiểm tra trọn bộ các cơ phận liên quan trực tiếp và gián tiếp trong cơ chế bảo mật của (các) máy chủ.
- sau mỗi lượt thay đổi / cập nhật, phải thực hiện một quy trình thử nghiệm cho máy chủ này. Thử nghiệm này có thể trải dài từ thử nghiệm tính năng cho đến thử nghiệm tính bền bỉ và vững vàng của máy chủ (penetrating test hay còn gọi là pen test).

Chuyện gì tiếp tục xảy ra với các cú POST và GET? Mời bạn đón xem phần http://hvaonline.net/hvaonline/posts/list/280.html

Go to:

Users currently in here
1 Anonymous