THIẾT LẬP SIEM/SOC TRÊN NỀN TẢNG OPENSEARCH ĐỂ PHÁT HIỆN BRUTE FORCE
I. Yêu cầu bài Lab & Thực tế
1. Giới thiệu
Trong kịch bản này, chúng ta đóng vai trò là SOC tại một doanh nghiệp. Hệ thống liên tục ghi nhận các nỗ lực truy cập bất thường vào máy chủ quản lý. Nhiệm vụ là phải xây dựng lọc dữ liệu để tách biết giữa người dùng quên mật khẩu và cuộc tấn công dò quét (Brute Force) thực sự.
1. Giới thiệu
Trong kịch bản này, chúng ta đóng vai trò là SOC tại một doanh nghiệp. Hệ thống liên tục ghi nhận các nỗ lực truy cập bất thường vào máy chủ quản lý. Nhiệm vụ là phải xây dựng lọc dữ liệu để tách biết giữa người dùng quên mật khẩu và cuộc tấn công dò quét (Brute Force) thực sự.
2. Vấn đề cốt lõi
Log hệ thống (System logs) sinh ra hàng giây. Việc kiểm tra thủ công là không khả thi. Chúng ta cần một hệ thống có khả năng:
- Normalization: Chuẩn hóa dữ liệu log thô.
- Correlation: Liên kết các sự kiện đơn lẻ thành một chuỗi tấn công.
- Real-time Alerting: Báo động ngay lập tức khi phát hiện hành vi xâm nhập.
Việc triển khai trên Docker Compose không đơn giản là up -d. Thực tế, mình đã vấp phải lỗi xác thực SSL giữa các node.
1. Tối ưu hóa Docker Compose
Thay vì dùng cấu hình mặc định, mình đã ép hệ thống chạy theo một quy trình kiểm soát chặt chẽ:
# Cấu hình "Hardening" ban đầu
services:
opensearch:
image: opensearchproject/opensearch:2.12.0
environment:
- discovery.type=single-node
- OPENSEARCH_INITIAL_ADMIN_PASSWORD=Str0ngPassw0rd@2026 # Force pass mạnh ngay từ đầu
ulimits:
memlock: { soft: -1, hard: -1 } # Tránh tình trạng swap làm chậm xử lý log
2. Xử lý lỗi "Socket Hang Up"
Đây là lỗi kinh điển khi Dashboards không thể kết nối được với core. Thay vì tắt toàn bộ bảo mật, mình đã tinh chỉnh biến môi trường để hệ thống vẫn chạy HTTPS nhưng tạm bỏ qua bước xác thực certificate cục bộ (SSL_VERIFICATION_MODE=none), giúp quá trình Lab diễn ra thông suốt mà không cần thiết lập CA phức tạp.
Hình 2: Trạng thái các Container OpenSearch và Dashboards đang vận hành ổn định trên máy ảo.
III. Phân tích dữ liệu bảo mật
Sau khi dữ liệu đồ về, mình thực hiện "đào sâu" bằng Query DSL. Đây là phần quan trọng nhất để chứng minh năng lực phân tích.
1. Truy vấn kẻ tấn công
Thay vì chỉ xem log chung chung, mình dùng truy vấn tập trung vào các sự kiện thất bại:
GET /security-auditlog-*/_search
{
"query": {
"match_all": {}
},
"aggs": {
"top_attacker_ips": {
"terms": {
"field": "audit_request_remote_address.keyword"
}
}
}
}
Kết quả: Nhận diện ngay lập tức địa chỉ IP nào đang cố gắng vào hệ thống nhiều nhất.
Hình 3: Thực thi ngôn ngữ truy vấn Query DSL trong giao diện Dev Tools để lọc danh sách IP thực hiện hành vi Brute Force.
Mình đã xây dựng một Dashboard tổng hợp bao gồm:
- Heatmap thời gian: Chỉ ra rằng tấn công đạt đỉnh (spike) vào khoảng 4/5 đến 5/5 với hơn 10 nỗ lực/phút.
- Metric Counter: Hiện thị con số 872 lượt vi phạm để cảnh báo mức độ nghiêm trọng.
Hình 4: Giao diện SOC Dashboard tổng hợp ghi nhận 872 nỗ lực truy cập bất thường, chứng minh khả năng giám sát tập trung của hệ thống.
Đỉnh cao của SOC là Alerting. Mình đã thiết lập một Monitor để hệ thống tụ vận hành 24/7.
- Quy tắc: Cứ 1 phút, Monitor sẽ quét Index Pattern một lần.
- Logic: ctx.results[0].hits.total.value > 5.
- Phản ứng: Khi điều kiện thỏa mãn, hệ thống tự động ghi nhận một trạng thái Active Alert.
Hình 5: Trạng thái Active Alert trong phân hệ Alerting.
V. Tổng kết
Hệ thống đã hoàn thành trọn vẹn chu trình SOC: Thu thập -> Phân tích -> Cảnh báo tự động.
1. Kết quả
- Phát hiện: Lọc chính xác 872 sự kiện đăng nhập sai (AUTHENTICATION_FAILED) và nhận diện các IP tấn công Brute Force.
- Trực quan hóa: Dashboard xác định đỉnh tấn công (spike) vào lúc 00:00:00 với tần suất >10 lần/phút.
- Cảnh báo: Monitor tự động kích hoạt Active Alert khi vi phạm ngưỡng thiết lập (Threshold > 5).
- Hạ tầng: Làm chủ cấu hình SSL và xác thực trên Docker để đảm bảo kết nối thông suốt giữa các node.
- Vận hành: Ứng dụng Query DSL và Monitor giúp chuyển từ giám sát bị động sang phòng thủ chủ động, tối ưu hóa thời gian phản ứng sự cố (MTTR).
Sửa lần cuối: