Chống giả mạo bản ghi (Log) với Journald Forward Sealing (FSS)

Sự im lặng lúc 2 giờ sáng: Khi các bản ghi biến mất

Lúc 2:14 sáng, một cảnh báo ‘Critical’ từ Nagios báo về điện thoại của tôi. Cụm cơ sở dữ liệu chính đang bị treo ở mức 98% tải CPU. Tôi vội vàng đến bàn làm việc, lấy laptop và SSH vào node đó. Hành động đầu tiên của tôi là một phản xạ tự nhiên: kiểm tra journal.

journalctl -xe

Trống rỗng. Lệnh này chỉ đưa ra năm dòng lẻ loi từ hai phút trước. Mười giờ lịch sử trước đó — các lần đăng nhập SSH, thực thi sudo, lỗi ứng dụng — đơn giản là đã biến mất. Cảm giác như máy chủ này vừa mới được “sinh ra” vào lúc 2:12 sáng vậy.

Đó là khoảnh khắc kinh hoàng khi bạn nhận ra một cuộc tấn công đang diễn ra. Kẻ tấn công không chỉ nhanh; chúng còn đủ kỷ luật để xóa sạch bằng chứng. Vào thời điểm tôi đăng nhập, chúng đã xóa sạch journal của hệ thống. Đây là lỗ hổng cơ bản của việc ghi log thông thường. Nếu kẻ tấn công có quyền root, chúng sở hữu luôn cả lịch sử của bạn. Chúng có thể xóa log, ghi đè mốc thời gian hoặc chèn các mục giả để khiến bạn phải đuổi theo những bóng ma.

Tôi đã dành cả tuần đó để dựng lại hệ thống. Quan trọng hơn, tôi dành thời gian đó để đảm bảo mình sẽ không bao giờ bị “mù” thông tin một lần nữa. Quá trình tìm kiếm giải pháp đã dẫn tôi đến Forward Sealing (FSS) trong systemd-journald.

Lỗ hổng trong thiết lập hiện tại của bạn

