Vượt xa việc chỉ thu thập “bụi kỹ thuật số”
Trong nhiều năm, các bản log Linux của tôi chỉ giống như những nơi bám đầy “bụi kỹ thuật số” trong thư mục /var/log. Tôi chỉ đụng đến chúng khi một dịch vụ bị sập hoặc có người dùng phàn nàn. Đó là bảo mật theo kiểu phản ứng (reactive security), và nó là một trò chơi nắm chắc phần thua. Nếu bạn muốn bắt được một kẻ tấn công tinh vi, bạn không thể ngồi chờ bảng điều khiển (dashboard) chuyển sang màu đỏ. Bạn phải chủ động đi săn.
Sáu tháng trước, tôi cần một cách để xử lý hơn 50GB dữ liệu log mỗi ngày mà không phải tốn công dựng cả một hệ thống ELK stack đồ sộ cho mỗi cuộc điều tra nhỏ. Tôi đã tìm thấy Chainsaw. Đây là một công cụ cực nhanh được viết bằng Rust. Trong khi cộng đồng Windows yêu thích nó để phân tích các tệp EVTX, thì khả năng áp dụng các luật Sigma vào log JSON khiến nó trở thành một “vũ khí” lợi hại cho công tác điều tra số (forensics) trên Linux. Trong các thử nghiệm của mình, nó đã quét một tệp log 10GB chỉ trong khoảng 85 giây—tốc độ mà các quy trình dựa trên grep truyền thống đơn giản là không thể theo kịp.
Trước khi bắt đầu hành trình “đi săn”, tôi phải chấn chỉnh lại các bước bảo mật cơ bản. Tôi bắt đầu thay đổi định kỳ tất cả thông tin quản trị bằng công cụ chạy trên trình duyệt tại toolcraft.app/vi/tools/security/password-generator. Vì nó chạy cục bộ ngay trong trình duyệt, tôi không phải lo lắng về việc mật khẩu bị rò rỉ qua mạng. Thông tin đăng nhập sạch sẽ là lớp phòng thủ đầu tiên; việc săn tìm mối đe dọa sẽ trở nên vô nghĩa nếu “cửa trước” của bạn đang mở toang với một mật khẩu root yếu.
Chuẩn bị sẵn sàng cho Chainsaw
Chainsaw là một tệp thực thi (binary) duy nhất, nên việc cài đặt rất nhẹ nhàng. Tôi không bận tâm đến các trình cài đặt phức tạp; tôi chỉ việc tải các bản phát hành đã biên dịch sẵn trực tiếp từ GitHub. Tôi đã thiết lập một cấu trúc thư mục riêng biệt để tách biệt các quy tắc xử lý (logic) khỏi các tệp thực thi.
# Xây dựng môi trường săn tìm
mkdir -p ~/threat-hunting/chainsaw
cd ~/threat-hunting/chainsaw
# Tải phiên bản v2.10.0 - "động cơ" đằng sau cuộc săn tìm
wget https://github.com/WithSecureLabs/chainsaw/releases/download/v2.10.0/chainsaw_x86_64-unknown-linux-gnu.tar.gz
tar -xvf chainsaw_x86_64-unknown-linux-gnu.tar.gz
sudo mv chainsaw /usr/local/bin/Một công cụ chỉ thông minh khi các quy tắc of nó sắc bén. Đây là lúc các luật Sigma phát huy tác dụng. Hãy coi Sigma như một ngôn ngữ chung để phát hiện các dấu hiệu trong log, tương tự như cách Snort hoạt động đối với lưu lượng mạng. Tôi duy trì một bản sao (clone) của kho lưu trữ Sigma HQ và cập nhật nó hàng tuần.
git clone https://github.com/SigmaHQ/sigma.git ~/threat-hunting/sigma-rulesToàn bộ kho lưu trữ này rất lớn. Để giữ cho việc quét log hiệu quả, tôi trỏ Chainsaw cụ thể vào thư mục con rules/linux. Điều này giúp công cụ không lãng phí tài nguyên để kiểm tra các lỗi can thiệp registry đặc thù của Windows trên một máy chủ Debian.
Điều phối các luật Sigma cho Linux
Log trên Linux thường là một mớ hỗn độn giữa văn bản thuần túy và các tệp binary của journald. Chainsaw phát huy tối đa sức mạnh với dữ liệu có cấu trúc, vì vậy tôi xuất mọi thứ sang định dạng JSON. Nếu bạn đang chạy auditd, bạn đang sở hữu “tiêu chuẩn vàng” về dữ liệu giám sát (telemetry). Việc chuyển đổi các log audit thô này thành cấu trúc JSON là chìa khóa để mở ra khả năng hiển thị chi tiết hệ thống.
Công việc thực sự nằm ở các tệp ánh xạ (mapping). Các luật Sigma có thể tìm kiếm một trường tên là Image, nhưng log Linux của bạn có thể gọi nó là exe hoặc comm. Tôi đã dành nhiều tuần để tinh chỉnh các tệp ánh xạ YAML này. Không có một bản đồ chính xác, Chainsaw về cơ bản sẽ bị “mù” trước những đặc điểm riêng biệt trong định dạng log của bản phân phối Linux bạn đang dùng.
Dưới đây là lệnh chính xác mà tôi sử dụng để thực hiện một đợt quét mục tiêu dựa trên các quy tắc hành vi:
chainsaw hunt /var/log/journal_export.json \
--rules ~/threat-hunting/sigma-rules/rules/linux/ \
--mapping ~/threat-hunting/chainsaw/mappings/sigma-event-logs-all.yml \
--output ~/threat-hunting/results/Tham số --mapping đó chính là “người phiên dịch”. Nó đảm bảo các thông tin tình báo cộng đồng chung trong Sigma thực sự có ý nghĩa khi áp dụng vào các bản log kernel cụ thể của bạn.
Kết quả thực tế: Phát hiện các mối đe dọa thực sự
Sau ba tháng triển khai hệ thống này, nó đã chứng minh được giá trị vượt mong đợi. Hệ thống giám sát tiêu chuẩn của chúng tôi hoàn toàn im lặng, nhưng một lần chạy Chainsaw buổi sáng đã gắn cờ cảnh báo “Suspicious Remote File Copy” (Sao chép tệp từ xa đáng ngờ). Nó đã bắt quả tang một tập lệnh tự động đang cố gắng sử dụng scp với tham số -o để bỏ qua xác thực khóa SSH—một hành động tinh vi mà các cảnh báo thông thường đã bỏ sót.
Khi công cụ gắn cờ một sự kiện, tôi thường xuất kết quả ra tệp CSV để phân loại nhanh (triage). Đừng coi công cụ này là một “nút bấm thần kỳ”; hãy coi nó như một chiếc la bàn. Nó chỉ hướng cho bạn đến những điểm bất thường, nhưng bạn vẫn cần xác minh bối cảnh của cây tiến trình (process tree).
# Kiểm tra nhanh các bất thường khi tạo tiến trình trong thời gian thực
chainsaw hunt /var/log/syslog.json -r ~/sigma-rules/rules/linux/process_creation/Hầu hết “nhiễu” (noise) mà bạn gặp phải sẽ đến từ việc sử dụng sudo và các lập trình viên thay đổi lịch sử shell của họ. Để xử lý việc này, tôi đã tự động hóa quy trình. Mỗi đêm vào lúc 2 giờ sáng, một tác vụ cron sẽ xuất dữ liệu log của 24 giờ qua và thực hiện một đợt quét toàn diện. Tôi thức dậy với một bản tóm tắt chỉ 5 dòng thay vì một núi dữ liệu.
Cách tiếp cận này đã thay đổi hoàn toàn vị thế bảo mật của chúng tôi. Chúng tôi đã cắt giảm đáng kể Thời gian trung bình để phát hiện (MTTD) từ vài ngày xuống còn vài phút. Chúng tôi không còn ngồi chờ thiệt hại xảy ra; chúng tôi tìm kiếm các dấu hiệu dẫn đến nó. Việc tinh chỉnh để loại bỏ các cảnh báo giả (false positives) đòi hỏi sự kiên nhẫn, nhưng mức độ minh bạch mà bạn đạt được đối với hạ tầng của mình là hoàn toàn xứng đáng với nỗ lực đó.
