Wazuh

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

Khoa Mạng máy tính & Truyền thông
BÁO CÁO ĐỒ ÁN CHUYÊN NGÀNH
Đề Tài: Nghiên cứu thực nghiệm về triển khai, đánh giá HIDS
Wazuh cho hệ thống sử dụng Docker Container
GVHD: Th.s Nguyễn Thanh Hòa

NHÓM THỰC HIỆN:
1. Phạm Quang Tuấn - 17521220
2. Đào Anh Quý - 17520961
3. Lê Lý Thúy Vi - 17521254
Cập nhật lần cuối: Ngày 15 tháng 3 năm 2021

LỜI MỞ ĐẦU
Cùng với tiến trình phát triển chung của nền kinh tế toàn cầu, Internet ra đời được ví như một
cuộc cách mạng trong thế giới kinh doanh và truyền thông. Internet đã và đang thay đổi mọi quan
điểm về học tập, kinh doanh và đưa chúng ta đến với thời đại mới - thời đại công nghệ số. Internet
trở thành một môi trường kinh doanh xoá đi mọi ranh giới quốc gia và tạo ra một thị trường lớn nhất
trong lịch sử nhận loại, cùng với nó là sự phát triển như vũ bão của mạng toàn cầu tại Việt Nam.
Bên cạnh những thành tựu to lớn của mạng Internet mang lại cho nhân loại mà chúng ta đang đạt
được, nỗi lo về an toàn thông tin ngày càng được quan tâm hơn. Hàng ngày chúng ta được nghe rất
nhiều thông tin về các cuộc tấn cồng vào các hệ thổng thông tin quan trọng với những thiệt hại rất
lớn về tài chính, thông tin riêng tư của các cá nhân và các tổ chức. Mục tiêu của các cuộc tấn công
mạng thì rất đa dạng, từ những vấn đề cá nhân, những mục đích xấu trong kinh doanh cho đến mục
tiêu chính trị với tầm ảnh hường trên nhiêu quốc gia. Tội phạm an ninh mạng ngày càng phát triển
cả về số lượng, quy mô và mức độ nguy hiểm. Do vậy vấn đề bảo mật, an ninh mạng luôn luôn được
bất cứ cá nhân, công ty hay tổ chức đặt lên hàng đầu.
Với khả năng kết nối nhiêu máy tính và mạng, bảo mật trở thành vấn đề lớn và khó khăn hơn bao
giờ hết trong môi trường doanh nghiệp. Hacker và những kẻ xâm nhập đã đễ dàng đạt được nhiều
mục đích trong việc phá hủy hệ thống mạng và dịch vụ web. Rất nhiêu hãng có uy tín về bảo mật
đã có nhiều giải pháp để hạn chế sự tấn công trên mạng và những phương thức đã được triển khai
trong nỗ lực bảo vệ hạ tầng mạng và truyền thông qua mạng internet bao gồm firewall, các phương
thức mã hóa, và các mạng riêng ảo .
Phát hiện xâm nhập củng là một kỹ thuật liên quan được áp dụng. Các phương thức phát hiện
xâm nhập xuất hiện vài năm gần đây. Với các phương pháp này người quản trị có thể thu thập và
sử dụng thông tin từ các dạng tấn công chưa được biết hoặc phát hiện cuộc tấn công đang diễn ra.
Những thông tin thu thập được sẽ giúp người quản trị gia cố an ninh mạng, đưa ra các chính sách an
toàn cho hệ thống nhằm giảm thiểu những tấn công bất hợp pháp.
Chính vì vậy em chọn đề tài này : "Nghiên cứu thực nghiệm về triển khai, đánh giá HIDS
Wazuh cho hệ thống sử dụng Docker Container”
LỜI CAM ĐOAN
Em xin cam đoạn:

1. Những nội dung trong đồ án này là do nhóm em thực hiện dưới sự hướng dẫn trực tiếp của thầy
giáo Ths.Nguyễn Thanh Hòa
2. Mọi tham khảo dùng trong đồ án đều được trích dẫn rõ ràng và trung thực tên tác giả, tên công
trình, thời gian, địa điểm công bố.
3. Mọi sao chép không hợp lệ, vi phạm quy chế đào tạo, hay gian trá, em xin chịu hoản toàn trách
nhiệm.
1
Mục lục
Chương 1 GIỚI THIỆU CHUNG 3

1.1 Lý do chọn đề tài . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Tính mới của đề tài . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Phương pháp nghiên cứu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 phạm vi và đối tượng nghiên cứu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Chương 2 KIẾN THỨC NỀN TẢNG 5

2.1 Tổng quan về hệ thống phát hiện xâm nhập IDS . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Định nghĩa về IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1.1 Phân biệt IDS với các cơ chế bảo mật khác . . . . . . . . . . . . . . . 5
2.1.2 kiến trúc của hệ thống IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2.1 Thành phần của IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Phân loại IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4 Cách thức hoạt động của Host-Based IDS . . . . . . . . . . . . . . . . . . . . 7
2.2 Giới thiệu về WAZUH 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Khái niệm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.1 OSSEC HIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.2 OpenSCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.3 Elastic Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Các Thành phần của WAZUH . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2.1 Wazuh Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2.2 Wazuh Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2.3 Elastic Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 Kiến trúc của WAZUH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3.1 Giao tiếp Agent - Server . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.3.2 Giao tiếp Wazuh - Elastic . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4 Các port cần thiết . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4.1 WAZUH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4.2 Elastic Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4.3 Lưu trữ dữ liệu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.5 luật trong WAZUH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.5.1 Tổ chức các luật . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.5.2 Các thuộc tính của Rule . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.5.3 Phân loại luật . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.6 Phương thức hoạt động của luật trong WAZUH . . . . . . . . . . . . . . . . . 18
2.2.6.1 Cú pháp của Decoders . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.6.2 Cú pháp của Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.6.3 Biểu thức chính quy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3 Các công nghệ liên quan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.1 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.1.1 Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.1.2 Container Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.1.3 Lưu trữ dữ liệu trên container . . . . . . . . . . . . . . . . . . . . . . 36
2
2.3.1.4 Lưu trữ trên Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Chương 3 XÂY DỰNG HỆ THỐNG 39

3.1 triển khai Wazuh trên Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.1 Cài đặt Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Cài đặt Wazuh Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Các tiện ích của Wazuh Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Chương 4 TRÌNH BÀY, ĐÁNH GIÁ VỀ KẾT QUẢ 44

4.1 File integrity monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.1 Cách thức hoạt động . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.1.2 Cấu hình . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Active Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1 Cách thức hoạt động . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.2 Cấu hình . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3 Auditing who-data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.1 Auditing who-data trong Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.2 Cấu hình . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4 VirusTotal integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.1 Điều khoản dịch vụ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.2 Cấu hình . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5 Monitoring system calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.5.1 Cấu hình . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Chương 5 KẾT LUẬN,HƯỚNG PHÁT TRIỂN 69

5.1 Ưu điểm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2 Nhược điểm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3 Hướng phát triển . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Chương 6 TÀI LIỆU THAM KHẢO 71

DANH MỤC HÌNH
Hình Nội Dung Số trang
2.1 Thành phần của IDS 5
2.2 Nguyên lý hoạt động 5
2.3 Mô hình hệ thống 7
2.4 Wazuh Server 8
2.5 Wazuh Server 9
2.6 Wazuh Agent 10
2.7 Wazuh Distributed deployment 12
2.8 Wazuh All-in-one deployment 13
2.9 Ouput 14
2.10 Cấu trúc thư mục của Rule 15
2.11 Kết nối giữa hai container 34
2.12 Ba cách lưu trữ container 35
2.13 Cách dữ liệu lưu trữ trên Docker 36
3.1 Ouput docker-compose ps 41
3.2 Ouput docker volume ls 42
4.1 Mô hình FIM 44
4.2 Kiểm tra Container đã tạo 45
4.3 Nơi lưu trữ Container 45 4.33 API key
4.4 Container ID 46 4.34 Thay đổi file ossec.conf m
4.5 ossec.conf 46 4.35 Thay đổi file ossec.conf A
4.6 File 47 4.36
4.7 Log 47 4.37 kiểm tra database
4.8 thay đổi file 48 4.38 Kiểm tra file Json
4.9 log 49 4.39 Kiểm tra file Json
4.10 log 50 4.40 Cài dặt audit
4.11 Ví dụ 48 4.41 Thay đổi file ossec.conf
4.12 Kết quả 49 4.42 Đặt lệnh
4.13 Mô hình Active Response 49 4.43
4.14 Cấu hình ossec.conf manager 50 4.44 Kiểm tra
4.15 Cấu hình ossec.conf manager 50
4.16 Restart 51
4.17 Cấu hình ossec.conf Agent 52
4.18 Cấu hình ossec.conf Agent 52
4.19 Kiểm tra 53
4.20 Kiểm tra 53
4.21 Cấu hình ossec.conf manager 54
4.22 Kiểm tra 54
4.23 Thay đổi file ossec.conf 55
4.24 Cài dặt audit 55
4.25 Tạo container mới 56
4.26 file Log 56
4.27 Kiểm tra file 557
4.28 Kết quả 57
4.29 Kết quả 58
4.30 Kết quả 59
4.31 Kết quả file 60
4.32 Kết quả 62
1
DANH MỤC VIẾT TẮT
CNTT Công nghệ thông tin
Dos Disk Operating System
ECCDF Extensible Configuration Checklist
Description Format
FIM File integrity monitoring
HIDS Host Intrusion Detection System
IDS Intrusion Detection systems
IP Địa chỉ mạng
MVP Model View Presenter
NIDS Network Intrusion Detection System
OSSEC Open Source HIDS SECurity
SCA Security configuration asemssment
SSL Secure Sockets Layer
TLS Transport Layer Security
VPN Virtual Private Network
2
Chương 1
GIỚI THIỆU CHUNG
1.1 Lý do chọn đề tài

Bảo mật là một vấn đề lớn đối với tất cả các mạng trong mội trường doanh nghiệp hiện nay. Tin
tặc và kẻ xâm nhập đã nhiều lân thành công trong việc xâm nhập vào mạng công ty và đem ra ngoài
rất nhiều thông tin giá trị. Đã có nhiều phương pháp phát triển để đảm bảo cho hạ tầng mạng và
giao tiếp trên internet như : sử dụng Firewall, VPN trong đó có hệ thống phát hiện và ngăn chặn xâm
nhập.
Phát hiện xâm nhập là một trong những công nghệ và phướng thức dùng để phát hiện hành động
khả nghỉ trên cả Host và mạng.Các phương pháp phát hiện xâm nhập bắt đầu xuất hiện những năm
gần đây, sử dụng phương thức phát hiện xâm nhập , bạn có thể thu thập, sử dụng thông tin từ những
lỗ hổng tấn công đã biết để tìm ra và cảnh báo một ai đó đang cố gắng tấn công vào mạng hay máy
cá nhân.
Vì vậy,là sinh viên được trang bị những kiến thức của ngành hệ thống thông tin với những kiến
thức đã tiếp thu và vận đụng lý thuyết đó vào công việc thực tế nên em đã chọn đê tài “Xây dựng
hệ thống HIDS sử dụng WAZUH” để thực hiện đồ án chuyên ngành của mình với mục đích xây dựng
được hệ thống phát hiện và phòng chống xâm nhập trái phép nhằm đảm bảo an toàn hệ thống mạng
cho doanh nghiệp và cá nhân.
1.2 Tính mới của đề tài

Trong những năm gần đây, công nghệ ảo hóa Docker Container xuất hiện đóng vai trò là một giải
pháp rất tốt giúp giảm tải gánh nặng về việc setup và deploy application lên một hoặc nhiều server
khác nhau cũng như việc triển khai và chạy các ứng dụng trên các máy khác nhau.
Chính vì tính ứng dụng và thiết thực của công nghệ Docker Container, việc bảo mật và đảm bảo
an toàn cho công nghệ này cũng đã được hệ thống HIDS Wazuh chú ý và tích hợp vào trong hệ thống
này với tên gọi Containers Security. Wazuh cung cấp khả năng hiển thị bảo mật cho các máy chủ và
Docker host, theo dõi hành vi của chúng và phát hiện các mối đe dọa, lỗ hổng và các điểm bất thường.
Wazuh liên tục thu thập và phân tích các hoạt động diễn ra trên container và hiển thị cũng như
tích hợp với các Docker engine giúp người dùng dễ dàng giám sát các images, volumes, network setting
và chạy các container [3]. Đề tài này sẽ tập trung vào việc triển khai, đánh giá HIDS Wazuh cho hệ
thống sử dụng Docker Container.
1.3 Phương pháp nghiên cứu

Cách tiếp cận: ứng dụng được xây dựng dựa theo mô hình MVP trên nền tảng Android.
Nhóm đã sử dụng các phương pháp nghiên cứu:
- Phương pháp đọc tài liệu
3
- Phương pháp thực nghiệm
1.4 phạm vi và đối tượng nghiên cứu

Phạm vi: Triển khai hệ thống HIDS Wazuh giám sát và đánh giá tập trung vào ứng dụng về
Containers Security.
Đồ án này hướng đến nghiên cứu các đối tượng sau:
Các công nghệ:
+ Máy ảo VMware
+ Docker
+ ELK stack
4
Chương 2
KIẾN THỨC NỀN TẢNG
2.1 Tổng quan về hệ thống phát hiện xâm nhập IDS

2.1.1 Định nghĩa về IDS
IDS (Intrusion Detection Systems - Hệ thống phát hiện xâm nhập) là thiết bị hoặc phần mềm có
nhiệm vụ giám sát traffic mạng, các hành vi đáng ngờ và cảnh báo cho admin hệ thống.
Mục đích của IDS là phát hiện và ngăn ngừa các hành động phá hoại bảo mật hệ thống, hoặc
những hành động trong tiến trình tấn công như dò tìm, quét các cổng.
IDS cũng có thể phân biệt giữa những cuộ tấn công nội bộ (từ chính nhân viên hoặc khách hàng
trong tổ chức) và tấn công bên ngoài (từ hacker). Trong một số trường hợp, IDS có thể phản ứng
lại với các traffic bất thường/độc hại bằng cách chặn người dùng hoặc địa chỉ IP nguồn truy cập mạng.
2.1.1.1 Phân biệt IDS với các cơ chế bảo mật khác
Khi mà Internet đang ngày càng phát triển và tiếp cận rộng rãi hơn trong cộng đồng, các nguy cơ
từ các cuộc tấn công cũng theo đó mà gia tăng. Người dùng nói chung hay người quản trị hệ thống
nói riêng sẽ luôn phải đối mặt với những nguy cơ tiềm ẩn nếu như hệ thống không được bảo vệ triệt
để. Từ đó, những cơ chế bảo mật cũng được sinh ra tùy theo nhu cầu của mỗi hệ thống. Chúng ta
cần phân biệt rõ ràng sự khác nhau giữa IDS và một số cơ chế bảo mật khác:
• Hệ thống ghi nhật ký mạng được sử dụng để phát hiện lỗ hổng đối với những cuộc tấn công từ
chối dịch vụ (DoS) trên mạng đang bị tắc nghẽn. Đây là các hệ thống giám sát traffic trong mạng.
• Các công cụ đánh giá lỗ hổng, dùng để kiểm tra lỗi và lỗ hổng trong hệ điều hành, dịch vụ mạng
(các bộ quét bảo mật).
• Các phần mềm diệt virus được thiết kế để phát hiện phần mềm nguy hiểm như virus, Trojan horse,
worm, logic bomb... Mặc dù những tính năng mặc định có thể rất giống hệ thống phát hiện xâm nhập
và thường cung cấp một công cụ phát hiện vi phạm bảo mật hiệu quả, nhưng xét tổng thể chúng
không phải là IDS.
• Tường lửa: Dù nhiều tưởng lửa hiện đại được tích hợp sẵn IDS, nhưng IDS không phải là tường
lửa.
• Các hệ thống bảo mật/mật mã, ví dụ như VPN, SSL, S/MIME, Kerberos, Radius.
5
2.1.2 kiến trúc của hệ thống IDS
2.1.2.1 Thành phần của IDS
Hình 2.1 : Thành phần của IDS
• Bộ tạo sự kiện (Event Generato): Cung cấp một số chính sách thích hợp cho các sự kiện, có thể là
một bản ghi các sự kiện của hệ thống hoặc các gói mạng. Số chính sách này cùng với thông tin chính
sách có thể được lưu trong hệ thống được bảo vệ hoặc bên ngoài.
Ví dụ: khi luồng dữ liệu sự kiện được truyền tải trực tiếp đến bộ phân tích mà không có sự lưu dữ
liệu nào được thực hiện. Điều này cũng liên quan một chút nào đó đến các gói mạng.
• Bộ cảm biến (Sensor):Dùng để lọc thông tin và loại bỏ dữ liệu không tương thích đạt được từ các
sự kiện liên quan với hệ thống bảo vệ, vì vậy có thể phát hiện được các hành động nghi ngờ.
• Bộ phân tích (Response Module): sử dụng cơ sở dữ liệu chính sách phát hiện cho mục này.
Ngoài ra còn có các thành phần: dấu hiệu tấn công, profile hành vi thông thường, các tham số cần
thiết (ví dụ: các ngưỡng). Thêm vào đó, cơ sở dữ liệu giữ các tham số cấu hình, gồm có các chế độ
truyền thông với module đáp trả. Bộ cảm biến cũng có cơ sở dữ liệu của riêng nó, gồm dữ liệu lưu về
các xâm nhập phức tạp tiềm ẩn (tạo ra từ nhiều hành động khác nhau).
IDS có thể được sắp đặt tập trung (ví dụ như được tích hợp vào trong tường lửa) hoặc phân tán.
Một IDS phân tán gồm nhiều IDS khác nhau trên một mạng lớn, tất cả chúng truyền thông với nhau.
Nhiều hệ thống tinh vi đi theo nguyên lý cấu trúc một tác nhân, nơi các module nhỏ được tổ chức
trên một host trong mạng được bảo vệ.
Hình 2.2 : Nguyên lý hoạt động
6
Hệ thống IDS sẽ hoạt động theo 3 bước: Giám sát - Cảnh báo - Bảo vệ
• Giám sát : Giám sát lưu lượng mạng cũng như các hoạt động bất thường
• Cảnh báo: Gửi cảnh báo hệ thống cho người quản trị khi phát hiện có bất thường
• Bảo vệ : Sử dụng các thiết lập từ người quản trị để bảo vệ hệ thống
Khi một sự xâm nhập được phát hiện, IDS đưa ra các cảnh báo đến các quản trị viên hệ thống về
sự việc này. Bước tiếp theo được thực hiện bởi các quản trị viên hoặc có thể là bản thân IDS bằng
cách lợi dụng các tham số đo bổ sung (các chức năng khóa để giới hạn các session, backup hệ thống,
định tuyến các kết nối đến bẫy hệ thống, cơ sở hạ tầng hợp lệ,. . . ) – theo các chính sách bảo mật của
các tổ chức (Hình 2). Một IDS là một thành phần nằm trong chính sách bảo mật.
Giữa các nhiệm vụ IDS khác nhau, việc nhận ra kẻ xâm nhập là một trong những nhiệm vụ cơ
bản. Nó cũng hữu dụng trong việc nghiên cứu mang tính pháp lý các tình tiết và việc cài đặt các bản
vá thích hợp để cho phép phát hiện các tấn công trong tương lai nhằm vào các cá nhân cụ thể hoặc
tài nguyên hệ thống.
Phát hiện xâm nhập đôi khi có thể đưa ra các báo cảnh sai, ví dụ những vấn đề xảy ra do trục
trặc về giao diện mạng hoặc việc gửi phần mô tả các tấn công hoặc các chữ ký thông qua email.
2.1.3 Phân loại IDS

