Giám Sát Bảo Mật Runtime Trên Linux Với eBPF: Triển Khai Falco Và Tetragon Từ A Đến Z

Tại Sao eBPF Đang Thay Đổi Cục Diện Bảo Mật Linux Trong 2026

Bạn đã triển khai Wazuh để giám sát log, cấu hình nftables chặn traffic xấu, bật SELinux ở chế độ enforcing — nhưng thành thật mà nói, tất cả những lớp phòng thủ đó đều có một điểm mù chung: chúng phản ứng sau khi sự kiện đã xảy ra. Log được ghi sau khi hành động hoàn tất. Firewall chặn dựa trên rule tĩnh. SELinux kiểm soát quyền truy cập nhưng không thực sự theo dõi hành vi bất thường theo thời gian thực.

Đó chính xác là nơi eBPF (extended Berkeley Packet Filter) bước vào cuộc chơi.

eBPF cho phép bạn chạy các chương trình sandbox ngay bên trong Linux kernel — theo dõi mọi system call, kết nối mạng, truy cập file và thực thi tiến trình — với chi phí hiệu năng dưới 1% CPU. Không cần viết kernel module, không cần reboot, không cần sửa mã nguồn kernel. Nghe hơi quá tốt đúng không? Nhưng nó thực sự hoạt động như vậy.

Theo báo cáo CNCF State of Cloud Native Development Q1/2026, các giải pháp bảo mật dựa trên eBPF đã tăng trưởng 300% so với cùng kỳ năm trước trong môi trường production. AWS đã chọn Cilium (xây dựng trên eBPF) làm CNI mặc định cho EKS. Netflix, Datadog, Meta — tất cả đều dùng eBPF làm nền tảng giám sát bảo mật cốt lõi.

Trong bài viết này, mình sẽ hướng dẫn bạn triển khai hai công cụ runtime security hàng đầu dựa trên eBPF — Falco và Tetragon — từ cài đặt, cấu hình, viết policy tùy chỉnh đến tích hợp với hệ thống giám sát hiện có. Mình đã dùng cả hai trong production hơn một năm rồi, nên sẽ chia sẻ cả những kinh nghiệm thực tế nữa.

eBPF Hoạt Động Như Thế Nào Trong Bối Cảnh Bảo Mật

Kiến trúc cơ bản của eBPF

eBPF về cơ bản là một máy ảo được nhúng trong Linux kernel (từ phiên bản 3.18, mở rộng mạnh qua các phiên bản 5.x). Nó cho phép bạn gắn các chương trình nhỏ vào các hook points trong kernel — tracepoints, kprobes, network events, LSM hooks — và thực thi khi hook đó được kích hoạt.

Điều làm eBPF an toàn hơn kernel module truyền thống chính là bộ verifier. Mỗi chương trình eBPF phải qua kiểm tra trước khi chạy, đảm bảo không thể crash kernel, truy cập bộ nhớ tùy ý, hoặc lặp vô tận. Nói cách khác, bạn có thể triển khai trong production mà không cần lo kernel panic — và đó là một điểm cộng rất lớn so với cách viết kernel module kiểu cũ.

So sánh eBPF với các phương pháp giám sát truyền thống

Để hiểu tại sao eBPF vượt trội, hãy so sánh nhanh với các cách tiếp cận cũ:

• Auditd: Thu thập tất cả syscall rồi gửi lên userspace — tạo ra khối lượng log khổng lồ, tốn tài nguyên xử lý, và quan trọng nhất là kẻ tấn công đã hoàn thành hành động trước khi log được phân tích.
• Kernel module (OSSEC/AIDE): Cần compile cho từng phiên bản kernel, có thể gây crash hệ thống nếu có bug, và không thể load/unload linh hoạt. Mình từng gặp trường hợp kernel module conflict sau khi update kernel — không vui chút nào.
• User-space agent: Chạy bên ngoài kernel nên có thể bị tamper, tốn nhiều tài nguyên hơn, và có độ trễ cao hơn.
• eBPF: Hook trực tiếp vào kernel, lọc và xử lý ngay tại nguồn, chỉ gửi event phù hợp lên userspace. Kết quả: phát hiện theo thời gian thực, overhead tối thiểu, không thể bị bypass từ userspace.

