HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

KHOA CÔNG NGHỆ THÔNG TIN

Học phần: Chuyên đề an ninh mạng

Bài báo cáo:

Ứng dụng hệ thống IDS Security Onion vào giám sát
môi trường mạng doanh nghiệp

Giảng viên hướng dẫn: TS. Nguyễn Ngọc Điệp

Sinh viên thực hiện:

Đoàn Công Hoàng B16DCAT064
Nguyễn Thành Nam B16DCAT111
Đồng Văn Quang B16DCAT128
Vũ Tiến Quốc B16DCAT132
Phạm Hải Sơn B16DCAT140

HÀ NỘI, 2020
 Mục lục
CHƯƠNG 1 Tổng quan về hệ thống phát hiện xâm nhập...........................1
1.1.Tổng quan về xâm nhập.................................................................................................1
1.2. Hệ thống phát hiện xâm nhập......................................................................................2
1.2.1.Hệ thống phát hiện xâm nhập cho mạng....................................................................2
1.2.2.Hệ thống phát hiện xâm nhập cho host......................................................................3
1.3. Kỹ thuật phát hiện xâm nhập.......................................................................................4
1.3.1.Phát hiện xâm nhập dựa trên chữ ký..........................................................................4
1.3.2.Phát hiện xâm nhập dựa trên bất thường (Anomaly intrusion detection)..................5
CHƯƠNG 2 Giới thiệu Security Onion.........................................................7
2.1. Giới thiệu........................................................................................................................7
2.2. Các chức năng................................................................................................................7
2.2.1. Bắt tất cả gói tin (Full Packet Capture):...................................................................8
2.2.2.Phát hiện mạng và các điểm cuối:.............................................................................9
2.2.3.Các công cụ phân tích..............................................................................................12
2.2.4. Các công cụ NIDS..................................................................................................19
2.2.5. Các công cụ hỗ trợ phân tích điểm cuối (Host Visibility)......................................20
CHƯƠNG 3 Cách thức hoạt động của Security Onion..............................21
3.1. Kiến trúc.......................................................................................................................21
3.1.1.Import.......................................................................................................................22
3.1.2.Evaluation................................................................................................................22
3.1.3.Standalone................................................................................................................23
3.1.4.Distributed...............................................................................................................23
3.1.5.Các loại nodes..........................................................................................................25
3.2.Cách thức hoạt động....................................................................................................25
3.2.1. IDS..........................................................................................................................26
3.2.2. IPS...........................................................................................................................26
3.3.Cài đặt............................................................................................................................26
3.3.1.Yêu cầu phần cứng đối với Security Onion.............................................................26
3.3.2. Môi trường cài đặt...................................................................................................27
3.3.3.Các tác vụ cần thực hiện sau khi cài đặt xong:........................................................28
CHƯƠNG 4 Luật trong Security Onion......................................................30
4.1. Rule Header.................................................................................................................31
 4.1.1 Rule Action..............................................................................................................31
4.1.2. Protocol...................................................................................................................31
4.1.3. IP Address...............................................................................................................32
4.1.4. Port..........................................................................................................................32
4.1.5. Điều hướng.............................................................................................................32
4.2. Rule Option...................................................................................................................33
4.2.1. General....................................................................................................................33
4.2.2. Payload....................................................................................................................35
4.2.3. Non-Payload...........................................................................................................38
4.3: Add Local Rules...........................................................................................................44
4.3.1.Giới thiệu.................................................................................................................44
4.3.2.Chính sách IPS.........................................................................................................44
4.3.3.Các bước thực hiện..................................................................................................45
CHƯƠNG 5 Ứng dụng Security Onion giám sát môi trường mạng doanh
nghiệp ...................................................................................................48
5.1. Các công cụ được sử dụng......................................................................................48
5.1.1. Sguil...................................................................................................................48
5.1.2. Wazuh................................................................................................................51
5.2. Sơ đồ môi trường demo giám sát/phát hiện xâm nhập........................................76
5.3. Các bước cài đặt Security Onion để thực hiện giám sát server theo mô hình môi
trường demo trên................................................................................................................76
5.4. Thực hiện tấn công và phát hiện tấn công từ trong mạng, đưa ra cảnh
báo/phân tích bằng Sguil....................................................................................................92
5.4.1. Phát hiện tấn công rà quét lỗ hổng.................................................................92
5.4.2. Phát hiện tấn công DOS...................................................................................93
5.5. Các bước cài đặt Wazuh để thực hiện giám sát các điểm cuối trong mạng theo môi
trường demo trên Ubuntu.....................................................................................................98
5.5.1. Cài đặt Wazuh Server.........................................................................................98
5.5.2. Cài đặt Wazuh Agent........................................................................................105
5.6. Demo Wazuh giám sát tính toàn vẹn của file (file integrity).............................105
5.6.1. Tổng quan.......................................................................................................105
5.6.2. Mô hình triển khai.........................................................................................106
5.6.3. Hướng dẫn cấu hình.......................................................................................107
 Danh mục hình ảnh
Ảnh 1.1 Vị trí hệ thống IDS trong sơ đồ mạng.........................................................................................2
Ảnh 1.2 Các NIDS được bố trí để giám sát phát hiện xâm nhập tại cổng vào và cho từng phân đoạn
mạng...........................................................................................................................................................3
Ảnh 1.3 Sử dụng kết hợp NIDS và HIDS để giám sát lưu lượng mạng và các host................................4
Ảnh 1.4 Lưu đồ giám sát phát hiện tấn công, xâm nhập dựa trên chữ ký................................................5
Ảnh 1.5 Biểu đồ tín hiệu entropy theo thời gian.......................................................................................6
Ảnh 2.1 Sơ đồ hoạt động của SO trong môi trường mạng doanh nghiệp truyền thống...........................8
Ảnh 2.2 Minh họa phát hiện tấn công trên cơ sở hệ thống mạng (NIDS)................................................9
Ảnh 2.3 Minh họa phát hiện tấn công dựa trên cơ sở hệ thống máy chủ/đầu cuối (HIDS)...................11
Ảnh 2.4 Giao diện của SOC.....................................................................................................................12
Ảnh 2.5 Giao diện Hunt...........................................................................................................................12
Ảnh 2.6 Giao diện bắt và thu hồi gói tin của SOC..................................................................................13
Ảnh 2.7 Giao diện Kibana.......................................................................................................................14
Ảnh 2.8 Giao diện Cyberchef..................................................................................................................15
Ảnh 2.9 Giao diện CapME.......................................................................................................................16
Ảnh 2.10 Giao diện Squert.......................................................................................................................17
Ảnh 2.11 Giao diện Sguil.........................................................................................................................18
Ảnh 2.12 Giao diện Wireshark................................................................................................................18
Ảnh 3.1 Kiến trúc hoạt động tổng thể của Security Onion.....................................................................21
Ảnh 3.2 Kiến trúc Evaluation..................................................................................................................22
Ảnh 3.3 Kiến trúc Standalone..................................................................................................................23
Ảnh 3.4 Kiến trúc Distributed..................................................................................................................24
Ảnh 4.1 Cấu trúc luật trong Suricata.......................................................................................................30
Ảnh 4.2 Ví dụ luật trong Suricata............................................................................................................30
Ảnh 4.3 Thông tin phân loại lớp quy tắc.................................................................................................35
Ảnh 4.4 Một số tuỳ chọn của Ipopts........................................................................................................38
Ảnh 4.5 Bảng Type của ICMP Header...................................................................................................42
Ảnh 4.6 Kiểm tra sguil để biết cảnh báo tương ứng...............................................................................46
Ảnh 4.7 Xác minh payload......................................................................................................................47
Ảnh 5.1 Giao diện Sguil 0.9.0.................................................................................................................48
Ảnh 5.2 Barnyard nhận các cảnh báo từ Snort IDS, sử lý và lưu vào database.....................................49
Ảnh 5.3 Tổng quan kiến trúc của Sguil...................................................................................................50
Ảnh 5.4 Tổng quan kiến trúc của Sguil (2).............................................................................................51
Ảnh 5.5 Kiến trúc Single-node deployment của Wazuh.........................................................................54
Ảnh 5.6 Kiến trúc Multi-node deployment của Wazuh...........................................................................54
Ảnh 5.7 Sơ đồ giao tiếp giữa agent và server..........................................................................................55
Ảnh 5.8 Các file rule trong /var/ ossec/ruleset/rules...............................................................................56
Ảnh 5.9 Rule liên quan đến ssh của hệ thống 0095-sshd_rules.xml......................................................57
Ảnh 5.10 Cảnh báo hành vi đăng nhập sử dụng một non-existent user.................................................57
Ảnh 5.11 Dữ liệu hiển thị trên Kibana dưới dạng Table.........................................................................58
Ảnh 5.12 Dữ liệu hiển thị trên Kibana dưới dạng JSON........................................................................59
Ảnh 5.13 Các mức độ cảnh báo OSSEC.................................................................................................60
Ảnh 5.14 Luật OSSEC.............................................................................................................................61
Ảnh 5.15 Thông tin các file rule trong Wazuh.......................................................................................62
Ảnh 5.16 Các file rule của Windows.......................................................................................................62
Ảnh 5.17 Các file Rules Linux...................................................................................................................63
Ảnh 5.18 Sơ đồ cấu trúc node Manager..................................................................................................64
Ảnh 5.19 Tạo bộ decoder mới trong file local_decoder.xml..................................................................66
Ảnh 5.20 Thêm thông tin cho rule vào đường dẫn..................................................................................67
Ảnh 5.21 Kiểm tra rule............................................................................................................................68
Ảnh 5.22 Sao chép decoders.xml............................................................................................................69
Ảnh 5.23 Loại bỏ decoders.xml bằng thẻ <decoder_exclude>...............................................................69
Ảnh 5.24 Rule có id 5710........................................................................................................................70
Ảnh 5.25 Dán đoạn code rule id 5710 vào đường dẫn............................................................................71
Ảnh 5.26 Test rule vừa được sửa đổi.......................................................................................................72
Ảnh 5.27 Các tham số trong thẻ <rule>..................................................................................................72
Ảnh 5.28 Rule id 5710 cũ........................................................................................................................73
Ảnh 5.29 Các cảnh báo lặp lại.................................................................................................................73
Ảnh 5.30 Thêm tham số ignore................................................................................................................74
Ảnh 5.31 Kết quả sao khi thêm tham số ignore vào rule........................................................................74
Ảnh 5.32 Rule id 5710 sử dụng noalert...................................................................................................74
Ảnh 5.33 Kết quả sau khi thay đổi..........................................................................................................75
Ảnh 5.34 Sơ đồ demo giám sát phát hiện tấn công/xâm nhập..............................................................76
Ảnh 5.35 Cấu hình cài đặt máy ảo Security Onion trên máy server.......................................................77
Ảnh 5.36 Cài đặt Promiscuous Mode......................................................................................................78
Ảnh 5.37 Rà quét lỗ hổng máy server sử dụng công cụ Zenmap...........................................................92
Ảnh 5.38 Kết quả giám sát.......................................................................................................................93
Ảnh 5.39 Lệnh sửa file local.rules thông qua cửa sổ terminal................................................................93
Ảnh 5.40 Thêm luật vào file local.rules..................................................................................................94
Ảnh 5.41 Thực hiện lệnh rule-update để cập nhật IDS ruleset...............................................................95
Ảnh 5.42 Thực hiện tấn công DOS trên máy Kali..................................................................................96
Ảnh 5.43 Trạng thái website sau khi bị tấn công DOS...........................................................................96
Ảnh 5.44 Giao diện Sguil hiện cảnh báo tấn công DOS thời gian thực cùng các thông tin liên quan. .97
Ảnh 5.45 Cài đặt Wazuh-manager thành công........................................................................................99
Ảnh 5.46 Thông báo cài đặt thành công Elasticsearch..........................................................................101
Ảnh 5.47 Cài đặt thành công Filebeat...................................................................................................103
Ảnh 5.48 Giao diện quản trị Kibana của Wazuh-server........................................................................104
Ảnh 5.49 Sơ đồ cách thức hoạt động của FIM......................................................................................106
Ảnh 5.50 Sơ đồ triển khai Wazuh manager/agent................................................................................107
Ảnh 5.51 Kiểm tra cấu hình giám sát FIM..............................................................................................108
Ảnh 5.52 File .txt để thực hiện giám sát (1)..........................................................................................108
Ảnh 5.53 File .txt để thực hiện giám sát (2)..........................................................................................108
Ảnh 5.54 Giao diện quản trị Wazuh-manager.......................................................................................109
Ảnh 5.55 Integrity monitoring trong Wazuh-manager.........................................................................109
Ảnh 5.56 Kiểm tra tính toán vẹn của file .txt (1)...................................................................................110
Ảnh 5.57 Kiểm tra tính toán vẹn của file .txt (2)...................................................................................110
 Danh mục từ viết tắt