IDS có nhiều loại và tiếp cận các traffic đáng ngờ theo nhiều cách khác nhau. Có IDS dựa trên
mạng (NIDS) và dựa trên máy chủ (HIDS). Có IDS phát hiện dựa trên việc tìm kiếm các chữ ký cụ
thể của những mối đe dọa đã biết (tương tự như cách các phần mềm diệt virus phát hiện và ngăn
chặn malware) và IDS phát hiện bằng cách so sánh các mẫu traffic với baseline rồi xem có sự bất
thường nào không. Có những IDS chỉ theo dõi và cảnh báo, có IDS sẽ thực hiện hành động khi phát
hiện xâm nhập. Chúng ta sẽ xem xét cụ thể dưới đây:
• NIDS: Network Intrusion Detection Systems được đặt tại một điểm chiến lược hoặc những điểm
giám sát traffic đến và đi từ tất cả các thiết bị trên mạng. Lý tưởng nhất là bạn có thể quét tất cả
traffic inbound và outbound, nhưng việc này có thể tạo ra nút thắt cổ chai làm giảm tốc độ chung
của mạng.
• HIDS: Host Intrusion Detection Systems, hệ thống phát hiện xâm nhập này chạy trên máy chủ
riêng hoặc một thiết bị đặc biệt trên mạng.HIDS có thể được cài đặt trên nhiều dạng máy tính khác
nhau cụ thể như các máy chủ, máy trạm, máy tính xách tay. HIDS cho phép bạn thực hiện một cách
linh hoạt trong các đoạn mạng mà NIDS không thể thực hiện được. HIDS chỉ giám sát các gói dữ
liệu inbound và outbound từ thiết bị và cảnh báo người dùng hoặc quản trị viên về những hoạt động
đáng ngờ được phát hiện.
• Signature-Based: Là các IDS hoạt động dựa trên chữ ký, giám sát các gói tin trên mạng và so
sánh chúng với cơ sở dữ liệu chữ ký, thuộc tính từ những mối đe dọa đã biết, tương tự như cách phần
mềm diệt virus hoạt động. Vấn đề đối với hệ thống IDS này là có thể không phát hiện ra mối đe dọa
mới, khi chữ ký để nhận biết nó chưa được IDS kịp cập nhật.
• Anomaly-Based: IDS này sẽ phát hiện mối đe dọa dựa trên sự bất thường. Nó giám sát traffic
mạng và so sánh với baseline đã được thiết lập. Baseline sẽ xác định đâu là mức bình thường của
mạng: loại băng thông thường được dùng, giao thức thường dùng, cổng và thiết bị thường kết nối với
nhau, cảnh báo cho quản trị viên mạng hoặc người dùng khi phát hiện traffic truy cập bất thường
hoặc những khác biệt đáng kể so với baseline.
• Passive: IDS thụ động sẽ chỉ phát hiện và cảnh báo. Khi phát hiện traffic đáng ngờ hoặc độc hại,
nó sẽ tạo cảnh báo và gửi đến quản trị viên hoặc người dùng. Việc hành động như nào sau đó tùy
thuộc vào người dùng và quản trị viên.
• Reactive: Loại IDS này bên cạnh nhiệm vụ như IDS Passive, nó còn thực hiện những hành động
được thiết lập sẵn để ngay lập tức phản ứng lại các mối đe dọa, ví như: chặn truy cập, khóa IP.
2.1.4 Cách thức hoạt động của Host-Based IDS

Với các cuộc tần công trong không gian mạng và kẻ tần công có thẻ đánh cắp thông tin của một
hệ thống khi bị chiếm quyền truy cập, việc bảo mật cho một công ty hay một tô chức ngày càng được
chú trọng. Chúng ta biết rằng một bức tường lửa không đủ và không phải là công cụ duy nhất mà
chúng ta dựa vào vì sự an toàn. Chứng ta đã chuyễn sang một giai đoạn mới mà chúng ta có thể thực
7
hiện các bước đề bảo đảm cơ sở hạ tằng CNTT của mình khỏi phần mềm độc hại với giao diện đa lớp.
Phân mềm phát hiện xâm nhập (IDS) là một ứng dụng giám sát mạng hoặc giám sát một hệ thống
cho hoạt động đáng ngờ và thường được ghép nổi với tường lửa đề tăng tính bảo mật. Một loại khác
thuộc IDS là phần mềm phát hiện xâm nhập dựa trên máy chủ (HIDS). HIDS là một hệ thống rất đa
dạng của IDS. Như tên của nó cho thầy, HIDS sẽ được cài đặt trong một hệ thống máy chủ duy nhất
đề theo dõi và báo cáo về cầu hình và hoạt động ứng dụng của hệ thống. Lớp bảo vệ bỗ sung này
đảm bảo mọi thứ khi vượt qua tường lửa sẽ không khiến hệ thống dễ bị tôn thương. HIDS có nhiều
khía cạnh, chăng hạn như phát hiện chữ ký (Signature Detection), phát hiện sự bất thường (Anomaly
Detection), phát hiện phân tích trạng thái giao thức (Stateful Protocol Analysis Detection), giám sát
Iogfile (Monitoring logfile) và giám sát tính toàn vẹn (Monitoring integrity) đễ bảo vệ hệ thống khỏi
các mồi đe doa nguy hiểm.
Hình 2.3 : Mô hình hệ thống
+ Ví trí : cài đặt cục bộ trên máy tính và dạng máy tính,linh hoạt hơn NIDS.
+ Loại : software.
+ Nhiệm vụ : phân tích lưu lượng ra vào mạng chuyển tới máy tính cài đặt HIDS.
+ Ưu điểm : Cài đặt trên nhiều dạng máy tính : xách tay, PC,máy chủ ...Phân tích lưu lượng mạng
rồi mới forward.
+ Nhược điểm : Đa số chạy trên hệ điều hành Window. Tuy nhiên cũng đã có 1 số chạy được trên
Unix và những hệ điều hành khác
8
2.2 Giới thiệu về WAZUH 4.0
2.2.1 Khái niệm
Wazuh là một dự án mã nguồn mở với các chức năng security detection, visibility, và compliance
monitoring. Wazuh ban đầu được phát triển dựa trên OSSEC HIDS và sau đó được tích hợp thêm
Elastic Stack cùng với OpenSCAP để trở thành một giải pháp an ninh toàn diện với các khả năng như:
Hình 2.4 : Các chức năng của WAZUH
2.2.1.1 OSSEC HIDS

OSSEC là một HIDS (Host-based Intrusion Detection System) với kiến trúc gồm các agent vệ tinh
đa nền tảng và một hệ thống quản lý trung tâm (central manager). Các agent này sẽ forward dữ liệu
hệ thống (chẳng hạn log messages, file hashes, và các hoạt động bất thường) đến cho trung tâm quản
lý để được phân tích và xử lý và đưa ra các alert thích hợp. Các dữ liệu này sẽ được gửi thông qua
các kênh truyền an toàn và được xác thực.
Ngoài ra, OSSEC cũng có thể được triển khai với cấu hình một syslog server trung tâm cùng hệ
thống giám sát phi tác nhân (agentless configuration monitoring system). Ở cấu hình này, OSSEC sẽ
đưa ra các security insight từ các sự kiện và thay đổi diễn ra trên các thiết bị agentless như firewall,
switch, routers, access point, network appliance, v...v. . .
2.2.1.2 OpenSCAP
OpenSCAP là trình thông dịch cho chuẩn ngôn ngữ thẩm định OVAL (Open Vulnerability Assess-
ment Language) và định dạng cấu hình an ninh hệ thống ECCDF (Extensible Configuration Checklist
Description Format). OpenSCAP có được sử dụng để kiểm tra các cấu hình của hệ thống và phát
hiện các ứng dụng có lỗ hổng. Đây là một công cụ được thiết kế với khả năng thẩm định và gia cố
của các hệ thống áp dụng các tiêu chuẩn an ninh công nghiệp cho môi trường doanh nghiệp.
2.2.1.3 Elastic Stack

Elastic Stack là một bộ phần mềm (Wazuh sử dụng Filebeat, Elasticsearch, Kibana) được dùng để
thu thập, phân giải, index, lưu trữ, tìm kiếm và biểu diễn log. Elastic Stack cung cấp một high-level
dashboard ở phía front-end để phục vụ các thao tác phân tích nâng cao cũng như data mining.
9
2.2.2 Các Thành phần của WAZUH
2.2.2.1 Wazuh Server
Wazuh server chịu trách nhiệm phân tích dữ liệu gửi từ agent và trigger alert khi có một sự kiện
khớp với rule (chẳng hạn phát hiện xâm nhập, file bị thay đổi, cấu hình không tuân thủ chính sách,
rootkit,...).
Hình 2.5 : Wazuh Server
Wazuh server thường sẽ được cài đặt trên một máy chủ vật lý hoặc máy ảo riêng biệt, hay cũng có
thể là một máy trên cloud và chạy các agent để tự giám sát chính nó.
Các thành phần chính của Wazuh Server:

• Agents registration service: Được sử dụng để đăng ký Agent mới bằng cách cung cấp và phân
phối khóa xác thực chia sẻ trước dành riêng cho từng Agent. Quá trình này chạy như một dịch vụ
mạng và hỗ trợ xác thực thông qua chứng chỉ TLS / SSL hoặc bằng cách cung cấp mật khẩu cố định.
• Agents registration service: Đây là dịch vụ nhận dữ liệu từ các Agent. Nó sử dụng các khóa
được chia sẻ trước để xác thực danh tính từng tác nhân và mã hóa thông tin liên lạc giữa tác nhân
và Wazuh Serever. Ngoài ra, dịch vụ này được sử dụng để cung cấp quản lý cấu hình tập trung, có
thể đẩy các cài đặt tác nhân mới từ xa.
• Analysis engine: Đây là quá trình thực hiện phân tích dữ liệu. Nó sử dụng bộ giải mã để xác định
loại thông tin đang được xử lý (ví dụ: Windows events, SSHD logs, web server logs, v.v.) và trích xuất
các phần tử dữ liệu có liên quan từ thông báo nhật ký (ví dụ: ource IP address, event ID, username,
v.v.) . Tiếp theo, bằng cách sử dụng các quy tắc (Rules), nó xác định các mẫu cụ thể trong các sự
kiện được giải mã có thể kích hoạt cảnh báo và thậm chí có thể gọi các biện pháp đối phó tự động
(ví dụ: lệnh cấm IP trên tường lửa).
• Wazuh RESTful API:Dịch vụ này cung cấp giao diện để tương tác với cơ sở hạ tầng Wazuh. Nó
được sử dụng để quản lý các tác nhân và cài đặt cấu hình máy chủ, để theo dõi trạng thái cơ sở hạ
tầng và tình trạng tổng thể, quản lý và chỉnh sửa các quy tắc (Rule) và bộ giải mã Wazuh cũng như
truy vấn về trạng thái của các điểm cuối được giám sát. Nó cũng được sử dụng bởi giao diện người
dùng web Wazuh, đó là ứng dụng Kibana.
• Wazuh cluster daemon: Dịch vụ này được sử dụng để mở rộng các Wazuh Server theo chiều
ngang, triển khai chúng dưới dạng một cụm. Loại cấu hình này, kết hợp với bộ cân bằng tải mạng,
cung cấp tính khả dụng cao và cân bằng tải. Daemon cụm Wazuh là thứ mà các máy chủ Wazuh sử
dụng để giao tiếp với nhau và giữ đồng bộ hóa.
• Filebeat:Nó được sử dụng để gửi các sự kiện và cảnh báo tới Elasticsearch. Nó đọc kết quả của
công cụ phân tích Wazuh và gửi các sự kiện trong thời gian thực. Nó cũng cung cấp khả năng cân
bằng tải khi được kết nối với một cụm Elasticsearch nhiều nút.
10
2.2.2.2 Wazuh Agent
Wazuh agent có thể được cài đặt trên các hệ điều hành Windows, Linux, Solaris, BSD, và Mac .
Các agent sẽ thu thập dữ liệu từ hệ thống và ứng dụng và sau đó gửi chúng đến Wazuh server qua
một kênh truyền đã được mã hóa và xác thực. Kênh truyền an ninh này sẽ được khởi tạo bởi một
tiến trình đăng ký sử dụng các khóa duy nhất với mỗi agent.
Các agent có thể được sử dụng để giám sát các máy chủ vật lý, các máy ảo và cloud instance
(Amazon AWS, Azure, Google Cloud). Các gói cài đặt agent khả dụng hiện tại bao gồm các gói cài
đặt cho Linux, HP-UX, AIX, Solaris, Windows, và Darwin (Mac OS X).
Trên các hệ điều hành Unix-based, Wazuh agent sẽ chạy nhiều tiến trình riêng và giao tiếp với
nhau thông qua local Unix domain socket. Một trong số các tiến trình này sẽ chịu trách nhiệm giao
tiếp và gửi dữ liệu đến Wazuh server. Đối với các hệ điều hành Windows, chỉ có một tiến trình agent
duy nhất sử dụng mutex để chạy đa nhiệm các tác vụ. Các tác vụ hoặc tiến trình khác nhau của agent
sẽ chịu trách nhiệm giám sát khác nhau (chẳng hạn file kiểm tra tính toàn vẹn của file, đọc log, quét
các cấu hình hệ thống).
Hình 2.6 : Wazuh Agent
Các thành phần chính của Wazuh Agent:

• Log collector: Tiến trình này sẽ chịu trách nhiệm đọc log hệ thống và ứng dụng, bao gồm flat log,
các log sự kiện tiêu chuẩn và cả các kênh sự kiện Windows. Ngoài ra, log collector còn có thể được
cấu hình để định kỳ bắt các output từ một số lệnh nhất định.
• Command execution: Agent có thể chạy các lệnh được ủy quyền theo định kỳ, thu thập kết quả
đầu ra của chúng và báo cáo lại cho Wazuh Server để phân tích thêm. Mô-đun này có thể được sử
dụng để đáp ứng các mục đích khác nhau (ví dụ: theo dõi dung lượng ổ cứng còn lại, nhận danh sách
người dùng đăng nhập lần cuối, v.v.).
• File integrity monitoring (FIM): Mô-đun này giám sát hệ thống tệp, báo cáo khi tệp được tạo,
xóa hoặc sửa đổi. Nó theo dõi các thuộc tính tệp, quyền, quyền sở hữu và nội dung. Khi một sự kiện
xảy ra, nó nắm bắt thông tin chi tiết về ai , cái gì và khi nào trong thời gian thực. Ngoài ra, mô-đun
này xây dựng và duy trì cơ sở dữ liệu với trạng thái của các tệp được giám sát, cho phép các truy vấn
được chạy từ xa.
• Security configuration assessment (SCA): Thành phần này cung cấp đánh giá cấu hình liên
tục, sử dụng các kiểm tra bên ngoài dựa trên điểm chuẩn của Trung tâm Bảo mật Internet (CIS).
Người dùng cũng có thể tạo kiểm tra SCA của riêng họ để giám sát và thực thi các chính sách bảo
mật của họ.
11
• System inventory:Thành phần này cung cấp đánh giá cấu hình liên tục, sử dụng các kiểm tra
bên ngoài dựa trên điểm chuẩn của Trung tâm Bảo mật Internet (CIS). Người dùng cũng có thể tạo
kiểm tra SCA của riêng họ để giám sát và thực thi các chính sách bảo mật của họ.
• Malware detection: Sử dụng cách tiếp cận không dựa trên chữ ký, thành phần này có khả năng
phát hiện sự bất thường và sự hiện diện có thể có của rootkit. Giám sát các cuộc gọi hệ thống, nó tìm
kiếm các quy trình ẩn, tệp ẩn và cổng ẩn.
• Active response:Mô-đun này chạy các hành động tự động khi các mối đe dọa được phát hiện.
Trong số những thứ khác, nó có thể chặn kết nối mạng, dừng quá trình đang chạy hoặc xóa tệp độc
hại. Người dùng cũng có thể tạo phản hồi tùy chỉnh khi cần thiết (ví dụ: chạy tệp nhị phân trong hộp
cát, nắm bắt lưu lượng kết nối mạng, quét tệp bằng phần mềm chống vi-rút, v.v.).
• Containers security monitoring:Mô-đun tác nhân này được tích hợp với API Docker Engine để
theo dõi các thay đổi trong môi trường được chứa trong vùng chứa. Ví dụ: nó phát hiện các thay đổi
đối với hình ảnh vùng chứa, cấu hình mạng hoặc khối lượng dữ liệu. Bên cạnh đó, nó cảnh báo về các
vùng chứa đang chạy ở chế độ đặc quyền và về việc người dùng thực hiện các lệnh trong vùng chứa
đang chạy.
• Cloud security monitoring:Thành phần này giám sát các nhà cung cấp đám mây như Amazon
AWS, Microsoft Azure hoặc Google GCP. Nó tự nhiên giao tiếp với các API của họ. Nó có khả năng
phát hiện các thay đổi đối với cơ sở hạ tầng đám mây (ví dụ: người dùng mới được tạo, nhóm bảo
mật được sửa đổi, phiên bản đám mây bị dừng, v.v.) và thu thập dữ liệu nhật ký dịch vụ đám mây
(ví dụ: AWS Cloudtrail, AWS Macie, AWS GuardDuty , Azure Active Directory, v.v.)

