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

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 22

[Article] Ký sự các vụ DDoS đến HVA - Phần 22	30/09/2008 20:59:19 (+0700) \| #1 \| 153418

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Những ngày cuối tháng 8, 2008, công việc chồng chất, mẹ tôi lại bệnh nặng nên tôi ít vào diễn đàn, ít theo dõi tình hình hệ thống máy chủ của diễn đàn.

Tối 25 tháng 8, tôi đăng nhập YIM để đọc offline messages và kiểm tra mail vì đã nhiều ngày không mó tới chúng, tôi nhận được một thông điệp của JAL như sau:
"Anh xem thử servers của mình thế nào đó. Mấy hôm nay cứ khoảng, 7, 8 giờ tối là servers, đường dây đều bị treo cứng cả tiếng đồng hồ mới chạy lại. Không biết có phải mình bị DDoS không nữa."

Tôi hồi báo JAL:
"Ừa, để anh sắp xếp thời gian xem thử chuyện gì xảy ra."

Trong lòng tôi nghĩ chắc là cái CSDL lại trở chứng deadlock đâu đó chớ gần hai năm nay, chưa có cú DDoS nào gọi là đáng kể hoặc đáng quan tâm cả.

Sau một ngày dài dằng dặc với ngập ngụa công việc, tôi đã mệt lắm rồi nên chẳng muốn đụng tới máy chủ hay máy con gì nữa. Định logoff nhưng nghĩ sao, tôi lại login máy chủ chạy web của HVA để xem qua. Theo phản xạ tự nhiên, tôi lướt qua mớ logs trên máy chủ với sed, awk, cat, sort, uniq..... -65- nhưng chẳng thấy gì đặc biệt. Tôi cố nán lại để xem thêm logs của vài ngày trước cho đến hôm nay hy vọng tìm ra chút manh mối nhưng hoàn toàn chẳng thấy gì bất thường hoặc ít nhất, chẳng có gì mang dấu hiệu web server đã bị DDoS.

Tôi gởi cho JAL một thông điệp báo rằng tôi sẽ cố gắng thu xếp thời gian để vào máy chủ khoảng 7, 8 giờ tối để theo dõi hiện trạng ngay lúc bị "DDoS" và logoff.

Tối 25/8/2008
Tôi pha một ly cà fê và login máy chủ HVA, mở mấy cái console lên và chạy vài cái "tail" rồi ngồi duyệt diễn đàn HVA. Không lâu sau đó, tình trạng duyệt diễn đàn càng lúc càng chậm. Tôi chuyển sang console đang "tail" access log của web server và thấy số lượng request / response ít lại từ từ nhưng chẳng thấy có gì khác lạ. Tôi quyết định chạy thử tcpdump để lấy một nhúm gói tin về phân tích:
# tcpdump -i eth0 -s0 -w 25-08-2008

Vội vã copy file 25-08-2008 về laptop và dùng wireshark (ethereal) mở ra, tôi phát hiện ngay máy chủ đang bị Syn Flood với vận tốc cực nhanh:

Tôi chép miệng: "Mấy cái quỷ synflood này làm sao làm các truy cập khác chậm hơn được cà? Chắc chắn phải có cái gì khác nữa."

Tôi tiếp tục duyệt qua mớ packets từ file 25-08-2008 ở trên và phát hiện ra thêm một số thông tin lý thú, ví dụ:

Ngoài tcp synflood còn có một mớ UDP fragmentation flood.

Kiểm tra lại kernel parameters cho IPV4, tôi thấy ngay số lượng SYN được nhận và giá trị TIME_OUT -66- của chúng không đủ để phục vụ. Điều này có nghĩa, những cú SynFlood kia quá nhiều và quá nhanh nên chúng chiếm hết chỗ cho các request hợp lệ (người dùng bình thường). Chuyện này không khó khắc phục mấy, đặc biệt memory còn dư giả. Tôi điều chỉnh ngay /etc/sysctl.conf -67- và áp dụng ngay lập tức, đồng thời cũng thắt chặt thêm vài chi tiết nhỏ trên firewall. Sau một phút, tình hình duyệt diễn đàn HVA thay đổi thấy rõ: duyệt nhanh hơn mặc dù lượng syn flood không hề giảm mà còn tăng hơn.

