Do Snort chỉ lu các alert vào file /var/log/snort/alert (mặc định) nên sau một thời gian file alert sẽ có kích thớc rất lớn làm cho vừa lãng phí dung lợng ổ cứng vừa gây khó khăn cho ngời quản trị có thể xem xét các cảnh báo của Snort. Để khắc phục nhợc điểm này thì có nhiều cách, em sẽ sử dụng logrotate để khác phục nhợc điểm này vì logrotate là một tiện ích có sẵn của hệ điều hành Centos nói riêng và trên các hệ điều hành Linux nói chung.
a. Tổng quan về logrotate:
Logrotate là một công cụ trên các hệ thống Linux dùng để thiết lập chính sách quay vòng định kỳ cho các log file. Với Logrotate các file log có thể đợc định kỳ sử dụng lại theo ngày tuần tháng hay theo kích thớc file log, nén, xoá bỏ file log...
Hoạt động của logrotate mặc định đợc cấu hình tại file /etc/logrotate.conf thông qua những tham số tuỳ chọn, sau đây là một số tham số thờng dùng.
- compress : nén những file log đã sử dụng.
- nocompress: ngợc lại với tuỳ chọn compress.
- create mode owner group: khi sử dụng một file log mới, file log mới đợc tạo sẽ có các thuộc tính (mode, owner group).
- mail address : khi hết chu kỳ sử dụng file log sẽ đợc gửi tới địa chỉ (address).
- nomail : ngợc lại với tuỳ chọn trên.
- daily : chu kỳ sử dụng file log theo ngày.
- weekly : chu kỳ sử dụng file log theo tuần.
- monthly : chu kỳ sử dụng file log theo tháng.
- rotate count : xác định số lần luân phiên sử dụng file log.
- size size : chu kỳ sử dụng file log đợc xác định theo kích thớc.
- include /etc/logrotate.d : đọc thêm các thông tin cấu hình tại các file trong th mục /etc/logrotate. Các tham số khai báo ở các file này có độ u tiên cao hơn các tham số khai báo trong file /etc/logrotate.conf.
Ví dụ: Weekly rotate 4 errors rootc reate compress include /etc/logrotate.d/ var/log/wtmp { monthly
create 0664 root utmp rotate 1
}/var/log/lastlog { Monthly
rotate 1 }
Phần mặc định xác định mỗi file log đợc ghi trong một tuần, chỉ lu lại file log của bốn tuần, các thông báo lỗi của logrotate đợc gửi tới root, các file log lu trữ đợc nén lại.Cho phép logrotate đọc thêm các thông tin cấu hình nằm tại các file trong th mục /etc/logrotate.d
File log /var/log/wtmp đợc ghi log trong một tháng, khi tạo file log mới file này có thuộc tính là 0664, owner là root, group là utmp, chỉ lu thông tin log trong một tháng.
File log /var/log/lastlog đợc ghi log trong một tháng, chỉ lu thông tin log trong một tháng.
b. Xoay vòng log cho Snort
Tạo file snort tại /etc/logrotate.d/ với nội dung
/var/log/snort/alert { daily rotate 7 missingok notifempty sharedscripts
create 0640 snort snort postrotate
/etc/init.d/snort restart >/dev/null endscript
}
Đặt lịch cho logrotate chạy vào lúc 0h mỗi ngày.
crontab –e
00 00 * * * /usr/sbin/logrotate -f /etc/logrotate.conf >/ dev/null 2>&1
Thử nghiệm, đánh giá
Với mục tiêu đặt ra là tăng thời gian chống chịu DDoS cho máy chủ web để những ngời quản trị có thời gian khắc phục, nên em xây dựng test case theo mục tiêu đã đề ra.
Trớc hết là tiến hành cài đặt một site joomla trên máy chủ web. Sau đây là một số hình ảnh của trang web.
Hình 5-: Hình trang chủ DemoDDoS
Trang chủ gồm trang lý thuyết và trang phòng chống.
Hình 5-: Hình trang phòng chống DDoS
Công cụ để đo thời gian đáp ứng đợc sử dụng là jmeter, một project của apache. Hình ảnh về jmeter:
Hình 5-: Giao diện chính của Jmeter
Các bớc để chuẩn bị test thời gian đáp ứng:
Tạo một Thread Group : right-click vào Test plan chọn add -> Thread Group nh hình :
Hình 5-: Tạo Thread Group
Trong đó, Number of Threads là số user (concurrent connections) đến máy chủ web. Ramp-Up Period là thời gian để chạy hết số Threads đã khai báo ở trên.Ví dụ: Có 10 thread và Ramp-Up period là 100 giây thì jmeter sẽ chạy tất cả 10 thread trong 10 giây. Mỗi thread sẽ khởi động sau 10 giây sau khi thread trớc nó khởi động. Loop Count là số lần lặp lại.
Tạo HTTP Request Default nh sau: right-click vào Thread Group chọn Add- > Config Element chọn HTTP Request Default. Nhập IP của máy chủ web nh trong hình (IP của máy chủ web là 192.168.1.130)
Hình 5-: Tạo HTTP Default Request
Để xác định thời gian đáp ứng cho trang chủ ta làm nh sau:
Right-click vào Thread Group chọn Add->Sampler chọn HTTP Request.
Trong mục HTTP Request sửa tên thành home và gõ index.php tại Patch nh trong hình
Tơng tự tạo một HTTP Request đến trang phòng chống
Hình 5-: Tạo HTTP Request
Cuối cùng thêm vào các thông báo , right-click vào Thread Group chọn Add -> Listener chọn Graph Results, Summary Report và Aggregate.
Để bắt đầu kiểm tra ta chọn Run -> Start.
Công cụ để DDoS đợc sử dụng là DOSHTTP 2.0, sau đây là các bớc sẽ triển khai để thực hiện kiểm tra, đánh giá.
- Bớc 1: Kiểm tra server khi chạy bình thờng cha có hệ thống phòng thủ và cha bị DDoS
+ Đo thời gian đáp ứng của server sử dụng công cụ jmeter + Kiểm tra tài nguyên của server đang dùng
- Bớc 2: Kiểm tra server khi cài đặt hệ thống phòng chống và cha bị DDoS
+ Đo thời gian đáp ứng của server sử dụng công cụ jmeter + Kiểm tra tài nguyên của server đang dung
- Bớc 3: Kiểm tra server khi cha cài hệ thống phòng chống và đang bị DDoS
+ Đo thời gian đáp ứng của server sử dụng công cụ jmeter + Kiểm tra tài nguyên của server đang dùng.
- Bớc 4: Kiểm tra server khi đã cài hệ thống phòng chống và đang bị DDoS
+ Đo thời gian đáp ứng của server sử dụng công cụ jmeter + Kiểm tra tài nguyên của server đang dùng.
Thực hiện :
Bớc 1:
-Sử dụng công cụ jmeter với ta đợc đồ thị thời gian đáp ứng trung bình:
Hình 5-: Đồ thị thời gian đáp ứng trung bình và thông lợng (bớc 1)
-Thông qua đồ thị ta thấy : ở điều kiện bình thờng, thời gian đáp ứng trung bình là 165 ms, thông lợng là 359,865 request/phút.
-Tài nguyên của hệ thống :
Hình : Tài nguyên của hệ thống ( bớc 1)
-Tải trung bình là giá trị CPU load trong 1, 5 và 15 phút. Nh trên hình thì giá trị CPU load trong 1 phút trớc là 0.59, trong 5 phút trớc là 0.53 và trong 15
phút trớc là 1,26. Có nghĩa là trong một phút hay năm phút trớc không có tiến trình nào phải chờ để đợc CPU xử lý, còn trong 15 phút trớc thì có 1 tiến trình đang đợc xử lý và 0.26 tiến trình phải chờ.
Bớc 2:
-Sử dụng công cụ jmeter với ta đợc đồ thị thời gian đáp ứng trung bình:
Hình 5-: Đồ thị thời gian đáp ứng trung bình và thông lợng ( bớc 2)
Tài nguyên của hệ thống :
Hình 5-: Tài nguyên của hệ thống ( bớc 2)
So sánh kết quả giữa bớc 1 và bớc 2 ta thấy không có sự chênh lệch nhiều giữa thời gian đáp ứng trung bình (164 ms và 167 ms ), CPU load (0,59 và 0,64), RAM sử dụng (~ 250 Mb), SWAP (55Mb và 63 MB).Nh vậy có thể kết luận sau
khi cài đặt hệ thống phòng chống DDoS thì web server bị ảnh hởng không đáng kể.
Bớc 3:
-Tài nguyên của hệ thống lúc sắp bị DDoS
Hình 5-: Tài nguyên của hệ thống khi sắp bị DDoS (bớc 3)
-Bắt đầu bị DDoS, các packet đến card mạng tăng vọt
Hình 5-: ồ thị traffic của mạng khi bị DDoS (bớc 3)
Hình 5-: Tài nguyên của hệ thống sau hai phút bị DDoS (bớc 3)
Tài nguyên của hệ thống sau năm phút
Hình 5-: Tài nguyên của hệ thống sau năm phút bị DDoS (bớc 3)
Hình 5-: Hình ảnh Web site Demo DDoS
Sử dụng công cụ jmeter với ta đợc đồ thị thời gian đáp ứng trung bình:
Hình 5-: Đồ thị thời gian đáp ứng trung bình và thông lợng ( bớc 3)
Nhận xét :
Ngay khi bắt đầu bị DDoS, số lợng packet đến card mạng của web server tăng vọt (khoảng 1300 packet/giây so với trớc khi bị DDoS chỉ có khoảng 50 packet/ giây).
Sau 2 phút, có thể thấy apache đã phải tạo ra rất nhiều child process để xử lý các request đến. Khiến cho server load trung bình trong 1 phút vừa qua lên đến 25.46 , RAM còn d 11Mb.
Sau 5 phút, server load đã lên đến 44.18, lợng RAM còn d là khoảng 13Mb. Nh vậy là apache đã đạt đến giới hạn phục vụ (RAM còn rất ít và không đổi tức là apache không thể tạo thêm child process để phục vụ request nữa) nh vậy những ngời dùng hợp pháp gần nh không thể truy cập vào web site Demo DDoS.
Trên đồ thị thời gian đáp ứng, ta nhận thấy thời gian đáp ứng trung bình tăng lên tới 32640 ms tức là 32 giây gấp gần 200 lần thời gian đáp ứng khi server hoạt động bình thờng (bớc 1)
Bớc 4:
Thêm rule cho iptable:
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP iptables -A INPUT -p tcp -m tcp --dport 80 -m connlimit --\ connlimit-above 20 -j DROP
Thêm rule chặn DOSHTTP 2.0 cho snort
drop tcp any any -> any 80 (classtype:attempted-
user;sid:5;msg:"Detect\ DoSHTTP";content:"|2e 4e 45 54 20 43 4c\ 52|";offset:54;resp:rst_rcv;)
Tài nguyên hệ thống ngay trớc khi bị DDoS
Hình 5-: Tài nguyên của hệ thống trớc khi bị DDoS (bớc 4)
Hình 5-: Đồ thị traffic của mạng khi bị DDoS (bớc 4)
Sau 2 phút bị DDoS ta nhận đợc:
Hình 5-: Tài nguyên của hệ thống sau hai phút bị DDoS (bớc 4)
Hình 5-: Tài nguyên của hệ thống sau năm phút bị DDoS (bớc 4)
Sử dụng công cụ jmeter với ta đợc đồ thị thời gian đáp ứng trung bình:
Hình 5-: Đồ thị thời gian đáp ứng trung bình và thông lợng ( bớc 4)
Nhận xét:
Sau 2 phút và 5 phút bị DDoS, giá trị server load (0,24)và đáp ứng time trung bình (182) có chênh lệch không đáng kể so với giá trị server load và đáp ứng time ở bớc 1 và bớc 2. RAM sử dụng tăng lên 380 MB so với ở bớc 1 và bớc 2 là 250 MB. RAM tăng lên do server phải kiểm tra số lợng connection từ một IP và kiểm tra các packet đến apache (Snort inline). Để server vẫn phục vụ đợc cho những ngời dùng hợp pháp trong khi bị DDoS thì theo em mức độ sử dụng tài nguyên nh vậy là chấp nhận đợc.
Rule của iptables sử dụng connlimit thì chỉ cho phép 20 connection từ một địa chỉ IP đến port 80 (http), nếu nhiều hơn thì sẽ DROP. Còn Snort inline thì sẽ kiểm tra trong các connection đi qua đợc firewall cái nào có chuỗi mà match với
chuỗi trong rule thì cũng sẽ cũng sẽ bị DROP. Chính vì thế mà số packet đến đợc và đợc apache xử lý khá ít và toàn là packet hợp lệ nên server load khá nhỏ.
Một vài nhận xét sau khi thực hiện kiểm tra đánh giá:
Hệ thống đã đáp ứng đợc mục tiêu đa ra-kéo dài thời gian “phục vụ ” của server khi bị DDoS.
Việc lựa chọn giá trị để giới hạn số connection từ một IP cần phải đợc xem xét cẩn thận để không làm ảnh hởng đến những ngời dùng hợp pháp.
Do việc triển khai test trong mạng LAN và có số lợng ít máy tham gia nên cha đợc sát với thực tế.
Chơng 6 TổN G KếT
Sau khoảng 5 tháng làm đồ án, ít nhiều em cũng đã tìm hiểu tơng đối thành công về DDoS và xây dựng đợc thành công phơng pháp phòng chống DDoS theo cách hiểu của mình. Qua những gì tìm hiểu đợc, em vẫn cảm thấy vẫn còn nhiều điều phải làm để có thể hoàn thiện hơn đồ án cũng nh cần có sự h- ớng dẫn nhiều hơn nữa của các thầy cô và bạn bè.