Từ/cụm từ viết tắt Ý nghĩa
AF-PACKET Một socket trong các hệ điều hành nhân
Linux, cho phép ứng dụng gửi và nhận các
gói tin
East-west traffic Lưu lượng truy cập trong 1 hệ thống trung
tâm dữ liệu
CSV Comma-seperated value
CIS Center for Internet Security
CAT Configuration Assessment Tool
DOS Denial-of-service
FIM File integrity monitoring
GUI Graphical User Interface
GPL GNU General Public License
HIDS Host-based intrusion detection systems
IDS Intrusion Detection System
IP Internet Protocol
IPS Intrusion Prevention System
ISO image optical disc file system
JSON JavaScript Object Notation
NIDS Network-based intrusion detection system
NSM Network Security Monitoring
NIC Network Interface Controller
North-south traffic Lưu lượng truy cập từ bên ngoài đến trung
tâm dữ liệu
(và ngược lại)
OSSEC Open Source HIDS SECurity
OVAL Open Vulnerability and Assessment
Language
PPA Personal Package Archives
(software repository được thiết kế cho người
dùng Ubuntu)
SANCP Security Analyst Network Connection
Profiler
SCA Security Configuration Assessment
SOC Security Onion Control
SPAN Switch Port Analyzer
Salt (SaltStack) là một phần mềm Python mã
nguồn mở, dử dụng trong các tác vụ IT chủ
động hướng sự kiện (event-driven IT
automation), thi hành các tác vụ điều khiển
từ xa (remote task execution), quản lý cài
đặt/cấu hình (configuration management).
Cung cấp cách tiếp cận code-based với cơ
sở hạ tầng, các hệ thống cơ sở dữ liệu và các
hệ thống triển khai/quản lý, cài đặt/cấu hình
tự động, SecOps, cảnh báo rủi ro, công nghệ
đám mây.
SSH Secure Shell
Tcl Ngôn ngữ lập trình Tcl (phát âm như
“tickle”)[2]
TCP Transmission Control Protocol
TCP/IP Internet protocol suite
(Transmission Control Protocol + Internet
Potocol)
TLS Transport Layer Security
Tk Một bộ công cụ thư viện mã nguồn mở đa
nền tảng, cung cấp các thành phần GUI cho
nhiều ngôn ngữ lập trình khác nhau [3]
TAP Terminal Access Point
UPS Uninterruptible power supply
WNIC Wireless Network Interface Controller
XCCDF Extensible Configuration Checklist
Description Format
CHƯƠNG 1 Tổng quan về hệ thống phát hiện xâm nhập
1.1.Tổng quan về xâm nhập
Xâm nhập là tập các hành động nhằm thỏa hiệp với mục tiêu an toàn (tính bảo
mật, tính toàn vẹn và tính sẵn dùng) của tài nguyên mạng hoặc máy tính.
Các hệ thống phát hiện tấn công, xâm nhập (IDS) là một lớp phòng vệ quan trọng trong
các lớp giải pháp đảm bảo an toàn cho hệ thống thông tin và mạng theo mô hình phòng
thủ có chiều sâu (defence in depth). Hệ thống phát hiện tấn công, xâm nhập IDS có
nhiệm vụ chính là:
- Giám sát lưu lượng mạng hoặc các hành vi trên một hệ thống để nhận dạng các
dấu hiệu của tấn công, xâm nhập.
- Khi phát hiện các hành vi tấn công, xâm nhập, thì ghi logs các hành vi này cho
phân tích bổ sung sau này.
- Gửi thông báo cho người quản trị về các các hành vi tấn công, xâm nhập đã phát
hiện được
Thông thường hệ thống IDS thường được kết nối vào các bộ định tuyến, switch, card
mạng và chủ yếu làm nhiệm vụ giám sát và cảnh bảo, không có khả năng chủ động ngăn
chặn tấn công, xâm nhập

1
 Ảnh 1.1 Vị trí hệ thống IDS trong sơ đồ mạng

1.2. Hệ thống phát hiện xâm nhập

Hệ thống phát hiện xâm nhập IDS được chia thành hai loại chính đó là: Hệ thống
phát hiện xâm nhập cho mạng và hệ thống phát hiện xâm nhập cho host.
1.2.1.Hệ thống phát hiện xâm nhập cho mạng
NIDS (Host-based IDS) phân tích lưu lượng mạng để phát hiện tấn công, xâm
nhập cho cả mạng hoặc một phần mạng. Trong một sơ đồ mạng, trong đó các NIDS
thường được bố trí để giám sát phát hiện xâm nhập tại cổng vào và cho từng phân đoạn
mạng.

2
 Ảnh 1.2 Các NIDS được bố trí để giám sát phát hiện xâm nhập tại cổng vào và cho từng phân đoạn mạng

1.2.2.Hệ thống phát hiện xâm nhập cho host

HIDS (Host-based IDS) phân tích các sự kiện xảy ra trong hệ thống/dịch vụ để
phát hiện tấn công, xâm nhập cho hệ thống đó. Trong một sơ đồ mạng các NIDS thường
sử dụng để giám sát lưu lượng tại cổng mạng và HIDS để giám sát các host thông qua các
IDS agent. Một trạm quản lý (Management station) đƣợc thiết lập để thu nhập các thông
tin từ các NIDS và HIDS để xử lý và đưa ra quyết định cuối cùng.

3
 Ảnh 1.3 Sử dụng kết hợp NIDS và HIDS để giám sát lưu lượng mạng và các host

1.3. Kỹ thuật phát hiện xâm nhập

Các kỹ thuật phát hiện xâm nhập được chia thành hai kỹ thuật chính đó là: phát
hiện xâm nhập dựa trên chữ ký và phát hiện xâm nhập dựa trên bất thường.
1.3.1.Phát hiện xâm nhập dựa trên chữ ký
Phát hiện xâm nhập dựa trên chữ ký (Signature-based intrusion detection) trước hết
cần xây dựng cơ sở dữ liệu các chữ ký, hoặc các dấu hiệu của các loại tấn công, xâm
nhập đã biết. Hầu hết các chữ ký, dấu hiệu được nhận dạng và mã hóa thủ công và dạng
biểu diễn thường gặp là các luật phát hiện (Detection rule). Bước tiếp theo là sử dụng cơ
sở dữ liệu các chữ ký để giám sát các hành vi của hệ thống, hoặc mạng, và cảnh báo nếu
phát hiện chữ ký của tấn công, xâm nhập.

4
 Ảnh 1.4 Lưu đồ giám sát phát hiện tấn công, xâm nhập dựa trên chữ ký

Ưu điểm lớn nhất của phát hiện xâm nhập dựa trên chữ ký là có khả năng phát hiện
các tấn công, xâm nhập đã biết một cách hiệu quả. Ngoài ra, phương pháp này cho tốc độ
xử lý cao, đồng thời yêu cầu tài nguyên tính toán tương đối thấp. Nhờ vậy, các hệ thống
phát hiện xâm nhập dựa trên chữ ký đƣợc ứng dụng rộng rãi trong thực tế. Tuy nhiên,
nhược điểm chính của phương pháp này là không có khả năng phát hiện các tấn công,
xâm nhập mới, do chữ ký của chúng chưa tồn tại trong cơ sở dữ liệu các chữ ký. Hơn
nữa, nó cũng đòi hỏi nhiều công sức xây dựng và cập nhật cơ sở dữ liệu chữ ký, dấu hiệu
của các tấn công, xâm nhập.
1.3.2.Phát hiện xâm nhập dựa trên bất thường (Anomaly intrusion detection)

Phát hiện xâm nhập dựa trên bất thường (Anomaly intrusion detection) dựa trên giả
thiết: các hành vi tấn công, xâm nhập thường có quan hệ chặt chẽ với các hành vi bất
thường. Quá trình xây dựng và triển khai một hệ thống phát hiện xâm nhập dựa trên bất
thƣờng gồm 2 giai đoạn: là huấn luyện và là phát hiện.

- Giai đoạn huấn luyện: Hồ sơ (profile) của đối tƣợng trong chế độ làm việc bình
thường được xây dựng. Để thực hiện giai đoạn huấn luyện này, cần giám sát đối
tƣợng trong một khoảng thời gian đủ dài để thu thập đƣợc đầy đủ dữ liệu mô tả
các hành vi của đối tượng trong điều kiện bình thường làm dữ liệu huấn luyện.
5
 Tiếp theo, thực hiện huấn luyện dữ liệu để xây dựng mô hình phát hiện, hay hồ sơ
của đối tượng.

- Giai đoạn đoạn phát hiện: Thực hiện giám sát hành vi hiện tại của hệ thống và
cảnh báo nếu có khác biệt rõ nét giữa hành vi hiện tại và các hành vi lưu trong hồ
sơ của đối tượng.

Ảnh 1.5 Biểu đồ tín hiệu entropy theo thời gian

Giá trị entropy của IP nguồn của các gói tin từ lưu lượng hợp pháp (phần giá trị cao, đều)
và entropy của IP nguồn của các gói tin từ lưu lượng tấn công DDoS (phần giá trị thấp)

Hình trên biểu diễn giá trị entropy của IP nguồn của các gói tin theo cửa sổ trượt từ lưu
lượng bình thường và entropy của IP nguồn của các gói tin từ lưu lượng tấn công DDoS.
Có thể thấy sự khác biệt rõ nét giữa giá trị entropy của lưu lượng bình thường và lưu
lượng tấn công và như vậy, nếu một ngưỡng entropy được chọn phù hợp ta hoàn toàn có
thể phát hiện sự xuất hiện của cuộc tấn công DDoS dựa trên sự thay đổi đột biến của giá
trị entropy.

Ưu điểm của phát hiện xâm nhập dựa trên bất thường là có tiềm năng phát hiện các loại
tấn công, xâm nhập mới mà không yêu cầu biết trước thông tin về chúng. Tuy nhiên,
phương pháp này có tỷ lệ cảnh báo sai tƣơng đối cao so với phương pháp phát hiện dựa
trên chữ ký. Điều này làm giảm khả năng ứng dụng thực tế của phát hiện xâm nhập dựa
trên bất thường. Ngoài ra, nó cũng tiêu tốn nhiều tài nguyên hệ thống cho việc xây dựng
hồ sơ đối tượng và phân tích hành vi hiện tại.

