Xây dựng một hệ thống SOAR (Active Response) tự động phát hiện Brute Force và gọi API chặn IP nghe thì rất ngầu. Thế nhưng, từ lý thuyết đến khi bấm nút Run trong OpenSearch là cả một hành trình "đấu trí" với đủ loại lỗi từ giao diện, cú pháp cho đến kiểu dữ liệu.
Dưới đây là 4 bài học "xương máu" mình và cộng sự đã đúc kết được sau khi cấu hình thành công Use Case: Phát hiện Failed Login > 5 lần/5 phút ➡ Kích hoạt Telegram Alert ➡ Gọi Webhook block IP qua Firewall.
Dưới đây là 4 bài học "xương máu" mình và cộng sự đã đúc kết được sau khi cấu hình thành công Use Case: Phát hiện Failed Login > 5 lần/5 phút ➡ Kích hoạt Telegram Alert ➡ Gọi Webhook block IP qua Firewall.
1. Cú lừa từ Giao diện (UI Dropdown) & Sức mạnh của Extraction Query
Khi cấu hình Per bucket monitor để gom nhóm đếm log theo từng IP (source.ip), giao diện OpenSearch bỗng dưng báo lỗi trống rỗng: “You've selected all available options”.- Sự thật là: Do log giả lập được nạp vào dưới dạng dynamic mapping, OpenSearch tự động hiểu trường IP là kiểu text thay vì keyword. Để bảo vệ hệ thống không bị treo RAM, giao diện đã ẩn toàn bộ các trường này đi.
- Giải pháp: Hãy "bỏ qua" giao diện kéo thả (Visual editor) và chuyển ngay sang Extraction query (Viết bằng JSON). Việc chỉ định trực tiếp trường ẩn source.ip.keyword trong code JSON sẽ giúp bạn bypass giới hạn này một cách dễ dàng:
"aggs": {
"ips": {
"terms": {
"field": "source.ip.keyword",
"size": 10,
"min_doc_count": 6
}
}
}
2. Bí ẩn biến
Khi chuyển sang viết điều kiện kích hoạt Trigger (Condition), lỗi quen thuộc NullPointerException hoặc Variable [ctx] is not defined xuất hiện khiến không ít người bối rối.
- Sự thật là: Ở chế độ Per bucket monitor, OpenSearch bóc tách dữ liệu cực kỳ sâu. Nó cô lập từng "giỏ IP" riêng biệt để xử lý, đồng thời xóa bỏ luôn đối tượng phức tạp ctx ra khỏi môi trường script.
- Giải pháp: Đừng viết dài dòng theo kiểu cũ. Trong Per bucket, bạn có thể gọi trực tiếp biến số lượng bản ghi:
doc_count > 5Hoặc nếu đã cài "min_doc_count": 6 ở tầng Query, bạn chỉ cần gõ đúng một chữ: true.
3. Khi Sigma Rule đòi hỏi "Sự hoàn hảo" (UUID & Tiếng Anh)
Khi lấn sân sang Security Analytics để tạo các Detection Rule nâng cao theo chuẩn Sigma, bộ biên dịch của OpenSearch sẽ lập tức "bắt lỗi" nếu bạn viết theo thói quen thông thường:
- Lỗi ID: Trường id trong file YAML của luật Sigma không cho phép đặt tên bừa bãi (như custom-rule-test). Nó bắt buộc phải là một chuỗi định dạng UUID (định danh duy nhất toàn cầu). Bạn phải dùng các công cụ tạo UUID ngẫu nhiên để điền vào.
- Lỗi Tiếng Việt: Ô mô tả (description) nếu có tiếng Việt có dấu sẽ bị từ chối ngay lập tức. Bộ luật Sigma chỉ chấp nhận ký tự ASCII tiếng Anh thuần túy hoặc tiếng Việt không dấu.
4. Những cú "vấp chân" khi mồi Log qua Dev Tools
Để test End-to-End hệ thống từ lúc tấn công đến lúc bị chặn, việc dùng Dev Tools bắn log giả lập là bắt buộc. Nhưng hãy cẩn thận với 2 lỗi này:
- Không ghi đè vào trường Alias (Bí danh): Khi log mạng có chứa cấu trúc trường kiểu như "id": {"orig_h": ...}, nếu trong Mapping hệ thống định nghĩa đây là trường Alias, bạn sẽ nhận ngay lỗi Cannot write to a field alias. Giải pháp là hãy xóa hẳn cụm trường đó ra khỏi payload giả lập.
- Giá trị "now" chỉ dùng để tìm kiếm, không dùng để nạp: Khi viết @timestamp: "now" với hy vọng log lấy giờ hiện tại, OpenSearch sẽ báo lỗi parse dữ liệu. Từ khóa "now" chỉ có tác dụng trong câu lệnh Query. Khi nạp log (Insert), bắt buộc phải dùng chuỗi thời gian ISO thực tế (ví dụ: "2026-05-18T21:05:00.000Z").
Kết quả
Sau khi vượt qua chuỗi "thử thách" trên, hệ thống đã chạy mượt mà đúng như thiết kế:
- Thực hiện tấn công giả lập (bắn 6 log failed login liên tiếp từ IP 22.33.44.55).
- OpenSearch lập tức tóm được trong vòng chưa đầy 1 phút.
- Điện thoại rung lên, Telegram báo đích danh IP vi phạm kèm số lần tấn công.
- Một payload JSON được tự động gửi thẳng tới Firewall API để thực hiện lệnh cấm vận IP đó vĩnh viễn.