Elastic Stack là một bộ gồm các công cụ mã nguồn mở phục vụ cho mục đích quản lý log, bao
gồm Elasticsearch, Kibana, Filebeat, Logstash,.... Các công cụ của Elastic stack được sử dụng trong
Wazuh gồm:
• Elasticsearch: Một công cụ tìm kiếm và phân tích mạnh mẽ với chức năng full-text search cũng
như khả năng mở rộng cao. Elasticsearch được tổ chức phân phối, nghĩa là dữ liệu (index) sẽ được
chia thành các phân đoạn cơ sở dữ liệu (shard) và mỗi phân đoạn có thể có 0 hoặc nhiều bản sao.
• Kibana: Cung cấp một giao diện web linh hoạt và trực quan cho mining, phân tích, và trình bày
dữ liệu. It runs on top of the content indexed on an Elasticsearch cluster.
• Filebeat: Một công cụ gọn nhẹ để forward log trong mạng, thường được sử dụng cho Elasticsearch.
Wazuh tích hợp Elastic Stack để lưu trữ và index các log đã được giải mã với Elasticsearch, và sử
dụng như một giao diện console real-time để theo dõi các alert và phân tích log. Bên cạnh đó, giao
diện người dùng của Wazuh (chạy trên Kibana) cũng có thể được sử dụng để quản lý và giám sát hạ
tầng của Wazuh.
Một Elasticsearch index là một tập hợp các văn bản có các đặc trưng tương tự. Wazuh sử dụng 3
index sau:
• wazuh-alerts: các alert được tạo bởi Wazuh server.
• wazuh-events: mọi event được gửi đến từ agent.
• wazuh-monitoring: các dữ liệu liên quan đến trạng thái của agent. Nó được sử dụng cho giao
diện web của Wazuh để hiển thị các trạng thái của agent như: “Active”, “Disconnected” hay “Never
connected”.
Như đã đề cập ở trên, các index của Elasticsearch có thể được chia thành nhiều phân đoạn (shard)
và nhân thành các bản sao. Mỗi thực thể này là một Lucene index. Vì vậy, có thể coi một Elasticsearch
index là một tập các Lucene index. Khi một yêu cầu tìm kiếm được thực hiện trên một Elasticsearch
index, yêu cầu này sẽ được thực thi song song trên các phân đoạn của index và kết quả sau đó sẽ được
được trộn lại với nhau. Việc chia nhỏ các index của Elasticsearch được sử dụng trong multiple-node
Elasticsearch cluster với mục đích mở rộng tìm kiếm để đảm bảo tính sẵn sàng. Đối với các single-node
Elasticsearch cluster thì thường mỗiindex sẽ chỉ tồn tại một phân đoạn duy nhất và không có bản sao
12
2.2.3 Kiến trúc của WAZUH
Kiến trúc của Wazuh xoay quanh mô hình: agent chạy trên các host được giám sát và forward dữ
liệu đến server trung tâm. Bên cạnh đó, Wazuh cũng hỗ trợ các thiết bị agentless (firewall, switch,
router, access point,...) submit dữ liệu thông qua syslog, hoặc có thể bị động chờ hệ thống quét các
thay đổi trong cấu hình của chúng và sau đó forward dữ liệu đến server trung tâm. Server trung tâm
sẽ chịu trách nhiệm giải mã và phân tích các thông tin được gửi đến và chuyển tiếp kết quả đến
Elasticsearch để được index và lưu trữ.
Một Elasticsearch cluster là một tập hợp của một hay nhiều node (server) giao tiếp với nhau để
thực hiện các thao tác đọc và ghi trên các index. Một single-node Elasticsearch cluster có thể dễ dàng
quản lý một hệ thống Wazuh cỡ nhỏ với khoảng 50 agent đổ lại. Các multi-node Elasticsearch cluster
thường được khuyến cáo khi có một số lượng lớn hệ thống cần giám sát,hay có một lượng dữ liệu lớn,
hoặc những hệ thống có yêu cầu cao về tính sẵn sàng.
Khi mà Wazuh server và Elasticsearch cluster nằm trên các host khác nhau, Filebeat sẽ chịu trách
nhiệm truyền tải các alert hoặc các sự kiện hệ thống đến các Elasticsearch server bằng giao thức TLS.
Mô hình bên dưới minh họa cách các thành phần của một hệt thống Wazuh. Trong kiểu triển khai
này, các thành phần sẽ được cài đặt trên các Host riêng biệt. Kibana có thể được cài đặt trên cùng
một Host của nút Elasticsearch hoặc trên một Host riêng biệt. Kiểu triển khai này phù hợp với môi
trường sản xuất vì nó cung cấp tính khả dụng và khả năng mở rộng cao của các dịch vụ.
Hình 2.7 : Wazuh Distributed deployment
Các thành phần sẽ được cài đặt:

• Máy chủ Wazuh, bao gồm trình quản lý Wazuh dưới dạng một cụm nút đơn(single-node) hoặc
dưới dạng cụm nhiều nút(multi-node), API Wazuh và Filebeat.
• Elastic Stack, bao gồm Open Distro cho Elasticsearch dưới dạng một cụm nút đơn(single-node)
hoặc dưới dạng cụm nhiều nút(single-node) và Kibana, bao gồm cả plugin Wazuh Kibana, trên cùng
một máy chủ lưu trữ như nút Elasticsearch hoặc trên một máy chủ riêng biệt.
Đối với các triển khai Wazuh quy mô nhỏ thì chúng ta sẽ cài đặt và cấu hình Wazuh server và
Elastic Stack trên cùng một máy chủ.
13
Hình 2.8 : Wazuh All-in-one deployment
Các thành phần sau sẽ được cài đặt:

• Wazuh Server, Wazuh Manager dưới dạng một cụm nút đơn(single-node) và API Wazuh.
• Elastic Stack, bao gồm Open Distro cho Elasticsearch dưới dạng một cụm nút đơn(single-node),
Filebeat và Kibana bao gồm cả plugin Wazuh Kibana.
Về cấu hình đề nghị từ Wazuh:

• Tài nguyên cần thiết của Elasticsearch, Logstash và Kibana: 8 cores, tối thiểu cần 32GB RAM,
tối đa cho phép là 64G, dung lượng ổ cứng tối thiểu 1TB
• tài nguyên cần thiết của Wazuh Manager: 4 cores, 16GB RAM , dung lượng ổ cứng tối thiểu
1TB
2.2.3.1 Giao tiếp Agent - Server

Wazuh Agent liên tục gửi các sự kiện đến máy chủ Wazuh Server để phân tích và phát hiện mối
đe dọa. Để bắt đầu vận chuyển chúng, Agent thiết lập kết nối với dịch vụ Server để kết nối Agent,
dịch vụ này sẽ lắng nghe trên port 1514 (cổng này có thể cấu hình được). Máy chủ Wazuh sau đó giải
mã và kiểm tra rule các sự kiện đã nhận, sử dụng công cụ phân tích. Các sự kiện liên quan đến quy
tắc được tăng cường với dữ liệu cảnh báo như Rule ID và Rule name. Sự kiện có thể được lưu vào
một hoặc cả hai tệp sau, tùy thuộc vào việc quy tắc có bị chặn hay không:
• /var/ossec/logs/archives/archives.json mọi sự kiện kể cả có vi phạm rule hay không.

• /var/ossec/logs/alerts/alerts.json các sự kiện vi phạm rule.
- Alert sẽ bị lặp nếu sử dụng cả 2 file này để tạo các alert. Bên cạnh đó, cả 2 file này đều chứa các
dữ liệu đã được giải mã.
- Wazuh message protocol sử dụng mã hóa Blowfish 192-bit với đủ 16-round, hoặc mã hóa AES
128 bit mỗi block và 256-bit khóa. Có thể đọc thêm bài viết Benefits of using AES in Wazuh commu-
nications để tìm hiểu thêm chi tiết.
2.2.3.2 Giao tiếp Wazuh - Elastic

Filebeat sẽ định dạng các dữ liệu được gửi tới (có thể tùy chọn gắn thêm thông tin GeoIP) trước
khi gửi chúng đến Elasticsearch (port 9200/TCP). Một khi dữ liệu đã được index tại Elasticsearch ,
Kibana (port 5601/TCP) sẽ mining và trình bày dữ liệu ở phía front-end.
Wazuh App chạy trên Kibana sẽ thường xuyên query dữ liệu qua RESTful API (port 55000/TCP
trên Wazuh manager) để hiển thị cấu hình và các thông tin trạng thái của các server và agent và có
14
thể thực hiện các yêu cầu khởi động lại agent khi cần thiết. Giao tiếp này sẽ được mã hóa TLS và
xác thực với username và password.
2.2.4 Các port cần thiết

Để đảm bảo cho việc cài đặt Wazuh và Elastic Stack, các port sau đây sẽ được mở để đảm bảo
giao tiếp giữa các thành phần trong hệ thống Wazuh được đảm bảo:
2.2.4.1 WAZUH
Component Port Protocol Purpose
1514 TCP Nhận các sự kiện được thu thập từ agent (Khi cấu hình gửi qua TCP)
1514 UDP Nhận các sự kiện được thu thập từ agent - Mặc định
Wazuh 1515 TCP Dịch vụ đăng ký agent
Manager 1516 TCP Giao tiếp trong Wazuh cluster
514 TCP Nhận các sự kiện được thu thập từ syslog (Khi cấu hình gửi qua TCP)
514 UDP Nhận các sự kiện được thu thập từ syslog - Mặc định
Wazuh API 55000 TCP HTTP request đến Wazuh

Component Port Protocol Purpose
9200 TCP Nhận các sự Elasticsearch RESTful API
Elasticsearch
9200 - 9400 TCP Giao tiếp trong Elasticsearch cluster
Kibana 5601 TCP Giao diện web Kibana
2.2.4.3 Lưu trữ dữ liệu

Mọi sự kiện kể cả sự kiện không bị alert cũng sẽ được lưu trữ trong Wazuh server để gửi đến
Elasticsearch nếu cần. Các file lưu trữ này có thể được lưu với định dạng JSON (.json) hoặc thuần
text (.log - chưa giải mã). Các file này sẽ được nén và checksum với MD5 và SHA1 mỗi ngày. Đường
dẫn thư mục và cấu trúc tên file sẽ như sau:
/var/ossec/logs/archives/2020/Dec# ls -l
Hình 2.9 : Ouput
15
Việc luân chuyển (rotation) và backup các file này sẽ tùy thuộc vào khả năng lưu trữ củaWazuh
manager server. Mặt khác, cũng có thể lựa chọn chuyển hết mọi file dữ liệu này đến lưu trữ tại
Elasticsearch, nhất là đối với các triển khai Wazuh có Elasticsearch được cấu hình thực hiện các
snapshot cho backup định kỳ hoặc các multi-node Elasticsearch cluster với nhiều bản sao phân đoạn.
Cron job có thể được sử dụng cho việc lựa chọn các file trong một khung thời gian nhất định để
giữ lại trên Wazuh manager (chẳng hạn trong vòng vài tháng hay một năm đổ lại). Ngoài ra, cũng có
thể lên lịch với cron job để tự động chuyển các snapshot của index trong Elasticsearch đến một server
lưu trữ cuối cùng và checksum với MD5 và SHA1.
2.2.5 luật trong WAZUH

Luật (rules) là một phần vô cùng quan trọng trong hệ thống Wazuh, nó chính là cốt lõi trong việc
đảm bảo hệ thống Wazuh có được hoạt động theo quy trình, chính xác và hiệu quả hay không. Rules
có định dạng XML, được cấu hình trong Wazuh server /var/ossec/etc/ossec.conf và nằm trong thẻ
<ossec_config>. Rules được lưu trong /var/ossec/rules.
2.2.5.1 Tổ chức các luật
Hình 2.10 : Cấu trúc thư mục của Rule
2.2.5.2 Các thuộc tính của Rule

Id: bắt buộc có ( mỗi rules sẽ có 1 id riêng k trùng lặp là các số từ 100-99999, khi tạo mới thì
thường từ trên 100000)
level: bắt buộc có 16 level từ 0-15
Cấp độ Tên Chú thích
00 Ignored Không thực hiện hành động nào. Khi
gặp luật có cấp độ này thì sẽ không có
thông báo. Các luật này được quét
trước tất cả các luật khác. Chúng bao
gồm các sự kiện không có sự liên quan
về bảo mật. 252
01 None (không).
02 System low priority notification Thông báo hệ thống hoặc thông báo
(hệ thống thông báo ưu tiên trạng thái. Không có sự liên quan về
thấp): bảo mật.
16
03 Successful/Authorized events Bao gồm các lần đăng nhập thành
(sự kiện thành công/được ủy công, tường lửa cho phép sự kiện, v.v.
quyền):
04 System low priority error(lỗi ưu Các lỗi liên quan đến cấu hình hoặc
tiên hệ thống thấp): thiết bị/ứng dụng không sử
dụng.không có sự liên quan về bảo mật
và thường được gây ra bởi các cài đặt
mặc định hoặc kiểm thử phần mềm.
05 User generated error(lỗi do Chúng bao gồm mật khẩu bị bỏ lỡ,
người dùng tạo): hành động bị từ chối, v.v. Chính chúng
không có sự liên quan về bảo mật.
06 Low relevance attack (tấn công Chúng chỉ ra một con sâu hoặc virus
mức độ liên quan thấp): không ảnh hưởng đến hệ thống (như
mã màu đỏ cho các máy chủ apache,
vv). Chúng cũng bao gồm các sự kiện
IDS thường xuyên và các lỗi thường
xuyên.
07 “Bad word” matching (kết hợp Chúng bao gồm các từ như "bad",
“Từ xấu”): "error", v.v. Những sự kiện này hầu
như không được phân loại và có thể có
một số mức độ liên quan về bảo mật.
08 First time seen (lần đầu tiên Bao gồm các sự kiện lần đầu tiên được
nhìn thấy): xem. Lần đầu tiên một sự kiện IDS
được kích hoạt hoặc lần đầu tiên người
dùng đăng nhập. Nếu bạn mới bắt đầu
sử dụng OSSEC HIDS, những thông
báo này có thể sẽ thường xuyên.Sau
một thời gian sẽ giảm dần, Nó cũng
bao gồm các hành động bảo mật có
liên quan (như bắt đầu của một
sniffer).
09 Error from invalid source(lỗi từ Bao gồm các lần đăng nhập dưới dạng
nguồn không hợp lệ): người dùng không xác định hoặc từ
nguồn không hợp lệ. Có thể có sự liên
quan về bảo mật (đặc biệt nếu được
lặp lại). Chúng cũng bao gồm các lỗi
liên quan đến tài khoản "quản trị"
(root).
10 Multiple user generated errors Chúng bao gồm nhiều mật khẩu không
(tập hợp lỗi do người dùng tạo): hợp lệ, nhiều lần đăng nhập không
thành công, v.v. Họ có thể chỉ ra một
cuộc tấn công hoặc có thể chỉ là người
dùng vừa quên thông tin đăng nhập
của mình.
11 Integrity checking warning Chúng bao gồm các thông báo liên
(cảnh báo kiểm tra tính toàn quan đến việc sửa đổi các tệp nhị phân
vẹn): hoặc sự hiện diện của rootkit (bằng
kiểm tra root). Nếu bạn chỉ cần sửa
đổi cấu hình hệ thống của bạn, bạn sẽ
được báo về các thông báo "syscheck".
Nó có thể chỉ ra một cuộc tấn công
thành công. Cũng bao gồm các sự kiện
IDS sẽ bị bỏ qua (số lần lặp lại cao).
17
12 High importancy event (sự kiện Chúng bao gồm các thông báo lỗi hoặc
quan trọng cao): cảnh báo từ hệ thống, hạt nhân, v.v.
Chúng có thể chỉ ra một cuộc tấn công
chống lại một ứng dụng cụ thể.
13 Unusual error (high importance) Hầu hết các lần khớp với một kiểu tấn
- Lỗi bất thường (mức độ quan công chung.
trọng cao):
14 High importance security event Hầu hết thời gian được thực hiện với
(sự kiện bảo mật quan trọng sự tương quan và nó chỉ ra một cuộc
cao): tấn công.
15 Severe attack (tấn công nghiêm Cần chú ý ngay lập tức.
trọng):
noalert : không bắt buộc : không kích hoạt cảnh báo nếu rules hợp lệ.
Frequency: chỉ định số lần rules được kiểm tra trước khi thực hiện. Số lần kích hoạt phải gấp
đôi số lần cài đặt. Ví dụ: tần sô = 2 => rule phải được so sánh 4 lần.(từ 1- 99999)
Timeframe: khung thời gian tính bằng giây, được sử dụng để kết hợp với frequency.(1-99999)
Ignore: thời gian (s) bỏ qua rule này. ( 1-99999)
Overwrite: Cho phép chỉnh sửa rule ( overwrite= "yes or no")
Ví dụ: Rule được tạo bằng ID: 3151 và nó sẽ kích hoạt cảnh báo cấp 10 nếu Rule 3102 khớp 8 lần
trong 120 giây qua.
<rule id="3151" level="10" frequency="8" timeframe="120">
<if_matched_sid>3102</if_matched_sid>
<same_source_ip />
<description>sendmail: Sender domain has bogus MX record.</description>
<description>It should not be sending e-mail.</description>
<group>multiple_spam,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SI.4,</group>
</rule>
2.2.5.3 Phân loại luật

Trong Wazuh, luật được chia thành 2 loại: Luật nguyên tố và luật kết hợp:
• Luật nguyên tố - các luật xử lý 1 sự kiện: cảnh báo, thông báo hay hành động ứng phó sẽ xuất
hiện khi có 1 sự kiện thỏa mãn.
Ví dụ: Bao nhiêu lần đăng nhập thất bại sẽ xuất hiện bấy nhiêu lần thông báo.
<rule id="100000" level="7">
<list lookup="match_key" field="srcip">path/to/list/file</list>
<description>Checking srcip against cdb list file</description>
</rule>
• Luật kết hợp – xử lý nhiều sự kiện một lúc trong 1 luật:
Có thể sử dụng với thẻ Frequency và Timeframe để xử lý một xự kiện được diễn ra nhiều lần.
Các luật được kết hợp với nhau thông qua id, sử dụng thẻ <if_sid> hoặc (<if_matched_sid>
hoặc <same_id> hoặc <same_source_ip> - các thẻ này được kết hợp với Frequency và Timeframe).
Ví dụ: Nếu Rule khớp với ID 100102 và nhật ký chứa cụm từ Failed trong đó, Rule sẽ kích hoạt và
kích hoạt cảnh báo cấp 7. <rule id="100103" level="7">
<if_sid>100102</if_sid>
<match>F̂ailed</match>
<description>Fakeinc Custom: Failed password</description>
</rule>
2.2.6 Phương thức hoạt động của luật trong WAZUH

Như trong hình 2.10 ta thấy được cấu trúc thư mục của Rule sẽ bao gồm Decoders và rule
18
2.2.6.1 Cú pháp của Decoders
Có nhiều tùy chọn để cấu hình trong bộ giải mã:
Tùy chọn Giá trị Miêu tả

