Tại sao eBPF đang thay thế các tác nhân User-Space trong giám sát bảo mật?

Tại sao eBPF đang thay thế các tác nhân User-Space trong giám sát bảo mật?

eBPF đang nổi lên như phương pháp ưu tiên cho khả năng quan sát bảo mật so với các tác nhân truyền thống. Bằng cách gắn các probe trực tiếp vào giao diện syscall của nhân Linux, nó cung cấp khả năng hiển thị nhất quán ngay cả khi container bị xâm phạm. eBPF giúp giảm tiêu thụ CPU liên quan đến bảo mật và giới hạn lượng dữ liệu thông qua cơ chế lọc ở mức nhân, nâng cao hiệu suất vận hành.

Giới thiệu

Năm ngoái, tôi đã điều tra một báo cáo sau sự cố (post-mortem) về một cuộc tấn công thoát ra khỏi container (container breakout) hoàn toàn không bị phát hiện trong một cụm Kubernetes sản xuất. Đội bảo mật đã mở các bảng điều khiển, lướt qua nhật ký nhưng không tìm thấy thông tin gì hữu ích. Hóa ra là kẻ tấn công đã giết ngay lập tức logging sidecar như một bước đầu tiên. Mọi thứ diễn ra sau đó đều vô hình đối với hệ thống.

Cuộc tấn công thực ra không quá tinh vi. Chỉ là stack giám sát có một điểm yếu cấu trúc sẵn: tác nhân (agent) chia sẻ không gian người dùng (user-space) với thứ mà nó được giao nhiệm vụ theo dõi. Với quyền root trong container, kẻ tấn công có thể dùng lệnh kill -9 để tắt tác nhân, cắt ngắn các tệp nhật ký, và sau đó tự do hành động. Các payload không dùng tệp (fileless) thông qua memfd_create() không bao giờ chạm vào hệ thống tệp. Việc tiêm quy trình ẩn sau các PID đáng tin cậy. Lớp ghi nhật ký là mục tiêu mềm nhất trong toàn bộ thiết lập này.

Bài viết đó đã khiến tôi nghiêm túc tìm hiểu về eBPF. Mọi quy trình, độc hại hay không, đều phải vượt qua ranh giới syscall để mở tệp, kết nối mạng hoặc tạo ra quy trình con. eBPF cho phép bạn instrument (cắm công cụ đo lường) ranh giới đó ngay bên trong nhân, nơi kẻ tấn công ở cấp độ container không thể với tới.

Vấn đề của các tác nhân bảo mật User-Space

Hầu hết giám sát bảo mật Kubernetes chạy dưới dạng các container sidecar hoặc DaemonSets, về cơ bản là các quy trình user-space nằm cạnh các khối lượng công việc mà chúng theo dõi.

Mô hình giám sát bảo mật truyền thống dựa trên sidecar

Kiến trúc này có một vấn đề cơ bản: tác nhân bảo mật và kẻ tấn công hoạt động ở cùng một cấp độ. Với quyền root trong container, kẻ tấn công có thể:

• Dùng lệnh kill -9 để tiêu diệt tác nhân bảo mật.
• Dùng lệnh truncate để xóa trắng các tệp nhật ký.
• Trích xuất dữ liệu bí mật ra ngoài mà không kích hoạt bất kỳ cảnh báo nào vì tác nhân đã bị "chết" trước khi bất cứ điều gì thú vị xảy ra.

Các tác nhân user-space cũng gây ra chi phí thực sự. Để kiểm tra lưu lượng mạng, chúng phải proxy các kết nối thông qua chính mình, nghĩa là mọi gói tin phải vượt qua ranh giới người dùng - nhân nhiều lần. Thêm vào đó là việc tuần tự hóa, phân tích cú pháp và truyền tải nhật ký, rất dễ để mất một phần đáng kể CPU của cụm chỉ cho chi phí giám sát.

eBPF thay đổi cuộc chơi như thế nào

eBPF cho phép bạn chạy các chương trình sandbox bên trong nhân Linux mà không cần viết mô-đun nhân. Ban đầu là một cơ chế lọc gói tin (do đó có tên "Berkeley Packet Filter"), phiên bản mở rộng hiện đại là một khung instrument nhân đa mục đích. Ba yếu tố quan trọng đối với bảo mật là:

1. Trình xác minh (Verifier) tích hợp: Phân tích tĩnh từng chương trình eBPF tại thời điểm tải, chứng minh rằng nó không thể làm sập nhân, truy cập bộ nhớ trái phép hoặc lặp vô hạn.
2. Ngữ cảnh nhân: Các chương trình eBPF thực thi trong ngữ cảnh nhân với quyền truy cập trực tiếp vào các cấu trúc dữ liệu nhân. Không có chuyển đổi ngữ cảnh người dùng - nhân, không có chi phí proxy.
3. Điểm gắn (Attach points): Bạn có thể gắn các probe đến hàng nghìn hàm nhân, syscall, sự kiện mạng và tracepoint.

Trình xác minh xứng đáng được nhắc đến riêng. Việc chạy mã tùy chỉnh trong nhân khiến mọi người lo ngại, và điều đó là đúng với các mô-đun nhân. Một mô-đun bị lỗi có thể gây panic cho máy. Trình xác minh của eBPF loại bỏ hoàn toàn chế độ thất bại này. Nó đi qua mọi đường dẫn thực thi có thể thông qua bytecode và kiểm tra các đảm bảo chấm dứt, giới hạn bộ nhớ, hạn chế gọi hàm và độ sâu ngăn xếp. Tất cả đều tĩnh, trước khi chương trình được tải.

Các probe eBPF nằm ở giao diện syscall

Đối với bảo mật, các chương trình eBPF gắn tại giao diện syscall, ranh giới mà mọi quy trình phải vượt qua cho các hoạt động đặc quyền. Khi bất kỳ quy trình nào gọi connect(), execve() hoặc open(), probe sẽ bắt giữ các đối số syscall, ID quy trình/chủ đề, ID container, metadata pod Kubernetes, ID người dùng, khả năng và chuỗi quy trình cha. Vì probe chạy trong ngữ cảnh nhân, kẻ tấn công có root trong container sẽ cần thoát ra khỏi nhân máy chủ (host kernel) để can thiệp vào nó. Đó là một vấn đề hoàn toàn khác so với việc giết một quy trình user-space.

Câu chuyện về chi phí và hiệu suất

Các tổ chức đã thay thế stack bảo mật user-space nhiều tác nhân bằng một tác nhân duy nhất dựa trên eBPF báo cáo mức giảm CPU từ 60-80% cho khối lượng công việc bảo mật.

Cũng có khía cạnh về thể tích dữ liệu. Các tác nhân user-space gửi mọi dòng nhật ký, sự kiện kết nối và quyền truy cập tệp đến một nền tảng tập trung, nơi phần lớn trong số đó bị loại bỏ sau khi tiêu thụ. Với eBPF, việc lọc diễn ra trong nhân, vì vậy chỉ những sự kiện thực sự quan trọng mới rời khỏi node. Việc giảm chi phí tiêu thụ SIEM thay đổi tùy theo khối lượng công việc, nhưng đối với hầu hết các trường hợp, nó là đáng kể.

Về tính tương thích nhân, các tính năng quan trọng cho bảo mật sản xuất đã được giới thiệu qua các nhân từ 4.15 đến 5.7. Hầu hết các bản phân phối Kubernetes sản xuất đều đi kèm với nhân 5.4+, nên hỗ trợ nhân hiếm khi là rào cản.

Triển khai từng giai đoạn để không làm hỏng hệ thống

Đừng bỏ qua bước quan sát để đi thẳng đến thực thi (enforcement). Con đường đó dẫn đến các dương tính giả giết chết quy trình sản xuất và một bản báo cáo sau sự cố rất khó xử.

Chiến lược triển khai từng giai đoạn: Quan sát, Cảnh báo, sau đó Thực thi

Giai đoạn 1: Quan sát và Học hỏi

Triển khai một tác nhân eBPF (như Falco hoặc Tetragon) dưới dạng DaemonSet ở chế độ thụ động. Tác nhân quan sát tất cả các syscall nhưng không chặn bất cứ thứ gì. Trong giai đoạn này, bạn đang xây dựng các đường cơ sở (baselines): binary nào mà mỗi dịch vụ chạy, kết nối mạng nào nó thiết lập, tệp nào nó chạm vào.

Giai đoạn 2: Cảnh báo về bất thường

