5. Phương pháp nghiên cứu
2.6. Chế độ phòng chống của Snort
2.6.1.Snort Inline
Snort-inline là một nhánh phát triển riêng của Snort do William Metcalf lãnh đạo. Từ bản 2.3.0 RC1 của Snort, inline-mode đã được tích hợp vào bản chính thức do snort.org phát hành. Việc tích hợp này đã biến Snort từ một IDS thuần túy trở thành một hệ thống có các khả năng của một IPS, mặc dù chế độ này vẫn chỉ là tùy chọn chứ không phải mặc định.
Các phiên bản Snort từ 2.9.x đi kèm với DAQ 2.0x – đây là bộ module và thư viện tiếp nhận và xử lý các gói tin I/O. DAQ thay thế phương thức gọi trực tiếp đến thư viện libpcap và có thể chạy trên một loạt các phần cứng và phần mềm. Snort inline-mode là kết hợp khả năng ngăn chặn của iptables vào bên trong snort. Điều này được thực hiện bằng cách thay đổi module phát hiện và module xử lý cho phép snort tương tác với iptables. Cụ thể, việc chặn bắt các gói tin trong Snort được thực hiện thông qua Netfilter và thư viện libpcap sẽ được thay thế bằng việc sử dụng ipqueue và thư viện libipq. Hành động ngăn chặn của snort-inline sẽ được thực hiện bằng một module trong trong kernel của iptables.
Hệ thống DAQ cho snort ba chế độ read-file | passive | inline và kèm theo ba loại daq chính là: pcap | afpacket | nfq.
• Pcap: mặc định chạy trong DAQ và làm việc ở chế độ passive, bao gồm
các thư viện chụp bắt lại cái gói tin trong mạng. Cách khởi chạy: # snort --daq pcap --daq-mode passive
• Afpacket: có nhiệm vụ chặn và lọc các gói tin trong DAQ làm việc ở chế
độ inline, sử dụng bộ đệm (buffer_size_mb) để tiếp nhận xử lý các gói tin. Khi snort hoạt động ở chế độ inline mode sử dụng afpacket, một thư viện có tên af_packet.c (được build sẵn từ source khi cài DAQ) được load vào trong kernel để bật module apf (Advanced Policy Firewall) cho phép nó làm việc thông qua iptables để chặn lọc các gói tin. Afpacket có ưu điểm là hiệu suất xử lý chặn lọc gói tin nhanh vì sử dụng bộ đệm buffer, có nhược điểm là yêu cầu phần cứng cao, bộ đệm lớn, tối thiểu từ 2 card mạng trở lên để có thể hoạt động được trong chế độ inline mode. Cách khởi chạy:
# snort --daq afpacket -i eth0:eth1 (có thể đổi tên card mạng cho phù hợp) • Nfq (NetFilter Queue): ra đời lâu hơn afpacket cũng có tác dụng chặn
lọc gói tin trong DAQ ở chế độ inline, sử dụng module ipqueue và thư viện libipq để load các queue traffic từ iptables về để quyết định chặn lọc gói tin. Ưu điểm là không yêu cầu phần cứng cao và có nhược điểm là hiệu suất xử lý chặn lọc gói tin không cao. Cách khởi chạy:
# iptables -A INPUT -p tcp --dport 80 -j NFQUEUE --queue-num 2
# snort --daq nfq --daq-var queue=2 -Q -l /var/log/snort -c /usr/local/snort/etc/snort.conf
2.6.2.Bổ sung cho cấu trúc Rules trong Snort chạy Inline mode
Để hỗ trợ tính năng ngăn chặn và phòng chống của Snort-inline, các thay đổi và bổ sung đã được đưa vào bộ luật Snort. Đó là đưa thêm 3 hành động DROP, SDROP, INJECT và thay đổi trình tự ưu tiên của các Rules trong Snort.
• DROP
DROP yêu cầu iptables loại bỏ gói tin và ghi lại thông tin như hành động LOG.
• SDROP
SDROP tương tự như DROP, điều khác biệt là ở chỗ Snort sẽ không ghi lại thông tin như hành động LOG.
• REJECT
REJECT yêu cầu iptables sẽ loại bỏ gói tin và gửi lại một thông báo cho nguồn gửi gói tin đó. Hành động REJECT không ghi lại bất cử thông tin gì.
2.7.Tiểu kết
Qua chương này chúng ta đã biết được các tổng quan về lý thuyết, định nghĩa của hệ thống.Ở chương sau chúng ta sẽ biết được cách xây dựng mô hình cũng như triển khai hệ thống.
Chương 3 : TRIỂN KHAI HỆ THỐNG PHÁT HIỆN XÂM NHẬP
Để triển khai hệ thống phát hiện thử nghiệm trên Snort chúng ta trải qua các bước sau:
Nắm rõ các địa chỉ IP trong mạng Lan Lựa chọn thiết bị phù hợp
Cài đặt và cấu hình Chạy thử hệ thống.
3.1.Sơ đồ triển khai 3.1.1.Mô hình 3.1.1.Mô hình
Mô hình áp dụng:
Vị trí của Snort:
Snort nên đặt ở trước server điều khiển vì mọi gói tin phải đi qua snort trước khi đến server, đồng thời giúp bảo vệ được server trước các cuộc tấn công
Đánh giá mô hình khi có Snort và không áp dụng snort:
Khi không có snort:
Trong mô hình IoT trên tác giả sử dụng giao thức MQTT trong đó quá trình trao đổi giữa các thiết bị và Server sử dụng tài khoản và mật khẩu để kết nối vào các topic. Ở các gói tin điều khiển giữa các thiết bị và Server có TLS/SSL là các giao thức mã hóa sử dụng cơ chế handshake (bắt tay) để tạo kết nối an toàn giữa máy khách và máy chủ. Sau khi hoàn thành các bước “handshake”, một kênh giao tiếp mã hóa giữa client và server được thiết lập và đảm bảo không kẻ tấn công nào có khả năng nghe trộm thông tin trong suốt quá trình giao tiếp. Dù có bắt được gói tin thì cũng sẽ không thể giả mạo
nó. Nhưng khi không có Snort thì các hoạt động bất thường sẽ không được alert nên các nguy cơ tấn công khác như Ddos hoặc Syn attack có thể xảy ra.
Khi có snort:
Khi có Snort các alert về các hoạt động diễn ra liên tục trong mô hình đồng thời nhờ các dấu hiệu biết trước nên snort sẽ phần nào giảm thiểu được các nguy cơ tấn công.
3.1.2.Thiết bị
Để thực hiện chúng ta cần các thiết bị như:
- Raspberry Pi (hoặc 1 Laptop hoặc pc cài ubutu16.04)
- Các thiết bị Iot (tùy theo môi trường) - Màn hình Monitor để hiển thị
- Laptop hoặc Computer (tối thiểu 1)
3.1.3.Các công cụ cần thiết.
Để thực hiện chúng ta cần cài đặt các công cụ sau. Snort Mysql Ntop-ng Mqtt Base Hình 3-2 Thiết bị Ras3
3.1.3.1. Snort
Đây là công cụ rất quan trọng trong mô hình phát hiện và phòng chống xâm nhập dưới đây là hình ảnh sau khi cài đặt Snort thì chúng ta chạy thử nghiệm trên màn hình Console và test thử 1 gói tin ping để thử hệ thống phát hiện.
Với rất nhiều các Rules thì ở báo cáo này chỉ tập trung các rules cần thiết trong mô hình IoT dưới đây là hình ảnh Snort phát hiện có gói tin Syn vào MQTT và điều khiển thiết bị IoT.
Hình 3-3 Chạy Snort
3.1.3.2. BASE
Giao diện BASE để hỗ trợ hiển thị tối ưu cho Snort, Base sẽ tổng hợp các con số của từng loại gói tin cũng như sẽ cập nhật các alert theo thời gian thực như màn hình console, tuy nhiên khi chạy trên ras sẽ rất hay bị đơ do Base cần rất nhiều dịch vụ đi kèm vì thế nên khi chạy trên Ras ko nên thêm Base.
Base cung cấp một giao diện quản lý các alert một cách trực quan hơn. Hình 3-5 Giao diện Base
3.1.3.1. MQTT
MQTT được cài đặt ngay trên Ras để có thể điều khiển. Chúng ta có thể cài song song MQTT server và client trên 1 thiết bị để test. Nếu có nhiều thiết bị thì nên phân ra riêng biệt server và client
3.1.3.2. Ntop-NG
Ntop-NG là công cụ hỗ trợ người quản trị có thể xem được traffic mạng đồng thời biết được các thông tin của các client trong mạng Lan.
Hình 3-8 Giao diện làm việc Ntop-Ng Hình 3-7 Khởi chạy MQTT
3.1.3.3. Mysql
Mysql được cài đặt chung với công cụ barnyard2 để lưu các alert sau khi đã được thông báo, đồng thời còn kết hợp với các công cụ hiển thị cảnh báo như Base để hiển thị được một cách tường minh hơn.
3.2.Đánh giá và nhận xét
Đã cài đặt thành công hệ thống phát hiện và chống xâm nhập Snort chạy trên hệ điều hành Ubuntu.
Hệ thống Snort đã cài thành công có các chức năng:
Phát hiện được các hành vi bất thường diễn ra trong môi trường. Thể hiện được các alert qua giao diện Base.
Lưu trữ thời gian , địa chỉ ip .... của đối tượng xâm nhập qua các sở sở dữ liệu được lưu ở mysql.
Tuy nhiên, vẫn còn nhiều chức năng chưa khai thác hết. Hình 3-9 Các dữ liệu của alert được lưu lại
Chương 4 : THỬ NGHIỆM PHÒNG CHỐNG TẤN CÔNG BẰNG SNORT
Ở chương này tác giả sẽ nói về các cách tấn công phổ biến và cách phòng chống.
4.1.Mô Hình
4.2.Các phương thức tấn công
4.2.1.Attack ping of death (DOS).
Với dạng tấn công này thì ở máy tấn công sẽ liên tục gửi gói tin icmp có kích thước lớn hơn gói tin ping thông thường cụ thể là lớn hơn 65.536 bytes, gói tin sẽ bị chia thành các segment nhỏ, nhưng khi máy ở đích ráp gói tin lại, địa chỉ đích nhận thấy rằng là gói tin quá lớn đối với buffer bên nhận. Kết quả sẽ khiến hệ thống không thể quản lý nổi tình trạng bất thường này và sẽ reboot hoặc bị treo bằng lệnh:
VD :Ping 192.168.1.252 –s 66000
4.2.2.Attack Syn Flood
Đây là kiểu tấn công từ chối dịch vụ, người tấn công gửi liên tục các gói tin kết nối Syn đến hệ thống. Loại tấn công này khá phổ biến và rất nguy hiểm, nếu hệ thống chia sẻ tài nguyên ngay sau khi nhận gói tin Syn từ máy tấn công và trước khi nhận gói tin Ack.
4.2.3.Attack Zero Day
Zero-day là một thuật ngữ của sự tấn công hay các mối đe dọa khai thác lỗ hổng của ứng dụng trong máy tính cái mà chưa được công bố và chưa được sửa chữa trong các bản update windows cũ.
"Windows Vista/7:SMB2.0 NEGOTIATE PROTOCOL REQUEST Remote B.S.O.D." là nguyên văn tiêu đề mô tả mã tấn công viết bằng Python mà Gaffie đưa lên blog bảo mật Seclists.org. Cuộc tấn công nhằm vào lỗi xuất phát từ System Message Block phiên bản 2.0 (SMB2) vốn có trong Windows Vista, Windows 7 và Windows Server 2008. Đi sâu vào lỗi do Gaffie công bố, nguyên nhân chính xuất phát từ cách thức driver srv2.sys xử lý các yêu cầu từ máy khách trong khi
phần header của ô "Process Id High" chứa đựng một ký tự "&"(mã hexa là 00 26). Cuộc tấn công không cần đến chứng thực nhận dạng, chỉ cần cổng 445 có thể truy xuất. Mối lo ngại ở đây là cổng 445 thường được mở mặc định trong phần cấu hình mạng nội bộ (LAN) của Windows.
Cách phòng chống:
+ Cập nhật bản vá lỗi cho windows mới nhất. + Lọc dữ liệu từ port TCP 445 bằng tường lửa/ + Lock port SMB trong registry.
4.2.4.Attack ARP Spoofing
Attack ARP Spoofing hình thức tấn công Man in the middle hiện đại có xuất sứ lâu đời kiểu tấn công này cho phép kẻ tấn công nằm trên cùng một subnet với các nạn nhân của nó có thể nghe trộm tất cả các lưu lượng mạng giữa các máy tính nạn nhân. Đây là loại tấn công đơn giản nhất nhưng lại là một hình thức hiệu quả nhất khi được thực hiện bởi kẻ tấn công.
Cách phòng chống:
Cấu hình Snort để phát hiện ARP Spoofing
Bật tính năng nhận dạng arp spoofing trong file snort.conf: preprocessor arpspoof
preprocessor arpspoof_detect_host: 192.168.1.1 00:0d:70:b3:3a:90
Nguyên tắc cơ bản để phát hiện ARP Spoofing chính là so sánh với bảng liên hệ giữa IP và MAC do người quản trị đặt ra, nếu có gói tin gửi thông tin sai về MAC của một địa chỉ IP thì sẽ kích hoạt báo động.
Snort dùng preprocessor để phát hiện arp spoofing nên sẽ không có thông tin về source và destination. arpspoof preprocessor chỉ alert không MAC address không đúng với IP address được ánh xạ trong file cấu hình
Hình 4-2 ARP Cache
arp –s <IP ADDRESS> <MAC ADDRESS>.
Có nhiều trường hợp cấu hình mạng của bạn ít khi thay đổi, bạn hoàn toàn có thể tạo một danh sách các entry ARP static và sử dụng chúng cho các client thông qua một kịch bản tự động. Điều này sẽ bảo đảm được các thiết bị sẽ luôn dựa vào ARP cache nội bộ của chúng thay vì các ARP request và ARP reply.
4.3.Thử nghiệm phòng chống tấn công của snort 4.3.1.Attack ping of death (DOS). 4.3.1.Attack ping of death (DOS).
Đầu tiên thêm một rule có nội dụng như phía dưới vào file local.rules để phát hiện tấn công.
Snort sẽ hiển thị các Alert liên tục .
Hình 4-4 Kết quả thử nghiệm phát hiện
Sau đó thêm rule sau vào để ngăn chặn Attack.
Sau khi thêm rule xong , chạy snort ở chế độ inline và kết quả : Hình 4-3 Rule phát hiện tấn công
Hình 4-6 Kết quả chặn Dos Còn giao diện Dos bên phía máy tấn công
Hình 4-7 Kết quả sau khi bị chặn của máy tấn công
4.3.2.Attack Syn Flood
Cách phòng chống:
Thêm rules sau vào Snort.
Hình 4-8 Rule chặn Syn Attack Sau khi thêm Snort
4.4.Tiểu kết
Đánh giá hệ thống phòng chống xâm nhập của Snort:
Phát hiện được các hành vi bất thường diễn ra trong môi trường. Phòng chống được các kiểu tấn công như Ping of Death và Syn Flood.
Hệ thống phòng chống của snort phụ thuộc vào các dấu hiệu cho nên kẻ tấn công chỉ cần thay đổi cấu trúc và nếu như snort chưa biết dấu hiệu đó thì có thể bị bỏ qua.
Chương 5 : TỔNG KẾT
Những kết quả đạt được:
Về mặt lý thuyết:
Sau thời gian nghiên cứu đề tài “ Xây dựng hệ thống phát hiện và giám sát trong mọi trường IoT, tác giả đã nghiên cứu và tìm hiểu được nguyên lý hoạt động các thành phần trong môi trường IoT, cũng như hệ thống Snort, cách thức vận hành và cách thức đưa ra các alert thông báo khi có hành vi xâm nhập diễn ra trong môi trường này. Đồng thời hiểu rõ được cách xuất output và các alert cũng như cách cấu hình snort trên hệ điều hành ubuntu 16.04. Bên cạnh việc sử dụng các rule của nhà phát triển tác giả còn phải tìm hiểu cách viết và xây dựng rules cho môi trường nghiên cứu sao cho phù hợp.
Về mặt thực nghiệm:
• Phát hiện được các hành vi bất thường diễn ra trong môi trường IoT. • Thể hiện được các alert qua giao diện Base.
• Lưu trữ thời gian , địa chỉ ip .... của đối tượng xâm nhập qua các sở sở dữ liệu được lưu ở mysql.
• Phòng chống được các kiểu tấn công như Ping of Death và Syn Flood. Cuối cùng, tổng hợp lại những gì đã làm được ra một sản phẩm hiển thị trên màn hình monitor hiển thị phát hiện và giúp phòng chống xâm nhập cho hệ thống.
Những vấn đề còn tồn tại:
Tuy nhiên trong quá trình nghiên cứu đề tài tác giả gặp một số khó khăn trong việc triển khai hệ thống vào server điều khiển nên tác giả phải giả lập chung một ras vừa là server điều khiển vừa là hệ thống cảnh báo. Ngoài ra thiếu kiến thức về việc lập trình và linux nên mất khá nhiều thời gian cho việc tìm hiểu, cài đặt và giải quyết vấn đề.
Hệ thống chỉ có thể phòng chống hoặc phát hiện các cuộc tấn công một cách hiệu quả nếu như biết trước được các dấu hiệu của cuộc tấn công. Điều này khiến kẻ tấn công dễ thay đổi các dấu hiệu và có thể vượt qua hệ thống.
Vấn đề tấn công hiện tại rất lớn, các cách thức tấn công ngày càng đổi mới và khó có thể đoán trước được.
Định hướng phát triển trong tương lai:
Nâng cấp hệ thống phát hiện và phòng chống, ngăn chặn được nhiều hơn các dạng xâm nhập vào tài nguyên của Server. Đồng thời phát triển thêm các rules mới phù hợp với môi trường IoT.
TÀI LIỆU THAM KHẢO
[1] Sforzin† Alessandro, A Fruitful Intrusion Detection System for IoT, 2016.
[2] Michael Andersson, Andreas Mickols, A study of Centralized Network Intrusion Detection, 2017.
[3] Trần Văn Cường, "Tìm hiểu cơ chế, cách hoạt động của IDS,"