decoder Tên hoặc loại Các thuộc tính của nó sẽ được sử dụng
để xác định bộ giải mã.
parent Tên decoder bất kì Nó sẽ tham chiếu đến bộ giải mã mẹ
và bộ hiện tại sẽ trở thành bộ giải mã
con.
accumulate không có Nó cho phép theo dõi các sự kiện qua
nhiều thông báo nhật ký.
program_name tên bất kì Nó xác định tên của chương trình
được liên kết với bộ giải mã.
prematch 1 chuỗi hoặc biểu thứ Nó xác định tên của chương trình
chính quy được liên kết với bộ giải mã.
regex biểu thức chính quy bất Bộ giải mã sẽ sử dụng tùy chọn này để
kì tìm các trường quan tâm và trích xuất
chúng.
order Xem trong bảng order Các giá trị mà regex sẽ trích xuất, sẽ
được lưu trữ trong các nhóm này.
fts xem trong bảng fts Lần đầu tiên nhìn thấy
ftscomment Chuỗi bất kì thêm nhận xet vào fts
plugin_decoder Xem bên dưới Chỉ định một plugin sẽ thực hiện việc
giải mã. Hữu ích khi việc trích xuất
bằng regex không khả thi.
use_own_name True Cho phép đặt tên của bộ giải mã con
từ thuộc tính name thay vì sử dụng
tên của bộ giải mã mẹ.
json_null_field Chuỗi Thêm tùy chọn quyết định cách giá trị
null từ JSON sẽ được lưu trữ.
json_array_structure Chuỗi Thêm tùy chọn quyết định cách cấu
trúc mảng từ JSON sẽ được lưu trữ.
var Đặt tên cho biến Xác định các biến có thể được sử dụng
lại bên trong cùng một tệp.
Để hiểu sâu hơn thì các tùy chọn sẽ được giải thích rõ hơn ở bên dưới.
1: <decoder name ="..."> ... <decoder> : Đặt tên cho decoder

Ví dụ: đặt tên decoder là wazuh
<decoder name="wazuh">
...
</decoder>
2: <parent>...</parent> : Nó được sử dụng để liên kết một decoder cấp dưới với parent của nó.
Một parent decorderẹ có thể có nhiều decoder con nhưng cần lưu ý rằng một decoder con không thể
là parent decoder.
Ví dụ: Decoder_junior sẽ chỉ nhập nếu decoder_parent đã khớp trước đó. <decoder name="decoder_junior">
<parent>decoder_father</parent>
...
</decoder>
3: <program_name> biểu thức sregex bất kì </program_name> : Nó xác định tên của
program được liên kết với decoder. Tên program của nhật ký sẽ được lấy.
Ví dụ: Xác định rằng bộ giải mã có liên quan đến quá trình syslogd:
19
<decoder name="syslogd_decoder">
<program_name>syslogd</program_name>
</decoder>
4: prematch : Prematch cố gắng tìm một kết quả phù hợp trong nhật ký cho chuỗi được xác định.
Nó được sử dụng như một điều kiện để nhập,decoder nếu nó tìm thấy khớp, decoder hiện tại sẽ được
sử dụng và việc tìm kiếm decoder sẽ dừng lại và chỉ những bộ giải mã con của nó mới có thể khớp.
Điều quan trọng là phải càng cụ thể càng tốt để tránh trùng khớp với các sự kiện sai.
5: <regex>Biểu thức chính quy</regex>: Biểu thức chính quy hoặc regexlà chuỗi các ký tự
xác định một mẫu. Bộ giải mã sử dụng chúng để tìm các từ hoặc các mẫu khác vào các quy tắc. Bộ
giải mã sẽ chỉ trích xuất những trường có trong dấu ngoặc đơn.
Một ví dụ là regex này khớp với bất kỳ chữ số nào:
<regex> [+-]?(\d+(\.\d+)?|\.\d+)([eE][+-]?\d+)? </regex>
Ví dụ: Hiển thị thời điểm người dùng thực hiện lệnh sudo lần đầu tiên:
<decoder name="sudo-fields">
<parent>sudo</parent>
<prematch>\s</prematch>
<regex>ˆ \s*(\S+)\s*:</regex>
<order>srcuser</order>
<fts>name,srcuser,location</fts>
<ftscomment>First time user executed the sudo command</ftscomment>
</decoder>
6: Oder : Nó xác định những gì các nhóm ngoặc chứa và thứ tự chúng được nhận. Nó yêu cầu một
regex được xác định trên cùng một decoder.
Giá trị mặc định n/a

Trường tĩnh srcuser Trích xuất tên người dùng nguồn
dstuser Trích xuất tên người dùng đích (đích)
user Một bí danh cho dstuser (chỉ một trong hai có thể được sử
dụng)
srcip Nguồn ip
dstip Ip đích
srcport Port nguồn
dstport Port đích
protocol Giao Thức
ID ID của sự kiện
url url của sự kiện
action Hành động sự kiện (từ chối, bỏ, chấp nhận, v.v.)
status Trạng thái sự kiện (thành công, thất bại, v.v.)
extra_data Mọi dữ liệu bổ sung
Trường động Bất kỳ chuỗi nào không có trong danh sách trước đó
7: <fts>các tùy chọn trong bảng</fts>: Nó được sử dụng để chỉ định một bộ giải mã là bộ giải
mã trong đó lần đầu tiên nó khớp với quản trị viên sẽ được cảnh báo.
20
Giá trị được phép location Nhật ký đến từ đâu
srcuser Trích xuất tên người dùng nguồn
dstuser Trích xuất tên người dùng đích (đích)
user Một bí danh cho dstuser (chỉ một trong hai có thể được sử
dụng)
srcip Nguồn ip
dstip Ip đích
srcport Port nguồn
dstport Port đích
protocol Giao Thức
ID ID của sự kiện
url url của sự kiện
action Hành động sự kiện (từ chối, bỏ, chấp nhận, v.v.)
status Trạng thái sự kiện (thành công, thất bại, v.v.)
extra_data Mọi dữ liệu bổ sung
Ví dụ: Bộ giải mã sau sẽ trích xuất người dùng đã tạo cảnh báo và vị trí từ nơi nó đến:
</decoder>
<fts>srcuser, location</fts>
</decoder>
8: ftscomment: Nó thêm nhận xét vào bộ giải mã khi thẻ <fts> được sử dụng.
9: plugin_decoder: Sử dụng một bộ giải mã plugin cụ thể để giải mã các trường đến. Nó rất hữu ích
cho những trường hợp cụ thể mà việc trích xuất các trường bằng cách sử dụng regexes sẽ rất khó khăn.

Giá trị được phép PF_Decoder
SymantecWS_Decoder
SonicWall_Decoder
OSSECAlert_Decoder
JSON_Decoder
10:use_own_name: Cho phép đặt tên của bộ giải mã con từ thuộc tính name thay vì sử dụng tên
của bộ giải mã mẹ.
11:json_null_field: Chỉ định cách xử lý các trường NULL đến từ các sự kiện JSON. Chỉ dành cho
bộ giải mã JSON.
Giá trị mặc định string

Giá trị được phép string (Nó hiển thị giá trị NULL dưới dạng chuỗi)
loại bỏ (Nó loại bỏ các trường NULL và không lưu trữ
chúng vào cảnh báo)
trống (Nó hiển thị trường NULL dưới dạng trường trống)
12:json_array_ architects: Chỉ định cách xử lý các cấu trúc mảng đến từ các sự kiện JSON. Chỉ
dành cho bộ giải mã JSON.
Giá trị mặc định mảng

Giá trị được phép mảng (Nó hiển thị cấu trúc mảng dưới dạng mảng JSON)
csv (Nó hiển thị cấu trúc mảng dưới dạng chuỗi CSV)
13: var:Xác định một biến có thể được sử dụng ở bất kỳ vị trí nào của cùng một tệp.
Ví dụ :
<var name="header">myprog</var>
<var name="offset">after_parent</var>
<var name="type">syscall</var>
21
<decoder name="syscall">
<prematch>$̂header</prematch>
</decoder>
<decoder name="syscall-child">
<parent>syscall</parent>
<prematch offset="$offset">:̂ $type </prematch>
<regex offset="after_prematch">(\S+)</regex>
<order>syscall</order>
</decoder>
14: Type: Nó đặt loại nhật ký mà decoder sẽ khớp

Ví dụ: Đặt type của decoder cho nhật ký hệ thống
<decoder>
<type>syslog</type>
</decoder>
2.2.6.2 Cú pháp của Rule

Các nhãn xml được sử dụng để cấu hình rule sđược liệt kê ở đây.
Lựa chọn Giá trị Sự miêu tả
rule Xem bảng bên dưới Nó bắt đầu một quy tắc mới và các tùy chọn
xác định của nó.
match Bất kỳ sregex Nó sẽ cố gắng tìm một kết quả phù hợp
trong nhật ký, quyết định xem quy tắc có
nên được kích hoạt hay không.
regex Bất kỳ biểu thức regex Nó làm tương tự như matchnhưng trong
nào regex thay vì sregex .
decoded_as Tên người giải mã bất kỳ Nó sẽ khớp với các bản ghi đã được giải mã
bởi một bộ giải mã cụ thể
category ossec, ids, syslog, firewall, Nó sẽ phù hợp với các bản ghi có bộ giải mã
web-log, squid or windows của loại tán.
field Tên và sregex Nó sẽ so sánh một trường được trích xuất bởi
bộ giải mã theo thứ tự với một giá trị cụ thể.
srcip Bất kỳ địa chỉ IP nào Nó sẽ so sánh địa chỉ IP với IP được giải mã
dưới dạng srcip. Sử dụng "!" để phủ định nó.
dstip Bất kỳ địa chỉ IP nào Nó sẽ so sánh địa chỉ IP với IP được giải mã
dưới dạng dstip. Sử dụng "!" để phủ định nó.
extra_data Chuỗi bất kỳ Nó sẽ so sánh một chuỗi với chuỗi được giải
mã dưới dạng extra_data.
user Bất kỳ sregex Nó sẽ so sánh một sregex đại diện cho tên
người dùng với một chuỗi được giải mã dưới
dạng user.
program_name Sregex bất kỳ Nó so sánh nó với tên chương trình thu được
trong giai đoạn giải mã trước.
hostname Sregex bất kỳ Nó so sánh nó với tên máy chủ có được trong
giai đoạn giải mã trước.
time Bất kỳ phạm vi thời gian. Nó kiểm tra xem sự kiện có được tạo trong
ví dụ: (hh: mm-hh: mm) khoảng thời gian đó hay không.
weekday thứ hai - chủ nhật, các Nó kiểm tra xem sự kiện có được tạo trong
ngày trong tuần, cuối một số ngày trong tuần hay không.
tuần
id Sregex bất kỳ Nó sẽ tìm kiếm một kết quả phù hợp với
trường được giải mã là ID
22
url Sregex bất kỳ Nó sẽ tìm kiếm một kết quả phù hợp với
trường được giải mã là url
location Sregex bất kỳ Vị trí xác định nguồn gốc của đầu vào.
action Bất kỳ chuỗi nào Nó sẽ so sánh nó với trường được giải mã
dưới dạng action.
if_sid rule ID Nó hoạt động tương tự như parent decoder.
Nó sẽ khớp nếu rule ID đó đã khớp trước đó.
if_group Tên nhóm bất kỳ Nó sẽ khớp nếu nhóm được chỉ định đã khớp
trước đó.
if_level Bất kỳ cấp độ nào từ 1 Nó sẽ khớp nếu mức đó đã được kích hoạt
đến 16 bởi một quy tắc khác.
if_match_sid Bất kỳ ID quy tắc nào Tương tự như if_sid nhưng nó sẽ chỉ khớp
(Số) nếu ID đã được kích hoạt trong một khoảng
thời gian.
if_match_group Tên nhóm bất kỳ Tương tự như if_group nhưng nó sẽ chỉ khớp
nếu nhóm đã được kích hoạt trong một
khoảng thời gian.
same_id Không có ID đã giải mã phải giống nhau.
not_same_id Không có ID được giải mã phải khác nhau.
different_id Không có ID được giải mã phải khác nhau.
same_source_ip Không có Phần srcip đã giải mã phải giống nhau.
not_same_source_ip Không có Phần srcip được giải mã phải khác nhau.
same_srcip Không có Phần đã giải mã srcip phải giống nhau.
different_srcip Không có Phần srcip được giải mã phải khác nhau.
same_dstip Không có Phần dstip đã giải mã phải giống nhau.
different_dstip Không có phần dstip được giải mã phải khác nhau.
same_srcport Không có Phần srcport đã giải mã phải giống nhau.
different_srcport không có Phần srcport được giải mã phải khác.
same_dstport Không có Phần dstport đã giải mã phải giống nhau.
different_dstport Không có Phần dstport được giải mã phải khác.
same_location Không có Các location phải giống nhau.
different_location Không có Các location phải khác nhau.
same_srcuser Không có Phần srcuser đã giải mã phải giống nhau.
different_srcuser Không có Phần srcuser được giải mã phải khác.
same_user Không có Phần user đã giải mã phải giống nhau.
not_same_user Không có Phần user được giải mã phải khác.
different_user Không có Phần user được giải mã phải khác nhau.
not_same_agent Không có Người được giải mã agent phải khác.
same_field Không có Phần field được giải mã phải giống với những
phần trước.
not_same_field Không có Phần field được giải mã phải khác với những
phần trước.
different_field Không có Phần field được giải mã phải khác với những
phần trước.
same_protocol Không có protocol Phần đã giải mã phải giống nhau.
different_protocol Không có Phần protocol được giải mã phải khác nhau.
same_action Không có Phần action đã giải mã phải giống nhau.
different_action Không có Phần action được giải mã action phải khác.
same_data Không có Phần data đã giải mã phải giống nhau.
different_data Không có Phần data được giải mã phải khác.
same_extra_data Không có Phần extra_data đã giải mã phải giống
nhau.
different_extra_data Không có Phần extra_data được giải mã phải khác
nhau.
23
same_status Không có Phần status đã giải mã phải giống nhau.
different_status Không có Phần statu được giải mã phải khác nhau.
same_system_name Không có Phần system_name đã giải mã phải giống
nhau.
different_system_name Không có Phần system_name được giải mã phải khác
nhau.
same_url Không có Phần url đã giải mã phải giống nhau.
different_url Không có Phần url được giải mã phải khác.
same_srcgeoip Không có Phần srcgeoip được giải mã srcgeoip phải
giống nhau.
different_srcgeoip Không có Phần srcgeoip được giải mã phải khác.
same_dstgeoip Không có Phần dstgeoip được giải mã phải giống nhau.
different_dstgeoip Không có Phần dstgeoip được giải mã dstgeoip phải
khác.
description Chuỗi bất kì Cung cấp mô tả mà con người có thể đọc
được để giải thích mục đích của rule là gì.
Vui lòng sử dụng trường này khi tạo rule tùy
chỉnh.
list Đường dẫn đến tệp CDB Thực hiện tra cứu CDB bằng danh sách
ossec.
info Chuỗi bất kỳ Thông tin bổ sung bằng cách sử dụng các
thuộc tính nhất định.
options Xem bảng options bên Các tùy chọn quy tắc bổ sung có thể được sử
dưới dụng.
check_diff Không có Xác định khi đầu ra của một lệnh thay đổi.
group Chuỗi bất kỳ Thêm nhóm bổ sung vào cảnh báo.
status bắt đầu, hủy bỏ, thành Khai báo trạng thái hiện tại của quy tắc.
công, thất bại, mất, v.v.
mitre Xem bảng Mitre bên dưới Chứa ID kỹ thuật Mitre phù hợp với rule
var Đặt tên cho biến. Được Định nghĩa một biến có thể được sử dụng ở
sử dụng nhiều nhất: bất kỳ đâu bên trong cùng một tệp.
BAD_WORDS
Để hiểu sâu hơn thì các tùy chọn sẽ được giải thích rõ hơn ở bên dưới.
1: <rule> ... </rule>: là nhãn bắt đầu khối xác định quy tắc . Trong phần này, các tùy chọn
khác nhau cho nhãn này sẽ được giải thích ở bảng bên dưới.
Ví dụ Rule:Rule được tạo bằng ID: 3151 và nó sẽ kích hoạt cảnh báo cấp 10 nếu rule có ID là
3102 khớp 8 lần trong 120 giây qua.
<same_source_ip />
<description>sendmail: Sender domain has bogus MX record. </description>
<description>It should not be sending e-mail.</description>
<group>multiple_spam,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SI.4,</group>
</rule>
24
Định nghĩa Chỉ định cấp của quy tắc. Cảnh báo và phản
level
hồi sử dụng giá trị này.
Giá trị được phép 0 đến 16
Định nghĩa Chỉ định ID của quy tắc.
id
Giá trị được phép Bất kỳ số nào từ 1 đến 999999
Định nghĩa Chỉ định kích thước tối đa của sự kiện.
maxsize
Định nghĩa Số lần rule phải khớp trước khi kích hoạt.
frequency
Định nghĩa Khung thời gian tính bằng giây. Tùy chọn
timeframe
này được sử dụng với tùy chọn tần số.
Định nghĩa Thời gian (tính bằng giây) để bỏ qua quy tắc
ignore
này sau khi bắn nó (để tránh lũ lụt).
Định nghĩa Được sử dụng để thay thế quy tắc OSSEC
overwrite
bằng các thay đổi cục bộ.
Giá trị được phép có, không
Định nghĩa Không kích hoạt cảnh báo nếu quy tắc phù
noalert
hợp.
Giá trị được phép Thuộc tính không có giá trị
2: <match>biểu thức sregex bất kỳ</match>: Được sử dụng như một điều kiện tiên quyết
để kích hoạt quy tắc, sẽ tìm kiếm kết quả phù hợp trong sự kiện nhật ký. Ví dụ: Nếu rule khớp với id
100200 và nhật ký chứa cụm từ Queue flood! trong đó, rule sẽ kích hoạt và kích hoạt cảnh báo cấp 3.
<rule id="100001" maxsize="300" level="3">
<match>Queue flood!</match>
<description>Flooded events queue.</description>
</rule>
3: <regex> ... </regex>: Được sử dụng như một điều kiện tiên quyết để kích hoạt quy tắc, sẽ tìm
kiếm kết quả phù hợp trong sự kiện nhật ký.
Ví dụ Regex: Nếu rules khớp với id 100500 và sự kiện chứa bất kỳ IP hợp lệ nào, rules sẽ được kích
hoạt và tạo cảnh báo cấp 3.
<rule id="100001" level="3">
<regex>\d+\.\d+\.\d+\.\d+</regex>
<description>Matches any valid IP</description>
</rule>
4: <decoded_as>smtpd</decoded_as> : Được sử dụng như một điều kiện tiên quyết để kích
hoạt rule. Nó sẽ được kích hoạt nếu sự kiện đã được giải mã bởi một thứ nhất định decoder. Hữu ích
cho các quy tắc nhóm và có các quy tắc con kế thừa từ nó.
Ví dụ decoder_as: Rule sẽ được kích hoạt nếu sự kiện smtpdn được giải mã bởi decoder. Bây giờ
có thể tạo nhiều rule hơn sẽ kế thừa từ rule này, được tạo riêng cho các sự kiện OpenSMTPd.
<rule id="53500" level="0">
<decoded_as>smtpd</decoded_as>
<description>OpenSMTPd grouping.</description>
</rule>
5: <category>bất kỳ danh mục nào</category>: được sử dụng như 1 điều kiện tiên quyết
để kích hoạt quy tắc. nó sẽ được kích hoạt nếu trong decoder bao gồm các danh mục như: id,
syslog,firewall, web-log, squid, windows
Ví dụ category: rules sẽ được kích hoạt nếu sự kiện đã có syslog trong đó, nhưng nó sẽ không kích
25
hoạt cảnh báo. Thay vào đó, nó sẽ được khớp với các quy tắc khác có thể kích hoạt cảnh báo nếu cần.
<rule id="01" level="0" noalert="1">
<category>syslog</category>
<description>Generic template for all syslog rules </description>
</rule>
6: <field name="integration">virustotal</field>: Được sử dụng như một điều kiện tiên quyết
để kích hoạt quy tắc. Nó sẽ kiểm tra sự trùng khớp trong nội dung của trường được bộ giải mã trích
xuất.
Ví dụ field: Rule này, nhóm các sự kiện được giải mã từ json thuộc một tích hợp có tên là Virustotal
. Nó kiểm tra trường được giải mã như thế nào integration và nếu nội dung của nó là virustotal thì
rules sẽ được kích hoạt.
<decoded_as>json</decoded_as>
<field name="integration">virustotal</field>
<description>VirusTotal integration messages.</description>
<options>no_full_log</options>
</rule>
7: <srcip>ip bất kì</srcip>: Được sử dụng như một điều kiện tiên quyết để kích hoạt quy tắc.
Nó sẽ so sánh bất kỳ địa chỉ IP hoặc khối CIDR nào với một IP được giải mã dưới dạng srcip. Sử
dụng "!" để phủ định nó.
Ví dụ srcip: Quy tắc này sẽ kích hoạt khi chính xác đó srcip đã được giải mã.
<rule id="100105" level="8">
<if_sid>100100<if_sid>
<srcip>10.25.23.12</srcip>
<description>Forbidden srcip has been detected.</description>
</rule>
8: <dstip>ip phủ định bất kì</dstip>: Được sử dụng như một điều kiện tiên quyết để kích
hoạt quy tắc. Nó sẽ so sánh bất kỳ địa chỉ IP hoặc khối CIDR nào với một IP được giải mã dưới dạng
dstip. Sử dụng "!" để phủ định nó.
Ví dụ dstip: Rules này sẽ kích hoạt khi phát hiện một rules dstip khác 198.168.41.30
<rule id="100110" level="5">
<if_sid>100100<if_sid>
<dstip>!198.168.41.30</dstip>
<description>A different dstip has been detected </description>
</rule>
9: Data: Bất kỳ chuỗi nào được giải mã vào trường data .
10: <extra_data>chuỗi bất kỳ</extra_data>: Được sử dụng như một điều kiện tiên quyết
để kích hoạt rules. Nó sẽ so sánh bất kỳ chuỗi nào với chuỗi đã được giải mã vào trường extra_data.
Ví dụ extra_data: Rules này sẽ được kích hoạt khi nhật ký thuộc danh mục windows và field được
giải mã là Symantec AntiVirus
<category>windows</category>
<extra_data>Ŝymantec AntiVirus</extra_data>
<description>Grouping of Symantec AV rules from eventlog.</description>
</rule>
11: <user>mysql</user>:Được sử dụng như một điều kiện tiên quyết để kích hoạt rules. Nó sẽ
kiểm tra tên người dùng (được giải mã là user).
Ví dụ user: Rule này sẽ kích hoạt khi người dung mysql đăng nhập thành công vào hệ thống. Là
26
người dùng Hệ thống không bao giờ được đăng nhập vào hệ thống.
<rule id="140101" level="12">
<if_group>authentication_success</if_group>
<user>mysql</user>
<description>System user successfully logged to the system.</description>
</rule>
12: <if_group>authentication_success</if_group>: Được sử dụng như một điều kiện tiên

