Phân tích bảo mật bằng ELK
ELK Stack là tập hợp 3 phần mềm đi chung với nhau, phục vụ cho công việc logging. Ba phần mềm này lần lượt là: Elasticsearch, Logstash, Kibana. Hãy cùng Bizfly Cloud điểm qua 3 phần mềm này chi tiết hơn nhé!
- Elasticsearch: Cơ sở dữ liệu để lưu trữ, tìm kiếm và query log
- Logstash: Tiếp nhận log từ nhiều nguồn, sau đó xử lý log và ghi dữ liệu và Elasticsearch
- Kibana: Giao diện để quản lý, thống kê log. Đọc thông tin từ Elasticsearch
Vài tháng trước, tôi đã có cơ hội thực hiện hai cuộc hội thảo tại BSidesDelhi và CSI Mumbai về chủ đề trên. Cả hai phiên đều là những trải nghiệm tuyệt vời và cho phép tôi thấy sự quan tâm ngày càng tăng trong số các nhân viên bảo mật thông tin cho nguồn mở ELK stack.
Những người biết về cá nhân tôi hoặc follow tôi trên các phương tiện truyền thông xã hội (Twitter / Linkedin) sẽ biết rằng tôi là một fan hâm mộ lớn của ELK stack. Hãy xem các blog trước đây của chúng tôi về việc sử dụng ELK cho các scenario khác nhau.
ELK stack chủ yếu được xây dựng từ 3 thành phần - Elasticsearch (E), Logstash (L), Kibana (K). Có những thành phần khác như Beats, Modules, Plugins, v.v... nhưng hiện tại chúng tôi sẽ bỏ qua các thành khác này sang một bên.
Elasticsearch là kho dữ liệu chính, công cụ phân tích và tìm kiếm. Logstash chịu trách nhiệm việc tích hợp, xử lý, phân tích và làm phong phú log. Kibana là một lớp hình dung nằm phía trên của Elasticsearch. Nó cho phép chúng tôi thực hiện các truy vấn tìm kiếm và tập hợp và tạo trực quan bằng cách sử dụng giao diện người dùng web đơn giản.
ELK stack là một nền rất linh hoạt và nó đã được dùng cho nhiều trường hợp sử dụng trên các ngành công nghiệp khác nhau. Trong miền Bảo mật thông tin, nó thường được so sánh với nền Splunk.
Một số trường hợp sử dụng của ELK stack bao gồm có:
- Dashboarding
- Săn bắt mối đe dọa
- Quản lý log
- Giám sát an ninh
- Nghiên cứu log forensic
Chủ đề chung trong tất cả các trường hợp sử dụng ở trên đó là nền ELK cung cấp cho bạn khả năng phân tích log theo cách tốt hơn một cách đáng kể. Sẽ không có hư hại nào khi việc phân tích này xảy ra với tốc độ quá nhanh 😊
Đối với blogpost này, tôi sẽ minh họa cách chúng tôi có thể sử dụng ELK stack để phân tích một bộ log máy chủ web Apache và xác định các nhóm người hoặc tổ chức có ý gây ra các sự cố về an ninh mạng hoặc các mẫu lưu lượng truy cập.
Chúng tôi sẽ sử dụng một bộ dữ liệu log cục bộ từ một nghiên cứu mà chúng tôi đã tiến hành cho một khách hàng.
Luồng dữ liệu sẽ hoạt động theo như cách dưới đây:
Lưu lượng dữ liệu trong ELK stack
Filebeat hay nói một cách đơn giản là một log shipper. Chúng ta cần xác định đường dẫn của tệp log trong filebeat và rồi filebeat sẽ gửi dữ liệu đến Logstash (hoặc Elasticsearch nếu cần)
Trong Logstash, chúng ta sẽ nhận được các logs Filebeat gửi và sau đó phân tích các trường liên quan bằng cách sử dụng bộ lọc GROK (GROK là một cơ chế trích xuất mẫu dựa trên regex).
Để cải thiện các phân tích, chúng tôi có thể nâng cao hơn nữa các sự kiện bằng cách bao gồm chi tiết vị trí địa lý của địa chỉ IP nguồn (khách truy cập website) và chuyển chuỗi user-agent (một chuỗi nhận dạng của trình duyệt web khi gửi yêu cầu đến máy chủ web) thành các nhóm hệ điều hành và trình duyệt đã biết.
Cấu hình Logstash đầy đủ có sẵn trên repo Gitlab của chúng tôi
Khi chúng tôi đã phân tích cú pháp các sự kiện chính xác, chúng tôi có thể gửi logs tới Elasticsearch để nhập.
Trong Kibana, chúng tôi phải tạo ra một ' index pattern (mô hình chỉ mục)' để Kibana có thể lấy ra các dữ liệu mục lục chỉ thị cần thiết.
Khi chúng tôi thấy một số logs đang được nhập trong tab 'Discover' ở Kibana, chúng tôi có thể bắt đầu xây dựng các hiển thị hóa.
Visualizations là một thành phần quan trọng trong Kibana. Hiển thị đại diện của dữ liệu giúp các nhà phân tích / nhà nghiên cứu hiểu cách bố trí của các log sự kiện, có thể xác định bất kỳ các điểm dị biệt / bất thường theo một cách nhanh hơn nhiều so với việc phân tích dựa trên CLI. Giống như người ta vẫn thường nói - Trăm nghe không bằng một thấy.
Vì vậy, để bắt đầu, trước tiên chúng tôi sẽ xây dựng một biểu đồ hình tròn giúp chúng tôi hiểu được sự phân bố của các log sự kiện. Chúng tôi chọn trường phương thức HTTP, trong đó có một tập hợp hữu hạn các giá trị có sẵn.
Như được nhìn thấy từ hình ảnh trên, chúng tôi đã có được biểu đồ như dự kiến - hiển thị phần lớn các yêu cầu bằng phương thức GET HTTP.
Chúng tôi có thể bắt đầu với một số phân tích sơ bộ về tập dữ liệu trong giai đoạn 'Visualization (Trực quan hóa)'. Tuy nhiên, rất nhiều bối cảnh và phân tích bắt đầu được xây dựng ở giai đoạn 'Dashboard' - nơi chúng tôi có thể tương quan trực quan các khối dữ liệu khác nhau từ bộ dữ liệu log.
Chúng tôi tiếp tục và tạo thêm các hình ảnh trực quan như dưới đây:
Khi các hình ảnh trực quan cần thiết được tạo, chúng tôi thu thập tất cả chúng thành một trang tổng quan duy nhất để phân tích và tương quan.
Bây giờ đây là nơi Elasticsearch và đặc biệt là Kibana có thể 'tỏa sáng'. Những gì mà chúng tôi sẽ mất nhiều giờ để phân tích (như trong Excel hoặc CLI) giờ đây có thể hoàn thành chỉ trong vài phút.
Thứ nhất, chúng tôi nhận thấy rằng dữ liệu của chúng tôi chứa một số mục vận hành/rác (được biểu thị bằng ::1 trong trường clientip). Các mục này chỉ đơn giản là các chỉ lệnh giám sát hiệu năng / ứng dụng chạy các tác vụ được lên lịch trình sẵn. Vì vậy, chúng tôi có thể loại trừ các mục này trên tất cả các hình ảnh hóa bằng cách nhấp vào biểu tượng (-). Điều đó làm giảm dữ liệu xuống ~ 85k sự kiện.
Tiếp theo, chúng tôi bắt đầu với các phương thức HTTP. Quan sát khá nhanh và chúng tôi tìm thấy outlier (dữ liệu ngoại lai) đầu tiên của chúng tôi. Phương thức HTTP PUT được coi là "nguy hiểm". Người ta hi vọng sẽ không phải sử dụng phương thức này trong môi trường sản xuất. Việc lọc trên phương thức HTTP này đã để lại cho chúng tôi hai sự kiện.
OK - vậy là cũng không còn gì nhiều để tiếp tục. Nhưng vì IP này đang cố gắng 'đặt' một tệp text trên máy chủ của tôi, hãy xem người này đã làm hoặc xoay sở như thế nào để đạt được. Do đó, chúng tôi sẽ xóa bộ lọc cho phương pháp PUT và chỉ áp dụng bộ lọc cho địa chỉ IP - cách đó khoảng 2 lần nhấp chuột 😊
Chúng tôi thấy rằng IP này đã gửi 42 yêu cầu đến máy chủ của chúng tôi. Không yêu cầu nào trong số này xuất hiện hợp pháp (chỉ yêu cầu HEAD và PUT thôi sao?). Ngoài ra, việc hiển thị phân tích User-Agent (UA) của chúng tôi đặt trình duyệt của anh ấy trong 'Khác'. Điều này cho thấy thực tế là anh ấy không duyệt trang web của chúng tôi bằng trình duyệt truyền thống.
Nhìn vào các yêu cầu thô, chúng ta có thể thấy rằng kẻ tấn công đang cố gắng xác định một plugin ứng dụng có tên là 'fckeditor' trên trang web của chúng tôi
May mắn thay, nó không tồn tại trên trang web của chúng tôi. Tuy nhiên, cần lưu ý rằng Fckeditor được biết là có rất ít lỗ hổng trong việc thực thi mã và tải lên tệp. Nhiều khả năng đó là những gì mà kẻ tấn công đang cố gắng tấn công.
Bây giờ chúng ta có thể tiến thêm một bước nữa và xem ai khác đã cố gắng hit máy chủ của chúng tôi với máy dò fckeditor
Wow, thật hấp dẫn! Bây giờ, chúng tôi cũng đã có danh sách những người khác cố gắng hit máy chủ của chúng tôi với khai thác Fckeditor.
Bây giờ chúng ta có thể tiến thêm bước nữa, chọn các điểm dữ liệu riêng lẻ trong các hình ảnh khác nhau mà chúng ta đã chuẩn bị và xác định các dữ liệu ngoại lai trong chúng.
Tôi hy vọng tôi có thể chứng minh khả năng của ELK trong ví dụ này. Nếu bạn quan tâm đến việc tìm hiểu thêm về ELK stack và các trường hợp sử dụng của chúng tôi, hãy liên hệ với chúng tôi để có các dịch vụ chuyên nghiệp và chương trình đào tạo về săn bắt mối đe dọa và phân tích bảo mật.
link gốc: http://niiconsulting.com/checkmate/2018/04/security-analytics-using-elk/
VCCloud via niiconsulting.com
>> Có thể bạn quan tâm: Phương pháp phân tích mã độc