Hầu hết các bản phân phối Linux hiện đại đều dựa vào systemd-journald. Nó nhanh và xử lý dữ liệu nhị phân tốt, nhưng theo mặc định, log chỉ là các tệp trên đĩa. Với đặc quyền root, một lệnh đơn giản rm -rf /var/log/journal/* hoặc chỉnh sửa có mục tiêu bằng trình chỉnh sửa hex có thể phá hủy toàn bộ dấu vết pháp lý của bạn.

Ghi log tập trung (như đẩy sang ELK stack) là rất quan trọng, nhưng nó không phải là “viên đạn bạc”. Luôn có một khoảng trễ nhất định. Một script thông minh có thể tắt tiến trình ghi log, xóa bộ đệm cục bộ và để lại một lỗ hổng lớn trong bằng chứng trước khi dữ liệu kịp truyền đi qua mạng. Chúng ta cần một cách để chứng minh rằng những gì chúng ta đang đọc chính xác là những gì hệ thống đã ghi lại.

How Forward Sealing (FSS) Works

Forward Sealing là một tính năng mã hóa được tích hợp trực tiếp vào systemd. Nó sử dụng Forward Secure Pseudo-Random Generator (FSPRG) để bảo vệ tính toàn vẹn cho dữ liệu của bạn.

Hệ thống tạo ra một chuỗi các khóa mã hóa. Cứ sau mỗi 15 phút (khoảng thời gian mặc định), nó sẽ tạo ra một “khóa niêm phong” (sealing key) mới và ngay lập tức hủy khóa trước đó. Mỗi mục log được ký bằng khóa hiện tại. Vì các khóa cũ đã bị xóa khỏi bộ nhớ và đĩa, kẻ tấn công chiếm được quyền root lúc 3:00 chiều không thể giả mạo hoặc sửa đổi các bản ghi từ lúc 2:00 chiều. Chúng thiếu các khóa để tạo lại các chữ ký cụ thể đó.

Nó hoạt động giống như một con dấu sáp kỹ thuật số thay đổi hoa văn sau mỗi 15 phút. Nếu kẻ xâm nhập phá vỡ con dấu từ ba giờ trước, họ không thể thay thế nó. Khuôn dấu cụ thể đó đã biến mất mãi mãi.

Thiết lập Forward Sealing (FSS)

Bảo mật bắt đầu từ vòng ngoài. Khi tôi thiết lập node này, tôi đã sử dụng trình tạo mật khẩu tại toolcraft.app/vi/tools/security/password-generator cho thông tin đăng nhập root ban đầu. Nó chạy hoàn toàn trong trình duyệt, nên không có dữ liệu nào được truyền qua mạng. Đó là một bước đầu tiên tuyệt vời, nhưng ngay cả mật khẩu mạnh nhất cũng không thể ngăn chặn một lỗ hổng zero-day. Đó là lúc FSS đóng vai trò như một hộp đen ghi lại hành trình của bạn.

Bước 1: Tạo cặp khóa

Để khởi tạo FSS, bạn phải tạo một cặp khóa. Việc này sẽ tạo ra một Sealing Key cho máy chủ và một Verification Key cho bạn. Hãy chạy lệnh sau:

sudo journalctl --setup-keys

Bạn sẽ thấy kết quả tương tự như thế này:

# Khóa niêm phong đã được tạo và lưu trữ tại /var/log/journal/...
# Khóa xác thực là: 791a2b845c... (một chuỗi 64 ký tự)

# Khóa niêm phong có hiệu lực trong khoảng thời gian 15 phút.
# Nó sẽ được tự động xoay vòng (rotate).

Đừng bỏ qua bước này: Hãy sao chép khóa xác thực đó. Lưu nó vào một kho lưu trữ bảo mật hoặc in ra và cất vào két sắt vật lý. Nếu bạn mất khóa này, bạn sẽ không bao giờ có thể xác thực các bản ghi của mình. Nếu kẻ tấn công có được nó, chúng có thể giả mạo log. Hãy giữ nó hoàn toàn tách biệt khỏi máy chủ.

Bước 2: Điều chỉnh khoảng thời gian niêm phong

Khoảng thời gian 15 phút mặc định thường là đủ tốt, nhưng các môi trường quan trọng có thể cần độ chính xác cao hơn. Nếu kẻ tấn công xóa log sau năm phút kể từ khi niêm phong, bạn sẽ mất cửa sổ năm phút đó. Bạn có thể rút ngắn khoảng thời gian này bằng cách sử dụng cờ --interval:

sudo journalctl --setup-keys --interval=10s

Mặc dù khoảng thời gian 10 giây mang lại độ chi tiết đáng kinh ngạc, nhưng nó làm tăng nhẹ mức sử dụng CPU. Trên phần cứng Xeon hoặc EPYC hiện đại, tác động thường dưới 1%, nhưng vẫn nên theo dõi.

Bước 3: Kích hoạt dịch vụ

Sau khi các khóa đã sẵn sàng, systemd-journald sẽ bắt đầu ký các bản ghi. Tôi thường khởi động lại dịch vụ để đảm bảo cấu hình được khởi tạo đầy đủ.

sudo systemctl restart systemd-journald

Xác thực bản ghi của bạn

Nếu bạn nghi ngờ có sự xâm nhập, giờ đây bạn có thể xác thực log bằng Verification Key ngoại tuyến của mình. Đây là lúc điều kỳ diệu xảy ra.

journalctl --verify --verify-key=791a2b845c...

Hệ thống sẽ quét mọi tệp journal, kiểm tra chữ ký mã hóa so với khóa. Nếu các bản ghi không bị can thiệp, bạn sẽ thấy thông báo thành công:

PASS: /var/log/journal/...
# Tệp journal /var/log/journal/.../system.journal đã được xác thực thành công.

Nếu kẻ tấn công xóa dù chỉ một dòng hoặc sửa đổi mốc thời gian, quá trình xác thực sẽ thất bại ngay lập tức. Nó sẽ chỉ ra chính xác điểm mà chuỗi bị đứt gãy. Ngay cả khi chúng xóa hoàn toàn các tệp journal, các số thứ tự bị thiếu sẽ lộ rõ trong quá trình kiểm tra của bạn.

Bài học thực tế

Tôi đã chạy FSS trên các cụm máy chủ production trong hơn một năm. Đây là những gì tôi rút ra được:

• Xoay vòng tự động: Khi các tệp journal đạt đến giới hạn kích thước (ví dụ: 500MB) và xoay vòng, siêu dữ liệu FSS sẽ được chuyển sang một cách liền mạch.
• Phòng thủ đa lớp: FSS bảo vệ đĩa cục bộ. Bạn vẫn nên đẩy log sang một hệ thống SIEM từ xa. FSS là phương án dự phòng khi bạn không thể tin tưởng vào log truyền qua mạng.
• Kiểm tra thường xuyên: Đừng đợi đến khi thảm họa xảy ra. Hãy thiết lập một tác vụ cron hàng tháng để xác thực tính toàn vẹn của log. Điều này đảm bảo không có lỗi phần cứng nào đang âm thầm làm hỏng dữ liệu của bạn.

Tại sao điều này lại quan trọng

Trong một cuộc điều tra, sự chắc chắn là tất cả. Khi bạn đang nhìn chằm chằm vào màn hình lúc 2 giờ sáng, bạn cần biết liệu dữ liệu đó có phải là sự thật hay không. Không có FSS, bạn chỉ đang nhìn vào một tệp văn bản mà bất kỳ người dùng root nào cũng có thể viết ra.

FSS sẽ không ngăn chặn được một cuộc tấn công khai thác. Nó sẽ không ngăn kẻ tấn công làm sập cơ sở dữ liệu của bạn. Nhưng nó ngăn chúng lẩn trốn. Nó buộc chúng phải để lại dấu chân, và trong trò chơi cân não khi ứng phó sự cố, dấu chân đó thường là cách duy nhất để tóm gọn chúng.

Nếu bạn chưa bật tính năng này, hãy làm ngay hôm nay. Chỉ mất năm phút và bạn sẽ thầm cảm ơn chính mình khi có cảnh báo tiếp theo xảy ra.