quyết để kích hoạt quy tắc. Đối sánh nếu nhóm đã khớp trước đó.
Ví dụ if_group: Rule phù hợp nếu nhóm sysmon_event1 đã khớp trước đó và nếu trường sys-
mon.image được giải mã là “lsm.exe”.
<rule id="184676" level="12">
<if_group>sysmon_event1</if_group>
<field name="sysmon.image">lsm.exe</field>
<description>Sysmon - Suspicious Process - lsm.exe</description>
<group>pci_dss_10.6.1,pci_dss_11.4,gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AU.6,n
</rule>
13: <hostname>yum.log$</hostname>: Được sử dụng như một điều kiện tiên quyết để kích
hoạt rule. Bất kỳ tên máy chủ nào (được giải mã là tên máy chủ nhật ký hệ thống) hoặc tệp nhật ký.
Ví dụ hostname: Rules này sẽ nhóm các rules có tên yum.log khi chúng ta Installed, Updated,
Erased 1 cái gì đó.
<hostname>yum.log$</hostname>:
<hostname>yum.log$</hostname>
<match>ˆ Installed|ˆUpdated|ˆErased</match> <description>Yum logs.</description>
</rule>
14: <time>thời gian bất ky</time>: Được sử dụng như một điều kiện tiên quyết để kích hoạt
quy tắc. Được sử dụng để kiểm tra thời gian sự kiện được tạo.
Ví dụ time: Rule này sẽ kích hoạt khi có đăng nhập thành công trong khoảng thời gian từ 6 giờ
chiều đến 8 giờ sáng.
<time>6 pm - 8:30 am</time>
<description>Successful login during non - business hours.</description>
<group>login_time,pci_dss_10.2.5,pci_dss_10.6.1,gpg13_7.1,gpg13_7.2,gdpr_IV_35.7.d,
gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_AU.6
</group>
</rule>
15: <weekday>các ngày trong tuần</weekday>:Được sử dụng như một điều kiện tiên quyết
để kích hoạt quy tắc. Kiểm tra ngày trong tuần mà sự kiện đã được tạo.
Ví dụ weekday: Rule này sẽ kích hoạt khi có đăng nhập thành công vào cuối tuần.
<weekday>weekends</weekday>
<description>Successful login during weekend.</description>
<group>login_day,pci_dss_10.2.5,pci_dss_10.6.1,gpg13_7.1,gpg13_7.2,gdpr_IV_35.7.d,gdpr_
IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_AU.6
,</group>
</rule>
16: <id>usb</id>:Được sử dụng như một điều kiện tiên quyết để kích hoạt quy tắc. Nó sẽ kiểm
tra bất kỳ ID nào (được giải mã là ID).
27
Ví dụ ID:Rule này sẽ nhóm các bản ghi có ID được giải mã là usb.
<decoded_as>kernel</decoded_as>
<id>usb</id>
<description>USB messages grouped.</description>
</rule>
17: <url>.jpg|.gif |favicon.ico|.png|robots.txt|.css|.js|.jpeg</url>Được sử dụng như một điều

kiện tiên quyết để kích hoạt quy tắc. Nó sẽ kiểm tra bất kỳ URL nào (được giải mã là URL).
Ví dụ url: Rule này là con từ quy tắc cấp 5 31101và trở thành quy tắc cấp 0 khi nó xác nhận rằng
các tiện ích mở rộng không có gì đáng lo ngại.
<url>.jpg$|.gif|f avicon.ico$|.png|robots.txt$|.css|.js|.jpeg$</url>
<compiled_rule>is_simple_http_request</compiled_rule>
<description>Ignored extensions on 400 error codes.</description>
</rule>
18: <location>biểu thức sregex bất kỳ</location>: Được sử dụng như một điều kiện tiên
quyết để kích hoạt quy tắc. Nó sẽ kiểm tra nội dung của vị trí hiện trường và cố gắng tìm một điểm
trùng khớp.
Ví dụ location :Rule này, nhóm các bản ghi đến từ osqueryvị trí. Kích hoạt cảnh báo cấp độ 3 cho nó.
<location>osquery$</location>
<description>osquery message</description>
</rule>
19: <action>chuỗi bất kỳ</action>:Được sử dụng như một điều kiện tiên quyết để kích hoạt
quy tắc. Nó sẽ kiểm tra bất kỳ hành động nào (được giải mã là HÀNH ĐỘNG).
Ví dụ action: Rule này sẽ kích hoạt cảnh báo cấp 4 khi hành động Netscreen được giải mã từ
warning
<rule id="4502" level="4"> <if_sid>4500</if_sid>
<action>warning</action>
<description>Netscreen warning message.</description>
</rule>
20: <if_sid>ip cần so sánh</if_sid>:Được sử dụng như một điều kiện tiên quyết để kích hoạt
quy tắc. Đối sánh nếu ID đã khớp trước đó. Nó tương tự như một bộ giải mã con, với điểm khác biệt
chính là các cảnh báo có thể có nhiều con cháu nếu cần, trong khi bộ giải mã không thể có “cháu”.
Ví dụ if_sid : Rule sẽ được kích hoạt nếu rule có id: 100100 đã được kích hoạt trước đó và nhật ký
chứa từ "Error".
<rule id="100110" level="5">
<match>Error</match>
<description>There is an error in the log.</description>
</rule>
21: <if_group>nhóm bất kỳ</if_group>:Được sử dụng như một điều kiện tiên quyết để kích
hoạt quy tắc. Đối sánh nếu nhóm đã khớp trước đó.
Ví dụ if_group: Rule khớp nếu nhóm sysmon_event1 đã khớp trước đó và nếu trường sysmon.image
được giải mã là “lsm.exe”.
<rule id="184676" level="12">
<if_group>sysmon_event1</if_group>
<field name="sysmon.image">lsm.exe</field>
28
<description>Sysmon - Suspicious Process - lsm.exe</description>
<group>pci_dss_10.6.1,pci_dss_11.4,gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AU.
6,nist_800_53_SI.4,</group>
</rule>
22: if_level : Đối xứng nếu cấp độ ( 1-16) đã khớp trước đó.
23: <if_matched_sid>id cần so sánh </if_matched_sid>:Đối sánh nếu một cảnh báo về ID
xác định đã được kích hoạt trong một số giây nhất định.
Tùy chọn này được sử dụng kết hợp với frequencyvà timeframe.
Ví dụ if_matched_sid: Rule được kích hoạt khi rule 30315 được kích hoạt 10 lần trong 120 giây
và nếu các yêu cầu srcip được thực hiện giống nhau .
<if_matched_sid>30315</if_matched_sid> <same_source_ip />
<description>Apache: Multiple Invalid URI requests from same source.</description>
<group>invalid_request,pci_dss_10.2.4,pci_dss_11.4,gdpr_IV_35.7.d,hipaa_164.312.b,nist_800
_53_AU.14,nist_800_53_AC.7,nist_800_53_SI.4,</group>
</rule>
24:<if_matched_group>virus</if_matched_group:>Đối xứng nếu một cảnh báo về nhóm

xác định đã được kích hoạt trong một số giây nhất định.
Ví dụ if_match_group: Rule sẽ kích hoạt khi nhóm virus được so khớp 8 lần trong 360 giây qua.
<if_matched_group>virus</if_matched_group>
<description>Multiple viruses detected - Possible outbreak.</description>
<group>virus,pci_dss_5.1,pci_dss_5.2,pci_dss_11.4,gpg13_4.2,gdpr_IV_35.7.d,nist_800
_53_SI.3,nist_800_53 _SI.4,</group>
</rule>
25:if_fts: Làm cho decoder đã xử lý sự kiện xem xét dòng fts .
26:same_id: Chỉ định rằng id được giải mã phải giống nhau. Tùy chọn này được sử dụng kết hợp
với frequency và timeframe.
27:not_same_id: Chỉ định rằng id được giải mã phải khác. Tùy chọn này được sử dụng kết hợp với
frequency và timeframe.
28:different_id: Chỉ định rằng id được giải mã phải khác. Tùy chọn này được sử dụng kết hợp với
29:same_source_ip: Chỉ định rằng ip nguồn được giải mã phải giống nhau. Tùy chọn này được sử
dụng kết hợp với frequency và timeframe.
30:not_same_source_ip: Chỉ định rằng ip nguồn được giải mã phải khác. Tùy chọn này được sử
31:same_srcip: Chỉ định rằng ip nguồn được giải mã phải giống nhau. Tùy chọn này được sử dụng
kết hợp với frequency và timeframe.
32:different_srcip: Chỉ định rằng ip nguồn được giải mã phải khác. Tùy chọn này được sử dụng kết
hợp với frequency và timeframe.
33:same_dstip: Chỉ định rằng ip đích được giải mã phải giống nhau. Tùy chọn này được sử dụng
29
34:different_dstip: Chỉ định rằng ip đích được giải mã phải khác. Tùy chọn này được sử dụng kết
35:same_srcport: Chỉ định rằng cổng nguồn được giải mã phải giống nhau. Tùy chọn này được sử
36:different_srcport: Chỉ định rằng cổng nguồn được giải mã phải khác. Tùy chọn này được sử
37:same_location: Chỉ định rằng vị trí phải giống nhau. Tùy chọn này được sử dụng kết hợp với
38:different_location: Chỉ định rằng vị trí được giải mã phải khác. Tùy chọn này được sử dụng kết
39:same_srcuser: Chỉ định rằng người dùng nguồn được giải mã phải giống nhau. Tùy chọn này
được sử dụng kết hợp với frequency và timeframe.
40:different_srcuser: Chỉ định rằng người dùng nguồn được giải mã phải khác. Tùy chọn này được
sử dụng kết hợp với frequency và timeframe.
41:same_user: Chỉ định rằng người dùng được giải mã phải giống nhau. Tùy chọn này được sử dụng
42:not_same_user: Chỉ định rằng người dùng được giải mã phải khác. Tùy chọn này được sử dụng
43:different_userChỉ định rằng người dùng được giải mã phải khác. Tùy chọn này được sử dụng
44:not_same_agent: Chỉ định rằng tác nhân được giải mã phải khác. Tùy chọn này được sử dụng
45:same_field: Giá trị của trường động được chỉ định trong tùy chọn này phải xuất hiện trong các
sự kiện trước đó một frequency số lần trong phạm vi bắt buộc timeframe.
46:not_same_field: Nó là cài đặt đối lập của same_field. Giá trị của trường động được chỉ định
trong tùy chọn này phải khác với giá trị được tìm thấy trong các sự kiện trước đó một frequency số
lần trong yêu cầu timeframe.
47:different_field: Nó là cài đặt đối lập của same_field. Giá trị của trường động được chỉ định
trong tùy chọn này phải khác với giá trị được tìm thấy trong các sự kiện trước đó một frequency số
lần trong yêu cầu timeframe.
48:global_frequency: Chỉ định rằng các sự kiện của tất cả các tác nhân sẽ được dự tính khi sử dụng
tần suất và timeframe tùy chọn. Theo mặc định, chỉ các sự kiện được tạo bởi cùng một tác nhân sẽ
được tính đến để tăng bộ đếm tần suất cho một quy tắc.
49:same_protocol: Chỉ định rằng giao thức được giải mã phải giống nhau. Tùy chọn này được sử
50:different_protocol: Chỉ định rằng giao thức được giải mã phải khác. Tùy chọn này được sử dụng
30
51:same_action: Chỉ định rằng hành động được giải mã phải giống nhau. Tùy chọn này được sử
52:different_action: Chỉ định rằng hành động được giải mã phải khác. Tùy chọn này được sử dụng
53:same_data: Chỉ định rằng dữ liệu được giải mã phải giống nhau. Tùy chọn này được sử dụng kết
54:different_data: Chỉ định rằng dữ liệu được giải mã phải khác. Tùy chọn này được sử dụng kết
55:same_extra_data: Chỉ định rằng dữ liệu bổ sung được giải mã phải giống nhau. Tùy chọn này
được sử dụng kết hợp với frequencyvà timeframe.
56:different_extra_data: Chỉ định rằng dữ liệu bổ sung được giải mã phải khác. Tùy chọn này
57:same_status: Chỉ định rằng trạng thái được giải mã phải giống nhau. Tùy chọn này được sử
58:different_status: Chỉ định rằng trạng thái được giải mã phải khác. Tùy chọn này được sử dụng
59:same_system_name: Chỉ định rằng tên hệ thống được giải mã phải giống nhau. Tùy chọn này
61:different_system_name: Chỉ định rằng tên hệ thống được giải mã phải khác. Tùy chọn này
62:same_url: CChỉ định rằng url được giải mã phải giống nhau. Tùy chọn này được sử dụng kết hợp
với frequency và timeframe.
63:different_url: Chỉ định rằng url được giải mã phải khác. Tùy chọn này được sử dụng kết hợp với
64:same_srcgeoip: Chỉ định rằng vị trí địa lý nguồn phải giống nhau. Tùy chọn này được sử dụng
65:different_srcgeoip: Chỉ định rằng vị trí địa lý nguồn phải khác. Tùy chọn này được sử dụng kết
Ví dụ different_srcgeoip: Rule đó lọc user khi cùng một tệp cố gắng mở tệp /home nhưng trả về lỗi,
trên một tệp khác ip và sử dụng cùng một tệp port.
<rule id=100005 level="0">
<match> Could not open /home </match>
<same_user />
<different_srcgeoip /> <same_dstport />
</rule>
66:same_dstgeoip: Chỉ định rằng vị trí địa lý đích phải giống nhau. Tùy chọn này được sử dụng
67:different_dstgeoip: Chỉ định rằng vị trí địa lý đích phải khác. Tùy chọn này được sử dụng kết
hợp với frequencyvà timeframe.
31
68:list: Thực hiện tra cứu CDB bằng danh sách ossec. Đây là cơ sở dữ liệu nhanh trên đĩa sẽ luôn
tìm thấy các khóa trong hai lần tìm kiếm của tệp.
Ví dụ list: Rule Sẽ tìm kiếm “Audit.key” trong danh sách CDB. Nơi nó sẽ kiểm tra xem nó có bằng
“write” hay không, trong trường hợp đó nó sẽ khớp và kích hoạt cảnh báo cấp 3.
<list field="audit.key" lookup="match_key_value" check_value="write">etc/lists/audit-
keys</list>
<description>Audit: Watch - Write access</description>
<group>audit_watch_write,gdpr_IV_30.1.g,</group>
</rule>
69:info: bổ sung có thể được thêm vào thông qua các thuộc tính text,link,cve,ovsdb:
Ví dụ info: Rule cung cấp thông tin bổ sung về mối đe dọa mà nó phát hiện.
<rule id="5714" level="14" timeframe="120" frequency="3">
<match>Local: crc32 compensation attack</match>
<description>sshd: SSH CRC-32 Compensation attack</description>
<info type="cve">2001-0144</info> <info type="link">http://www.securityfocus.com/bid/2
<group>exploit_attempt,pci_dss_11.4,pci_dss_6.2,gpg13_4.12,gdpr_IV_35.7.d,nist_800_53
</rule>
70: <options>thuộc tính</options>
Các options quy tắc bổ sung.