Các khả năng phát hiện chính của eBPF

Đây là phần thú vị nhất:

• Syscall Tracing: Theo dõi execve để giám sát mọi command execution, open để phát hiện truy cập file nhạy cảm.
• Privilege Escalation Detection: Phát hiện khi tiến trình thay đổi UID từ non-root sang UID 0 — dấu hiệu gần như chắc chắn của leo thang đặc quyền.
• File Integrity Monitoring thời gian thực: Không như Tripwire quét theo lịch, eBPF bắt được cả file tạo rồi xóa giữa hai lần quét (mình thấy khá nhiều malware làm kiểu này).
• Network Intrusion Detection: Phân tích packet theo thời gian thực — phát hiện port scan, kết nối đến C2 server, reverse shell.
• Behavioral Correlation: Kết hợp nhiều tín hiệu — ví dụ: kết nối mạng từ tiến trình con của shell — để bắt reverse shell bất kể attacker dùng binary nào.

Triển Khai Falco Với Modern eBPF Driver Trên Linux

Falco là gì

Falco là công cụ runtime security mã nguồn mở, ban đầu do Sysdig phát triển, hiện là dự án tốt nghiệp (graduated project) của CNCF. Nó sử dụng eBPF để hook vào kernel, thu thập system call events, và so khớp với các rule do bạn định nghĩa để phát hiện hành vi bất thường.

Từ Falco 0.38.0, driver mặc định đã chuyển sang Modern eBPF — sử dụng công nghệ CO-RE (Compile Once - Run Everywhere). Driver được nhúng sẵn trong binary Falco luôn, không cần tải hay compile riêng. Khá tiện! Phiên bản mới nhất hiện tại là Falco 0.43.0 với driver 9.1.0.

Yêu cầu hệ thống

Trước khi cài, hãy đảm bảo máy bạn đáp ứng các yêu cầu sau:

• Kernel: ≥5.8 (với BPF ring buffer support và BTF enabled)
• Kiểm tra BTF: File /sys/kernel/btf/vmlinux phải tồn tại
• Linux capabilities cần thiết: CAP_SYS_ADMIN, CAP_SYS_RESOURCE, CAP_SYS_PTRACE
• OS khuyến nghị: Ubuntu 22.04/24.04, Debian 12, RHEL 9, AlmaLinux 9, Rocky Linux 9

Cài đặt Falco trên Ubuntu/Debian

# Kiểm tra BTF support
ls -la /sys/kernel/btf/vmlinux
# Nếu file tồn tại, kernel hỗ trợ BTF — sẵn sàng dùng modern_ebpf

# Kiểm tra phiên bản kernel
uname -r
# Cần >= 5.8

# Thêm Falco GPG key và repository
curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \
  sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] https://download.falco.org/packages/deb stable main" | \
  sudo tee /etc/apt/sources.list.d/falcosecurity.list

# Cài đặt Falco
sudo apt-get update
sudo apt-get install -y falco

# Chọn driver modern_ebpf khi được hỏi
# Hoặc cấu hình thủ công sau cài đặt

Cấu hình Modern eBPF driver

Chỉnh sửa file /etc/falco/falco.yaml để đảm bảo Falco dùng Modern eBPF. Đây là phần quan trọng nhất:

# /etc/falco/falco.yaml

# Chọn Modern eBPF driver — QUAN TRỌNG
engine:
  kind: modern_ebpf
  modern_ebpf:
    cpus_for_each_buffer: 2
    buf_size_preset: 4

# Bật JSON output để dễ tích hợp với SIEM
json_output: true
json_include_output_property: true
json_include_tags_property: true

# Ghi log ra file và syslog
file_output:
  enabled: true
  keep_alive: false
  filename: /var/log/falco/events.json

syslog_output:
  enabled: true

# Bật HTTP output để gửi alert đến webhook
http_output:
  enabled: true
  url: "http://localhost:2801"
  user_agent: "falcosecurity/falco"

