3.2.1. Chuẩn bị
Máy ảo cài kali
o Ip: 192.168.0.109
o Cài đặt Snort
o Cài đặt và sử dụng công cụ slowhttptest dùng để tấn công DOS SYN flood
o Sử dụng Hping3 tấn công DOS ICMP flood
Hình 23: Config Snort
Máy nạn nhân
o Ip: 192.168.0.104
o Cài đặt xampp, bật máy chủ server Apache
Hình 24: Máy chủ Apache nạn nhân
3.2.2. Tấn công ICMP FLOOD
Tại thời điểm Snort đã sẵn sàng để chạy. ngoại trừ, nó không có bất kỳ quy tắc nào được tải. Bây giờ chúng tôi viết các quy tắc sẽ cho phép snort phát hiện một cuộc tấn công DoS. Mở tệp local.rules trong trình soạn thảo văn bản dưới dạng root bằng lệnh sau:
sudo gedit /etc/snort/rules/local.rules
Sau đó, chúng tôi nhập như sau:
alert icmp any any -> $HOME_NET any (msg:"ICMP flood"; sid:1000001; rev:1; classtype: icmp-event; detection_filter:track by_dst, count 500, seconds 3;)
Hình 25: Cài rule cho IDS IMCP Flood
Đây là quy tắc của câu lệnh này
Rule Header
alert: Hành động quy tắc. Snort sẽ tạo cảnh báo khi điều kiện đã đặt được đáp ứng
any: Cổng nguồn. Snort sẽ xem xét tất cả các cổng - >: Phương hướng. Từ nguồn đến đích
$HOME_NET: IP đích. Chúng tôi đang sử dụng giá trị HOME_NET từ tệp snort. conf
any: Cảng đích. Snort sẽ xem xét tất cả các cổng trên mạng được bảo vệ
Rule Options
msg:” ICMP flood”: Snort sẽ bao gồm thông báo này cùng với cảnh báo sid:1000001: ID quy tắc ngắn. Hãy nhớ rằng tất cả các số <1.000.000
đều được đặt trước, đây là lý do tại sao chúng tôi bắt đầu với 1000001 (bạn có thể sử dụng bất kỳ số nào, miễn là nó lớn hơn 1.000.000). rev:1: Số sửa đổi. Tùy chọn này cho phép duy trì quy tắc dễ dàng hơn classtype: icmp-event: Phân loại quy tắc dưới dạng “icmp-event”, một
trong các danh mục Snort được xác định trước. Tùy chọn này giúp tổ chức quy tắc
detection_filter: track by_dst: Snort theo dõi địa chỉ IP đích để phát hiện.
count 500: Nếu trong khoảng thời gian lấy mẫu, Snort phát hiện hơn 500 yêu cầu thì chúng tôi sẽ nhận được cảnh báo
seconds 3: thời gian lấy mẫu được đặt thành 3 giây
Bây giờ, hãy bắt đầu Snort ở chế độ IDS và yêu cầu nó hiển thị cảnh báo cho bảng điều khiển:
Hình 26: Chạy snort với rule cho ICMP
Ở đây chúng ta đang trỏ Snort đến tệp cấu hình mà nó sẽ sử dụng (-c) và chỉ định giao diện (-i eth0). Tùy chọn bảng điều khiển -A in cảnh báo ra đầu ra tiêu chuẩn. Chúng ta không thấy bất kỳ đầu ra nào khi chúng ta nhập lệnh vì Snort không phát hiện thấy bất kỳ hoạt động nào được chỉ định trong quy tắc chúng tôi đã viết. Chúng ta tạo ra một số hoạt động và xem liệu quy tắc của chúng tôi có hoạt động hay không. Chúng ta khởi chạy máy ảo của chúng ta
Sau đó ta sử dụng công cụ Hping3 để tiến hành tấn công IMCP flood trên máy nạn nhân bằng lệnh:
hping3 -1 --flood -a 192.168.0.109 192.168.0.104
Thấy các cảnh báo được tạo cho mọi yêu cầu phản hồi ICMP vượt quá giá trị đếm được chỉ định trong khoảng thời gian lấy mẫu với văn bản thông báo mà
chúng ta đã chỉ định trong tùy chọn tin nhắn.
Hình 28: Snort xuất cảnh báo ICMP Flood
Chúng tôi cũng có thể thấy địa chỉ IP nguồn của máy chủ chịu trách nhiệm về hoạt động tạo cảnh báo.
Hình 29: Thông số Snort
3.2.3. Tấn công SYN FLOOD
Ta sửa rule trong file local.rules với luật mới:
alert tcp any any -> $HOME_NET 80 (flags: S; msg:"Possible DoS Attack Type : SYN flood"; flow:stateless; sid:3; detection_filter:track by_dst, count 20, seconds 10;)
Hình 30: Rule cho cảnh báo SYN Flood
Trong quy tắc này, chúng tôi đã thay đổi giao thức thành TCP và đặt số cổng đích là 80. Cờ từ khóa kiểm tra xem có các bit cờ TCP cụ thể (trong trường hợp này là cờ SYN) hay không. Khoảng thời gian lấy mẫu được đặt thành 10 giây. Nếu trong khoảng thời gian này có hơn 20 yêu cầu được phát hiện thì chúng tôi sẽ nhận được cảnh báo.
Chạy snort như bước ở trên. Ở đây ta sẽ sử dụng công cụ slowhttptest thực hiện tấn công bằng lệnh:
- c là số lượng kết nối
- i là khoảng thời gian truyền giữa các dữ liệu
- r là kết nối mỗi giây
- x độ dài ngân nhiên gửi đi trên header hoặc body của request
- p thời gian chờ phản hồi HTTP trên kết nối thăm dò, sau đó máy chủ được coi là không thể truy cập được
sudo slowhttptest -c 140 -H -g -o ./output_file -i 10 -r 200 -t GET -u http://192.168.0.104/ -x 24 -p 2
Hình 31: Tấn công ở mức service nạn nhân vẫn hoạt động
Ở kết qua trên slowhttptest cho thấy serivce của server nạn nhận vẫn còn hoạt động và vẫn truy cập được vào trang server nhưng nếu ta tăng số lượng kết nối c lên 500 thì người dùng không thể truy cập bằng lệnh:
sudo slowhttptest -c 500 -H -g -o ./output_file -i 10 -r 200 -t GET -u http://192.168.0.104/ -x 24 -p 2
Hình 32: Tấn công làm ngừng service của nạn nhân
Ta thu được kết quả tại bên màn console của snort thông báo tấn công SYN Flood
Kết quả thu được của snort phát hiện SYN Flood.
3.2.4. Tấn công XSS
Ta sẽ thêm một file rules mới có tên là XSS-injection.rules trong folder fules với các luật như sau:
Hình 34. Luật trong rules XSS-injection
Chạy lệnh snort để bắt đầu ở chế độ IDS:
“snort -c C:\Snort\etc\snort.conf -A console -i 6”
Ở đây chúng ta sẽ trỏ Snort đến tệp cấu hình mà nó sẽ sử dụng (-c) và chỉ định giao diện (-i eth0). Tùy chọn bảng điều khiển -A in cảnh báo ra đầu ra tiêu chuẩn. Chúng ta không thấy bất kỳ đầu ra nào khi chúng ta nhập lệnh vì Snort không phát hiện thấy bất kỳ hoạt động nào được chỉ định trong quy tắc đã viết. Thực hiện tấn công XSS vào trên webserver và quan sát màn hình cảnh báo để xem luật có được thực hiện hay không.
Ở đây chúng ta sẽ thực hiện demo trên web DVWA được cài đặt trên máy snort để giám sát. Vào xampp bật Appache và Mysql. Mở cmd gõ ipconfig để xem ip máy snort
Hình 36. IP của máy cài snort
Ở máy ảo Ubuntu thực hiện vào trang DVWA trên máy snort và chọn XSS( Reflected)
Hình 37. Khởi chạy DVWA trên máy ubuntu
Thực hiện nhập “?name=<script>alert("XSS");</script>” trên máy Ubuntu ta sẽ có kết quả như sau:
Hình 38. Kết quả sau khi tấn công XSS trên máy Ubuntu