6
CHƯƠNG 1 Giới thiệu Security Onion
2.1. Giới thiệu
Security Onion (SO) là một phiên bản của Linux được thiết kế để phát hiện xâm
nhập và giám sát an toàn mạng. Bộ công cụ này dựa trên Xubuntu 10.04, gồm Snort,
Suticata, Sguil, Squert, Snorby, Bro, NetworkMiner, Xplico, và nhiều các công cụ an toàn
khác. Đây là bộ công cụ rất hữu dụng trong giảng dạy và học tập, ngoài ra Security Onion
còn được sử dụng cho các văn phòng và mạng lưới cá nhân.
2.2. Các chức năng
Trong sơ đồ bên dưới, có thể thấy Security Onion trong môi trường mạng doanh
nghiệp sẽ bao gồm tường lửa, máy trạm và máy chủ. Người quản trị có thể sử dụng
Security Onion để theo dõi lưu lượng truy cập từ phía bên ngoài trung tâm dữ liệu
(North-south traffic) để phát hiện kẻ xâm nhập một môi trường mạng, thiết lập lệnh và
kiểm soát (Command and Control) hoặc có thể là xâm nhập dữ liệu. Người quản trị cũng
có thể muốn theo dõi lưu lượng truy cập trong 1 trung tâm dữ liệu (East-west traffic) để
để phát hiện các động thái có nguy cơ từ bên trong. Do ngày càng nhiều lưu lượng truy
nhập trong mạng được mã hóa, việc khắc phục những điểm mù tới từ việc đó bằng cách
bằng khả năng hiển thị bổ sung dưới dạng chuẩn đoán thiết bị đầu cuối (endpoint
telemetry) là rất quan trọng. Security Onion có thể sử dụng được nhật ký (logs) từ các
máy chủ và máy trạm, sau đó có thể tìm kiếm bao quát toàn bộ môi trường mạng và nhật
ký lưu trữ của máy chủ cùng một lúc.

7
 Ảnh 2.6 Sơ đồ hoạt động của SO trong môi trường mạng doanh nghiệp truyền thống

Security Onion có ba chức năng cốt lõi chính:

2.2.1. Bắt tất cả gói tin (Full Packet Capture):

Bắt tất cả gói tin được thực hiện thông qua công cụ Stenographer.
Stenographer là công cụ hỗ trợ bắt gói tin cho các gói dữ liệu đệm đến ổ đĩa, nhằm
mục đích phát hiện xâm nhập và giúp người quản trị có thể có các động thái kịp
thời khi phát hiện ra hiện tượng xâm nhập. Stenographer cung cấp cơ chế cài đặt
đọc và ghi các gói tin bắt được từ network adapter (card mạng) ra ổ đĩa (NIC-to-
8
 disk packet writing), xử lý ngoại lệ khi ổ đĩa hết dung lượng bằng cách xóa bớt các
gói tin đi, cung cấp các phương thức để có thể đọc lại các gói tin cụ thể, nhanh
chóng. Sternographer sử dụng AP-PACKET để có thể thực hiện gửi và nhận các
gói tin.

2.2.2.Phát hiện mạng và các điểm cuối:

Phát hiện mạng và đầu cuối (network and endpoint detection) phân tích lưu lượng
gói tin trong mạng hoặc hệ thống máy chủ, đồng thời cung cấp dữ liệu nhật ký
(các bản ghi log) và cảnh báo cho các sự kiện và hoạt động được phát
hiện. Security Onion cung cấp nhiều tùy chọn:

Ảnh 2.7 Minh họa phát hiện tấn công trên cơ sở hệ thống mạng (NIDS)

o NIDS hướng theo quy tắc (Rule-driven NIDS). Để phát hiện xâm nhập
mạng theo quy tắc, Security Onion 2 sử dụng Suricata. Hệ thống dựa trên

9
 quy tắc xem xét lưu lượng mạng để tìm dấu vân tay và số nhận dạng khớp
với lưu lượng độc hại, bất thường hoặc đáng ngờ.

o NIDS hướng phân tích. Để phát hiện xâm nhập mạng theo hướng phân tích
(analysis-driven network intrusion detection), Security Onion cung cấp
công cụ Zeek. Zeek giám sát hoạt động mạng và ghi vào nhật ký (log) mọi
kết nối, yêu cầu DNS, dịch vụ mạng và phần mềm được phát hiện, chứng
chỉ SSL và hoạt động HTTP, FTP, IRC, SMTP, SSH, SSL và Syslog mà nó
nhìn thấy, cung cấp khả năng hiển thị đầy đủ và thiết thực trong ngữ cảnh
dữ liệu và sự kiện xảy ra với chúng bên trong môi trường mạng. Ngoài ra,
Zeek bao gồm các bộ phân tích cho nhiều giao thức phổ biến, và mặc định
có khả năng kiểm tra tổng MD5 cho các lần tải xuống tệp HTTP chống lại
dự án Đăng ký phần mềm mã độc của Team Cymru (Team Cymru’s
Malware Hash Registry project). Ngoài hoạt động ghi nhật ký và phân tích
lưu lượng, Zeek cung cấp nhiều giải pháp cho việc mở rộng để phân tích dữ
liệu mạng trong thời gian thực. Khung đầu vào cho phép cung cấp dữ liệu
vào Zeek, có thể được script theo một bộ lọc nào đó, ví dụ, để đọc một file
CSV của một nhân viên cấp quản lý và so sáng tương khắc của nó với các
hoạt động khác trong mạng, ví dụ như hoạt động tải một file thực thi
(executable file) từ mạng internet xuống. Framework phân tích dữ liệu cung
cấp các cách thức phân tích dữ liệu độc lập về giao thức, cho phép bắt dữ
liệu khi chúng đi qua môi trường mạng và tự động chuyển chúng vào môi
trường sandbox hoặc một file chia sẻ kiểm tra vi-rút.

10
 Ảnh 2.8 Minh họa phát hiện tấn công dựa trên cơ sở hệ thống máy chủ/đầu cuối (HIDS)

o Để giám sát điểm cuối, Security Onion cung cấp Wazuh, một công cụ HIDS
mã nguồn mở, miễn phí cho Windows, Linux và Mac OS X. Khi thêm bộ
lọc/bộ quét của Wazuh vào các điểm cuối trên mạng, người quản trị có thể nắm
bắt được các thông tin có giá trị từ các điểm cuối (endpoint) đến các điểm thoát
(exit) trong môi trường mạng . Wazuh thực hiện phân tích nhật ký, kiểm tra
tính toàn vẹn của tệp, giám sát chính sách, phát hiện rootkit, cảnh báo thời gian
thực và phản hồi chủ động. Một bổ sung mới cho Security Onion 2 là osquery
– một công cụ mã nguồn mở miễn phí khác có chức năng tương tự. Ngoài ra,
Security Onion có thể thu thập dữ liệu thông qua Syslog hoặc Beats.

11
2.2.3.Các công cụ phân tích

Ảnh 2.9 Giao diện của SOC

Ảnh 2.10 Giao diện Hunt

12
 Ảnh 2.11 Giao diện bắt và thu hồi gói tin của SOC

Security Onion Console (SOC): Nó bao gồm một giao diện cảnh báo mới
cho phép người quản trị xem tất cả các cảnh báo NIDS và HIDS. Security
Onion Console (SOC) cũng bao gồm một giao diện Hunt mới để săn tìm
mối đe dọa, cho phép người quản trị truy vấn không chỉ cảnh báo NIDS /
HIDS mà còn cả nhật ký Zeek và nhật ký hệ thống. Security Onion Console
(SOC) cũng bao gồm một giao diện để truy xuất toàn bộ gói tin (PCAP).
TheHive: TheHive là giao diện quản lý case. Khi đang làm việc với Alerts,
Hunt hoặc Kibana, người quản trị có thể tìm thấy các cảnh báo hoặc bản ghi
tiềm ẩn nguy cơ để gửi tới TheHive và tạo case.

13
 Ảnh 2.12 Giao diện Kibana

Kibana: Kibana, được tạo ra bởi nhóm tại Elastic, cho phép nhanh chóng
phân tích và xoay vòng giữa tất cả các loại dữ liệu khác nhau do Security
Onion tạo ra thông qua một “ô kính duy nhất” (“single pane of glass”.). Nó
không chỉ bao gồm cảnh báo NIDS / HIDS mà còn cả nhật ký Zeek và nhật
ký hệ thống được thu thập thông qua nhật ký hệ thống hoặc phương tiện
truyền tải đại lý khác. Kibana có thể xoay vòng để chụp toàn bộ gói thông
qua Security Onion Console (SOC).

14
 Ảnh 2.13 Giao diện Cyberchef

CyberChef cho phép giải mã, giải nén và phân tích các đoạn mã/dữ liệu
Playbook: Playbook là một ứng dụng web cho phép tạo Detection
Playbook. Các Detection Playbook mô tả các khía cạnh khác nhau xung
quanh chiến lược phát hiện tấn công cụ thể.

15
 Ảnh 2.14 Giao diện CapME

CapME: một ứng dụng web cho phép:

 Xem một bản dịch pcap transcript được render bằng tcpflow hoặc Zeek
 Tải về file pcap

16
 Ảnh 2.15 Giao diện Squert

Squert: một ứng dụng web được sử dụng để thực hiện các câu lệnh truy vấn (querry) và
xem các sự kiện từ log thu thập được trong cơ sở dữ liệu của Sguil (các cảnh báo IDS):
 Xem một bản dịch pcap transcript được render bằng tcpflow
 Xem một bản dịch pcap transcript được render bằng Zeek
 Tải về file pcap

Ảnh 2.16 Giao diện Sguil

17
Sguil: một ứng dụng phân tích/giám sát mạng, có GUI, cung cấp khả năng bắt và truy cập
các sự kiện thời gian thực, bắt toàn bộ gói tin và các dữ liệu phiên (session data). Sguil là
một công cụ NSM và cũng là một công cụ phân tích hướng sự kiện (event driven)

Ảnh 2.17 Giao diện Wireshark

Wireshark: một ứng dụng phân tích dựa trên giao thức mạng rất phổ biến.

2.2.4. Các công cụ NIDS

Các công cụ NIDS là các công cụ giám sát, phát hiện xâm nhập hệ thống
mạng, bắt được các hành động khả nghi cụ thể và đưa ra các cảnh báo dựa vào luật
(rule)
Security Onion có thể sử dụng Snort hoặc Suricata làm NIDS engine. Trong
quá trình setup, nếu tích chọn “Evaluation Mode”, Security Onion sẽ mặc định
NIDS engine là Snort. Các phiên bản cài đặt khác mặc định sử dụng Suricata trong
chế độ AF_PACKET
Các cảnh báo NIDS có thể được phân tích kĩ hơn bằng các công cụ: Squert,
Kibana, Sguil
 Lệnh (terminal) chuyển đổi IDS engine từ Snort sang Suricata:
sudo so-sensor-stop
sudo sed -i 's|ENGINE=snort|ENGINE=suricata|g'
/etc/nsm/securityonion.conf

18
 sudo rule-update
sudo so-sensor-start

 Lệnh (terminal) chuyển đổi IDS engine từ Suricata sang Snort:
sudo so-sensor-stop
sudo sed -i 's|ENGINE=suricata|ENGINE=snort|g'
/etc/nsm/securityonion.conf
sudo rule-update
sudo so-sensor-start

 Lệnh (terminal, trên master server) chuyển đổi IDS engine từ Snort sang
Suricata trong môi trường phân tán Salt:
sudo so-sensor-stop
sudo sed -i 's|ENGINE=snort|ENGINE=suricata|g'
/etc/nsm/securityonion.conf
sudo rule-update
sudo so-sensor-start
#The remaining commands assume all sensor hostnames contain
"securityonionsensor"
sudo salt '*securityonionsensor*' cmd.run 'so-sensor-stop'
sudo salt '*securityonionsensor*' cmd.run 'sed -i "s|ENGINE=snort|
ENGINE=suricata|g" /etc/nsm/securityonion.conf'
sudo salt '*securityonionsensor*' state.highstate
sudo salt '*securityonionsensor*' cmd.run 'so-sensor-start'

Một số NIDS trong Security Onion:

 Snort
 Suricata
 Zeek: tiền thân được biết đến với cái tên Bro
 netsniff-ng

2.2.5. Các công cụ hỗ trợ phân tích điểm cuối (Host Visibility)
Security Onion có thể sử dụng nhiều cách khác nhau để thu thập, phân tích bản ghi
từ các điểm cuối (end point) trong mạng. Security Onion sử dụng các công cụ như:
 Wazuh