# Cấu hình rule files
rules_file:
  - /etc/falco/falco_rules.yaml
  - /etc/falco/falco_rules.local.yaml
  - /etc/falco/rules.d

Khởi động và kiểm tra Falco

Giờ thì khởi động Falco và xem nó hoạt động thế nào:

# Khởi động Falco
sudo systemctl enable falco-modern-bpf.service
sudo systemctl start falco-modern-bpf.service

# Kiểm tra trạng thái
sudo systemctl status falco-modern-bpf.service

# Xem log real-time
sudo journalctl -u falco-modern-bpf -f

# Test bằng cách trigger một rule — đọc file /etc/shadow
sudo cat /etc/shadow
# Falco sẽ tạo alert: "Warning Sensitive file opened for reading"

Nếu bạn thấy alert hiện lên khi đọc /etc/shadow, chúc mừng — Falco đang hoạt động đúng rồi.

Viết Falco rule tùy chỉnh

Sức mạnh thực sự của Falco nằm ở khả năng viết rule tùy chỉnh. Bộ rule mặc định đã khá tốt, nhưng mỗi môi trường sẽ có những yêu cầu riêng. Thêm rule của bạn vào /etc/falco/falco_rules.local.yaml:

# /etc/falco/falco_rules.local.yaml

# Phát hiện reverse shell — một trong những kỹ thuật phổ biến nhất
- rule: Reverse Shell Detected
  desc: Phát hiện tiến trình tạo kết nối mạng ra ngoài từ shell con
  condition: >
    evt.type=connect and
    fd.sockfamily=ip and
    fd.ip != "127.0.0.1" and
    proc.pname in (bash, sh, zsh, dash, ksh) and
    not proc.name in (curl, wget, apt-get, yum, dnf, pip)
  output: >
    REVERSE SHELL: kết nối ra ngoài từ shell
    (user=%user.name command=%proc.cmdline
    connection=%fd.name container=%container.id
    image=%container.image.repository)
  priority: CRITICAL
  tags: [network, shell, reverse_shell]

# Phát hiện container chạy với quyền privileged
- rule: Privileged Container Started
  desc: Container được khởi động với flag --privileged
  condition: >
    evt.type=container and
    container.privileged=true
  output: >
    Container privileged được khởi động
    (container=%container.name image=%container.image.repository
    user=%user.name)
  priority: CRITICAL
  tags: [container, privilege]

# Phát hiện thay đổi SSH authorized_keys
- rule: SSH Authorized Keys Modified
  desc: File authorized_keys bị thay đổi — có thể là backdoor
  condition: >
    open_write and
    fd.name endswith "authorized_keys"
  output: >
    File SSH authorized_keys bị sửa đổi
    (user=%user.name file=%fd.name command=%proc.cmdline
    parent=%proc.pname container=%container.id)
  priority: WARNING
  tags: [filesystem, ssh, backdoor]

# Phát hiện crypto miner
- rule: Crypto Mining Process Detected
  desc: Phát hiện tiến trình nghi ngờ là crypto miner
  condition: >
    spawned_process and
    (proc.name in (xmrig, minerd, cpuminer, cgminer, bfgminer) or
     proc.cmdline contains "stratum+tcp" or
     proc.cmdline contains "nicehash" or
     proc.cmdline contains "--donate-level")
  output: >
    Phát hiện crypto miner
    (user=%user.name process=%proc.name cmdline=%proc.cmdline
    container=%container.id image=%container.image.repository)
  priority: CRITICAL
  tags: [process, cryptominer]

# Validate rule trước khi apply
sudo falco --validate /etc/falco/falco_rules.local.yaml

# Reload rule mà không cần restart Falco
sudo kill -SIGHUP $(pidof falco)

Một mẹo nhỏ: luôn validate rule trước khi reload. Mình đã từng có lần rule sai syntax làm Falco refuse load toàn bộ ruleset — mất giám sát mấy tiếng mới phát hiện ra.

Triển Khai Tetragon — eBPF Runtime Enforcement

Tetragon là gì và khác Falco ở điểm nào