Thuộc tính Chú thích
alert_by_email Luôn cảnh báo qua email.
no_email_alert Không bao giờ thông báo qua email.
no_log Không ghi lại cảnh báo này.
no_full_log Không đưa full_log trường này vào cảnh báo.
no_counter Bỏ qua trường rule.firedtimes trong cảnh báo
JSON.
Ví dụ option:
<match>illegal user|invalid user</match>
<description>sshd: Attempt to login using a non-existent user</description>
<options>no_log</options>
</rule>
71: <check_diff />: Được sử dụng để xác định thời điểm đầu ra của một lệnh thay đổi.
Ví dụ check_diff:
<match>ossec: output: ’w’</match>
<check_diff />
<options>no_log</options>
<description>List of logged in users. It will not be alerted by default.</description>
</rule>
72:group: Thêm nhóm bổ sung vào cảnh báo. Nhóm là các thẻ tùy chọn được thêm vào cảnh báo.
Chúng có thể được sử dụng bởi các quy tắc khác bằng cách sử dụng if_group hoặc if_match_group
hoặc bằng các công cụ phân tích cú pháp cảnh báo để phân loại cảnh báo.
32
Nhóm là các biến xác định hành vi. Khi một cảnh báo bao gồm nhãn nhóm đó, hành vi này sẽ xảy ra.
73:status: Kiểm tra tình trạng thực tế của một sự kiện.
74:mitre: Chỉ định ID kỹ thuật MITER ATT & CK hoặc các ID phù hợp với quy tắc. 75:var: Xác
định một biến có thể được sử dụng ở bất kỳ vị trí nào của cùng một tệp. 76:BAD_WORDS: Là
một trường hợp sử dụng rất được sử dụng của <var>tùy chọn.
Nó được sử dụng để bao gồm nhiều từ trong cùng một biến. Sau đó, biến này có thể được so khớp với
bộ giải mã để kiểm tra xem có bất kỳ từ nào trong số đó nằm trong một sự kiện bị bắt hay không.
2.2.6.3 Biểu thức chính quy
Ở những phần bên trên chúng ta đã nhắc nhiều tới Regex vì vậy ở phần này em sẽ trình bày chi
tiết về Regex để mọi người có thể hiểu rõ hơn.
CÚ PHÁP REGEX Đây là một thư viện nhanh và đơn giản cho các biểu thức chính quy trong C.
Thư viện này được thiết kế đơn giản trong khi vẫn hỗ trợ các cụm từ thông dụng phổ biến nhất.
Biểu thức được hỗ trợ
Biểu thức Các ký tự hợp lệ
\w Ký tự AZ, az, 0-9, ’-’, ’’, ’0
\d 0-9 ký tự
\S Dấu cách ”“
\t Các tab
\p () * +, -.:; <=>? []! ” ’ $% & | {}
\W Bất cứ điều gì không w
\D Bất cứ điều gì không d
\S Bất cứ điều gì không s
\. Bất cứ điều gì
Bổ ngữ
Biểu thức Hành động
+ Để khớp một hoặc nhiều lần
* Để khớp với 0 hoặc nhiều lần
Ký tự đặc biệt
Biểu thức Hành động
ˆ Để chỉ định phần đầu của văn bản
$ Để chỉ định phần cuối của văn bản
k Để tạo một lôgic hoặc giữa nhiều mẫu
ký tự thoát
$ ( ) \ | <
\$  \\ \| \<
Hạn chế
• Các * và + bổ ngữ chỉ có thể được áp dụng cho các biểu thức dấu gạch chéo ngược, không phải là
các ký tự trống (ví dụ: +
. được hỗ trợ, 0+thì không)
• Bạn không thể sử dụng luân phiên trong một nhóm, ví dụ: (foo|bar)không được phép
• Tính năng theo dõi ngược phức tạp không được hỗ trợ, ví dụ:\p*\d*\s*\w*:không khớp với một
dấu hai chấm, vì \p*tiêu tốn dấu hai chấm
• .khớp với một dấu chấm theo nghĩa đen, trong khi \.khớp với bất kỳ ký tự nào
c \s chỉ khớp với khoảng trắng ASCII (32), không khớp với khoảng trắng khác như tab
• kkhông có cú pháp nào để khớp với dấu mũ, dấu hoa thị hoặc dấu cộng theo nghĩa đen (mặc dù \p
sẽ khớp với dấu hoa thị hoặc dấu cộng, cùng với một số ký tự khác)
33
2.3 Các công nghệ liên quan
2.3.1 Docker
2.3.1.1 Container
• Container: trong Linux, containers là một công nghệ ảo hóa hệ điều hành được sử dụng để đóng
gói các ứng dụng và các thành phần phụ thuộc của chúng và chạy chúng trong các môi trường biệt
lập.
• Container Image: Container images là files tĩnh xác định hệ thống file và hành vi của các cấu
hình container cụ thể. Container images được sử dụng để tạo containers.
• Container Orchestration(điều phối container): Container orchestration là một thuật ngữ được
sử dụng để mô tả các quy trình và công cụ cần thiết để quản lý các nhóm container trên nhiều máy
chủ. Container orchestration thường kiểm soát việc mở rộng quy mô, khả năng chịu lỗi, phân bổ tài
nguyên và lập lịch sử dụng nền tảng vùng chứa.
• Container Runtime(thời gian chạy container): A container runtime là thành phần thực sự
chạy và quản lý các containers trên host(máy chủ). Yêu cầu tối thiểu thường là có thể cung cấp một
container từ một image nhất định nhưng nhiều thời gian chạy gói các chức năng khác như quản lý
quy trình, giám sát và quản lý image. Docker bao gồm container runtime trong câu lệnh của docker,
nhưng có nhiều lựa chọn thay thế khác có sẵn cho các trường hợp sử dụng khác nhau.
• Docker: Docker was the first technology to successfully popularize the idea Linux containers. Among
others, Docker’s ecosystem of tools includes docker, a container runtime with extensive container and
image management features, docker-compose, a system for defining and running multi-container ap-
plications, and Docker Hub, a container image registry.
• Dockerfile: A Dockerfile là một tệp văn bản mô tả cách tạo một container image. Nó xác định hình
ảnh cơ sở, các lệnh để chạy trong hệ thống và cách thời gian chạy sẽ bắt đầu và quản lý các quy trình
trong container. Mặc dù không phải là tùy chọn duy nhất, Dockerfiles là định dạng phổ biến nhất để
xác định container images, ngay cả khi không sử dụng chức năng xây dựng images của Docker.
• Kata Containers: à một cách tiếp cận để quản lý các máy ảo nhẹ bằng cách sử dụng các mô hình,
quy trình làm việc và công cụ tái tạo trải nghiệm làm việc với container. Vùng chứa Kata tìm cách
nắm bắt lợi ích của containers rong khi cung cấp khả năng cách ly và bảo mật mạnh mẽ hơn.
• Kubernetes: Kubernetes là một nền tảng điều phối container orchestration mạnh mẽ quản lý các
cụm máy chủ container hosts và khối lượng công việc chạy trên chúng. Kubernetes cung cấp công cụ
và tóm tắt để triển khai, mở rộng quy mô, giám sát và quản lý các thùng chứa trong môi trường sản
xuất có tính khả dụng cao.
• Linux cgroups: Linux cgroups, or control groups, là một tính năng hạt nhân gói các quy trình lại
với nhau và xác định quyền truy cập của chúng vào tài nguyên. Containers in Linux được triển khai
bằng cách sử dụng cgroups để quản lý tài nguyên và các quy trình riêng biệt.
• Linux namespaces: Linux namespaces là một tính năng hạt nhân được thiết kế để giới hạn khả
năng hiển thị của một tiến trình hoặc cgroup đối với phần còn lại của hệ thống. Containers in Linux
sử dụng không gian tên để giúp cô lập khối lượng công việc và tài nguyên của chúng khỏi các quy
trình khác đang chạy trên hệ thống.
• LXC: LXC là một dạng Linux có trước Docker và nhiều công nghệ khác trong khi dựa trên nhiều
công nghệ nhân giống nhau. So với Docker, LXC thường ảo hóa toàn bộ hệ điều hành hơn là chỉ các
quy trình cần thiết để chạy một ứng dụng, điều này có vẻ giống với một máy ảo hơn.
• Virtual Machines: Virtual machines, or VMs, à một công nghệ ảo hóa phần cứng mô phỏng một
máy tính hoàn chỉnh. Một hệ điều hành đầy đủ được cài đặt trong máy ảo để quản lý các thành phần
bên trong và truy cập tài nguyên máy tính của máy ảo.
• Virtualization: Virtualization à một quá trình tạo, chạy và quản lý môi trường ảo hoặc tài nguyên
máy tính. Ảo hóa là một cách trừu tượng hóa các tài nguyên vật lý và thường được sử dụng để phân
đoạn một nhóm tài nguyên cho các mục đích khác nhau.
34
2.3.1.2 Container Image
• Container Images: Container images là các gói tệp tĩnh đại diện cho mọi thứ trong container
runtime như Docker , cần để chạy container, images bao gồm bố cục hệ thống tệp, tất cả các ứng
dụng và phụ thuộc được yêu cầu cũng như cấu hình.
Mỗi images được tạo ra từ images gốc hoặc từ một pseudo-image được gọi scratch. Hầu hết các
images gốc thường cung cấp cấu trúc hệ thống tệp giống như một hệ thống Linux tối thiểu, các công
cụ quản lý gói và chức năng cốt lõi mà bạn mong đợi từ môi trường dòng lệnh. images gốc có sẵn cho
hầu hết các bản phân phối Linux phổ biến, thường có nhiều cấu hình khác nhau. images cũng có sẵn
được cấu hình sẵn cho các ngôn ngữ lập trình và hệ sinh thái khác nhau.
Container images được xây dựng bằng cách áp dụng "lớp" lên các images trước đó. Mỗi lớp hệ
thống tệp đại diện cho một bản ghi tại thời điểm của trạng thái hệ thống tệp sau một số hành động
nhất định. images có tổ tiên chung chia sẻ các lớp hệ thống tệp, cho phép giảm chi phí và tính nhất
quán cao hơn giữa các hình ảnh.
Dockerfiles: Trong hầu hết các tình huống thực tế, bạn nên tạo images từ một Dockerfile. Một Dock-
erfile là một tệp văn bản thuần túy chứa các hướng dẫn cho công cụ xây dựng Docker cách images.
Các trách nhiệm chính của một Dockerfilebao gồm:
• Chi tiết images gốc hoặc trạng thái ban đầu mà images sẽ bắt đầu từ đó
• Cung cấp siêu dữ liệu về tác giả và thuộc tính images
• Phác thảo các lệnh chính xác để chạy trong quá trình xây dựng
• Chỉ định điều kiện thời gian chạy cho các container được tạo từ images
Docker Networking Types

• Host networking: container chia sẻ cùng một địa chỉ IP và không gian tên mạng như của máy
chủ. Các dịch vụ chạy bên trong container này có khả năng mạng giống như các dịch vụ chạy trực
tiếp trên máy chủ.
• Bridge networking: The container chạy trong một mạng riêng bên trong máy chủ. Giao tiếp với
các containers khác trong mạng đang mở. Giao tiếp với các dịch vụ bên ngoài máy chủ thông qua bản
dịch địa chỉ mạng (NAT) trước khi thoát khỏi máy chủ. Đây là chế độ mạng mặc định khi –net tùy
chọn không được chỉ định
• Custom bridge networking: Điều này cũng giống như mạng cầu nối nhưng sử dụng một cầu nối
được cho containersày (và các vùng chứa khác). Ví dụ về cách sử dụng điều này sẽ là một container
chạy trên mạng cầu nối "cơ sở dữ liệu" đặc biệt. Một container khác có thể có giao diện trên cầu nối
mặc định và trên cầu cơ sở dữ liệu, cho phép nó giao tiếp với cả hai mạng khi cần thiết.
• No networking: Disables networking for the container.
Kết nối trong container
Hình 2.11: Kết nối giữa hai container
35
Trong sơ đồ trên, hai container chạy trên cùng một máy chủ được kết nối qua docker0 cây cầu.
Nếu 172.17.0.6(bên tay trái) muốn gửi một yêu cầu đến 172.17.0.7(bên tay phải), các gói tin sẽ di
chuyển như sau:
1. Một gói tin rời khỏi container eth0 và đến vethxxx_interface tương ứng .
2. Các vethxxx_interface được kết nối với vethyyy_interface thông qua docker0 bridge .
3. docker0 bridge nối chuyển tiếp gói tin tới vethyyy_interface
4. Gói tin di chuyển đến eth0 interface bên trong container đích.
2.3.1.3 Lưu trữ dữ liệu trên container

Hiện nay có nhiều cách để lưu trữ dữ liệu trên container. Một trong những cách đơn giản nhất là
lưu trữ dữ liệu trực tiếp lên container (container layer ). Tuy nhiên, cách lưu trữ trực tiếp này có rất
nhiều khuyết điểm như:
• Dữ liệu sẽ mất khi container đó không còn chạy nữa, khó truy xuất dữ liệu nếu một container khác
hoặc process khác cần dữ liệu này.
• Container layer được gắn chặt với máy host khi container đang chạy. Khó di chuyển dữ liệu được
lưu trên container layer.
• Ghi dữ liệu trên container layer cần phải đi qua 1 lớp storage driver => overhead => giảm hiệu
năng ghi dữ liệu so với data volume (ghi trực tiếp lên host filesystem). Ta có 3 cách để lưu trữ dữ liệu
của Docker container là: volume, bind mount và tmpfs volume. Mặc định thì volume thường là lựa
chọn tốt nhất.
Hình 2.12: Ba cách lưu trữ container
• Dữ liệu trên volume được lưu trên filesystem của Docker host (/var/lib/docker/volumes/) và được
quản lý bởi Docker deamon. Các process không liên quan đến Docker sẽ không đụng đến phần dữ liệu
này. Volumes là cách lưu trữ dữ liệu tốt nhất trên Docker.
• Bind mount có thể được lưu ở bất cứ đâu trên máy host. Các process không liên quan đến Docker
hoặc một container khác có thể chỉnh sửa các file này bất kỳ lúc nào.
• Tmpfs mound được lưu trên bộ nhớ (RAM) của máy host và không ghi lên trên host filesystem
(không ghi lên disk).
2.3.1.4 Lưu trữ trên Docker

Thông tin chi tiết về các loại mount:
Volume: Được khởi tạo và quản lý bởi Docker. Ta có thể khởi tạo một volume bằng cách sử dụng
lệnh docker volume create hoặc tạo volume khi khởi tạo container/service.
Khi ta khởi tạo một volume, volume này sẽ nằm trong một thư mục trên Docker host. Khi ta mount
volume này lên container tức là ta mount thư mục đó lên container. Cách thức hoạt động của volume
tương tự như bind mount, ngoại trừ việc volume được quản lý bởi Docker và được phân tách (isolate)
36
khỏi máy host.
Hình 2.13: Cách dữ liệu lưu trữ trên Docker
Dữ liệu trong volume được lưu trữ bên ngoài các container, lưu trên Docker host Một volume có
thể được mount lên nhiều container cùng một lúc. Khi không có container nào sử dụng volume đó,
volume này vẫn tồn tại và được quản lý bởi Docker mà không bị xóa đi như container layer. Ta có
thể xóa các volume không sử dụng bằng cách dùng lệnh docker volume prune.
Ta có thể đặt tên cho một volume, nếu ta không đặt tên thì Docker sẽ tự động đặt tên cho volume
đó và tên này là duy nhất trên một Docker host.
Volume trên Docker hỗ trợ dùng nhiều loại volume drivers, cho phép lưu trữ dữ liệu trên remote host
hoặc trên hạ tầng lưu trữ của các nhà cung cấp dịch vụ cloud.
Bind mounts: Có từ thời xửa thời xưa khi Docker mới ra đời. So với volume thì bind mount có ít
chức năng hơn. Khi ta dùng bind mount, ta có thể mount 1 file hoặc một thư mục lên container. File
hoặc thư mục này được truy cập theo đường dẫn tuyệt đối trên máy host. Bind mount có hiệu năng
truy xuất rất cao, nhưng phụ thuộc vào file system của máy host.
Chú ý: khi dùng bind mount, các process trong container có thể thay đổi filesystem của máy host
(tạo file, thêm xóa sửa các dữ liệu hoặc thư mục quan trọng của hệ thống). Tính năng này tuy mạnh
nhưng có thể tạo ra nhiều nguy cơ về bảo mật, gây ảnh hưởng tới các process khác trên máy host.
Tmpfs mounts: tmpfs mount không được lưu trên đĩa cứng. tmpfs mount thường được dùng để lưu
dữ liệu khi container đang chạy (dữ liệu này không cần được lưu trữ lâu dài).
Khi nào nên dùng volume
Volume là cách thường được dùng khi cần lưu trữ dữ liệu lâu dài trong container và services. Một số
ứng dụng của volumes gồm:
• Chia sẻ dữ liệu giữa nhiều container đang chạy cùng lúc. Nhiều container có thể đồng thời mount
cùng 1 volume. (read-write hoặc read only). Volume không tự động xóa đi, ta cần phải gõ lệnh nếu
muốn xóa volume.
37
• Khi ta muốn lưu trữ dữ liệu của container trên remote host hoặc trên cloud provider (AWS, GCE,
Azure. . . ).
• Hoạt động được trên cả Linux và Windows container.
• Dữ liệu được lưu trên volume sẽ không làm tăng kích thước của container.
• Khi ta cần backup, phục hồi hoặc di chuyển dữ liệu từ mọt Docker host này sang một host khác,
volume là sự lựa chọn lý tưởng trong những trường hợp này. Ta có thể tạm dừng một container,
backup volume của container này (thường nằm trong /var/lib/docker/volumes/<volume-name>)
Khi nào nên dùng bind mount
Bind mount thích hợp trong những trường hợp sau:
• Chia sẻ các file cấu hình từ máy host sang container. Ví dụ: bind mount file /etc/resolv.conf từ máy
host lên mỗi container.
• Chia sẻ source code từ Docker host sang container.
• Khi file container cần file và thư mục phải đồng bộ với Docker host. Khi nào nên dùng tmpfs
mount
tmpfs mount được dùng khi ta không muốn lưu dữ liệu lâu dài trên cả máy host hoặc trong container
vì lý do an ninh. Hoặc do ta muốn đảm bảo hiệu năng của container khi cần xử lý một lượng lớn dữ
liệu tạm thời.
Một số chú ý khi dùng bind mount hoặc volume
Khi dùng bind mount hoặc volume thì cần chú ý những điều sau:
• Nếu ta mount một volume trống từ lên container, và trong thư mục tương ứng trên container đã có
sẵn dữ liệu thì các file trên đó sẽ được copy vào volume. Tương tự vậy, nếu ta khởi động một container
và yêu cầu một volume (volume này chưa tồn tại), Docker engine sẽ tạo ra một volume trống cho ta.
• Nếu ta mount một bind mount hoặc một volume đẫ có dữ liệu vào một thư mục trên container
và thư mục này cũng đã có dữ liệu, dữ liệu trên container sẽ bị “tạm thời thay thế” bởi dữ liệu mới
mount. Khi ta unmount thì dữ liệu này sẽ hiện ra như cũ.
• Khi ta dùng cờ -v hoặc –volume để bind-mount một file hay thư mục chưa tồn tại trên Docker host
thì Docker sẽ tạo ra một thư mục mới.
• Nếu ta dùng cờ –mount để bind-mount một file hay thư mục chưa tồn tại trên Docker host thì
Docker không tự động tạo thư mục mới mà sẽ thông báo lỗi.
38
Chương 3
XÂY DỰNG HỆ THỐNG
3.1 triển khai Wazuh trên Docker