Wazuh là một HIDS miễn phí, mã nguồn mở dành cho Windows, Linux
và Mac OS X. Khi thêm Wazuh agent vào các điểm cuối (end points)
19
 trên hệ thống mạng, người quản trị có thể quan sát được từ điểm cuối
(end point) đến điểm thoát (exit point). Wazuh thực hiện phân tích các
bản ghi (log), kiểm tra tính toàn vẹn của file, giám sát theo chính sách,
phát hiện rootkit, cảnh báo thời gian thực và phản hồi chủ động.
 Một số công cụ hỗ trợ khác:
o Elastic Beats
o Sysmon
o Autoruns
o Syslog

20
CHƯƠNG 2 Cách thức hoạt động của Security Onion
3.1. Kiến trúc
Để triển khai Security Onion có rất nhiều kiểu triển khai tùy thuộc vào mục đích sử dụng
từ một máy ảo nhỏ hay đến một hệ thống doanh nghiệm lớp hơn. Dựa trên mục đích
người ta chia Security Onion thành các kiến trúc sau:
 Import
 Evaluation
 Standalone
 Distributed.

Ảnh 3.18 Kiến trúc hoạt động tổng thể của Security Onion

21
3.1.1.Import
Kiến trúc đơn giản nhất là Import node. Import node là một node độc lập chạy vừa đủ các
thành phần để có thể nhập pcap bằng cách sử dụng so-import-pcap. Khi người quản trị
chạy so-import-pcap, nó sẽ phân tích pcap bằng cách sử dụng Suricata và Zeek và các
bản ghi kết quả được Filebeat thu thập và gửi đến Elasticsearch nơi chúng được phân tích
cú pháp và lập chỉ mục. Sau đó, người quản trị có thể xem các nhật ký đó trong Security
Onion Console (SOC).
3.1.2.Evaluation
Kiến trúc tiếp theo là Evaluation. Nó phức tạp hơn một chút so với Import vì nó có giao
diện mạng dành riêng cho việc đánh giá lưu lượng truy cập trực tiếp từ TAP hoặc SPAN
port. Các quy trình giám sát lưu lượng truy cập trên niffing interface và tạo nhật ký.
Filebeat thu thập các bản ghi đó và gửi chúng trực tiếp đến Elasticsearch nơi chúng được
phân tích cú pháp và lập chỉ mục. Chế độ Evaluation được thiết kế để cài đặt nhanh
chóng để tạm thời kiểm tra Security Onion. Nó hoàn toàn không được thiết kế để sử dụng
trong sản xuất.

22
 Ảnh 3.19 Kiến trúc Evaluation

3.1.3.Standalone
Triển khai theo mô hình Standalone, các thành phần của máy chủ (master) và các thành
phần của máy rà quét (sensor) đều hoạt động trên 1 box.
Kiến trúc này tương tự với Evaluation trong tất cả các thành phần ở trong 1 box. Tuy
nhiên, thay vì Filebeat gửi nhật ký trực tiếp đến Elasticsearch, nó sẽ gửi chúng đến
Logstash, tiếp theo nó được đưa đến Redis để xếp hàng đợi. Đường Logstash thứ hai kéo
các bản ghi ra khỏi Redis và gửi chúng đến ElasticSearch, nơi chúng được phân tích cú
pháp và lập chỉ mục.

23
 Ảnh 3.20 Kiến trúc Standalone

3.1.4.Distributed
Triển khai phân tán tiêu chuẩn bao gồm một manager node, một hoặc nhiều forward
nodes chạy các thành phần cảm biến mạng và một hoặc nhiều search nodes chạy các
thành phần Tìm kiếm đàn hồi. Kiến trúc này có thể trả trước nhiều hơn, nhưng nó cung
cấp khả năng mở rộng và hiệu suất cao hơn, vì người quản trị có thể chỉ cần thêm nhiều
nút hơn để xử lý nhiều nguồn lưu lượng truy cập hoặc nhật ký hơn. Kiến trúc này có thể
trả trước nhiều hơn, nhưng nó cung cấp khả năng mở rộng và hiệu suất cao hơn, vì người
quản trị có thể chỉ cần thêm nhiều nút hơn để xử lý nhiều nguồn lưu lượng truy cập hoặc
nhật ký hơn. Đây là loại kiến trúc được khuyên dùng.
Có tùy chọn chỉ sử dụng hai loại nút - manager node và một hoặc nhiều heavy nodes , tuy
nhiên, điều này không được khuyến nghị vì lý do hiệu suất và chỉ nên được sử dụng cho
mục đích thử nghiệm hoặc trong môi trường thông lượng thấp.

24
 Ảnh 3.21 Kiến trúc Distributed

Khi triển khai có thể rùy chọn sử dụng hai loại node đó là manager node và một hoặc
nhiều heavy node. Tuy nhiên, khuyến nghị không nên sử dụng heavy node vì hiệu xuất
thấp và chỉ sử dụng cho mục đích kiểm tra hoặc môi trường thông lượng thấp.
- Khuyến nghị chỉ triển khai nếu tiêu chuẩn distribute không thể triển khai được.
- Kiến trúc bao gồm một manager node và một hoặc nhiều heavy nodes.

3.1.5.Các loại nodes

a. Manager
Manager node chạy bản sao Elasticsearch trong local , quản lý cấu hình tìm kiếm nhiều
cụm để triển khai. Điều này bao gồm cấu hình cho các heavy nodes và search nodes (nếu
có), nhưng không phải forward nodes, vì chúng không chạy các thành phần của Elastic
Stack. Một nhà phân tích kết nối với máy chủ từ một máy trạm khách (thường là cài đặt

25
máy ảo Security Onion) để thực hiện các truy vấn và truy xuất dữ liệu. Một manager
node chạy các thành phần sau: Elasticsearch, Logstash, Kibaba, Curator, Elastalert,
Redis, Wazuh.
b. Forward Node
Khi sử dụng một forward node, thành phần Elastic Stack không được cài đặt. Filebeat
chuyển tiếp tất cả các logs tới Logstash trên manager node, nơi chúng được lưu trữ trong
Elasticsearch trên manager node hoặc một search node. Từ đó dữ liệu có thể được truy
vấn thống qua việc sử dụng tìm kiếm nhiều cụm.
Forward node chay các thành phần: Zeek, Suricata, Stenographer, Wazuh.
c. Search Node
Khi sử dụng một search node, Security Onion thực hiện triển khai phân tán sử dụng tìm
kiếm chéo chụm của Elasticsearch. Khi chúng ta cài đặt và chọn Search node, nó sẽ tạo
một local Elasticsearch và sau đó cấu hình manager node để truy vấn phiên bản đó. Điều
này được thực hiện bằng cách cập nhật _cluster/settings trên manager node vì thế nó sẽ
truy vấn phiên bản local Elasticsearch.
Search nodes chủ yếu thu thập các logs từ các node khác và lưu trữ chúng để tìm kiếm.
Search nodes chạy các thành phần: Elasticsearch, Logstash, Curator, Wazuh.
d. Heavy node
Tương tự như search node, heavy node mở rộng lưu trữ và xử lý các manager node. Tuy
nhiên, các heavy node cũng thực hiện các nhiệm vụ của cảm biến và do đó có hiệu suất
tổng thể thấp hơn.
Heavy node chạy các thành phần: Elasticsearch, Logstash, Curator, Zeek, Suricata,
Stenographer.

3.2.Cách thức hoạt động

Quy tắc hoạt động của IDS và IPS: [1]
3.2.1. IDS
IDS là công cụ dưới dạng phần mềm hoặc phần cứng có chức năng phát hiện
những truy cập trái phép đến một hệ thống máy tính hoặc mạng, thường xuất
phát từ internet
Kiến trúc của IDS bao gồm:
 Hệ thống cảm biến: thu thập những sự kiện liên quan đến an ninh hệ
thống

26
  Hệ thống phân tích: phát hiện tấn công và các hành vi đáng nghi dựa
trên hệ thống cảm biến
 Không gian lưu trữ: lưu trữ các sự kiện và kết quả phân tích
 Giao diện điều khiển: để cài đặt hệ thống IDS, cập nhật các trạng thái
bảo mật và kiểm tra các sự kiện/bản ghi từ hệ thống phân tích
3.2.2. IPS
 Các hệ thống/công cụ IDS thụ động sẽ chỉ cung cấp thông tin về các sự
kiện liên quan đến bảo mật hệ thống và lưu chúng vào trong các file
nhật ký (log), đồng thời các cảnh báo cũng sẽ được xuất hiện dưới dạng
cửa sổ hoặc thông qua một đường dẫn nào đó tới người quản trị hệ
thống.
 Các hệ thống IPS tương tự như các hệ thống IDS, hay có thể nói các hệ
thống IPS là mở rộng của các hệ thống IDS, do chúng có thể phản ứng
với những sự kiện hay cuộc tấn công xảy ra trong thời gian thực, có thể
bằng các hủy bỏ hoặc cấu hình lại tường lửa, hoặc chặn lưu lượng truy
cập từ nguồn gốc tấn công. Việc phản ứng chủ động này có thể được
thực hiện một cách tự động hoặc thông qua các lệnh thực thi.
Security Onion không hỗ trợ IPS.

3.3.Cài đặt
3.3.1.Yêu cầu phần cứng đối với Security Onion
 Security Onion chỉ hỗ trợ CPU có kiến trúc x86-64
 Các yêu cầu kĩ thuật tối thiểu (Nếu chỉ sử dụng import pcap, cài đặt
Security Onion 2 như một import node):
o 4GB RAM
o 2 nhân CPU
o 200GB không gian lưu trữ
 Với tất cả các case sử dụng, yêu cầu tối thiểu để chạy Security Onion 2 là:
o 12GB RAM
o 4 nhân CPU
o 200GB không gian lưu trữ
 Nếu sử dụng Elastic Stack, yêu cầu phải có tối thiểu 4 core CPU và 8GB
RAM, yêu cầu này sẽ gia tăng khi người quản trị giám sát và thu thập được
thêm nhiều lưu lượng mạng và thu thập được thêm nhiều bản ghi (log)
 Nên có UPS (bộ lưu điện) để phòng tránh các trường hợp shutdown thiết bị
không mong muốn, nhằm bảo vệ cho database của Security Onion không bị
hư hại trong quá trình giám sát mạng

27
  NIC:
o Ít nhất 1 kết nối có dây kết nối tới môi trường mạng cần giám sát,
nên là kết nối có địa chỉ IP tĩnh (static). Kết nối không dây vẫn có
thể được sử dụng, nhưng sẽ không được hỗ trợ tốt, do Security
Onion được thiết kế để sử dụng với kết nối có dây
o Security Onion yêu cầu ít nhất 1 network interface để thực hiện
sniffing (kết nối tới PAT hoặc SPAN port). Network interface này
nên là một thiết bị khác để tránh gây xung đột phần cứng trong máy
Security Onion. Network interface ảo hóa (virtualized) cũng có thể
được sử dụng, nhưng hãy cân nhắc cân bằng phân bố tài nguyên để
hệ thống có thể hoạt động ổn định.
 Phân vùng không gian lưu trữ:
o Nếu sử dụng Security Onion từ file ISO image, việc phân vùng
không gian lưu trữ đã dược thực hiện trước
o /boot: ít nhất 500MB
o /nsm: hầu hết dữ liệu sẽ được ghi vào /nms, nên giành ra ít nhất
100GB cho vùng lưu trữ này
o /: vùng root chứa /var/lib/docker/, cần ít nhất 100GB
o /tmp: ít nhất 2GB
o swap: vùng nhớ được sử dụng thay cho RAM trong một số trường
hợp, nên đặt dung lượng ít nhất 8GB
3.3.2. Môi trường cài đặt
 Cài đặt bằng file ISO image của Security Onion (tải về tại trang web
https://securityonionsolutions.com/), hoặc tải về ISO image của Ubuntu
(bản 16.04 trở lên) và thực hiện cài đặt/thêm các Security Onion PPA và các
package liên quan
 Luôn phải thực hiện xác nhận file ISO image được tải về
(hướng dẫn : https://github.com/Security-Onion-Solutions/security-
onion/blob/master/Verify_ISO.md)
 Sử dụng máy ảo:
o Vmware
o Virtualbox
 Virtualbox có chức năng snapshot để lưu lại trạng thái của máy ảo
Việc này sẽ rất hữu ích khi người sử dụng có thể thay đổi một cài đặt
nào đó, hiểu trạng thái thay đổi sau khi cài đặt và có thể chuyển đổi
về trạng thái cũ (theo snapshot đã lưu)

3.3.3.Các tác vụ cần thực hiện sau khi cài đặt xong:

28
 Thay đổi kích thước màn hình phù hợp với kích thước màn hình (displayer) của
thiết bị:
 Click vào menu “Applications” ở góc trên cùng bên trái
 Click “System Tools”
 Click “Setttings”
 Click “Displays”
 Chọn thiết bị hiển thị (display)
 Chọn độ phân giải phù hợp
 Click “Apply”
 Kiểm tra service:
o Xác nhận các server có hoạt động hay không bằng lệnh terminal:
sudo so-status
o Nếu có bất kì một service nào hiển thị không hoạt động, khởi động lại bằng
lệnh:
sudo so-start
o Đăng nhập vào Sguil, Squert, hoặc Kibana và xác nhận các công cụ đó có
ghi nhận được các log. Nếu không hiển thị một IDS arlert nào, có thể kiểm
tra IDS bằng câu lệnh terminal sau (yêu cầu có đường truyền internet):
curl http://testmyids.com
 Tùy chọn:
o Thêm người dùng mới bằng câu lệnh:
sudo so-user-add
o Trên hệ thống sử dụng cơ sở dữ liệu của Sguil, biến số DAYSTOKEEP
trong file config /etc/nsm/securityonion.conf cho phép người quản trị quyết
định bản ghi chỉ có thể được lưu trữ trong bộ nhớ trong vòng bao nhiêu
ngày, mặc định được cài đặt là 30
o Cài đặt định dạng HOMENET: mặc định là chuẩn RFC1918
(192.168.0.0/16, 10.0.0.0/8,172.16.0.0/12), người quản trị có thể sẽ phải cài
đặt lại nếu phải quản lý dải IP khác chuẩn RFC1918. File cài đặt cấu hình
sensor có thể được tìm thấy ở đường dẫn /etc/nsm/$HOSTNAME-
$INTERFACE/ . Sửa file snort.conf hoặc suricata.yaml (phụ thuộc vào lựa
chọn IDS engine của người quản trị trong quá trình cài đặt) và cập nhật
biến số HOME_NET (có thể thêm cả EXTERNAL_NET). Sau đó, cập nhật
file cài đặt/cấu hình của Zeek tại đường dẫn /opt/bro/etc/networks.cfg .
Cuối cùng, khởi động lại sensor bằng lệnh:
sudo so-sensor-restart
o
o Cài đặt cảnh báo qua email
o Cài đặt version control
o Cài đặt remote desktop đến server/sensor

29


30
CHƯƠNG 3 Luật trong Security Onion
Ở các phiên bản cũ của Security Onion, chúng ta có thể lựa chọn Snort hoặc
Suricata làm hệ thống phát hiện xâm nhập mạng (NIDS). Nhưng ở phiên bản Security
Onion mới nhất (Security Onion 2), Snort được loại bỏ, vì vậy Suricata là hệ thống phát
hiện xâm nhập mạng cho Security Onion. Chính vì vậy, phần tìm hiểu về luật dưới đây sẽ
tập trung vào luật của Suricata.
Một luật trong Suricata được chia thành hai phần đó là phần Rule header và Rule
options. Phần Rule header bao gồm: Rule Action, Protocol, địa chỉ IP nguồn, địa chỉ IP
đích, Subnetmask, Port nguồn, Port đích. Phần Rule options bao gồm các thông điệp cảnh
báo, thông tin các phần của gói tin sẽ được kiểm tra để xác định xem hành động nào sẽ
được áp dụng.

Ảnh 4.22 Cấu trúc luật trong Suricata

Cấu trúc luật trong Suricata

Ảnh 4.23 Ví dụ luật trong Suricata

Để cập nhật rule cho master server, trong cửa sổ terminal, chạy lệnh:
sudo rule-update
Nếu triển khai theo mô hình phân tán với Salt và chạy rule-update trên máy server, thì
rule mới sẽ được cập nhật từ server đến các sensor trong vòng 15 phút., hoặc cũng có thể
ép sensor phải thực hiện update ngay lập tức bằng cách sử dụng lệnh sau:

31
 sudo salt '*' state.highstate
Nếu triển khai theo mô hình phân tán không có Salt và chạy rule-update trên máy server,
thì rule mới sẽ được cập nhật từ server đến các sensor sau một khoảng thời gian, hoặc
cũng có thể ép sensor phải thực hiện update ngay lập tức bằng cách sử dụng lệnh sau:
sudo rule-update

4.1. Rule Header

Phần Header sẽ chứa các thông tin xác định ai, ở đâu, cái gì của một gói tin, cũng
như phải làm gì nếu tất cả các thuộc tính trong luật được hiện lên
4.1.1 Rule Action
Mục đầu tiên trong một luật đó chính là phần rule action, rule action sẽ nói cho
Suricata biết phải làm gì khi thấy các gói tin phù hợp với các luật đã được quy định sẵn.
Có 4 hành động mặc định trong Suricata đó là: pass (cho qua), drop (chặn gói tin), reject,
alert (cảnh báo).
 Pass: nếu signature được so sánh trùng khớp và chỉ ra là pass thì Suricata sẽ
thực hiện dừng quét gói tin và bỏ qua tất cả các luật phía sau đối với gói tin
này.
 Drop: nếu chương trình tìm thấy một signature hợp lệ và nó chỉ ra là drop thì
gói tin đó sẽ bị hủy bỏ và dừng truyền ngay lập tức, khi đó gói tin không thể
đến được nơi nhận.
 Reject: là hành động bỏ qua gói tin, bỏ qua ở cả bên nhận và bên gửi.
Suricata sẽ tạo ra một cảnh báo với gó i tin này.
 Alert: nếu signature được sánh là hợp lệ và có chứa một alert thì gói tin đó
sẽ được xử lý giống như với một gói tin không hợp lệ. Suricata sẽ tạo ra một
cảnh báo.
4.1.2. Protocol
Trường tiếp theo trong luật đó là protocol. Các giao thức mà Suricata hiện đang
phân tích các hành vi bất thường đó là TLS, SSH, SMTP (tải thư điện tử qua mạng

32
internet), IMAP (đặt sự kiểm soát email trên mail server), MSN, SMB (chia sẻ file), TCP,
UDP, ICMP và IP, DNS.
4.1.3. IP Address
Mục tiếp theo của phần header đó là địa chỉ IP. Các địa chỉ này dùng để kiểm tra
nơi đi và nơi đến của một gói tin. Địa chỉ ip đó có thể là địa chỉ của một máy đơn hoặc
cũng có thể là địa chỉ của một lớp mạng. Từ khóa “any” được sử dụng để định nghĩa một
địa chỉ bất kỳ.
Một địa chỉ ip sẽ được viết dưới dạng ip_address/netmask. Điều này có nghĩa là
nếu netmask là /24 thì lớp mạng đó là lớp mạng C, /16 là lớp mạng B hoặc /32 là chỉ một
máy đơn. Ví dụ: địa c hỉ 192.168.1.0/24 có nghĩa là một dải máy có địa chỉ IP từ
192.168.1.1-192.168.1.255.
Trong hai địa chỉ IP trong một luật Suricata thì sẽ có một địa chỉ IP nguồn và một
địa chỉ IP đích. Việc xác định đâu là địa chỉ nguồn, đâu là địa chỉ đích phụ thuộc vào
“→”.
Ngoài ra toán tử phủ định có thể được áp dụng cho việc định địa chỉ IP. Có nghĩa
là khi sử dụng toán tử này thì Suricata sẽ bỏ qua việc kiểm tra địa chỉ của gói tin đó. Toán
tử đó là “!”. Ngoài ra ta có thể định nghĩa một danh sách các địa chỉ IP bằng cách viết
liên tiếp chúng cách nhau bởi một dấu “,”.
Ví dụ:
Alert TCP any any → ![192.168.1.0/24, 172.16.0.0/16] 80 (msg: “Access”)
4.1.4. Port
Port có thể được định nghĩa bằng nhiều cách. Với từ khóa “any” giống như địa
chỉ IP để chỉ có thể sử dụng bất kỳ port nào. Gán một port cố định, ví dụ như gán kiểm tra
ở port 80 http hoặc port 22 ssh. Ngoài ra ta cũng có thể sử dụng toán tử phủ định để bỏ
qua một port nào đó hoặc liệt kê một dải các port.
Ví dụ:
Alert UDP any any → 192.168.1.0/24 1:1024 => port bất kỳ tới dãy port từ 1 - 1024.
Alert UDP any any → 192.168.1.0/24 :6000 => port bất kỳ tới dãy port nhỏ hơn
6000.

33
 Alert UDP any any → 192.168.1.0/24 !6000:6010 => port bất kỳ tới bất kỳ port
nào, bỏ qua dãy port từ 6000 –
6010.
4.1.5. Điều hướng
Toán tử hướng “→” chỉ ra đâu là hướng nguồn, đâu là hướng đích. Phần địa chỉ
IP và port ở phía bên trái của toán tử được coi như là địa chỉ nguồn và port nguồn, phần
bên phải được coi như địa chỉ đích và port đích. Ngoài ra còn có toán tử “<>” Suricata sẽ
xem cặp địa chỉ/port nguồn và đích là như nhau. Nghĩa là nó sẽ ghi/phân tích ở cả hai
phía của cuộc hội thoại.
Ví dụ:
Alert TCP !192.168.1.0/24 any <> 192.168.1.0/24 23
4.2. Rule Option
Rule options chính là trung tâm của việc phát hiện xâm nhập. Nội dung chứa các dấu
hiệu để xác định một cuộc xâm nhập. Nó nằm ngay sau phần Rule Header và được bọc bởi
dấu ngoặc đơn “()”. Tất cả các rule options sẽ được phân cách nhau bởi dấu chấm phẩy “;”,
phần đối số sẽ được tách ra bởi dấy hai chấm “:”.
Có 4 loại rule options chính bao gồm:
- General: Tùy chọn này cung cấp thông tin về luật đó nhưng không có bất cứ ảnh
hưởng nào trong quá trình phát hiện.
- Payload: Tùy chọn liên quan đến phần tải trong một gói tin.
- Non-payload: Bao gồm các tùy chọn không liên quan đến phần tải của gói tin
(header).
- Post-detection: Các tùy chọn này sẽ gây ra những quy tắc cụ thể sau khi một luật
đã được kích hoạt.
4.2.1. General
 Msg
Msg (Message): được dùng để cho biết thêm thông tin về từng signature và các
cảnh báo. Phần đầu tiên sẽ cho biết tên tập tin của signature và phần này quy ước là phải
viết bằng chữ in hoa. Định dạng của msg như sau:
34
 msg: “..........”;

 Sid
Sid (signature id): cho ta biết định danh riêng của mỗi signature. Định danh này
được bắt đầu với số. Định dạng của sid như sau:

sid:123;

 Rev
Rev (revision): mỗi sid thường đi kèm với một rev. Rev đại diện cho các phiên bản
của signature. Mỗi khi signature được sửa đổi thì số rev sẽ được tăng lên bởi người tạo ra.
Định dạng của rev như sau:

rev:123;

 Reference
Reference: cung cấp cho ta địa chỉ đến được những nơi chứa các thông tin đầy đủ
về signature. Các tham chiếu có thể xuất hiện nhiều lần trong một signature. Ví dụ về một
tham chiếu như sau:

reference: url, www.info.nl

Các tuỳ chọn của Reference:

system URL Prefix
bugtraq http://www.securityfocus.com/bid
cve http://cve.mitre.org/cgi-bin/cvename.cgi?name=
nessus http://cgi.nessus.org/plugins/dump.php3?id=
arachnids (No longer available but you might still encounter this in signatures.)
http://www.whitehats.com/info/IDS
mcafee http://vil.nai.com/vil/dispVirus.asp?virus_k=
url http://

 Classtype
Classtype: cung cấp thông tin về việc phân loại các lớp quy tắc và cảnh báo.
Mỗi lớp bao gồm một tên ngắn gọn, một tên đầy đủ và mức độ ưu tiên.

35
 Ví dụ:

Config classification: web-application-attack,Web Application Attack,1

config classification: not-suspicious,Not Suspicious Traffic,3

Ảnh 4.24 Thông tin phân loại lớp quy tắc

 Priority
Priority: chỉ ra mức độ ưu tiên của mỗi signature. Các giá trị ưu tiên dao động từ 1
đến 255, nhưng thường sử dụng các giá trị từ 1 -> 4. Mức ưu tiên cao nhất là 1. Những
signature có mức ưu tiên cao hơn sẽ được kiểm tra trước. Định dạng chỉ mức ưu tiên như
sau:

priority:1;

 Metadata
Metadata: Suricata sẽ bỏ qua những gì viết sau metadata. Định dạng của
metadata như sau:

metadata:......;

4.2.2. Payload
 Content

36
 Content: thể hiện nội dung chúng ta cần viết trong signature, nội dung này được
đặt giữa 2 dấu nháy kép. Nội dung là các byte dữ liệu, có 256 giá trị khác nhau (0-255).
Chúng có thể là các ký tự thường, ký tự hoa, các ký tự đặc biệt, hay là các mã hexa tương
ứng với các ký tự và các mã hexa này phải được đặt giữa 2 dấu gạch dọc. Định dạng của
một nội dung như sau:

content: ”............”;

Một số ký tự đặc biệt, khi cho trong nội dung chỉ có thể sử dụng các mã hexa để biểu
diễn nó.

“ |22|
; |3B|
: |3A|
| |7C|

 Nocase
Nocase: được dùng để chỉnh sửa nội dung thành các chữ thường, không tạo ra sự
khác biệt giữa chữ hoa và chữ thường. Nocase cần được đặt sau nội dung cần
chỉnh sửa.
Ví dụ:
content: “abC”; nocase;
 Depth
Depth: sau từ khóa depth là một số, chỉ ra bao nhiêu byte từ đầu một payload cần
được kiểm tra. Depth cần được đặt sau một nội dung. Ví dụ: ta có một payload:
abCdefghij. Ta thực hiện kiểm tra 3 byte đầu của payload.

content: “abC”; depth:3;

 Offset
Offset: chỉ độ lệch byte trong tải trọng sẽ được kiểm tra. Ví dụ: độ lệch là 3 thì sẽ
kiểm tra từ byte thứ 4 trong tải trọng.

37
 content: “def”; offset:3;

Ví dụ:
Alert TCP 192.168.1.0/24 any -> any any (content: \"HTTP"; offset: 4; depth:
40; msg: "HTTP matched";)
 Distance
Distance: xác định khoảng cách giữa các nội dung cần kiểm tra trong payload.
Khoảng cách này có thể là một số âm.
Ví dụ:
content: “abC”; content: “efg”; distance:1;
 Within
Within: được dùng cùng với distance, để chỉ độ rộng của các byte cần kiểm tra sau
một nội dung với khoảng cách cho trước đó.
Ví dụ:
content:"GET"; depth:3 content:"download"; distance:10 \within:9;
Luật có nghĩa là tìm “GET” trong 3 byte đầu tiên của trường dữ liệu, di chuyển
thêm 10 byte bắt đ ầu từ “GET” và tìm khớp “download”. Tuy nhiên, “download” phải
xuất hiện trong 9 byte tiếp theo.
 Dsize
Dsize: được dùng để tìm một payload có độ dài bất kỳ.

dsize:min<>max;

 Rpc
Rpc (Remote Procedure Call): là một ứng dụng cho phép một chương trình máy
tính thực hiện một thủ tục nào đó trên một máy tính khác, thường được sử dụng cho quá
trình liên lạc. Định dạng của rpc như sau:

rpc:<application number>, [<version number>|*], [<procedure number>|*]>;

 Replace

38
 Replace được dùng để thay đổi nội dung của payload, điều chỉnh lưu lượng mạng.
Việc sửa đổi nội dung của payload chỉ có thể được thực hiện đối với gói dữ liệu cá nhân.
Sau khi thực hiện thay đổi nội dung xong thì Suricata sẽ thực hiện tính toán lại trường
checksum.
4.2.3. Non-Payload
a. IP
 ttl
Được sử dụng để kiểm tra về thời gian sống, tồn tại tên mạng của một địa chỉ IP
cụ thể trong phần đầu của mỗi gói tin. Giá trị time-to-live (thời gian sống), xác định thời
gian tối đa mà mỗi gói tin có thể được lưu thông trên hệ thống mạng. Nếu giá trị này về 0
thì gói tin sẽ bị hủy bỏ. Thời gian sống được xác định dựa trên số hop, khi đi qua mỗi
hop/router thì thời gian sống sẽ bị trừ đi 1. Cơ chế này nhằm hạn chế việc gói tin lưu
thông trên mạng vô thời hạn. Định dạng của một ttl như sau:

ttl:<number>;

 ipopts
Chúng ta có thể xem và tùy chỉnh các tùy chọn cho việc thiết lập các địa chỉ IP.
Việc thiết lập các tùy chọn cần được thực hiện khi bắt đầu một quy tắc. Một số tùy chọn
có thể sử dụng:

Ảnh 4.25 Một số tuỳ chọn của Ipopts

39
 Định dạng của một ipopts như sau:

ipopts: <name>;

 sameip
Mỗi gói tin sẽ có một địa chỉ IP nguồn và đích. Chúng ta có thể sử dụng sameip
để kiểm tra xem địa chỉ IP nguồn và đích có trùng nhau hay không. Định dạng của
sameip như sau:

sameip;

 Ip_proto
Được dùng để giúp ta lựa chọn giao thức. Ta có thể chọn theo tên hoặc số tương
ứng với từng giao thức. Có một số giao thức phổ biến sau:

1 ICMP Internet Control Message

6 TCP Transmission Control Protocol
17 UDP User Datagram
47 GRE General Routing Encapsulation
50 ESP Encap Security Payload for IPv6
51 AH Authentication Header for Ipv6
58 IPv6-ICMP ICMP for Ipv6

Định dạng của ip_proto như sau:

ip_proto:<number/name>;

 Id
Được sử dụng để định danh cho các phân mảnh của gói tin được truyền đi. Khi
gói tin truyền đi sẽ được phân mảnh, và các mảnh của một gói tin sẽ có ID giống nhau.
Việc này giúp ích cho việc ghép lại gói tin một cách dễ dàng. Định dạng như sau:

id:<number>;

 Geoip

40
 Cho phép xác định địa chỉ nguồn, đích để gói tin lưu thông trên mạng.
 Fragbits
Fragbits được dùng để kiểm tra về tính phân mảnh của gói tin, nó được thiết lập trong
tiêu đề của gói tin và nằm tại vị trí đầu của rule.

 Cú pháp:

fragbits:[*+!]<[MDR]>;
fragbits:
-M tiếp tục phân mảnh gói tin
-D không phân mảnh
-R Reversed bit

Một vài tuỳ chọn đi kèm theo như:

+ Khóp với bit được chỉ định

* Khớp với bất kì bit nào được thiết lập
! Khớp nếu không có bit nào được thiết lập

 Fragoffset
Kiểm tra sự phù hợp trên các giá trị thập phân của từng mảnh gói tin trên trường
offset. Nếu muốn kiểm tra phân mảnh đầu tiên của gói tin, chúng ta cần kết hợp
fragoffset 0 với các tùy chọn fragment khác.

 Cú pháp:

fragoffset:[!|<|>]<number>;
< khớp nếu giá trị nhỏ hơn giá trị được chỉ định
> khớp nếu giá trị lớn hơn giá trị được chỉ định
! khớp nếu không có giá trị được chỉ định

b. TCP
 Sed

41
 Là một số ngẫu nhiên được tạo ra ở cả bên nhận và bên gửi gói tin để kiểm tra
số thứ tự của các gói tin đến và đi. Máy khách và máy chủ sẽ tự tạo ra một số seq
riêng của mình. Khi một gói tin được truyền thì số seq này sẽ tăng lên 1. Seq giúp
chúng ta theo dõi được những gì diễn ra khi một dòng dữ liệu được truyền đi.
 Ack
Được sử dụng để kiểm tra xem gói tin đã được nhận bởi nơi nhận hay chưa trong
giao thức kết nối TCP. Số thứ tự của ACK sẽ tăng lên tương ứng với số byte dữ liệu đã
được nhận thành công.
 Window
Được sử dụng để kiểm tra kích thước của cửa sổ TCP. Kích thước cửa sổ TCP là
một cơ chế dùng để kiểm soát các dòng dữ liệu. Cửa sổ được thiết lập bởi người nhận, nó
chỉ ra số lượng byte có thể nhận để tránh tình trạng bên nhận bị tràn dữ liệu. Giá trị kích
thước của cửa sổ có thể chạy từ 2 đến 65.535 byte.
c. ICMP
 Itype
Cung cấp cho việc xác định các loại ICMP. Các thông điệp khác nhau sẽ được phân
biệt bởi các tên khác nhau hay các giá trị khác nhau.
Định dạng của itype như sau:

itype:min<>max;
itype:[<|>]<number>;

42
 Ảnh 4.26 Bảng Type của ICMP Header

 Icode
Cho phép xác định mã của từng ICMP để làm rõ hơn cho từng gói tin ICMP. Định
dạng của icode như sau:

icode:min<>max;
icode:[<|>]<number>;

 Icmp_id
43
 Mỗi gói tin ICMP có một giá trị ID khi chúng được gửi. Tại thời điểm đó, người
nhận sẽ trả lại tin nhắn với cùng một giá trị ID để người gửi sẽ nhận ra và kết nối nó đúng
với yêu cầu ICMP đã gửi trước đó. Định dạng của một icmp_id như sau:

icmp_id:<number>;

 Icmp_seq
Được sử dụng để kiểm tra số thứ tự của ICMP. Định dạng của icmp_seq như sau:

icmp_seq:<number>;

d. HTTP
http_method Chỉ ra các phương thức được áp dụng với các request http. Các
phương thức http: GET, POST, PUT, HEAD, DELETE, TRACE,
OPTIONS, CONNECT và PATCH.
http_uri Chỉ ra đường dẫn tới nơi chứa nội dung yêu cầu.
http_raw_uri
http_header Chỉ ra phương thức sử dụng, địa chỉ cần truy cập tới và tình trạng
kết nối.
http_user_agent Là một phần của http_header, chỉ ra thông tin về trình duyệt của
người dùng.
http_client_body Chỉ ra các yêu cầu của máy trạm
http_stat_code Chỉ ra mã trạng thái của server mà máy trạm yêu cầu kết nối tới.
http_stat_msg Các dòng tin thông báo về tình trạng máy chủ, hay tình trạng về
việc đáp ứng các yêu cầu kết nối của máy trạm.
http_server_body Chỉ ra nội dung đáp trả các yêu cầu từ máy trạm của máy chủ.

File_data Chỉ ra nội dung, đường dẫn tới file chứa dữ liệu được yêu cầu.

e. Flow
 Flowbits
Gồm 2 phần, phần đầu mô tả các hành động được thực hiện, phần thứ 2 là tên của
flowbit. Các hành động của flowbit:

44
 flowbits: set, name Được dùng để thiết lập các điều kiện/tên cho các flow.
flowbits: isset, name Có thể được sử dụng trong các luật để đảm bảo rằng sẽ
tạo ra một cảnh báo khi các luật là phù hợp và các điều
kiện sẽ được thiết lập trong flow.
flowbits: toggle, name Dùng để đảo ngược các thiết lập hiện tại.
flowbits: unset, name Được sử dụng để bỏ các thiết lập về điều kiện trong luật.
flowbits: isnotset, name Được sử dụng để đảm bảo rằng sẽ tạo ra một cảnh báo
khi các luật là phù hợp và các điều kiện sẽ không được
thiết lập trong flow.

 Flow
Có thể được sử dụng để kết nối các thư mục chứa các flow lại với nhau. Các flow
có thể được đi từ hoặc đến từ Client/Server và các flow này có thể ở trạng thái được
thiết lập hoặc không. Việc kết nối các flow có thể xảy ra các trường hợp sau:

wq

4.3: Add Local Rules

4.3.1.Giới thiệu
Thêm luật cục bộ trong Security Onion là một quá trình khá đơn giản. Tuy nhiên, việc tạo
lưu lượng truy cập tùy chỉnh để kiểm tra cảnh báo đôi khi có thể là một thách thức. Ở
đây, chúng tôi sẽ chỉ cho bạn cách thêm quy tắc cục bộ và sau đó sử dụng trình quét thư
viện python để kích hoạt cảnh báo.

4.3.2.Chính sách IPS

Xin lưu ý nếu bạn đang sử dụng bộ quy tắc cho phép sử dụng chính sách
IPS /etc/nsm/pulledpork/pulledpork.conf, các quy tắc cục bộ của bạn sẽ bị vô hiệu
hóa. Để bật chúng, hãy hoàn nguyên chính sách bằng cách đánh dấu lại ips_policydòng
(và chạy rule-update) hoặc thêm loại chính sách vào các quy tắc trong local.rules.
Ví dụ: nếu ips_policyđược đặt thành security, bạn sẽ thêm phần sau vào mỗi quy tắc:
metadata:policy security-ips
Toàn bộ quy tắc sau đó sẽ giống như sau:

alert tcp any any -> $HOME_NET 7789 (msg: "Vote for Security Onion Toolsmith Tool
of 2011!"; reference: url,http://holisticinfosec.blogspot.com/2011/12/choose-2011-
toolsmith-tool-of-year.html; content: "toolsmith"; flow:to_server; nocase; sid:9000547;
metadata:policy security-ips; rev:1)
Các loại chính sách này có thể được tìm thấy trong /etc/nsm/rules/downloaded.rules.

45
4.3.3.Các bước thực hiện

 Mở /etc/nsm/rules/local.rulesbằng trình soạn thảo văn bản yêu thích của bạn. Nếu
đây là một triển khai phân tán, hãy chỉnh sửa local.rules trên máy chủ chính của
bạn và nó sẽ sao chép sang các cảm biến của bạn.

 Hãy thêm một quy tắc đơn giản sẽ cảnh báo việc phát hiện một chuỗi trong phiên
tcp.

alert tcp any any -> $HOME_NET 7789 (msg: "Vote for Security Onion Toolsmith Tool
of 2011!"; reference: url,http://holisticinfosec.blogspot.com/2011/12/choose-2011-
toolsmith-tool-of-year.html; content: "toolsmith"; flow:to_server; nocase; sid:9000547;
rev:1)

 Chạy rule-update (thao tác này sẽ hợp nhất local.rules thành download.rules, cập
nhật sid-msg.mapvà khởi động lại snort / suricata và barnyard):

sudo rule-update

 Nếu bạn đã xây dựng quy tắc một cách chính xác, thì snort sẽ được sao lưu và
chạy.

 Tạo một số lưu lượng truy cập để kích hoạt cảnh báo. Để tạo lưu lượng truy cập,
chúng tôi sẽ sử dụng trình quét thư viện python để tạo các gói với thông tin cụ thể
để đảm bảo chúng tôi kích hoạt cảnh báo với thông tin chúng tôi muốn.

sudo scapy

 Nhập mẫu sau vào một dòng tại một thời điểm. Bất kỳ dòng nào bắt đầu bằng "#"
đều có thể bị bỏ qua vì nó là một nhận xét.

# Craft the layer 2 information.

# The ip addresses can be random, but I would suggest sticking to RFC1918
ip = IP()
ip.dst = "192.168.200.4"
ip.src = "192.168.100.3"

# Craft the layer 3 information.

# Since we specified port 7789 in our snort rule,
tcp = TCP()
tcp.dport = 7789
tcp.sport = 1234

46
# Set the playload
payload = "Toolsmith"

# Use the / operator to compose our packet and transfer it with the send() method.
send(ip/tcp/payload)

 Kiểm tra sguil để biết cảnh báo tương ứng

Ảnh 4.27 Kiểm tra sguil để biết cảnh báo tương ứng

 Bạn có thể thấy rằng chúng tôi có một cảnh báo với các địa chỉ IP mà chúng tôi đã
chỉ định và các cổng TCP mà chúng tôi đã chỉ định. Nếu bạn nhấp chuột phải
vào cột ID cảnh báo, bạn có thể chọn " Transcript " và xác minh payload mà
chúng tôi đã gửi.

47
Ảnh 4.28 Xác minh payload

48
CHƯƠNG 4 Ứng dụng Security Onion giám sát môi trường
mạng doanh nghiệp

5.1. Các công cụ được sử dụng

5.1.1. Sguil
5.1.1.1. Tổng quan [4]
Sguil là một bộ phần mềm mã nguồn mở NSM (Network Security Monitoring)
được viết bởi Bamm Visscher
Sguil được sử dụng để giám sát an toàn mạng và phân tích các sự kiện dựa trên
các cảnh báo IDS.
Sguil client được viết bằng ngôn ngữ Tcl/Tk và có thể hoạt động trên mọi hệ
điều hành hỗ trợ ngôn ngữ đó.
Sguil được phát hành với chứng chỉ GPL 3.0 .

Ảnh 5.29 Giao diện Sguil 0.9.0

5.1.1.2. Thành phần cấu thành Sguil

 Các thành phần chính của Sguil có thể tóm gọi như sau:

49
 o GUI (Console): Giao diện người dùng trực quan, hiển thị đầy đủ những
thành phần quan trọng giúp người dùng dễ dàng trong việc quản trị
mạng, quản lý rủi ro trong mạng
o Hệ cơ sở dữ liệu sử dụng MySQL: lưu trữ các cảnh báo IDS, các dữ liệu
phiên, các thống kê, các chữ ký, thời gian, mức độ của cảnh báo (bình
thường/nghi ngờ/độc hại,...), số lần xuất hiện của cảnh báo, nguồn
gốc/đích của các cảnh báo,...
o Server: nhận các cảnh báo và dữ liệu thời gian thực từ sensor và đưa
chúng lên cửa sổ GUI
o Sensor: là các network interface được cài đặt để giám sát hệ thống mạng
(sniffing interface)
o IDS (Rule engine): sử dụng Snort hoặc Suricata, Sguil sẽ dựa vào rule
engine để đưa ra các cảnh báo (chủ yếu là cảnh báo IDS)

 Chi tiết hơn, các công cụ cấu thành Sguil bao gồm [4]:
o Hệ thống cơ sở dữ liệu và truy vấn sử đụng MySQL 4.x hoặc 5.x
o Snort/Suricata: sinh ra các cảnh báo xâm nhập, phát hiện xâm nhập, bắt
đầy đủ gói tin,...
o Barnyard: decode các cảnh báo IDS từ Snort và gửi về cho Sguil

Ảnh 5.30 Barnyard nhận các cảnh báo từ Snort IDS, sử lý và lưu vào database

o SANCP: các bản ghi TCP/IP

o Tcpflow: đưa ra một bản mã ASCII của một phiên TCP

50
 o p0f: giúp định danh các hệ thống (có thể hiểu là các điểm cuối – end
point) hoạt động trong mạng (hoạt động hiểu là việc gửi nhận các lưu
lượng mạng trong hệ thống mạng đi từ hoặc đến một điểm đến nhất định
trong mạng)[5]
o tcpdump: phân tích các phiên từ bản ghi các gói tin bắt được
o Wireshark: công cụ phân tích gói tin mạnh mẽ

5.1.1.3. Kiến trúc

Ảnh 5.31 Tổng quan kiến trúc của Sguil

51
 Ảnh 5.32 Tổng quan kiến trúc của Sguil (2)

 Các sensors được đặt ở các điểm trong hệ thống mạng sẽ thực hiện bắt
các gói pcap, các gói tin, các phiên,... xảy ra trong hệ thống mạng và gửi
về Sguil server.
 Server sẽ dựa vào các IDS (rule engine) thực hiện sàng lọc và đưa ra các
cảnh báo về cho các client (mặc định thông qua port 7734), đồng thời
lưu các dữ liệu liên quan vào hệ quản trị cơ sở dữ liệu MySQL.
 Tại các client, người quản trị có thể thực hiện phân tích và đánh giá rủi
ro thông qua các cảnh báo được đưa lên giao diện GUI.

5.1.2. Wazuh
5.1.2.1. Giới thiệu
a. Tổng quan
Wazuh là 1 dự án mã nguồn mở về phát hiện bảo mật. Nó được sinh ra từ 1 nhánh của
OSSEC HIDS, và sau đó được tích hợp với Elastic Stack và OpenSCAP.
 OSSEC HIDS là Hệ thống phát hiện xâm nhập dựa trên máy chủ (HIDS) được sử
dụng để phát hiện bảo mật.

52
  OpenSCAP là trình thông dịch OVAL và XCCDF được sử dụng để kiểm tra cấu
hình hệ thống và để phát hiện các ứng dụng dễ bị tấn công.
 Elastic Stack là một bộ phần mềm (Filebeat, Elasticsearch, Kibana) được sử dụng
để thu thập, phân tích, lập chỉ mục, lưu trữ, tìm kiếm và trình bày dữ liệu nhật ký.
b. Thành phần
 Wazuh Agent: chạy trên: Windows, Linux, Solaris, BSD hoặc MAC OS. Được
dùng để thu thập các dạng dữ liệu khác nhau của hệ thống và ứng dụng. Dữ liệu
sau đó được chuyển tới Wazuh server thông qua 1 kênh được mã hóa và xác thực.
 Wazuh Server: chịu trách nhiệm phân tích dữ liệu nhận được từ các Wazuh Agent
và kích hoạt cảnh báo khi một sự kiện phù hợp với quy tắc (ví dụ: phát hiện xâm
nhập, thay đổi tệp, cấu hình không tuân thủ chính sách, rootkit có thể, v.v.).
 Elastic Stack: Wazuh tích hợp với Elastic stack để cung cấp các log message đã
được giải mã và đánh index bởi Elasticsearch, cũng như là 1 web console real-time
cho việc cảnh báo và phân tích log. Wazuh web interface (chạy trên Kibana) có thể
dùng để quản lý và giám sát hạ tầng Wazuh
c. Các tính năng
 Giám sát Agentless:cho phép ta giám sát các thiết bị hoặc hệ thống không có
agent thông qua SSH, chẳng hạn như bộ định tuyến, tường lửa, thiết bị chuyển
mạch và hệ thống linux bsd. Điều này cho phép người dùng với các hạn chế cài
đặt phần mềm để đáp ứng các yêu cầu bảo mật và tuân thủ.
 Giám sát toàn vẹn tệp: Hệ thống giám sát toàn vẹn tệp (FIM) của Wazuh xem
các tệp được 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.
 Auditing who-data: Thành phần này chứa thông tin người dùng đã thực hiện các
thay đổi trên các tệp được theo dõi và cả tên chương trình hoặc quy trình được sử
dụng để thực hiện chúng.
 Giám sát chính sách bảo mật: là quá trình xác minh rằng tất cả các hệ thống tuân
thủ một tập hợp các quy tắc được xác định trước liên quan đến cài đặt cấu hình và
sử dụng ứng dụng được phê duyệt.
Wazuh sử dụng ba thành phần để thực hiện nhiệm vụ này: Rootcheck, OpenSCAP
và CIS-CAT
 Log data collection: cho phép Wazuh thu thập, phân tích và hiện thị log của các
server, thiết bị theo thời gian thực.
 Đánh giá cấu hình bảo mật: Wazuh có nhiều tích hợp để thực hiện quét đánh giá
cấu hình bao gồm OpenSCAP và CIS-CAT và gần đây là Đánh giá cấu hình bảo
mật (SCA).

53
 Phát hiện các bất thường và phần mềm độc hại: là tìm kiếm các patterns trong
hệ thống không khớp với hành vi dự kiến. Khi phần mềm độc hại (ví dụ: rootkit)
được cài đặt trên một hệ thống, nó sẽ sửa đổi hệ thống để ẩn chính nó khỏi người
dùng. Để phát hiện những hành động bất thường đấy Wazuh sử dụng broad
spectrum approach để tìm ra các patterns dị thường chỉ ra những kẻ xâm nhập có
thể.
Thành phần chính chịu trách nhiệm cho nhiệm vụ này là rootcheck, tuy nhiên,
Syscheck cũng đóng một vai trò quan trọng.
 Monitoring system calls: Linux Audit system cung cấp một cách để theo dõi
thông tin liên quan đến bảo mật trên hệ thống . Dựa trên các quy tắc được định
cấu hình trước, Audit tạo các mục nhật ký để ghi lại càng nhiều thông tin về các
sự kiện đang xảy ra trên hệ thống càng tốt.
 Giám sát Command: Đôi khi ta muốn theo dõi những thứ không có trong nhật
ký. Để giải quyết vấn đề này, Wazuh kết hợp khả năng giám sát đầu ra của các
lệnh cụ thể và xử lý đầu ra như thể đó là nội dung tệp nhật ký.
 Active response: Wazuh phản ứng lại với các active bằng các biện pháp đối phó
khác nhau để giải quyết các mối đe dọa, ví dụ chặn truy cập từ các agent đến các
mối đe dọa.
 Cơ chế Anti-flooding: được thiết kế để ngăn chặn các cuộc tấn công lớn flood,
ddos. Trên một agent gây ảnh hưởng tiêu cực đến mạng hoặc người quản lý.
 Agent labels: Tính năng này cho phép người quản trị tùy chỉnh thêm các thông tin
cảnh báo từ các agent.
 System inventory: Wazuh agents có thể thu thập thông tin hệ thống và lưu trữ nó
vào cơ sở dữ liệu SQLite của manager.
 Osquery: cho phép công cụ quản lý Osquery từ các Wazuh agents, có thể đặt cấu
hình Osquery và thu thập thông tin do Osquery tạo để gửi cho người quản lý, tạo
cảnh báo tương ứng nếu cần.
 Fluentd forwarder: cho phép Wazuh chuyển tiếp messages đến máy chủ Fluentd.
Fluentd là một phần mềm mã nguồn mở dùng để thu thập nhật ký đi kèm với các
plugin tuyệt vời để xây dựng logging layer của riêng bạn.
 Phát hiện lỗ hổng: Wazuh có thể phát hiện các lỗ hổng trong các ứng dụng được
cài đặt trong agents bằng cách sử dụng module Phát hiện lỗ hổng.
 Tích hợp VirusTotal: Wazuh có thể quét các tệp được theo dõi để tìm nội dung
độc hại trong các tệp được giám sát.
 Agent key polling: cho phép truy xuất thông tin tác nhân từ cơ sở dữ liệu bên
ngoài, như MySQL hoặc bất kỳ công cụ cơ sở dữ liệu nào, để đăng ký nó vào
client.keys.
54
5.1.2.2. Kiến trúc
- Mô hình Single-node deployment: Trong mô hình nhỏ, cả Wazuh và
Elasticsearch đều có thể cùng triển khai trên cùng 1 máy single server.

Ảnh 5.33 Kiến trúc Single-node deployment của Wazuh

 Mô hình Multi-node deployment: Khi Wazuh server và Elasticsearch cluster

chạy trên các host khác nhau, Filebeat được dùng để truyền một cách an toàn các
alerts, archived event tới Elasticsearch server sử dụng TLS để mã hóa.

Ảnh 5.34 Kiến trúc Multi-node deployment của Wazuh

5.1.2.3. Hoạt động

55
 Ảnh 5.35 Sơ đồ giao tiếp giữa agent và server

a. Agent-server communication
Wazuh agent sử dụng OSSEC message protocol để gửi các event thu thập được tới
Wazuh server thông qua port 1514 (UDP/ TCP). Wazuh server giải mã và thực hiện rule-
check với các event nhận được với công cụ phân tích. Các event ứng với các rule được bổ
sung 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:
- Tệp /var/ossec/logs/archives/archives.json chứa tất cả các sự kiện cho dù chúng
có vi phạm quy tắc hay không.
- Tệp /var/ossec/logs/alerts/alerts.json chỉ chứa các sự kiện vi phạm quy tắc.
b. Wazuh-Elastic communication
- Wazuh Server sử dụng Filebeat để gửi dữ liệu cảnh báo và sự kiện đến
Elasticsearch Server bằng cách sử dụng mã hóa TLS.
- Filebeat định dạng dữ liệu đến và tùy chọn nâng cao nó bằng thông tin GeoIP trước
khi gửi đến Elasticsearch (cổng 9200/ TCP). Khi dữ liệu được lập chỉ mục vào
Elasticsearch, thì Kibana (cổng 5601/ TCP) được sử dụng để khai thác và trực quan
hóa thông tin.
- Ứng dụng Wazuh chạy bên trong Kibana cái mà liên tục truy vấn API RESTful
(cổng 55000/ TCP trên Wazuh manager) để hiển thị thông tin liên quan đến cấu
hình và trạng thái của Server và Agents, cũng như khởi động lại Agents khi muốn.
Giao dịch này được mã hóa bằng TLS và được xác thực bằng tên người dùng và
mật khẩu.
5.1.2.4. Tìm hiểu về luật
a. Tổng quan về rule trong wazuh.
56
 Trong Wazuh sử dụng rất nhiều loại rules khác nhau có thể kể đến như
Rules Description
sshd sshd (SSH Daemon) là chương trình daemon cho ssh.
symantec-av Symantec antivirus -một chương trình chống vi-rút.
symantec-ws Symantec Web Security – bảo mật web
.... ...
b. Cấu trúc và các thành phần rules.
Cấu trúc thư mục chứa rules của wazuh:
/var/ossec/
├─ etc/
│ ├─ decoders/
| | └─ local_decoder.xml
│ └─ rules/
| └─ local_rules.xml
└─ ruleset/
├─ decoders/
└─ rules/
Wazuh sử dụng các rules được quy định theo tiêu chuẩn của Ossec, sau khi cài đặt
wazuh thành công ta có thể xem các rules được cài đặt mặc định tại đường dẫn:
cd /var/ossec/ruleset/rules

Ảnh 5.36 Các file rule trong /var/ ossec/ruleset/rules

Xem chi tiết các loại loại rules.

Ví dụ: rules liên quan đến ssh của hệ thống 0095-sshd_rules.xml

57
 Ảnh 5.37 Rule liên quan đến ssh của hệ thống 0095-sshd_rules.xml

Tất cả các rules của wazuh đều được lưu dưới dạng file *.xml và được wazuh kết
hợp bộ giải mã tích hợp cho nhật ký JSON cho phép trích xuất dữ liệu từ bất kỳ nguồn
nào.
ví dụ: rules ssh của hệ thống 0095-sshd_rules.xml có rule.id = 5710 rule này có
chức năng cảnh báo hành động đăng nhập vào hệ thống sử dụng một người dùng
không tồn tại qua ssh

Ảnh 5.38 Cảnh báo hành vi đăng nhập sử dụng một non-existent user

Dữ liệu hiện thị trên Kibana tồn tại dưới 2 dạng: Table và Json
Dạng Table:

58
 Ảnh 5.39 Dữ liệu hiển thị trên Kibana dưới dạng Table

Dạng JSON

59
 Ảnh 5.40 Dữ liệu hiển thị trên Kibana dưới dạng JSON

Giải thích thêm về rules 0095-sshd_rules.xml có rule.id = 5710 ta có

<rule id="5710" level="5">
<if_sid>5700</if_sid>
<match>illegal user|invalid user</match>
<description>sshd: Attempt to login using a non-existent user</description>
<mitre>
<id>T1110</id>
</mitre>
<group>invalid_login,authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,pci
_dss_10.6.1,gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_8
00_53_AU.14,nist_800_53_AC.7,nist_800_53_AU.6,tsc_CC6.1,tsc_CC6.8,ts
c_CC7.2,tsc_CC7.3,</group>
</rule>
Giải thích 1 số thông tin quan trọng:
<rule id="5710" level="5">
<if_sid>5700</if_sid>
60
 Trong wazuh rules chia ra thành 16 level tương đương với mức độ cảnh báo khác
nhau được sắp xếp theo thứ tự tăng dần từ 0 đến 15.

Ảnh 5.41 Các mức độ cảnh báo OSSEC

Rule id là tham số được định nghĩa ứng với từng id sẽ có từng thông báo, cảnh báo
lỗi khác nhau.
Tải bản FULL (file word 123 trang): bit.ly/2Ywib4t
Dự phòng: fb.com/KhoTaiLieuAZ

61
 Ảnh 5.42 Luật OSSEC

Tiếp theo là phần thông báo, cảnh báo lỗi

<match>illegal user|invalid user</match>
<description>sshd: Attempt to login using a non-existent user</description>
Có chức năng đưa ra các thông báo, cảnh báo cho người quản trị biết xử lý.
Sau cùng là phần phân loại nhóm những cảnh báo để dễ dàng theo dõi và quả lý
<mitre>
Tải bản FULL (file word 123 trang): bit.ly/2Ywib4t
<id>T1110</id> Dự phòng: fb.com/KhoTaiLieuAZ
</mitre>
<group>invalid_login,authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,
pci_dss_10.6.1,gpg13_7.1,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,tsc_CC6.1,tsc_
CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
c. Phân loại rules theo hệ điều hành.

62
 Trong thực tế giám sát log ta không thể dùng hết rules của wazuh được vì khi cài đặt
sử dụng rules quá nhiều sẽ dẫn đến tình trạng người quản trị viên không thể phân tích
được hết các cảnh báo lỗi do rules gửi về vì vậy sẽ dẫn đến việc bỏ sót các thông báo lỗi
quan trọng, để hạn chế việc này ta cần phân loại những rules cần thiết để có thể sử dụng 1
cách hợp lý nhất.
 Rules Windown.
Các sự kiện Windows có thể được tập hợp và chuyển tiếp đến người quản lý, nơi
chúng được xử lý và cảnh báo nếu chúng phù hợp với bất kỳ quy tắc nào. Có hai định
dạng để thu thập nhật ký Windows:
 Eventlog (được hỗ trợ bởi mọi phiên bản Windows)
 Eventchannel (dành cho Windows Vista và các phiên bản mới hơn)
Lưu ý: phiên bản Wazuh >= 3.9.0 và Wazuh < 3.9.0 có nhau về cách lưu rule.

Ảnh 5.43 Thông tin các file rule trong Wazuh

Ví dụ ta có thể tạo ra folder để chỉ chứa riêng rules của windown như sau.

Ảnh 5.44 Các file rule của Windows

Ngoài ra ta còn có thể thêm 1 số rule quan trọng khác cho windown như.
Rules Description
63
7270802