Tetragon là sub-project của Cilium (CNCF), cung cấp security observability và runtime enforcement dựa trên eBPF. Vậy nó khác Falco chỗ nào?

• Falco tập trung vào phát hiện (detection) — nó alert khi phát hiện hành vi bất thường, nhưng không chặn.
• Tetragon có thể enforcement (thực thi chính sách) — nó chặn hoặc kill tiến trình ngay tại kernel trước khi hành động hoàn tất. Không có chuyện "phát hiện rồi mới xử lý" — nó xử lý ngay.

Phiên bản mới nhất là Tetragon v1.6.0, với các cải tiến đáng chú ý: hỗ trợ BPF ring buffer mặc định từ kernel v5.11, chạy operator với non-root user, và sửa lỗi khi filename dài làm hỏng dữ liệu command-line argument. Khá là ổn định cho production rồi.

Cài đặt Tetragon trên Linux server

# Tải bản release mới nhất
curl -LO https://github.com/cilium/tetragon/releases/download/v1.6.0/tetragon-v1.6.0-amd64.tar.gz

# Giải nén
tar -xvf tetragon-v1.6.0-amd64.tar.gz
cd tetragon-v1.6.0-amd64/

# Cài đặt
sudo ./install.sh

# Kiểm tra trạng thái
sudo systemctl status tetragon

# Xem events real-time dạng compact
sudo tetra getevents -o compact

Cài đặt Tetragon trên Kubernetes

Nếu bạn đang dùng Kubernetes, quá trình cài đặt qua Helm khá đơn giản:

# Thêm Cilium Helm repo
helm repo add cilium https://helm.cilium.io
helm repo update

# Cài đặt Tetragon
helm install tetragon cilium/tetragon \
  --namespace kube-system \
  --set tetragon.enableProcessCred=true \
  --set tetragon.enableProcessNs=true

# Kiểm tra pods
kubectl get pods -n kube-system -l app.kubernetes.io/name=tetragon

# Cài đặt tetra CLI
GOOS=$(go env GOOS)
GOARCH=$(go env GOARCH)
curl -L --remote-name-all https://github.com/cilium/tetragon/releases/download/v1.6.0/tetra-linux-${GOARCH}.tar.gz
tar -xvf tetra-linux-${GOARCH}.tar.gz
sudo mv tetra /usr/local/bin/

Viết TracingPolicy cho Tetragon

Tetragon sử dụng TracingPolicy — các tài liệu YAML định nghĩa kernel hook nào cần theo dõi và hành động nào cần thực hiện. Nói thật là syntax hơi phức tạp hơn Falco rule, nhưng bù lại bạn được quyền kiểm soát sâu hơn rất nhiều. Dưới đây là các ví dụ thực tế:

Policy 1: Phát hiện đọc file nhạy cảm

# sensitive-file-access.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "monitor-sensitive-files"
spec:
  kprobes:
    - call: "fd_install"
      syscall: false
      args:
        - index: 0
          type: int
        - index: 1
          type: "file"
      selectors:
        - matchArgs:
            - index: 1
              operator: "Prefix"
              values:
                - "/etc/shadow"
                - "/etc/gshadow"
                - "/etc/sudoers"
                - "/root/.ssh"
                - "/etc/ssh/sshd_config"

Policy 2: Chặn thực thi binary trong /tmp — Enforcement

Đây là phần mình thấy ấn tượng nhất về Tetragon:

# block-tmp-execution.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "block-tmp-exec"
spec:
  kprobes:
    - call: "security_bprm_check"
      syscall: false
      args:
        - index: 0
          type: "linux_binprm"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Prefix"
              values:
                - "/tmp/"
                - "/var/tmp/"
                - "/dev/shm/"
          matchActions:
            - action: Sigkill

Cực kỳ quan trọng: Policy trên sử dụng action: Sigkill — nghĩa là Tetragon sẽ kill tiến trình ngay lập tức khi nó cố thực thi binary từ /tmp. Đây là enforcement thực sự ở kernel level, không phải chỉ alert. Mình khuyên bạn nên test kỹ ở staging trước — bạn sẽ ngạc nhiên khi thấy có bao nhiêu ứng dụng hợp lệ cũng chạy binary từ /tmp.