Thế còn cái mớ UDP fragmentation flood thì sao? Lúc ấy, tôi cho rằng chúng không tạo mấy dung hại bởi lẽ chúng là những gói UDP bất hợp lệ (bạn thử xem chúng bất hợp lệ ở điểm nào từ bức ảnh kèm theo? smilie

), vả lại chẳng có bao nhiêu gói tin UDP để đủ quan tâm (và đây là điều khiến tôi phải nhức đầu vài ngày sau đó).

Tôi quá mệt nên logoff sau khi gởi JAL một thông điệp ngắn gọn rằng mọi chuyện đã tạm ổn.

Ngày 26/8/2008
Sáng sớm ngày 26/8/2008, tôi vẫn bị cảm giác có gì đó chưa hoàn toàn an tâm. Tôi đăng nhập vào máy chủ của HVA và rà xuyên các logs một lần nữa. Không có dấu hiệu gì khác thường (tôi đã điều chỉnh firewall để báo cáo thêm chi tiết các hoạt động đêm trước). Dành khoảng nửa giờ với mấy cái máy chủ HVA, tôi đành phải xếp chúng qua một bên vì công việc đang bề bộn.

Tối hôm ấy, JAL lại gởi thêm cho tôi mấy cái e-mail và offline messages thông báo rằng tình trạng máy chủ bị "đơ" vẫn tiếp tục xảy ra. Tôi rất ngạc nhiên và không hiểu chuyện gì đã xảy ra. Ngay lúc nhận được e-mail của JAL, tôi thử vào diễn đàn và quả thật, truy cập rất trì trệ.

Đăng nhập vào máy chủ HVA, tôi phóng nhanh vài cái "tail" để theo dõi và chẳng thấy gì lạ. Kiểm tra netstat, kiểm tra top, kiểm tra firewall logs, kiểm tra web logs.... mọi chuyện đều bình thường, vậy cái gì đang xảy ra đây? Tôi quyết định chạy thử tcpdump để xem chuyện gì xảy ra:
# tcpdump -i eth0 tcp port 80

và chính cái lệnh trên đã... hại tôi. smilie

. Có lẽ bạn không thể đoán ra tại sao nó hại tôi nhưng sự thể rất đơn giản: tôi đòi tcpdump bắt lấy các gói tin đụng đến cổng 80 và dùng giao thức tcp. Điều này có nghĩa tôi hoàn toàn không thấy được các gói tin khác (có thể) đang tấn công máy chủ HVA. Dạng SYN Flood tối hôm qua hoàn toàn biến mất, biên độ các gói tin ra vào cổng 80 rất bình thường. Tôi ngớ ra vì chẳng biết sự thể thế nào nữa. Tôi gởi cho JAL một e-mail và bảo JAL kiểm tra xem phần cứng hoặc đường truyền có gì bất thường hay không bởi vì trên máy chủ mọi sự đều "bình thường".

Tôi logoff, mệt lả sau một ngày bận rộn.

Chú thích:
-65-: Các "lệnh" thông thường trên *nix để đọc và phân tích ASCII files.

-66-: Hai giá trị tối quan trọng cần theo dõi và điều chỉnh là:
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv và net.ipv4.tcp_max_orphans. Không có giá trị nào là tối ưu cho mọi hệ thống mà giá trị này phải được tính toán và điều chỉnh cho thích hợp tùy hoàn cảnh. Nếu net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv quá lớn, số lượng SYN sockets sẽ ngập ngụa trên server dẫn đếnt tình trạng người dùng hợp lệ không có cơ hội truy cập. Nếu như giá trị này quá thấp, SYN sockets sẽ bị triệt tiêu nhanh chóng khiến cho người dùng hợp lệ sẽ bị tình trạng chập chờn khi truy cập. Giá trị net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv này nên đủ thấp và tương quan với giá trị net.ipv4.tcp_max_orphans để cho phép người dùng hợp lệ có cơ hội truy cập. Điều này có nghĩa, net.ipv4.tcp_max_orphans cần được gia tăng (và tất nhiên, physical memory trên máy chủ phải được gia tăng để tránh tình trạng hết memory và treo máy).

-67-: Hồ sơ cấu hình cho kernel parameters trên Linux. Hồ sơ này có thể được điều chỉnh và áp dụng bằng lệnh sysctl -p thay vì dùng phương pháp điều chỉnh trực tiếp vào /proc filesystem. Tìm hiểu thêm /proc filesystem trên Linux để nắm sâu hơn.

What bringing us together is stronger than what pulling us apart.

[Question] Re: Ký sự các vụ DDoS đến HVA - Phần 22	01/10/2008 08:46:42 (+0700) \| #2 \| 153478