Tài nguyên hiện có :
1 máy ảo ubuntu server: CPU 8 cores , 8GB RAM , 40GB HHD
1 máy ảo ubuntu server: CPU 4 cores , 4GB RAM , 20GB HHD
1 máy ảo centOS server: CPU 4 cores , 4GB RAM , 20GB HHD
3.1.1 Cài đặt Docker

Docker engine
Docker yêu cầu hệ điều hành 64-bit chạy phiên bản hạt nhân 3.10 trở lên.
1. Kiểm tra phiên bản hạt nhân hiện tại của bạn. Mở một thiết bị đầu cuối và sử dụng để hiển thị
phiên bản hạt nhân của bạn :
uname -r
2. Chạy tập lệnh cài đặt Docker.
curl -sSL https://get.docker.com/ | sh
3. Bắt đầu dịch vụ Docker:
systemctl start docker
Docker compose
Docker Compose 1.6 hoặc mới hơn là bắt buộc. Làm theo các bước sau để cài đặt nó:
1. Tải xuống tệp nhị phân Docker Compose:
curl -L "https://github.com/docker/compose/releases/download/1.27.4/docker-compose-
(uname − s)−(uname -m)" -o /usr/local/bin/docker-compose
2. Cấp quyền thực thi:
chmod +x /usr/local/bin/docker-compose
3. Kiểm tra cài đặt để đảm bảo mọi thứ diễn ra bình thường:
docker-compose –version
3.2 Cài đặt Wazuh Docker

Yêu cầu
Bộ nhớ vùng chứa
Bạn nên đặt tùy chọn máy chủ lưu trữ Docker để cung cấp bộ nhớ ít nhất 6GB cho máy chủ đã tạo
vùng chứa (điều này không nhất thiết có nghĩa là tất cả chúng đều sẽ sử dụng nó, nhưng Elasticsearch
yêu cầu chúng hoạt động bình thường).
Tăng max_map_count trên máy chủ của bạn (Linux)
39
1. Bạn cần tăng max_map_counttrên máy chủ Docker của mình:
sysctl -w vm.max_map_count=262144
2. Để đặt giá trị này vĩnh viễn, hãy cập nhật cài đặt vm.max_map_count trong /etc/sysctl.conf. Để
xác minh sau khi khởi động lại, hãy chạy “sysctl vm.max_map_count”. Triển khai
1. Sao chép kho lưu trữ Wazuh vào hệ thống của bạn:
git clone https://github.com/wazuh/wazuh-docker.git -b v4.0.4_1.11.0 –depth=1
Chúng tôi sẽ sử dụng production-cluster.ymllàm cơ sở cho việc triển khai này, tất cả các đoạn mã
trên phần này đều đến từ tệp này.
2. Bảo mật lưu lượng truy cập bằng cách thay thế chứng chỉ demo
2.1 Tạo chứng chỉ cho mỗi nút của cụm
Chúng tôi đã tạo hình ảnh Docker để tự động tạo chứng chỉ bằng Công cụ TLS SearchGuard , sửa
đổi tệp ssl_certs/certs.ymlvà thực thi lệnh sau để có được chứng chỉ mong muốn:
docker-compose -f generate-opendistro-certs.yml run –rm generator
tác này sẽ lưu các chứng chỉ vào thư mục ssl_certs cũng như các đoạn mã cấu hình cho từng nút.
2.2 Thiết lập chứng chỉ SSL cho Elasticsearch trên thư mục ssl_certs . Kiểm tra phần Docker Security
từ tài liệu Open Distro.
- ./ssl_certs/root-ca.pem:/usr/share/elasticsearch/config/root-ca.pem
- ./ssl_certs/node.key:/usr/share/elasticsearch/node.key
- ./ssl_certs/node.pem:/usr/share/elasticsearch/node.pem
- ./elastic_opendistro/custom-elasticsearch.yml::/usr/share/elasticsearch/elasticsearch.yml
- ./elastic_opendistro/internal_users.yml:/usr/share/elasticsearch/internal_users.yml
2.3 Sử dụng mật khẩu an toàn cho người dùng quản trị trên Elasticsearch
Bạn hoàn toàn có quyền tự do tùy chỉnh người dùng trên vùng chứa Elasticsearch bằng cách gắn kết
của riêng bạn internal_users.yml:
-./elastic_opendistro/internal_users.yml:/usr/share/ elasticsearch/plugins/opendistro_security\se
Có thể tạo một hàm băm bằng cách sử dụng cùng một hình ảnh Docker, nhập bất kỳ mật khẩu nào
khi được nhắc và thay thế hàm băm trên internal_users.yml:
docker run –rm -ti amazon/opendistro-for-elasticsearch:1.11.0 bash /usr/share/elasticsearch/plugins/
2.4 Thiết lập chứng chỉ SSL cho filebeat trên vùng chứa Wazuh
environment:
- FILEBEAT_SSL_VERIFICATION_MODE=full - SSL_AUTHORITIES=/etc/filebeat/
root-ca.pem
- SSL_CERTIFICATE=/ etc/filebeat/filebeat.pem
- SSL_KEY=/etc/filebeat/filebeat.key
volumes:
- ./ssl_certs/root-ca.pem:/ etc/filebeat/root-ca.pem
- ./ssl_certs/filebeat.pem:/etc/filebeat/filebeat.pem
- ./ssl_certs/filebeat.key:/etc/filebeat/ filebeat.key
2.5 Thiết lập chứng chỉ SSL cho Kibana

Sao chép chứng chỉ của riêng bạn vào kibana_od_sslthư mục và đặt SERVER_SSL_ENABLEDthành
true :
environment:
- SERVER_SSL_ENABLED=true
- SERVER_SSL_CERTIFICATE=/usr/share/kibana/config/ash cert.pem
- SERVER_SSL_KEY=/usr/share/kibana/config/key.pem
volumes:
- ./production_cluster/kibana_ssl/cert.pem:/usr/share/kibana/config/cert.pem
- ./ production_cluster/usr/share/kibana/config/key.pem
40
2.5 Thiết lập SSL trên bộ cân bằng tải Nginx
Chứng chỉ SSL cho Nginx nên được đặt ở ./production_cluster/ nginx/ssl/, cert.pemvà key.pem, đây
là tùy vào file cấu hình nginx tại ./production_cluster/nginx/nginx.conf.
nginx:
...
volumes:
- ./production_cluster/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
- ./production_cluster/nginx/ssl:/etc/nginx/ssl:ro
3.Start Wazuh and Elastic Stack using docker-compose:

docker-compose -f production-cluster.yml up
3.3 Các tiện ích của Wazuh Docker

1. Bạn có thể truy cập giao diện người dùng Kibana tại địa chỉ IP của máy chủ Docker, ví dụ:
https: //localhost nếu bạn đang ở trong máy chủ Docker.
2.Các đại lý có thể được đăng ký bằng cách tuân theo quy trình đăng ký tiêu chuẩn và sử dụng địa
chỉ của máy chủ Docker làm địa chỉ của người quản lý. Để biết thêm thông tin, hãy xem: Đăng ký đại lý
3.Chúng ta có thể liệt kê các vùng chứa mà chúng ta đã tạo bằng cách thực thi docker-compile ps
trong thư mục chứa docker-compose.ymltệp:
docker-compose ps
Hình 3.1: Output

4.Chúng ta có thể truy cập dòng lệnh của mỗi vùng chứa bằng cách thực thi docker-compile exe-
cute <tên dịch vụ> / bin / bash từ thư mục chứa docker-compose.ymltệp:
docker-compose exec <service name> /bin/bash
Trong trường hợp là tên của mỗi dịch vụ trong tập tin. Theo mặc định (trong triển khai demo của
chúng tôi):service namedocker-compose.yml
•wazuh
41
•elasticsearch
•kibana
Wazuh service data volumes Các tệp nhật ký và cấu hình wazuh có thể được định cấu hình để
tồn tại bên ngoài vùng chứa của chúng. Điều này sẽ cho phép các tệp này tồn tại sau khi vùng chứa
được xóa và cung cấp tệp cấu hình tùy chỉnh cho vùng chứa của bạn.
Cần phải có nhiều khối lượng để đảm bảo tính ổn định trên một vùng chứa Wazuh, sau đây là ví dụ
về a docker-compose.ymlvới những vùng được xác định:
services:
wazuh:
volumes:
- ossec_api_configuration:/var/ossec/api/configuration
- ossec_etc:/var/ossec/etc
- ossec_logs:/var/ossec/logs
- ossec_queue:/var/ossec/queue
- ossec_var_multigroups:/var/ossec/var/multigroups
- ossec_integrations:/var/ossec/integrations
- ossec_active_response:/var/ossec/active-response/bin
- ossec_agentless:/var/ossec/agentless
- ossec_wodles:/var/ossec/wodles
- filebeat_etc:/etc/filebeat
- filebeat_var:/var/lib/filebeat
volumes:
ossec_api_configuration:
ossec_etc:
ossec_logs:
ossec_queue:
ossec_var_multigroups:
ossec_integrations:
ossec_active_response:
ossec_agentless:
ossec_wodles:
filebeat_etc:
filebeat_var:
Những tập này có thể được liệt kê với :docker volume ls
Hình 3.2: Output
42
Các lệnh và tập lệnh tùy chỉnh
Để thực hiện các lệnh trong vùng chứa trình quản lý Wazuh, bạn có thể thực thi một trình bao:
docker run -it wazuh-opendistro bash
Hãy nhớ rằng bất kỳ thay đổi nào được thực hiện trên trình bao này sẽ vẫn tồn tại miễn là bạn đã
định cấu hình đúng khối lượng dữ liệu.
43
Chương 4
TRÌNH BÀY, ĐÁNH GIÁ VỀ

KẾT QUẢ
4.1 File integrity monitoring

Hệ thống giám sát toàn vẹn tệp (FIM) của Wazuh theo dõi các tệp đã chọn và kích hoạt cảnh
báo khi các tệp này được sửa đổi. Thành phần chịu trách nhiệm cho nhiệm vụ này được gọi syscheck.
Thành phần này lưu trữ tổng kiểm tra mật mã và các thuộc tính khác của một tệp tốt đã biết hoặc
khóa đăng ký Windows và thường xuyên so sánh nó với tệp hiện tại đang được hệ thống sử dụng,
theo dõi các thay đổi.
4.1.1 Cách thức hoạt động
Hình 4.1: Mô hình FIM
Mô-đun FIM nằm trong tác nhân Wazuh, nơi chạy quét định kỳ hệ thống và lưu trữ tổng kiểm tra
và thuộc tính của các tệp được giám sát và khóa đăng ký Windows trong cơ sở dữ liệu FIM cục bộ.
Mô-đun tìm kiếm các sửa đổi bằng cách so sánh tổng kiểm tra của tệp mới với tổng kiểm tra cũ. Tất
cả các thay đổi được phát hiện đều được báo cáo cho người quản lý Wazuh.
44
Cơ chế đồng bộ hóa FIM mới đảm bảo kho tệp trong trình quản lý Wazuh luôn được cập nhật
đối với tác nhân Wazuh, cho phép xử lý các truy vấn API liên quan đến FIM liên quan đến tác nhân
Wazuh. Đồng bộ hóa FIM dựa trên các tính toán định kỳ về tính toàn vẹn giữa cơ sở dữ liệu của
tác nhân Wazuh và cơ sở dữ liệu của người quản lý Wazuh, chỉ cập nhật trong trình quản lý Wazuh
những tệp đã lỗi thời, tối ưu hóa việc truyền dữ liệu của FIM. Bất cứ khi nào các sửa đổi được phát
hiện trong các tệp được giám sát và / hoặc khóa đăng ký, một cảnh báo sẽ được tạo.
4.1.2 Cấu hình

1. tạo container docker run –name Ubuntu_2 -it ubuntu
Dùng lệnh kiểm tra các container đã tạo: docker container ls -a
Hình 4.2: Tạo Container và update
2. Tìm nơi lưu các container /var/lib/docker/containers/
Hình 4.3: Nơi lưu trữ Container
Giá trị đầu của tên file container sẽ trùng với giá trị cột container ID khi chúng ta gõ lệnh docker
container ls -a
45
Hình 4.4: Container ID
Để cấu hình kiểm tra hệ thống, danh sách các tệp và thư mục phải được xác định. Các check_all
thuộc tính của thư mục tùy chọn cho phép kiểm tra các kích thước tập tin, quyền, chủ sở hữu, ngày
sửa đổi cuối cùng, inode và tất cả các khoản tiền băm (MD5, SHA1 và SHA256). Theo mặc định,
syscheck quét các thư mục được chọn, danh sách của chúng phụ thuộc vào cấu hình mặc định cho hệ
điều hành của máy chủ.
Hình 4.5: ossec.conf
Thực hiện lệnh docker exec -it <container id> bash để thực hiện các dòng lệnh bên trog
ubuntu.
Ta kiểm tra các log đã thu thập được trong file <container id.log>:
Hình 4.6: File
46
Hình 4.7: Kiểm tra Log
Thay đổi file trong container
Kiểm tra log đã gửi về ELK
Hình 4.8: Kiểm tra database
47
Ví dụ: cài thêm gói fish cho ubuntu
Hình 4.9: Cài gói Fish
Kết quả bên database
Hình 4.10: Kết quả
Xóa gói fish
Hình 4.11: Ví dụ
48
Kết quả bên database
4.2 Active Response

Các phản ứng tích cực thực hiện các biện pháp đối phó khác nhau để giải quyết các mối đe dọa
đang hoạt động, chẳng hạn như chặn quyền truy cập vào tác nhân từ nguồn mối đe dọa khi đáp ứng
các tiêu chí nhất định.
Các phản hồi tích cực thực thi một tập lệnh để phản hồi lại việc kích hoạt các cảnh báo cụ thể
dựa trên mức cảnh báo hoặc nhóm quy tắc. Bất kỳ số lượng tập lệnh nào cũng có thể được khởi tạo
để phản hồi lại trình kích hoạt, tuy nhiên, những phản hồi này cần được xem xét cẩn thận. Việc thực
hiện không tốt các quy tắc và phản hồi có thể làm tăng tính dễ bị tổn thương của hệ thống.
4.2.1 Cách thức hoạt động
Hình 4.13: Mô hình Active Response
49
Wazuh cung cấp một mô-đun phản hồi tích cực để xử lý phản hồi tự động đối với các cảnh báo
cụ thể mà bạn định cấu hình trên Wazuh-manager.
Active Response là một tập lệnh được định cấu hình để thực thi khi một cảnh báo, mức cảnh báo
hoặc nhóm quy tắc cụ thể đã được kích hoạt. Active Response là phản hồi có trạng thái hoặc không
trạng thái. Phản hồi trạng thái được định cấu hình để hoàn tác hành động sau một khoảng thời gian
cụ thể trong khi phản hồi không trạng thái được định cấu hình thành hành động một lần.
4.2.2 Cấu hình

Điều hướng tới thư mục ossec.conf trong docker
Hình 4.14: Cấu hình ossec.conf manager
Chúng ta sẽ sử dụng tập lệnh firewall-drop.sh để cấu hình chúng sẽ hoạt động với các hệ điều hành
Linux / Unix phổ biến và nó cho phép chặn IP độc hại bằng cách sử dụng tường lửa cục bộ.
Command:
<!–active response -»
<command>
<name>firewall-drop</command>
<executable>firewall-drop.sh</executable>
<expect>srcip</expect>
<timeout_allowed>yes</timeout_allowed>
</command>
Active response:
<active-response>
<command>firewall-drop</command>
<location>local</location>
<timeout>5712</timeout>
<timeout>60</timeout>
</active-response>
- command : Lệnh đã được xác định trước đó (firewall-drop).
- location : Nơi lệnh sẽ được thực hiện. Chúng tôi muốn thực thi nó trên đại lý đã báo cáo sự kiện.
Vì vậy, chúng tôi sử dụng local.
- rules_id : Lệnh được thực thi nếu quy tắc 5712 được kích hoạt.
- timeout : Chặn IP trong 60 giây trên tường lửa (iptables, ipfilter, v.v.)
50
Sau đó ta khởi động lại wazuh-manager bằng lệnh như dưới hình.
Hình 4.16: Restart
51
Bây giờ trên máy chủ wazuh-agent, chúng ta sửa đổi tệp ossec.conf và thêm:
Hình 4.17: Cấu hình ossec.conf Agent
<active-response>
<disabled> no </disabled>
</active-response>
Hình 4.18: Cấu hình ossec.conf Agent
Sau khi cấu hình ta đăng nhập lại vào IP: 10.102.196.217 thì thấy rằng trang web đã bị từ chối.
52
Hình 4.19: Kiểm tra
Sau khi đợi 1 lúc thì đã vào được web tuy nhiên như dưới hình ta thấy các Agent đã bị từ chối.
Ta vào lại file ossec.conf tắt các cấu hình ta vừa thêm vào như dưới hình
53
Sau khi restart lại wazuh-manager thì các agent đã kết nối lại được với server như bình thường.
54
4.3 Auditing who-data
Từ phiên bản 3.4.0, Wazuh kết hợp một chức năng mới lấy thông tin dữ liệu ai từ các tệp được
giám sát.
Thông tin này bao gồm người dùng đã thực hiện các thay đổi trên các tệp được giám sát và cả
tên chương trình hoặc quy trình được sử dụng để thực hiện chúng.
4.3.1 Auditing who-data trong Linux

Chức năng giám sát dữ liệu ai sử dụng hệ thống con Kiểm toán Linux để lấy thông tin về người
đã thực hiện các thay đổi trong thư mục được giám sát. Những thay đổi này tạo ra các sự kiện kiểm
toán được xử lý bằng syscheck và báo cáo cho người quản lý.
4.3.2 Cấu hình

Mục tiêu: dùng user agent_1 (có quyền sudo) thực hiện các lệnh liên quan đến container xem
whodata hoạt động được không
Hình 4.23: Thay đổi file ossec.conf
Cài đặt audit bằng câu lệnh: apt install auditd

