Lưu Như Thắng
Intern
1. Cấu hình Cảnh báo (Alerting) qua Telegram & Gmail
1.1. Lý thuyết: Alerting là gì?
Trong hệ thống SIEM, việc giám sát log thủ công là không khả thi. Alerting (Cảnh báo) là cơ chế tự động quét dữ liệu log liên tục theo các điều kiện (Trigger) định trước. Khi phát hiện bất thường (ví dụ: đăng nhập sai 5 lần/phút, có người bị đổi mật khẩu), hệ thống sẽ lập tức gửi thông báo đến quản trị viên thông qua Email, Webhook (Telegram, Slack, Teams) để kịp thời xử lý.1.2. Hướng dẫn cấu hình Email (Gmail) và Telegram
Để gửi qua Gmail, cần dùng tài khoản Gmail có tính năng App Password (Mật khẩu ứng dụng) được cấp quyền gửi SMTP.- Cấu hình Email Sender trong OpenSearch:
- Chỉnh sửa cấu hình opensearch.yml (hoặc thông qua giao diện cấu hình Keystore của OpenSearch) để thiết lập máy chủ SMTP (smtp.gmail.com:587), tài khoản Gmail và App Password.
Để gửi qua Telegram cấu hình như hình dưới đây
- Tạo Destination & Monitor:
- Trong Alerting -> Destinations, chọn Type là Email. Khai báo người nhận (Recipients).
1.3. Khởi tạo Monitor và Triggers (Ví dụ: Giám sát sự kiện Tạo/Xoá tài khoản Windows)
A. Giải thích các khái niệm quan trọng
Trước khi cấu hình, bạn cần hiểu rõ các loại Monitor (Bộ theo dõi) mà OpenSearch cung cấp:- Per query monitor: Chạy một câu truy vấn (query) tìm kiếm và sinh cảnh báo dựa trên số lượng kết quả trả về. Rất phổ biến để tìm các log sự kiện.
- Per bucket monitor: Đánh giá dữ liệu dựa trên các giá trị tổng hợp (ví dụ: đếm tổng số lần đăng nhập sai của từng IP riêng biệt).
- Per cluster metrics monitor: Chạy các API request để giám sát sức khỏe của bản thân cụm máy chủ OpenSearch.
- Per document monitor: Quét và đánh giá từng document một khi chúng vừa được đưa vào hệ thống.
- Composite monitor: Kết hợp kết quả từ nhiều monitor khác nhau để tạo ra các cảnh báo phức tạp, giúp giảm thiểu cảnh báo rác (alert noise).
B. Các bước cấu hình Monitor
- Vào mục Alerting -> tab Monitors -> Nhấn Create monitor.
- Khai báo các thông tin cơ bản:
- Monitor type: Chọn Per query monitor.
- Monitor defining method: Chọn Extraction query editor.
- Frequency: Đặt lịch quét, ví dụ chạy mỗi 2 phút.
- Cấu hình nguồn dữ liệu (Select data):
- Select clusters: Chọn opensearch-cluster (Local).
- Indexes: Khai báo các index cần quét, ví dụ nhập các log của Windows: logs-windows-application-*, logs-windows-system-*, logs-windows-security-*.
- Cấu hình câu truy vấn (Query):
Dán đoạn mã truy vấn JSON sau vào khung Query. Câu truy vấn này quét trong 5 phút qua (now-5m) để tìm các sự kiện có mã EventID = 4720 (Tạo tài khoản) hoặc 4726 (Xoá tài khoản).
C. Cấu hình Triggers và Actions
Sau khi có Monitor để quét log, bạn cần đặt Trigger (Điều kiện kích hoạt) và Action (Hành động gửi thông báo).- Cuộn xuống phần Triggers, khai báo:
- Trigger name: Windows Tao Xoa Tai Khoan.
- Severity level: 1 (Highest) (Mức độ nghiêm trọng cao nhất).
- Trigger condition: ctx.results[0].hits.total.value > 0 (Nghĩa là kích hoạt ngay khi câu query tìm thấy ít nhất 1 log vi phạm).
- Cấu hình Actions (Gửi qua Telegram):
Nếu bạn muốn đẩy cảnh báo qua Webhook của Telegram, hãy chọn Channel tương ứng và dán đoạn mã JSON (sử dụng Mustache templates của OpenSearch) vào phần Message:
{
"chat_id": "YOUR_CHAT_ID",
"text": " <b>[WINDOWS SECURITY ALERT] TẠO/XÓA TÀI KHOẢN</b>\n━━━━━━━━━━━━━━━━━━━━━━━━━\n\n <b>Ý nghĩa</b>\nWindows ghi nhận thao tác <b>tạo mới</b> hoặc <b>xóa tài khoản</b>. Đây là sự kiện nhạy cảm vì kẻ tấn công có thể tạo tài khoản để duy trì truy cập hoặc xóa tài khoản nhằm che giấu dấu vết.\n\n <b>Thông tin cảnh báo</b>\n• Monitor: {{ctx.monitor.name}}\n• Trigger: {{ctx.trigger.name}}\n• Mức độ: <b>CRITICAL</b>\n• Thời gian bắt đầu: {{ctx.periodStart}} UTC\n• Thời gian kết thúc: {{ctx.periodEnd}} UTC\n• Tổng số sự kiện: {{ctx.results.0.hits.total.value}}\n\n <b>Chi tiết log</b>\n{{#ctx.results.0.hits.hits}}\n━━━━━━━━━━━━━━━━━━━━\n Máy: {{_source.agent.name}}\n IP: {{_source.agent.ip}}\n Rule ID: {{_source.rule.id}}\n Rule Level: {{_source.rule.level}}\n Rule: {{_source.rule.description}}\n Event ID: {{_source.data.win.system.eventID}}\n Thời gian: {{_source.timestamp}}\n Log:\n<code>{{_source.full_log}}</code>\n{{/ctx.results.0.hits.hits}}\n\n<b>Khuyến nghị kiểm tra</b>\n
Xác minh việc tạo/xóa tài khoản có được phê duyệt.\n
Kiểm tra tài khoản mới có được thêm vào nhóm Administrators hay không.\n
Xác định tài khoản hoặc người đã thực hiện thao tác.\n
Nếu phát hiện bất thường, vô hiệu hóa tài khoản, đổi mật khẩu liên quan và kiểm tra các cơ chế persistence.\n\n OpenSearch:\nhttps://192.168.75.145:5601",
"parse_mode": "HTML"
}
Cấu hình Actions (Gửi qua Gmail):
Nếu gửi qua Email, giao diện sẽ trực quan hơn. Bạn chỉ cần chọn Channel là Gmail và điền mẫu Text cảnh báo như sau:
D. Phân tích Kết quả Cảnh báo Thực tế
Sau khi hoàn tất cấu hình, hệ thống SOC sẽ tự động giám sát 24/7. Dưới đây là phân tích chi tiết về các luồng cảnh báo mà hệ thống trả về:Giám sát tổng quan trạng thái cảnh báo (Alerts by triggers)
Giao diện quản lý chính trên OpenSearch cung cấp góc nhìn toàn cảnh về tình trạng an ninh của hệ thống. Tại đây, các nhà phân tích SOC có thể theo dõi vòng đời của một sự kiện: từ lúc nó được kích hoạt (Active), được ghi nhận xử lý (Acknowledged) cho đến khi kết thúc (Completed). Bảng điều khiển liệt kê rõ ràng tên Trigger bị vi phạm, mốc thời gian bắt đầu/kết thúc và mức độ nghiêm trọng (Severity), giúp ưu tiên xử lý các sự cố mạng hiệu quả nhất.
- Chi tiết lịch sử một cảnh báo (Alert History):
Khi click vào một Trigger cụ thể (ví dụ: Windows Tao Xoa Tai Khoan), hệ thống hiển thị biểu đồ Timeline trục ngang. Các điểm màu đỏ/xanh cho biết chính xác thời điểm nào trong ngày sự kiện này xảy ra, giúp quản trị viên nắm bắt được tần suất hành vi bất thường.
- Cảnh báo Real-time qua Telegram:
Nhờ cấu hình Webhook, Bot Telegram (ví dụ: @poptechsocbot) sẽ ngay lập tức "nổ" thông báo về điện thoại của quản trị viên khi có sự kiện (ví dụ: LOGIN THÀNH CÔNG NGOÀI GIỜ). Tin nhắn hiển thị vô cùng chuyên nghiệp với đầy đủ IP, Tên máy, Rule ID và hướng dẫn hành động (Playbook).
- Cảnh báo qua hộp thư Gmail:
Tương tự, các sự kiện nhạy cảm (như TẠO/XÓA TÀI KHOẢN) cũng được định dạng rõ ràng và gửi thẳng vào Gmail của đội ngũ SOC. Việc nhận cảnh báo qua Email rất hữu ích để lưu trữ làm bằng chứng (evidence) dài hạn hoặc dùng để mở Ticket xử lý sự cố.
2. Quản lý Vòng đời Chỉ mục (Index State Management - ISM)
2.1. Lý thuyết: ISM là gì và tại sao cần thiết?
Log hệ thống (Index) sinh ra liên tục mỗi ngày và rất tốn ổ cứng. ISM (Index State Management) là chính sách quản lý vòng đời dữ liệu, giúp tự động chuyển đổi trạng thái của Log theo thời gian để tối ưu hiệu năng và dung lượng.Một quy trình ISM (hay còn gọi là cỗ máy trạng thái - State Machine) tiêu chuẩn thường có các khái niệm sau:
- States (Trạng thái): Giai đoạn hiện tại của log (VD: hot - log mới, warm - log cũ, delete - cần xóa).
- Actions (Hành động): Việc hệ thống sẽ làm khi log ở một trạng thái cụ thể. Ví dụ: khi log chuyển sang warm, hệ thống chạy hành động force_merge (gộp các mảnh dữ liệu nhỏ lại) hoặc read_only (chỉ đọc) để giảm tải RAM/CPU. Ở trạng thái delete, thực hiện hành động delete để xóa dữ liệu.
- Transitions (Chuyển đổi): Điều kiện để log tự động nhảy từ trạng thái này sang trạng thái khác. Ví dụ: Nếu log ở trạng thái hot quá 7 ngày (min_index_age: 7d), hãy chuyển sang trạng thái warm.
2.2. Hướng dẫn tạo Policy ISM
Có hai cách để tạo một Policy: Sử dụng mã JSON có sẵn hoặc cấu hình bằng giao diện (UI).Cách 1: Sử dụng JSON Editor (Nhanh nhất)
- Trong Dashboards, chọn Index Management -> State management policies -> Create policy.
- Khi được hỏi, hãy chọn JSON editor và dán toàn bộ đoạn mã dưới đây vào. (Đoạn mã này tạo ra một kịch bản chuẩn: Chuyển log sang trạng thái warm sau 7 ngày, và xoá log delete sau 30 ngày đối với các log của Linux và Windows).
Giải thích các trường dữ liệu chuyên sâu trong đoạn mã JSON trên:
- id / policy_id: Tên định danh duy nhất của Policy.
- seqNo / primaryTerm / schema_version / last_updated_time: Các siêu dữ liệu (metadata) nội bộ của OpenSearch dùng để kiểm soát phiên bản tránh xung đột (Concurrency Control) và ghi nhận thời gian cập nhật. Bạn thường không cần phải tự sửa các giá trị này.
- default_state: Trạng thái mặc định được gán cho một file log ngay khi nó vừa được tạo ra (thường là hot).
- error_notification: Nơi khai báo kênh gửi thông báo (ID của Slack/Telegram) nếu quá trình thực thi Policy gặp lỗi. Để null nếu không dùng.
- Khối states (Quản lý các trạng thái):
- Khối actions: Chứa hành động xử lý. Mặc định có thêm cơ chế retryđể hệ thống tự động làm lại nếu action gặp lỗi tạm thời.
- count: Số lần thử lại tối đa (ví dụ 3 lần).
- delay: Thời gian chờ giữa các lần thử (ví dụ 1m - 1 phút).
- backoff: exponential nghĩa là thời gian chờ sẽ tăng dần theo cấp số nhân (để tránh làm nghẽn hệ thống).
- force_merge: Hành động gộp nhiều mảnh dữ liệu nhỏ (segments) lại thành 1 khối lượng lớn (max_num_segments: 1) nhằm tối ưu tốc độ đọc và tiết kiệm RAM.
- read_only: Khoá index lại, cấm ghi thêm dữ liệu (vì log đã cũ).
- Khối transitions (Chuyển đổi): Định nghĩa điều kiện chuyển sang trạng thái kế tiếp. Tham số min_index_age: "7d" nghĩa là hệ thống sẽ đợi đến khi log đủ 7 ngày tuổi mới cho phép chuyển từ hot sang warm. Tương tự là 30 ngày để nhảy sang delete.
- Khối actions: Chứa hành động xử lý. Mặc định có thêm cơ chế retryđể hệ thống tự động làm lại nếu action gặp lỗi tạm thời.
- Khối ism_template (Tự động gán):
- index_patterns: Quy định những mẫu tên log nào (khớp với chuỗi này) sẽ tự động bị áp dụng chính sách này.
- priority: Độ ưu tiên của chính sách (số càng cao thì càng ưu tiên trong trường hợp bị trùng lặp rules).
Cách 2: Sử dụng Visual Editor (Dành cho người mới)
Bước 1: Khởi tạo Policy (Create Policy)- Từ Menu bên trái, trong phần Management, chọn Index Management -> State management policies.
- Hệ thống sẽ hiển thị bảng danh sách các Policy hiện có (Ví dụ như bảng dưới đây đang có Policy wazuh-logs-lifecycle). Để tạo mới, bạn chọn nút Create policy.
- Khi được hỏi cấu hình bằng Visual Editor hay JSON Editor, bạn nên chọn Visual editor cho trực quan và dễ thao tác.
- Tại màn hình Create Policy, điền thông tin cơ bản:
- Policy ID: Tên định danh của policy. Ví dụ bạn điền: hot_cold_workflow.
- Description: Nhập mô tả. Ví dụ: A sample description of the policy.
Bước 2: Gắn Policy vào Index Templates (ISM templates)
Tiếp theo, bạn kéo xuống phần ISM templates để gán policy này vào các file log tương lai:
- Index patterns: Chuỗi đại diện cho log. Ví dụ bạn điền logs-linux-auth-* để áp dụng chính sách này cho tất cả log xác thực của máy chủ Linux.
- Priority (Độ ưu tiên): Điền 100. Nếu một file log lọt vào nhiều policy khác nhau, hệ thống sẽ ưu tiên áp dụng policy có Priority cao nhất.
Tiếp tục kéo xuống phần States để định nghĩa vòng đời. Bạn nhấn nút Add state để bắt đầu thêm một trạng thái.
Tại khung bên phải, sẽ có các mục để bạn tinh chỉnh:
- Actions (Hành động):Nhấn + Add action để định nghĩa những gì hệ thống sẽ tự động thực thi khi file log rơi vào State này. Như trong hình dưới đây, menu Action type cung cấp một loạt các thao tác quản trị từ cơ bản đến nâng cao. Việc hiểu rõ và phối hợp các Action này giúp bạn thiết kế vòng đời dữ liệu cực kỳ tối ưu:
- Delete: Xóa hoàn toàn file log khỏi hệ thống để thu hồi dung lượng lưu trữ (thường dùng ở State cuối cùng khi log đã hết giá trị tra cứu).
- Force Merge: Các file log thường bị phân mảnh thành nhiều đoạn nhỏ (segments) trong quá trình hệ thống ghi liên tục. Hành động này ép OpenSearch gộp các mảnh nhỏ lại (ví dụ gộp thành 1 segment duy nhất). Điều này giúp tăng tốc độ tìm kiếm (Search) lên cực kỳ nhanh và giải phóng bộ nhớ RAM đáng kể cho máy chủ.
- Read Only: Chuyển trạng thái file log sang chế độ "chỉ đọc" và cấm ghi thêm bất cứ dữ liệu nào vào. Rất hữu ích cho các log cũ không còn thay đổi, giúp hệ thống không phải tốn tài nguyên duy trì khóa ghi (write locks).
- Rollover: Tự động cắt (đóng) file log cũ và mở một file log hoàn toàn mới để ghi tiếp (thường kết hợp với điều kiện dung lượng tối đa hoặc thời gian). Điều này ngăn chặn tình trạng một file log phình to lên hàng trăm GB gây tràn đĩa hoặc treo hệ thống.
- Snapshot: Tự động chụp bản sao lưu (backup) của file log và đẩy ra một kho lưu trữ độc lập bên ngoài (như AWS S3, NFS) để dự phòng thảm họa mất dữ liệu.
- Replica Count: Tăng hoặc giảm số lượng bản sao (replica) dự phòng của log. Ví dụ: Với log mới (hot) bạn để 1-2 bản sao để chống lỗi hỏng ổ cứng, nhưng với log cũ (warm) bạn có thể gọi action này để giảm xuống 0 bản sao dự phòng nhằm tiết kiệm 50% dung lượng đĩa.
- Notification: Bắn thông báo (qua Webhook, Slack, Email) mỗi khi log bắt đầu chuyển vào State này.
- Transitions (Chuyển đổi): Điều kiện để tự động chuyển sang State khác. Bạn nhấn + Add Transition. Tại phần Condition, menu thả xuống cung cấp các cơ chế kiểm soát vòng đời như:
- No Condition: Chuyển trạng thái ngay lập tức.
- Minimum Index Age: Dựa vào "tuổi đời" của file log tính từ lúc tạo ra (Ví dụ: chờ đủ 7 ngày 7d).
- Minimum Doc Count: Dựa vào số lượng bản ghi (document).
- Minimum Size: Dựa vào dung lượng vật lý của file log.
- Minimum Rollover Age: Dựa vào thời gian trôi qua kể từ lần cắt/cuộn log gần nhất.
- Cron Expression: Sử dụng biểu thức Cron để hẹn lịch cố định.
Dưới đây là một mô hình vòng đời chuẩn mực, giúp tiết kiệm dung lượng đĩa cứng khổng lồ mà vẫn đảm bảo tính sẵn sàng cho việc điều tra. Policy này sẽ gồm 3 trạng thái lần lượt là hot, warm, và delete:
1. Trạng thái hot (Giai đoạn log mới sinh ra):
- Lúc này log đang được hệ thống liên tục ghi đè vào, do đó phần Actions để trống (không can thiệp để đảm bảo tốc độ ghi).
- Phần Transitions đặt điều kiện Minimum index age is 7d (Chỉ khi file log đủ 7 ngày tuổi, nó mới bị đẩy sang trạng thái warm).
2. Trạng thái warm (Giai đoạn log cũ, ít tra cứu):
- Khi log bước vào giai đoạn này, hệ thống sẽ thực thi ngay 2 Actions: Force merge to 1 segments (tối ưu cấu trúc file để tiết kiệm RAM) và Read only (cấm ghi thêm dữ liệu vào file cũ này).
- Trạng thái này sẽ kéo dài cho đến khi log già thêm. Phần Transitions đặt điều kiện Minimum index age is 30d (Sau khi log chạm ngưỡng 30 ngày tuổi, nó sẽ bị chuyển qua trạng thái delete).
3. Trạng thái delete (Giai đoạn huỷ bỏ log hết hạn):
- Tại State cuối cùng này, Action được thiết lập là Delete nhằm tiêu huỷ file log hoàn toàn, trả lại dung lượng lưu trữ cho máy chủ. Không có bước chuyển đổi nào nữa nên Transitions để trống.
4. Tra cứu lịch sử và trạng thái ISM
- Sau khi gán Policy, bạn có thể giám sát vòng đời của các file log bằng cách truy cập vào mục Policy managed indices. Tại đây, hệ thống sẽ hiển thị trạng thái hiện tại (State) và chi tiết lịch sử chuyển đổi của từng file log, giúp quản trị viên dễ dàng theo dõi quá trình tự động hóa ISM.
3. Quản lý Người dùng, Phân Quyền và Tenants (Security)
3.1. Lý thuyết: RBAC & Tenants
- RBAC (Phân quyền theo vai trò): SIEM chứa dữ liệu nhạy cảm. Không phải ai cũng được xem tất cả log. Bạn cần tạo các Vai trò (Role) với các quyền đọc/ghi giới hạn, sau đó gán Người dùng (User) vào Role đó.
- Tenants (Không gian làm việc cô lập): Giúp tách biệt giao diện Dashboards. Một team DevOps có thể có Tenant riêng chỉ hiển thị biểu đồ về hiệu năng máy chủ, trong khi team SOC có Tenant riêng để xem biểu đồ tấn công mạng.
3.2. Hướng dẫn chi tiết từng bước
Trong phần này, chúng ta sẽ đi qua từng bước cụ thể để tạo một Role mới (ví dụ: soc_viewer) với quyền hạn cực kỳ chi tiết, sau đó tạo một tài khoản nhân sự (User) và gắn tài khoản đó vào Role, đồng thời thiết lập Tenant cho không gian làm việc.Bước 1: Khởi tạo một Role mới (Vai trò)
1. Truy cập vào OpenSearch Dashboards, mở menu bên trái và chọn Security.
Tại trang Get started, bấm chọn mục Roles ở menu con bên trái.
Bấm vào nút Create role màu xanh ở góc phải trên cùng của danh sách Roles.
Khai báo Tên và Quyền cấp cụm:
- Đặt tên cho Role dễ nhớ (ví dụ soc_viewer). Chú ý tên phải tuân thủ quy tắc không chứa ký tự đặc biệt.
- Bên dưới là mục Cluster permissions để cấp quyền cấp độ hệ thống.
Cấu hình Phân quyền chuyên sâu & Hoàn tất:
Cuộn xuống nửa dưới của trang tạo Role, bạn sẽ thấy các mục cấu hình bảo mật cực kỳ quan trọng:
- Index permissions: Quyền đọc/ghi trên các Index cụ thể (như wazuh-alerts-* với quyền read, search).
- Document level security (DLS) & Field level security (FLS): Lọc logs theo từng dòng hoặc ẩn các trường dữ liệu nhạy cảm.
- Tenant permissions: Quyền truy cập vào các không gian biểu đồ cụ thể (ví dụ gán global_tenant quyền Read only).
- Sau khi thiết lập xong, bấm nút Create ở góc dưới cùng bên phải để tạo.
Hệ thống hiển thị màn hình thông báo Role đã được tạo thành công cùng bảng tóm tắt cấu hình.
Bước 2: Khởi tạo tài khoản nhân sự (Internal Users)
Ở menu bên trái, chọn Internal users, sau đó bấm nút Create internal user ở góc phải.
Điền thông tin đăng nhập bao gồm Username (ví dụ: hdismtest) và Password. Các mục Backend roles và Attributes dùng cho AD/LDAP có thể bỏ qua nếu tạo tài khoản nội bộ. Sau đó kéo xuống bấm Create.
Tài khoản mới sẽ xuất hiện trong danh sách Internal users.
Bước 3: Gán tài khoản vào Role (Map User)
Tài khoản vừa tạo chưa có quyền gì cả, ta phải gắn nó vào Role soc_viewer.Mở lại danh sách Roles, click vào Role soc_viewer, chuyển sang tab Mapped users. Lúc này bảng báo "No user has been mapped to this role", hãy bấm vào nút Map users.
Tại giao diện Map user, ô Users, bạn gõ và chọn tài khoản hdismtest vừa tạo, sau đó bấm nút Map ở góc phải dưới.
Màn hình báo thành công, tài khoản hdismtest đã chính thức nhận các quyền của Role soc_viewer.
Bước 4: Khởi tạo Không gian làm việc (Tenants)
Tenants giúp chia tách các biểu đồ và dashboard cho từng team khác nhau.Từ menu bên trái chọn Tenants, sau đó bấm nút Create tenant.
Đặt tên cho Tenant (ví dụ: Test123) và nhập mô tả, sau đó bấm Create.
Cuối cùng, quay lại phần chỉnh sửa Role (Edit Role soc_viewer), cuộn xuống mục Tenant permissions, chọn Tenant Test123 vừa tạo, cấp quyền (ví dụ: Read only), và bấm Update để lưu lại là hoàn tất quy trình phân quyền.
Đính kèm
Bài viết liên quan
Được quan tâm
Bài viết mới