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

prof — GMT

Trưa 22/1/2005 Giờ ăn trưa, tôi dành vài phút login HVA server để xem tình hình. Hiện có hơn 60 người đang ở trên diễn đàn, tuy nhiên server load thật thấp: # w load average: 0.15, 0.43, 0.26 "Tail" snort log, tôi vẫn thấy rỉ rả những cú GET buồn cười kia đi vào. Điều tôi hết sức ngạc nhiên là không hề có tăm tích một cú x-flash POST nào đi vào. Tôi thử grep cái alert log hiện dụng của snort xem sao: # grep POST /var/log/snort/alert | wc -l 7989 Vậy là vẫn có POST ấy chứ nhưng con số này quá ít, chuyện gì nhỉ? Để xem thử cú POST cuối cùng đi vào lúc nào. Tôi tiếp tục dùng grep để xác định cú POST cuối cùng xảy ra lúc nào: # grep POST /var/log/snort/alert 01/22-04:17:35.30666 [**] [1:0:0] POST Null - Flash attack HVA [**] [Classification: POST-attack] [Priority: 1] {TCP} 210.245.122.43:3228 -> 219.207.204.25:80 4 giờ 17 phút 35 giây sáng ngày 22/1/2005, giờ máy chủ. Có nghĩa là chừng 2 giờ 15 sáng giờ VN hoặc 6 giờ 15 sáng giờ Sydney. Thử xem có bao nhiêu cú GET từ nửa đêm (12 giờ khuya giờ máy chủ): # grep GET /var/log/snort/alert | wc -l 28413 Whoa, POST đi, GET về . Giờ này khoảng 10 giờ 30 sáng trên máy chủ. Vậy sau 10 giờ 30 phút trôi qua có 28413 cú GET: 28413 / 10.5 hours = 2706 cú GET mỗi giờ 2706 / 60 = 45.1 cú GET mỗi phút 45.1 / 60 = 0.752 cú GET mỗi giây Tính ra trung bình 3 giây có 2 cú GET đi vào. Con số này lên tới hai mươi tám ngàn có lẽ đã xảy ra hồi khuya vì ngay lúc này, khi tôi thử "tail" thì nó chỉ "rỉ rả" mà thôi. Tôi đã quá ngấy những con số và dữ liệu này nên mở ra mấy cái signature của snort để điều chỉnh thêm. Tôi dùng Ethereal để "gọi" một đoạn packets lấy được hôm qua và xem xét kỹ các "pattern" đặc biệt của các cú POST và GET kia. Tôi tối ưu hoá chúng bằng cách tính toán kỹ lưỡng "offset" của các pattern này nằm trong khoảng (bytes) nào của gói tin để đưa vào signature của snort. Làm như thế, snort không phải mất thời gian tìm kiếm trong trọn bộ nội dung của gói tin và làm chậm trễ bước xử lý. Cho đến lúc này, máy chủ HVA ở trong tình trạng bình thường (nếu không muốn nói là rảnh rang) mặc dù lúc này trong ngày diễn đàn HVA đã bắt đầu đông đúc lên. Tôi lẩm nhẩm "để xem tình hình sắp tới ra sao". Trưa 23/1/2005: Tôi nhận được một số thông báo (xuyên qua Yahoo messenger) có một số thành viên ở VN, đặc biệt là từ HN không thể vào được diễn đàn HVA (bất kể ngày đêm) trong mấy ngày qua. Tuy nhiên, họ có thể vào diễn đàn HVA nếu đi xuyên qua một proxy server nào đó. Một điều tôi nắm chắc là firewall của HVA không có (và không muốn dùng) quy định cản hẳn một hoặc nhiều IP để khắc chế nạn DoS. Chính tôi là người đầu tiên phản bác giải pháp này và cũng chính tôi là người cố tìm giải pháp khác để thay thế. Dựa trên thông tin của các log files trên server và trên firewall, tôi thấy rõ có rất nhiều request đến từ VN nói chung và HN nói riêng nhưng không hề có bất cứ một gói tin hợp lệ nào bị cản. Tôi gởi thông điệp đến một số cá nhân khác ở HN và hỏi thăm xem họ có gặp sự cố "không vào được HVA" hay không và họ đều cho biết có thể vào được nhưng đôi khi nhanh, đôi khi chậm. Bởi trong tay tôi không có một bằng chứng gì rõ ràng, tôi chỉ có thể tạm đoán rằng một trong những dịch vụ Internet ở HN đã cố tình cản các request đến HVA và nếu các gói tin này bị cản ở khu vực ấy thì không thể có bất cứ thông điệp hay dấu hiệu gì trên HVA server về tình trạng này được vì các gói tin bị cản không thể đi ra ngoài được. Tôi đoán có ít nhất hai trường hợp có thể xảy ra: 1. Hai ngày trước, khi các "quả" x-flash từ những người dùng dịch vụ Internet nào đó (nay đã bị cản) dồn dập đi vào máy chủ HVA khiến cho đường dẫn của dịch vụ này bị ứ nghẽn và người dùng hợp lệ không có cơ hội truy cập HVA. Vấn đề này hoàn toàn có thể nếu như bandwidth của dịch vụ ấy quá hẹp. Nên nhớ, dẫu máy chủ HVA được gắn liền với một đường dây 10Mbit đi chăng nữa mà đầu bên kia bé tẹo và bị ứ nghẽn do hàng triệu gói tin đi ra (để đến HVA) thì chính người dùng ở đầu bên ấy là nạn nhân đầu tiên. 2. Cũng có thể tay admin nào đó của dịch vụ Internet này phát hiện ra "cơn lũ" từ mạng của anh ta đang ùn ùn đi ra và có mục tiêu là IP của máy chủ HVA. "Cơn lũ" này làm ảnh hưởng đến các người dùng khác trong mạng của dịch vụ này. Có hai cách giải quyết: a) truy ngược lại các IP nào trong mạng của anh ta tham gia vào việc tạo "cơn lũ" và xử lý từng IP, cách này chậm và mất thời gian. b) cản ngay tại router / firewall của mạng này mọi request đi đến HVA server, cơn lũ đi ra sẽ hết đường ra và sẽ bị triệt tiêu nhanh chóng, cách này nhanh nhưng vô tình tay admin này tiếp tay cho ý đồ "từ chối dịch vụ" của ai đó. Theo tôi, trường hợp thứ 2 có vẻ gần với thực tế xử lý hơn bởi vì những thành viên từ dịch vụ này không thể vào HVA bằng đường trực tiếp nhưng lại có thể vào HVA nếu dùng một proxy server nào khác. Nếu quả thật trường hợp 1 xảy ra trên thực tế thì ngay cả "đi vòng" qua một proxy khác, người dùng từ dịch vụ này cũng khó lòng đi đến được HVA vì đường dẫn của dịch vụ đang ở trong tình trạng ứ nghẽn. Trường hợp người dùng không thể vào HVA server trong hoàn cảnh "bị cản" hoặc bị "ứ nghẽn" ở đâu đó là một hoàn cảnh không thể giải quyết được (từ phía HVA). Nếu các admin của các dịch vụ là những tay có kinh nghiệm hoặc kiến thức bảo mật, xử lý các vấn nạn này không khó. Nếu họ xử lý được, không những họ cân bằng được chất lượng đường dẫn cho khách hàng của họ mà còn loại bỏ những gói tin phá hoại để tiết kiệm băng thông, giảm thiểu phí tổn. Trưa nay máy chủ HVA vẫn tiếp tục trong tình trạng hoàn toàn bình thường và ổn định mặc dù các cú GET vẫn đều đều "gõ". Tôi "log off" máy chủ HVA và trở lại "đối đầu" với hàng đống công việc ở sở. Trưa 4/2/2005 Đã gần 2 tuần lễ trôi qua, đều đặn mỗi ngày tôi chạy thử một cái script (từ laptop của tôi) để kiểm tra khối lượng các cú GET và POST. Server load của máy chủ vẫn nằm ở mức thấp và từ đó đến nay chưa bao giờ lên quá giới hạn 4.0 load. Sau đây là một số thông tin tôi nghĩ có thể chia xẻ với bạn: alert của snort vào ngày 29/1 Code:

[root@network snort]# zcat alert.1.gz | grep POST | wc -l
     0
[root@network snort]# zcat alert.1.gz | grep GET | wc -l
  9726

Trong đó, zcat là lệnh tương tự như gunzip -c, nó dùng để "cat" một hồ sơ đã được nén (thay vì bạn phải xả nén hồ sơ này trước rồi mới dùng "cat" đối với một hồ sơ không được nén). alert.1.gz là alert log của snort được lưu giữ trên hệ thống ở dạng nén. Cơ chế đổi log hàng ngày tự động tạo một alert log mới cho snort và lưu alert log cũ ở dạng .1.gz, .2.gz.... cho đến con số bao nhiêu đó tuỳ bạn ấn định cho hệ thống của mình. Các lệnh grep và wc không có gì đặc biệt, bạn muốn tìm hiểu thêm về chúng thì đơn giản thử man grep và man wc. Thông tin trên cho thấy có đến 9726 quả x-flash GET nhưng hoàn toàn không có quả x-flash POST nào đi vào. alert của snort vào ngày 30/1 Code:

[root@network snort]# zcat alert.1.gz | grep POST | wc -l
     0
[root@network snort]# zcat alert.1.gz | grep GET | wc -l
  8899

Tại sao vẫn là alert.1.gz? Cái này do ngày 31/1 tôi lấy thông tin cho ngày 30/1 nên alert log của snort đã trở thành alert.1.gz, alert log của snort cho ngày 29/1 trở thành alert.2.gz. Tôi phải đợi sang ngày hôm sau mới lấy thông tin vì tôi muốn có trọn bộ thông tin cho từng ngày. Thông tin trên cho thấy có đến 8899 quả x-flash GET nhưng hoàn toàn không có quả x-flash POST nào đi vào. alert của snort vào ngày 31/1 Code:

[root@network snort]# zcat alert.1.gz | grep POST | wc -l
     0
[root@network snort]# zcat alert.1.gz | grep GET | wc -l
  8317

Thông tin trên cho thấy có đến 8317 quả x-flash GET nhưng hoàn toàn không có quả x-flash POST nào đi vào. Có giảm sút. alert của snort vào ngày 1/2 Code:

[root@network snort]# zcat alert.1.gz | grep POST | wc -l
     0
[root@network snort]# zcat alert.1.gz | grep GET | wc -l
 10816

Thông tin trên cho thấy có đến 10816 quả x-flash GET nhưng hoàn toàn không có quả x-flash POST nào đi vào. Có gia tăng chút đỉnh. alert của snort vào ngày 2/2 Code:

[root@network snort]# zcat alert.1.gz | grep POST | wc -l
     0
[root@network snort]# zcat alert.1.gz | grep GET | wc -l
  8949

Thông tin trên cho thấy có đến 8949 quả x-flash GET nhưng hoàn toàn không có quả x-flash POST nào đi vào. Có giảm sút chút đỉnh. alert của snort vào ngày 3/2 Code:

[root@network snort]# zcat alert.1.gz | grep POST | wc -l
     0
[root@network snort]# zcat alert.1.gz | grep GET | wc -l
  9312

Thông tin trên cho thấy có đến 9312 quả x-flash GET nhưng hoàn toàn không có quả x-flash POST nào đi vào. Lại gia tăng chút đỉnh. alert của snort vào ngày 4/2 Code:

[root@network snort]# zcat alert.1.gz | grep POST | wc -l
     0
[root@network snort]# zcat alert.1.gz | grep GET | wc -l
  8588

Thông tin trên cho thấy có đến 8588 quả x-flash GET nhưng hoàn toàn không có quả x-flash POST nào đi vào. Lại giảm đi phần nào. Thông qua một chuỗi thông tin trên, tôi liên tưởng các con số như những cú "hits" trên một trang web nào đó. Nó ổn định và đều đặn. Mức thay đổi không quá lớn. Lý do tôi liên tưởng đến các cú hits trên một trang web là vì thông tin trên alert log của snort cho thấy các cú GET này rải khá đều trong ngày và chỉ tập trung cao độ ở những giờ cao điểm ở VN. Một cái banner hấp dẫn ở đâu đó để người dùng bấm chăng? hay một đoạn phim... "người nhớn" bằng flash để "dụ" những kẻ tò mò? và bên dưới đoạn flash này có cái gì đó thì.... tôi chỉ đoán vậy thôi :). Thế còn monit đóng vai trò đắc lực hay không? Tôi thử duyệt qua syslog thì thấy: Code:

[root@network snort]#  grep "'apache' started" ../messages*
../messages.1:Jan 24 08:48:27 network monit[27564]: 'apache' started
../messages.1:Jan 24 09:08:08 network monit[30083]: 'apache' started
../messages.2:Jan 22 15:24:37 network monit[19359]: 'apache' started

Hèm, khoảng xế chiều ngày 22/1 monit đã khởi động lại apache. Vì lý do gì đó, monit đã thực hiện chuyện này nhưng tôi không quan tâm lắm đến chi tiết. Ngày 24/1 có một loạt thông báo về monit (khá nhiều) nhưng tôi phát hiện ra cấu hình có điểm không hoàn chỉnh và đã điều chỉnh lại. Hai thông báo cho ngày 24 ở trên quả thật monit đã khởi động lại apache. Có lẽ luật theo dõi tôi ấn định cho monit khắt khe quá chăng? tôi để yên monit và tiếp tục theo dõi, từ đó đến nay không có một thông báo nào khác. Điều đáng ngạc nhiên là từ khi đưa monit vào, database server không còn dở chứng thêm lần nào nữa. Chuyện gì sẽ tiếp tục xảy ra? Tôi không rõ nhưng tôi có hai giả định: 1) anh chàng tấn công HVA đến nay hẳn đã thấy kết quả của những loạt tấn công của mình đến HVA và cảm thấy... nhàm với trò chơi vô bổ này? 2) anh chàng càng cay cú hơn và đang "luyện đan" để tiếp tục oanh tạc HVA? Ai mà biết? Riêng tôi, tôi muốn dành thời gian để làm những chuyện ích lợi hơn là phải "xem" những cái logs vô tri kia. Bạn nghĩ sao? Các bạn có thể theo dõi tiếp phần 15 tại http://hvaonline.net/hvaonline/posts/list/294.html

Latest posts for the topic " Ký sự các vụ DDoS đến HVA - Phần 14"

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