Dùng user agent_1 kiểm tra các container đang có, thực thi 1 vài dòng lệnh trong container ubuntu_1
Hình 4.24: Cài dặt audit
55
-> Kết Quả: bên dashboard wazuh không có xuất hiện sự kiện nào cả
- Thực hiện tiếp, thử tạo 1 container mới:
Hình 4.25: Tạo container mới
-> Kết Quả:Không tìm thấy file
Hình 4.26: Log
Kiểm tra nội dung bên trong, ta được:

{ "syscheck": { "uname_after": "root", "mtime_after": "2021-01-19T01:01:33",
"size_after": "8", "gid_after": "0", "mode": "whodata", "path":
"/var/lib/docker/overlay2/b519fe37285573861c1c18be5f0208e2e13023fd72ada66d9f522b3892439232/merged/sbin",
"sha1_after":
"da39a3ee5e6b4b0d3255bfef95601890afd80709", "gname_after": "root", "audit": { "process": { "par-
ent_name": "/lib/systemd/systemd", "cwd": "/", "parent_cwd": "/", "name": "/usr/bin/dockerd",
"id": "1675", "ppid": "1" }, "effective_user": { "name": "root", "id": "0" }, "user": { "name": "root",
"id": "0" }, "group": { "name": "root", "id": "0" } }, "uid_after": "0", "perm_after": "rwxrwxrwx",
"event": "added", "md5_after": "d41d8cd98f00b204e9800998ecf8427e", "sha256_after": "e3b0c44298fc1c149afbf4c8
"inode_after": 681366 }, "agent": { "ip": "10.102.196.180", "name": "agentu", "id": "001"}, "man-
ager": { "name": "wazuh-manager" }, "rule": { "firedtimes": 2698, "mail": false, "level": 5, "pci_dss":
[ "11.5" ], "hipaa": [ "164.312.c.1", "164.312.c.2" ], "tsc": [ "PI1.4", "PI1.5", "CC6.1", "CC6.8",
"CC7.2", "CC7.3" ], "description": "File added to the system.", "groups": [ "ossec", "syscheck" ],
"id": "554", "nist_800_53": [ "SI.7" ], "gpg13": [ "4.11" ], "gdpr": [ "II_5.1.f" ] }, "decoder": {
"name": "syscheck_new_entry" }, "full_log": "File
’/var/lib/docker/overlay2/b519fe37285573861c1c18be5f0208e2e13023fd72ada66d9f522b3892439232/merged/sbin’
added: whodata", "input": { "type": "log" }, "@timestamp": "2021-01-30T17:25:35.017Z", "location":
"syscheck", "id": "1612027535.21391716", "timestamp": "2021-01-30T17:25:35.017+0000", "_id": "Aa9UVHcBNTk
56
Hình 4.27: Kiểm tra file
-> Trong báo cáo của hệ thống, whodata hoạt động nhưng không xác định được chính xác user tạo
ra container
- Thử dùng user agent_1 thực hiện vài câu lệnh trong hệ thống
57
- KQ bên wazuh:
58
-> whodata hoạt động và xác định chính xác được user nào đang chỉnh sửa file hệ thống - Kiểm tra
log của audit (mở file /var/log/audit/audit.log):
59
Hình 4.31: Kết quả file
-> Trong log của audit có thông tin user đăng nhập vào container và user trong container đang hoạt
động.
Tóm lại, chức năng giám sát whodata sử dụng Linux Audit hoạt động trên máy agent chỉ dùng được
cho trường hợp xác định user nào chỉnh sửa file hệ thống nhưng không xác định được user đã thực
hiện các lệnh liên quan đến các container.
60
4.4 VirusTotal integration
Wazuh có thể quét các tệp được giám sát để tìm nội dung độc hại trong các tệp được giám sát.
Giải pháp này có thể thực hiện được thông qua tích hợp với VirusTotal, đây là một nền tảng mạnh
mẽ kết hợp nhiều sản phẩm chống vi-rút cùng với một công cụ quét trực tuyến. Kết hợp công cụ này
với công cụ FIM của chúng tôi cung cấp một phương tiện đơn giản để quét các tệp được theo dõi để
kiểm tra nội dung độc hại.
VirusTotal là một dịch vụ trực tuyến phân tích các tệp và URL để phát hiện vi-rút, sâu, trojan
và các loại nội dung độc hại khác bằng cách sử dụng công cụ chống vi-rút và trình quét trang web.
Nó cũng có khả năng phát hiện dương tính giả.
VirusTotal là một dịch vụ miễn phí với nhiều tính năng hữu ích. Đối với mục đích của chúng tôi,
chúng tôi sẽ làm nổi bật những điều sau:
• VirusTotal lưu trữ tất cả các phân tích mà nó thực hiện, cho phép tìm kiếm hàm băm của một
tệp cụ thể. Bằng cách gửi mã băm đến công cụ VirusTotal, có thể biết được tệp cụ thể đó đã được
quét bởi VirusTotal hay chưa và phân tích báo cáo của nó.
• VirusTotal cũng cung cấp một API cho phép truy cập vào thông tin do VirusTotal tạo ra mà
không cần sử dụng giao diện trang web HTML. API này tuân theo Điều khoản dịch vụ được thảo
luận ngắn gọn trong phần sau.
4.4.1 Điều khoản dịch vụ

Điều khoản dịch vụ của VirusTotal chỉ định hai cách API VirusTotal có thể được sử dụng:
API công khai: Phương pháp này sử dụng một API miễn phí với nhiều chức năng của VirusTotal,
tuy nhiên, nó có một số hạn chế quan trọng, chẳng hạn như:
• giới hạn tỷ lệ yêu cầu không quá bốn yêu cầu mỗi phút và
• quyền truy cập ưu tiên thấp của các yêu cầu do API này thực hiện cho công cụ VirusTotal.
Tài liệu VirusTotal chỉ ra rằng người dùng chạy honeyclient, honeypot hoặc bất kỳ hoạt động tự
động hóa nào khác cung cấp tài nguyên cho VirusTotal sẽ được thưởng với hạn ngạch tỷ lệ yêu cầu
cao hơn và các đặc quyền đặc biệt khi thực hiện các lệnh gọi tới API.
API riêng: VirusTotal cũng cung cấp một API riêng cao cấp trong đó tỷ lệ yêu cầu và tổng số truy
vấn được phép chỉ bị giới hạn bởi Điều khoản dịch vụ của người dùng. Ngoài ra, nó cung cấp quyền
truy cập ưu tiên cao cho các yêu cầu, cùng với các lợi thế bổ sung.
4.4.2 Cấu hình

Kịch bản: Chúng ta sử dụng API VirusTotal để phát hiện nội dung độc hại trong các tệp được
Giám sát toàn vẹn tệp giám sát . Tích hợp này hoạt động như được mô tả bên dưới:
1. FIM tìm kiếm bất kỳ sự bổ sung, thay đổi hoặc xóa tệp nào trên các thư mục được giám sát.
Mô-đun này lưu trữ hàm băm của các tệp này và kích hoạt cảnh báo khi có bất kỳ thay đổi nào được
thực hiện.
2. Khi tích hợp VirusTotal được bật, nó sẽ được kích hoạt khi có cảnh báo FIM. Từ cảnh báo này,
mô-đun trích xuất trường băm của tệp.
3. Sau đó, mô-đun thực hiện một yêu cầu HTTP POST tới cơ sở dữ liệu VirusTotal bằng cách sử
dụng API VirusTotal để so sánh giữa hàm băm được trích xuất và thông tin có trong cơ sở dữ liệu.
4. Một phản hồi JSON sau đó sẽ được nhận, đó là kết quả của tìm kiếm này sẽ kích hoạt một trong
các cảnh báo sau:
• Lỗi: Đã đạt đến giới hạn tỷ lệ yêu cầu API công khai.
• Lỗi: Kiểm tra thông tin đăng nhập.
• Cảnh báo: Không có bản ghi nào trong cơ sở dữ liệu VirusTotal.
• Cảnh báo: Không tìm thấy điểm tích cực nào.
• Cảnh báo: Công cụ X đã phát hiện tệp này.
Cấu hình:
Lên trang virustotal.com, đăng kí tài khoản rồi lấy API Key để điền vào file cấu hình ossec.conf
bên máy vm wazuh manager
61
Hình 4.32: API key
Mở máy vm wazuh manager lên và thực hiện dòng lệnh để mở, chỉnh sửa file ossec.conf. Sau đó restart
lại wazuh manager:
Hình 4.33: Thay đổi file ossec.conf manager
Vào máy agent, chỉnh sửa file ossec.conf như sau:
Hình 4.34: Thay đổi file ossec.conf Agent
62
Sau đó thực hiện lệnh docker restart wazuh-agent.
Tiếp theo vào bên trong container, tạo 1 file virus để kiểm tra xem virustotal được tích hợp vào wazuh
có hoạt động không:
Hình 4.35: Tạo container
bật tắt caps lock liên tục:
Hình 4.36
Trong wazuh mục integrity monitoring, sự kiện file malware mình tạo đã được hiển thị:
Để các hoạt động container xuất hiện trên dashboard wazuh, cần cấu hình thêm trong file ossec.conf
của agent như sau
<wodle name="docker-listener">
<interval>600</interval>
<disabled>no</disabled>
<run_on_start>yes</run_on_start>
<attempts>5</attempts
</wodle>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/auth.log</location>
</localfile>
<localfile>
<location>/var/log/syslog</location>
</localfile>
<localfile>
<location>/var/log/dpkg.log</location>
</localfile>
<localfile>
63
<location>/var/log/kern.log</location
</localfile>
Hình 4.37: kiểm tra database
64
Qua mục VirusTotal, có hiển thị các alert cảnh báo cho file này:
Hình 4.38: Kiểm tra file Json

File Json:
Hình 4.39: Kiểm tra file Json
65
4.5 Monitoring system calls
Các hệ thống Linux kiểm toán cung cấp một cách để theo dõi thông tin bảo mật có liên quan trên
máy tính của bạn. Dựa trên các quy tắc được định cấu hình trước, Kiểm toán chứng minh ghi nhật
ký thời gian thực chi tiết về các sự kiện đang xảy ra trên hệ thống của bạn. Thông tin này rất quan
trọng đối với các môi trường quan trọng để xác định người vi phạm chính sách bảo mật và các hành
động mà họ đã thực hiện.
Kiểm tra sử dụng một bộ quy tắc để xác định những gì sẽ được ghi lại trong các tệp nhật ký. Có
ba loại quy tắc Kiểm toán có thể được chỉ định:
• Các quy tắc kiểm soát: cho phép sửa đổi hành vi của hệ thống Kiểm toán và một số cấu hình
của nó.
• Các quy tắc hệ thống tệp: còn được gọi là đồng hồ tệp, cho phép kiểm tra quyền truy cập
vào một tệp hoặc một thư mục cụ thể.
• Các quy tắc gọi hệ thống: cho phép ghi nhật ký các cuộc gọi hệ thống mà các chương trình
đã chỉ định thực hiện.
Quy tắc kiểm toán có thể được xác định một cách tương tác với auditctl tiện ích dòng lệnh, nhưng
để thực hiện thay đổi dai dẳng, chỉnh sửa /etc/audit/audit.rules .
4.5.1 Cấu hình

Đầu tiên ta sẽ cài đặt audit
Hình 4.40: Cài dặt audit
Mở file ossec.conf trong máy agent (máy có OS là Centos7) lên và chỉnh như bên dưới:
Hình 4.41: thay đổi file ossec.conf Centos
Đặt lệnh giám sát các kết nối (như đọc, viết file) liên quan đến các container bên trong:
66
Hình 4.42: Đặt lệnh
Ý nghĩa các từ audit-wazuh -x là:

audit-wazuh-w:write
audit-wazuh-r:read
audit-wazuh-a:attribute
audit-wazuh-x:execute
audit-wazuh-c:command
Thực hiện vài dòng lệnh:
Hình 4.43
Kiểm tra bên wazuh:
67
68
Chương 5
KẾT LUẬN,HƯỚNG PHÁT

TRIỂN
Wazuh là một dự án nguồn mở được phát triển dựa trên OSSEC, HIDS và được tích hợp thêm
Elastic Stack cùng với OpenSCAP, trở thành một giải pháp an ninh tốt trong thời điểm các cuộc tấn
công, xâm nhập mạng ngày càng nhiều.
Xây dựng hệ thống wazuh bằng docker container dễ dàng. Giao diện kibana, wazuh thân thiện với
người dùng, thuận lợi cho việc quản lý.
Khả năng bảo mật hệ thống tốt. Các log system của agent cập nhật thường xuyên, có thông tin
chi tiết kèm mức cảnh báo của các alert khiến việc đánh giá khả năng hệ thống bị tấn công hay không
dễ dàng.
Các rule đã cài sẵn khá đầy đủ để cảnh báo các trường hợp xâm nhập mạng phổ biến khiến việc
tấn công vào rất khó khăn.
Đánh giá chung về hệ thống wazuh:
5.1 Ưu điểm
- Là mã nguồn mở với cộng đồng phát triển mạnh mẽ.
- Cài đặt bằng docker dễ dàng.
- Triển khai tốt với các mô hình quản lý nhỏ.
- Tích hợp giao diện kibana dưới dạng plugin đem đến trải nghiệm tuyệt vời trong việc cấu hình, quản
lý các agent, nhận các alert bảo mật.
- Khả năng monitoring đáp ứng được nhu cầu cơ bản, đảm bảo khả năng bảo mật của container chạy
trong agent.
- Cung cấp trải nghiệm hệ thống wazuh tốt với virtual machine image (OVA) được tạo sẵn.
- Rule cấu hình sẵn khá đầy đủ, đối phó được với các trường hợp tấn công phổ biến, cảnh báo tốt về
khả năng hệ thống bị tấn công.
5.2 Nhược điểm

- Cài đặt phức tạp khi triển khai mô hình quy mô lớn:
- Triển khai theo mô hình phân tán (Distributed deployment) cung cấp khả năng mở rộng cao của
các dịch vụ nhưng cài đặt khó khăn, thường gặp vấn đề lỗi liên quan đến version khi cài đặt wazuh
server.
- Triển khai wazuh bằng ansible dễ bị lỗi về vấn đề remote hosts connection.
- Nhận những alert không cần thiết nếu cấu hình rule sai.
- Không có biểu đồ tương quan với việc sử dụng tài nguyên của các containers.
- Giao diện hệ thống wazuh kết hợp kibana khởi động chậm.
69
5.3 Hướng phát triển
tích hợp thêm plugin để show các tài nguyên mà container sử dụng
tích hợp thêm các network policies cho các container, đảm bảo đường truyền được mã hóa giữa các
container
Kết hợp thêm các công nghệ như AI, machine learning để hệ thống có thể tự động hóa.
70
Chương 6
TÀI LIỆU THAM KHẢO
https://vi.wikipedia.org/wiki/Vi%E1%BB%87n_Nghi%C3%AAn_c%E1%BB%A9u_Ph%C3%A1t_tri%E1%
BB%83n
https://www.ossec.net/docs/
https://documentation.wazuh.com/4.0/getting-started/components/wazuh_server.html
https://documentation.wazuh.com/4.0/getting-started/components/wazuh_agent.html
https://documentation.wazuh.com/4.0/getting-started/components/elastic_stack.html
https://documentation.wazuh.com/4.0/getting-started/architecture.html
https://documentation.wazuh.com/4.0/user-manual/ruleset/index.html
https://documentation.wazuh.com/4.0/docker/index.html
https://documentation.wazuh.com/4.0/user-manual/capabilities/file-integrity/how-it-works.
html
71

Wazuh

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Wazuh

Uploaded by

Copyright:

Available Formats

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

BÁO CÁO ĐỒ ÁN CHUYÊN NGÀNH

GVHD: Th.s Nguyễn Thanh Hòa

Cập nhật lần cuối: Ngày 15 tháng 3 năm 2021

LỜI CAM ĐOAN

Em xin cam đoạn:

Chương 1 GIỚI THIỆU CHUNG 3

Chương 2 KIẾN THỨC NỀN TẢNG 5

Chương 3 XÂY DỰNG HỆ THỐNG 39

Chương 4 TRÌNH BÀY, ĐÁNH GIÁ VỀ KẾT QUẢ 44

Chương 5 KẾT LUẬN,HƯỚNG PHÁT TRIỂN 69

Chương 6 TÀI LIỆU THAM KHẢO 71

GIỚI THIỆU CHUNG

1.1 Lý do chọn đề tài

1.2 Tính mới của đề tài

1.3 Phương pháp nghiên cứu

1.4 phạm vi và đối tượng nghiên cứu

KIẾN THỨC NỀN TẢNG

2.1 Tổng quan về hệ thống phát hiện xâm nhập IDS

Hình 2.1 : Thành phần của IDS

Hình 2.2 : Nguyên lý hoạt động

2.1.3 Phân loại IDS

2.1.4 Cách thức hoạt động của Host-Based IDS

Hình 2.3 : Mô hình hệ thống

Hình 2.4 : Các chức năng của WAZUH

2.2.1.1 OSSEC HIDS

2.2.1.3 Elastic Stack

Hình 2.5 : Wazuh Server

Các thành phần chính của Wazuh Server:

Hình 2.6 : Wazuh Agent

Các thành phần chính của Wazuh Agent:

2.2.2.3 Elastic Stack

Hình 2.7 : Wazuh Distributed deployment

Các thành phần sẽ được cài đặt:

Các thành phần sau sẽ được cài đặt:

Về cấu hình đề nghị từ Wazuh:

2.2.3.1 Giao tiếp Agent - Server

• /var/ossec/logs/archives/archives.json mọi sự kiện kể cả có vi phạm rule hay không.

2.2.3.2 Giao tiếp Wazuh - Elastic

2.2.4 Các port cần thiết

2.2.4.2 Elastic Stack

2.2.4.3 Lưu trữ dữ liệu

Hình 2.9 : Ouput

2.2.5 luật trong WAZUH

2.2.5.1 Tổ chức các luật

Hình 2.10 : Cấu trúc thư mục của Rule

2.2.5.2 Các thuộc tính của Rule

2.2.5.3 Phân loại luật

2.2.6 Phương thức hoạt động của luật trong WAZUH

Tùy chọn Giá trị Miêu tả

1: <decoder name ="..."> ... <decoder> : Đặt tên cho decoder

Giá trị mặc định n/a

Giá trị mặc định n/a

Giá trị mặc định string

Giá trị mặc định mảng

14: Type: Nó đặt loại nhật ký mà decoder sẽ khớp

2.2.6.2 Cú pháp của Rule

9: Data: Bất kỳ chuỗi nào được giải mã vào trường data .

12: <if_group>authentication_success</if_group>: Được sử dụng như một điều kiện tiên

17: <url>.jpg|.gif |favicon.ico|.png|robots.txt|.css|.js|.jpeg</url>Được sử dụng như một điều

24:<if_matched_group>virus</if_matched_group:>Đối xứng nếu một cảnh báo về nhóm

25:if_fts: Làm cho decoder đã xử lý sự kiện xem xét dòng fts .

70: <options>thuộc tính</options>