SIEM/Log Management Cấu hình thu thập log: Windows, Linux, Container, Firewall, Switch, VMware,...

I. Mô Tả Yêu Của Của Bài Lab​

1. Giới thiệu tổng quan​

Trong môi trường quản trị hạ tầng hiện nay, dữ liệu log sinh ra từ các nền tảng khác nhau như Windows Event Logs, Linux Syslog, hay các thiết bị Network (Firewall, Switch) thường rất lớn và rời rạc. Bài lab này tập trung vào việc xây dựng một hệ thống giám sát tập trung (Centralized Logging) sử dụng OpenSearch và Logstash. Hệ thống không chỉ đơn thuần là nơi lưu trữ, mà còn phải đảm bảo khả năng phân loại, chuẩn hóa dữ liệu và quản lý vòng đời (Retention) một cách tự động.
Môi trường triển khai:

• Indexer Node: OpenSearch 2.x & Dashboards (Ubuntu 22.04 LTS).
• Logstash Aggregator: Đóng vai trò bộ lọc và điều phối dữ liệu.
• Sources: Windows Server 2022, Ubuntu Server, Docker Container và Cisco Switch giả lập.

2. Vấn đề cần giải quyết​

• Sự hỗn tạp dữ liệu: Log từ nhiều nguồn đổ về chung một luồng gây khó khăn cho việc phân tích và tạo Dashboard.
• Tối ưu tài nguyên: Tránh tình trạng tràn ổ cứng (Disk Full) do log lưu trữ vô thời hạn.
• Tính toàn vẹn: Đảm bảo log được gán nhãn đúng nguồn gốc ngay từ thời điểm thu thập.

II. Giải Pháp & Triển Khai Chi Tiết​

1. Thiết lập Shippers (Bộ thu thập tại nguồn)​

Chúng ta sẽ triển khai các Agent nhẹ (Beats) để tối ưu hóa CPU/RAM tại các máy chủ nguồn:

• Windows Server (Winlogbeat): Tập trung vào kênh Security để giám sát đăng nhập.
• Linux & Containers: Sử dụng Filebeat để monitor các dịch vụ /var/log/*.log và Fluent Bit để thu gồm log từ Docker stdout/stderr.
• Network Devices: Cấu hình Syslog (UDP/514) trỏ trực tiếp về IP của Logstash.

2. Xử lý logic tại Logstash (Pipeline Transformation)​

Đây là công đoạn quan trọng nhất để phân làn dữ liệu. Thay vì để OpenSearch tự định nghĩa Index, chúng ta sẽ gán nhãn Metadata tại Logstash:
input {
beats { port => 5044 }
syslog { port => 514 type => "network" }
}
filter {
if [agent][type] == "winlogbeat" {
mutate { add_field => { "[@metadata][target_index]" => "logs-windows" } }
} else if [agent][type] == "filebeat" {
mutate { add_field => { "[@metadata][target_index]" => "logs-linux" } }
} else if [type] == "network" {
mutate {
add_field => { "[@metadata][target_index]" => "logs-network" }
grok { match => { "message" => "<%{POSINT:syslog_pri}>%{GREEDYDATA:syslog_message}" } }
}
}
}
output {
opensearch {
hosts => ["https://localhost:9200"]
index => "%{[@metadata][target_index]}-%{+YYYY.MM.dd}"
user => "${OS_USER}"
password => "${OS_PWD}"
ssl => true
ssl_certificate_verification => false
}
}

3. Quản trị vòng đời dữ liệu với ISM (Index State Management)​

Để hệ thống vận hành bền bỉ, chúng ta thiết lập ISM Policy trên OpenSearch Dashboards để tự động hóa việc xoay vòng log:

III. Kết Luận​

Sau khi hoàn thành bài lab, chúng ta đã hình thành được một quy trình thu thập log chuẩn hóa từ hạ tầng đa nền tảng. Dữ liệu đổ về OpenSearch lúc này đã có cấu trúc, giúp việc tạo các biểu đồ giám sát (Visualization) trở nên trực quan và chính xác.
Một số lưu ý thực tế khi triển khai:

• Tối ưu JVM Heap: Luôn cấu hình Xms và Xmx bằng 50% RAM vật lý của server. Nếu set quá cao sẽ gây lỗi treo nhân OS (OOM Killer), nếu quá thấp sẽ dẫn đến lỗi Circuit Breaker Exception.
• Đồng bộ NTP: Đây là yếu tố sống còn. Chỉ cần lệch thời gian giữa Shipper và Indexer, các biểu đồ Time-series trên Dashboard sẽ bị sai lệch hoàn toàn, gây khó khăn cho việc tương quan sự cố.
• Cơ chế Backpressure: Trong các hệ thống lớn, nên cân nhắc đặt một cụm Kafka trước Logstash để làm buffer, tránh mất dữ liệu khi Logstash bị quá tải hoặc OpenSearch bận thực hiện các tiến trình merge index.