bigpig42
Member

Joined: 17/01/2008 18:12:06
Messages: 36
Offline

Những phần này rất hay, lâu rồi mới lại có tiếp để xem, hy vọng anh conmale post tiếp......đang hấp dẫn anh ạ.

<Lúc ấy, tôi cho rằng chúng không tạo mấy dung hại bởi lẽ chúng là những gói UDP bất hợp lệ (bạn thử xem chúng bất hợp lệ ở điểm nào từ bức ảnh kèm theo?>

-> em chỉ thấy rằng trong 1 khoảng thời gian rất ngắn từ source là 2 dải IP request xen kẽ nhau 83.142.226.7x và 209.123.8.12x liên tục request

[Question] Re: Ký sự các vụ DDoS đến HVA - Phần 22	01/10/2008 21:29:26 (+0700) \| #3 \| 153521

lQ
Moderator

Joined: 29/03/2005 17:06:20
Messages: 494
Offline

hi anh conmale,

Ko lẽ firewall của HVA ko filtered, mở một số dịch vụ UDP?? Ngoài ra, HVA cũng ko gửi packets reply những traffic đó. Vậy thì làm sao nó lại khiến anh nhức đầu? E đợi bài kế của anh.

[Question] Re: Ký sự các vụ DDoS đến HVA - Phần 22	01/10/2008 22:15:44 (+0700) \| #4 \| 153529

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

to bigpig42: nếu em "nhìn kỹ" thì sẽ thấy cái UDP packets đó không có source port và destination port smilie

. Đó chính là điểm "bất hợp lệ" lý thú.

to lQ: bởi chính firewall cản chúng nên mới sanh ra chuyện... nhức đầu smilie

. Bài kế tiếp anh sẽ trình bày.

Thân.

What bringing us together is stronger than what pulling us apart.

[Question] Re:Ký sự các vụ DDoS đến HVA - Phần 22	02/10/2008 00:01:39 (+0700) \| #5 \| 153545

JFS
Member

Joined: 22/03/2004 22:27:38
Messages: 192
Location: ----------d
Offline

Chào anh conmale !

Em tò mò quá tại sao FireWall filtered những gói tin UDP không hợp lệ thì giảm hiệu năng tại FireWall sao anh ?
Và nếu không có Source Port và Destination Port thì làm sao những gói tin ấy chạy vào được ạ .

Vì bị chặn ngay bởi FireWall , chính vấn đề này lại gây ra rắc rối sao anh ? Tò mò quá . Đang đợi bài kế của anh .

JFS

sugarCRM

[Question] Re: Ký sự các vụ DDoS đến HVA - Phần 22	02/10/2008 02:10:53 (+0700) \| #6 \| 153561

giobuon
Member

Joined: 10/09/2006 06:25:46
Messages: 72
Offline

Chẳng lẽ đây là fragment attack. Rõ ràng các gói này đi xuyên qua được firewall thì anh mới dump đc cả đống thế kia chứ smilie

Hi vọng sẽ sớm có bài tiếp theo smilie

[Question] Re: Ký sự các vụ DDoS đến HVA - Phần 22	02/10/2008 04:13:19 (+0700) \| #7 \| 153581

cvhainb
Member

Joined: 04/01/2007 14:32:38
Messages: 251
Offline

Hix đang hay mà đứt quãng smilie

[Question] Re: Ký sự các vụ DDoS đến HVA - Phần 22	02/10/2008 23:22:42 (+0700) \| #8 \| 153682

Phó Hồng Tuyết
Member

Joined: 20/04/2007 20:02:10
Messages: 275
Location: Nơi Sâu Thẳm Tâm Hồn
Offline

To @ conmale.
Em thì dùng cách khác đó là :
1. Ghi nhận và đếm sys, timewait của một ip. ( port 80,3306,443)
2. Clean all (processes ) connecting với thời gian định trước ( của em là 60 - 120s - nhằm xác định lại connect nào là thật và connect nào là ảo ).
3. Tạo rules cho sys căn cứ vào 1. để banip.
4. Tinh chỉnh lại timeout và keepalive.
và một số option khác.
kết quả.
- đang chờ ngày tái hẹn với Tera.
em test trên con botnet với foold sys thì có kết quả khả quan. Nhưng với Tere em chưa thử. Huy vọng mong manh cầm cự được 5 phút .

"Một người thành công không có ý nghĩ đổ thừa thất bại do ...."

Go to:

Users currently in here
1 Anonymous