Viết các quy tắc phát hiện dựa trên các đường cơ sở. Đây là phát hiện hành vi, không phải khớp chữ ký. Bạn đang tìm kiếm các sự lệch lạc so với những gì bạn biết là bình thường. Ví dụ, một quy tắc Falco để phát hiện quy trình không mong muốn trong dịch vụ thanh toán:

- rule: Unexpected Process in Payment Service
  desc: Detect execution of binaries not in the approved list
  condition: >
    spawned_process and
    container.name startswith "payment-" and
    not proc.name in (java, jcmd, jstat)
  output: >
    Unexpected process executed in payment container
    (user=%user.name container=%container.name
    process=%proc.name cmdline=%proc.cmdline
    parent=%proc.pname)
  priority: WARNING

Hãy dành thời gian điều chỉnh trong giai đoạn này. Xem xét mọi cảnh báo, hiểu các dương tính giả, chặn các mẫu đã biết là an toàn. Chỉ chuyển sang thực thi khi khối lượng cảnh báo có thể quản lý được và bạn đã xác thực các quy tắc chống lại các kịch bản tấn công đã biết.

Giai đoạn 3: Thực thi

Với sự tự tin cao vào các quy tắc phát hiện của mình, hãy bật chặn hoạt động. Tetragon có thể sử dụng bpf_send_signal() để gửi tín hiệu SIGKILL đến một quy trình trước khi syscall độc hại hoàn tất. Thời gian phản hồi được đo bằng microgiây, không phải phút hay giờ như quy trình IR truyền thống.

Giai đoạn này đòi hỏi kỷ luật. Một dương tính giả giết chết một quy trình hợp pháp là một sự cố ngừng dịch vụ. Các giai đoạn quan sát và cảnh báo tồn tại cụ thể để xây dựng đủ sự tự tin rằng việc thực thi không trở thành gánh nặng.

Công cụ và Bảo mật triển khai

Falco là nơi tôi sẽ bắt đầu với hầu hết các đội ngũ. Đó là một dự án đã tốt nghiệp của CNCF với cộng đồng lớn và nhiều năm vận hành sản xuất. Nó móc vào giao diện syscall thông qua eBPF và đánh giá các sự kiện dựa trên công cụ quy tắc dựa trên YAML.

Đối với việc thực thi hoạt động, nơi bạn cần giết một quy trình trước khi syscall độc hại hoàn tất, hãy xem xét Tetragon. Đó là một dự án con của Cilium và áp dụng chính sách đồng bộ trong nhân. Các nhà cung cấp thương mại như Sysdig, Datadog và Wiz cũng đã xây dựng lại tác nhân của họ dựa trên eBPF.

Các chương trình eBPF chạy trong nhân với các quyền nâng cao, vì vậy đừng lơ là bảo mật triển khai. Việc tải chương trình yêu cầu CAP_BPF (hoặc CAP_SYS_ADMIN trên nhân trước 5.8). Hãy bắt đầu với một container có đặc quyền nếu cần, sau đó thắt chặt xuống các khả năng tối thiểu, thường là CAP_BPF, CAP_PERFMON và CAP_SYS_RESOURCE.

Kết luận

Ghi nhật ký cấp ứng dụng sẽ không biến mất. Bạn vẫn cần nó để gỡ lỗi logic kinh doanh và truy vết yêu cầu qua lưới dịch vụ. Nhưng đối với bảo mật, nơi bước đi đầu tiên của kẻ thù là vô hiệu hóa công cụ đo lường của bạn, bạn cần giám sát ở một lớp mà chúng không thể dễ dàng tiếp cận.

eBPF mang lại điều đó. Khả năng hiển thị cấp syscall vẫn tồn tại bất kể ứng dụng làm gì, công cụ đo lường sống trong nhân nơi sự xâm phạm cấp độ container không thể chạm vào, và chi phí thấp hơn nhiều so với các tác nhân user-space áp đặt.

Nếu bạn muốn tự mình xem điều này: hãy triển khai Falco trên một cụm staging ở chế độ chỉ quan sát. Dành ba mươi phút để xem các sự kiện nó bắt giữ. Khoảng cách giữa những gì giám sát hiện tại của bạn hiển thị và những gì eBPF tiết lộ ở cấp syscall sẽ thuyết phục bạn tốt hơn bất cứ điều gì tôi có thể viết ở đây.