Policy 3: Giám sát kết nối mạng ra ngoài

# monitor-network-connections.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "monitor-outbound-connections"
spec:
  kprobes:
    - call: "tcp_connect"
      syscall: false
      args:
        - index: 0
          type: "sock"
      selectors:
        - matchArgs:
            - index: 0
              operator: "NotDAddr"
              values:
                - "127.0.0.1"
                - "10.0.0.0/8"
                - "172.16.0.0/12"
                - "192.168.0.0/16"

Áp dụng và kiểm tra policy

# Trên Linux server — copy policy vào thư mục Tetragon
sudo cp sensitive-file-access.yaml /etc/tetragon/tetragon.tp.d/
sudo systemctl restart tetragon

# Trên Kubernetes — apply trực tiếp
kubectl apply -f sensitive-file-access.yaml

# Theo dõi events
sudo tetra getevents -o compact

# Test: đọc file /etc/shadow
sudo cat /etc/shadow
# Tetragon sẽ ghi nhận event với đầy đủ thông tin tiến trình

So Sánh Chi Tiết: Falco vs Tetragon — Khi Nào Dùng Cái Nào

Câu hỏi mình hay được hỏi nhất: "Nên dùng Falco hay Tetragon?" Câu trả lời ngắn gọn: dùng cả hai. Nhưng nếu cần chọn một, hãy xem so sánh dưới đây:

• Mục đích chính: Falco tập trung vào phát hiện hành vi bất thường dựa trên rule linh hoạt. Tetragon cung cấp cả observability lẫn enforcement — có thể chặn hành động ngay tại kernel.
• Rule/Policy syntax: Falco dùng ngôn ngữ rule riêng, trực quan và dễ viết hơn. Tetragon dùng YAML TracingPolicy — phức tạp hơn nhưng linh hoạt hơn khi cần hook vào kernel function cụ thể.
• Enforcement: Falco chỉ alert (phát hiện). Tetragon có thể Sigkill hoặc Override return value — chặn trước khi hành động hoàn tất.
• Kubernetes integration: Cả hai đều hỗ trợ, nhưng Tetragon tích hợp sâu hơn với Cilium ecosystem và có cảm giác Kubernetes-native hơn.
• Hệ sinh thái: Falco có cộng đồng lớn hơn, nhiều rule sẵn có hơn, và tích hợp với nhiều SIEM/webhook hơn qua Falcosidekick.
• Kernel minimum: Falco modern_ebpf cần kernel ≥5.8. Tetragon hoạt động từ kernel 4.19 nhưng khuyến nghị 5.10+.

Khuyến nghị thực tế: Nếu ngân sách và tài nguyên cho phép, triển khai cả hai. Dùng Falco cho phát hiện rộng với bộ rule phong phú, dùng Tetragon cho enforcement đặc thù — ví dụ chặn thực thi binary đáng ngờ hoặc kill tiến trình leo thang đặc quyền. Hai công cụ bổ trợ nhau rất tốt.

Tích Hợp Với Wazuh SIEM Và Hệ Thống Giám Sát Hiện Có

eBPF runtime security mạnh nhất khi được tích hợp vào pipeline giám sát toàn diện. Nếu bạn đã triển khai Wazuh (và mình đoán là nhiều bạn đọc bài này đã có), thì phần này sẽ rất hữu ích.

Gửi Falco alerts vào Wazuh

# Bước 1: Cấu hình Falco ghi log JSON ra file
# Đã cấu hình ở phần trên — file /var/log/falco/events.json

# Bước 2: Thêm log source trong Wazuh agent config
# Chỉnh sửa /var/ossec/etc/ossec.conf trên agent

<localfile>
  <log_format>json</log_format>
  <location>/var/log/falco/events.json</location>
  <label key="log_type">falco</label>
</localfile>

# Bước 3: Tạo Wazuh decoder cho Falco
# Thêm vào /var/ossec/etc/decoders/local_decoder.xml trên Wazuh Server

<decoder name="falco">
  <prematch>\"priority\"</prematch>
  <plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>

# Bước 4: Tạo Wazuh rules cho Falco alerts
# Thêm vào /var/ossec/etc/rules/local_rules.xml

<group name="falco,">
  <rule id="100400" level="3">
    <decoded_as>falco</decoded_as>
    <description>Falco runtime alert</description>
  </rule>

  <rule id="100401" level="12">
    <if_sid>100400</if_sid>
    <field name="priority">Critical</field>
    <description>Falco CRITICAL: $(output)</description>
  </rule>

  <rule id="100402" level="10">
    <if_sid>100400</if_sid>
    <field name="priority">Warning</field>
    <description>Falco WARNING: $(output)</description>
  </rule>
</group>

Gửi Tetragon events vào SIEM

# Tetragon xuất events dạng JSON qua gRPC hoặc stdout
# Dùng tetra CLI để export ra file cho SIEM thu thập

sudo tetra getevents -o json > /var/log/tetragon/events.json &

# Hoặc cấu hình export trong /etc/tetragon/tetragon.yaml
export-filename: /var/log/tetragon/events.json
export-file-max-size-mb: 100
export-file-rotation-interval: 24h
export-file-max-backups: 5
export-file-compress: true

Sau khi tích hợp xong, bạn sẽ có alert từ eBPF tools hiển thị ngay trên Wazuh dashboard — kết hợp với các nguồn log khác để có bức tranh bảo mật toàn diện.

Cảnh Báo Bảo Mật: eBPF Rootkit Và Cách Phòng Chống

Phần này hơi đáng sợ, nhưng bạn cần biết: eBPF là con dao hai lưỡi. Cùng công nghệ cho phép defender giám sát kernel cũng có thể bị attacker lợi dụng để viết rootkit cực kỳ tinh vi.

Kỹ thuật tấn công eBPF rootkit hiện đại

Rootkit eBPF hiện đại nhắm vào pipeline giám sát bằng cách chặn function bpf_ringbuf_submit — function mà các chương trình eBPF dùng để đẩy event vào ring buffer. Khi rootkit lọc hoặc drop event trước khi chúng đến buffer, hành động vẫn xảy ra trên hệ thống nhưng công cụ giám sát không bao giờ nhận được record đó. Nói đơn giản: attacker trở nên vô hình trước mắt Falco/Tetragon.

Biện pháp phòng chống

# 1. Vô hiệu hóa unprivileged eBPF — BẮT BUỘC
echo 1 | sudo tee /proc/sys/kernel/unprivileged_bpf_disabled

# Làm cho cấu hình này persistent qua reboot
echo "kernel.unprivileged_bpf_disabled=1" | sudo tee -a /etc/sysctl.d/99-ebpf-security.conf
sudo sysctl -p /etc/sysctl.d/99-ebpf-security.conf

# 2. Bật BPF JIT hardening
echo 2 | sudo tee /proc/sys/net/core/bpf_jit_harden
echo "net.core.bpf_jit_harden=2" | sudo tee -a /etc/sysctl.d/99-ebpf-security.conf

# 3. Giám sát các chương trình eBPF đang chạy
sudo bpftool prog list
# Kiểm tra xem có program nào không thuộc về Falco/Tetragon không

# 4. Audit ai load eBPF program
sudo auditctl -a always,exit -F arch=b64 -S bpf -k ebpf_load

Ngoài ra, bạn nên triển khai Secure Boot và kernel lockdown mode để giảm thiểu khả năng attacker load eBPF program độc hại. Trên RHEL 9/Ubuntu 24.04, kernel lockdown đã được hỗ trợ mặc định khi Secure Boot bật — nên đây không phải việc phức tạp lắm đâu.

Thực Hành Tốt Nhất Khi Triển Khai eBPF Security 2026

Sau khi đã triển khai eBPF security cho nhiều hệ thống, đây là những bài học mình rút ra:

1. Bắt đầu ở chế độ giám sát: Deploy Falco và Tetragon ở chế độ alert-only trước. Quan sát volume event và loại bỏ false positive trong ít nhất 2 tuần trước khi bật enforcement. Tin mình đi, bạn sẽ cảm ơn bước này.
2. Kernel version: Dùng kernel mới nhất có thể. Kernel ≥5.11 hỗ trợ BPF ring buffer cho hiệu suất tốt nhất. Kernel ≥6.1 có nhiều cải tiến eBPF đáng kể.
3. Tách biệt rule/policy theo môi trường: Staging dùng rule rộng để phát hiện nhiều, production dùng rule tinh chỉnh để giảm nhiễu.
4. Giám sát chính công cụ giám sát: Dùng systemd watchdog hoặc Wazuh để theo dõi Falco/Tetragon — nếu chúng bị kill, bạn cần biết ngay lập tức.
5. Cập nhật rule thường xuyên: Falco phát hành rule mới hàng tháng. Theo dõi falcosecurity/rules trên GitHub để cập nhật.
6. Tài nguyên hệ thống: eBPF overhead dưới 1% CPU là bình thường. Nếu vượt 3%, kiểm tra lại policy — có thể bạn đang hook quá nhiều kernel function cùng lúc.

Câu Hỏi Thường Gặp (FAQ)

eBPF có an toàn không? Liệu chương trình eBPF có thể crash kernel?

Có, eBPF được thiết kế an toàn. Mỗi chương trình eBPF phải qua bộ verifier trước khi chạy trong kernel — bộ verifier kiểm tra đảm bảo không có vòng lặp vô tận, không truy cập bộ nhớ ngoài phạm vi, và không có thao tác gây crash. Đây là lý do eBPF an toàn hơn rất nhiều so với kernel module truyền thống. Tuy nhiên, eBPF vẫn cần quyền CAP_SYS_ADMIN hoặc CAP_BPF để load, nên hãy đảm bảo chỉ user tin cậy mới có quyền này.

Falco và Tetragon có thể chạy đồng thời trên cùng một máy không?

Hoàn toàn được, và mình khuyến khích làm vậy. Cả hai đều sử dụng eBPF nhưng không xung đột vì mỗi công cụ load các chương trình eBPF riêng biệt. Cách triển khai tốt nhất là dùng Falco cho phát hiện rộng với bộ rule phong phú, kết hợp Tetragon cho enforcement — chặn hành vi nguy hiểm ngay tại kernel level. Overhead tổng cộng thường dưới 2% CPU, hoàn toàn chấp nhận được.

Kernel tối thiểu cần bao nhiêu để dùng eBPF security tools?

Falco với Modern eBPF driver cần kernel ≥5.8 có hỗ trợ BTF (kiểm tra bằng ls /sys/kernel/btf/vmlinux). Tetragon hoạt động từ kernel 4.19 nhưng khuyến nghị 5.10+ để có đầy đủ tính năng. Với ARM64, Tetragon cần kernel 5.10+. Hầu hết distro hiện đại — Ubuntu 22.04+, RHEL 9+, Debian 12+ — đều đáp ứng yêu cầu này rồi.

eBPF security monitoring có thay thế được Wazuh/OSSEC không?

Không, và mình nghĩ bạn cũng không nên thay thế mà nên bổ sung. eBPF tools như Falco/Tetragon giám sát runtime behavior ở kernel level — phát hiện hành vi bất thường theo thời gian thực. Wazuh/OSSEC là SIEM — thu thập, phân tích, tương quan log từ nhiều nguồn, quản lý compliance và phản ứng sự cố. Cách tốt nhất là gửi Falco alerts vào Wazuh để có bức tranh toàn diện: eBPF phát hiện nhanh, Wazuh tương quan và phản ứng.

Làm sao phát hiện nếu attacker cài eBPF rootkit trên hệ thống?

Dùng lệnh bpftool prog list để liệt kê tất cả chương trình eBPF đang chạy. So sánh với danh sách đã biết (Falco, Tetragon, Cilium). Bất kỳ program nào không thuộc về công cụ bạn đã cài đặt đều đáng ngờ và cần điều tra ngay. Ngoài ra, bật audit cho syscall bpf() bằng auditd và vô hiệu hóa unprivileged eBPF (kernel.unprivileged_bpf_disabled=1) là hai bước bắt buộc.