Đo lường Overhead của eBPF và Kernel Hardening
Chúng ta cần xác định chi phí hiệu năng thực tế mà các lớp bảo mật đã áp dụng gây ra cho Database. Không có số liệu cụ thể, bạn không thể cân bằng giữa bảo mật và hiệu suất.
So sánh thông số cơ sở (Baseline) và sau Hardening
Trước tiên, bạn cần ghi lại các chỉ số hiệu năng của Database trong môi trường chưa hardening hoặc đã hardening. Chúng ta sẽ dùng perf và sysbench để đo.
Bước 1: Chạy test tải chuẩn để tạo baseline.
sysbench oltp_read_write --table-size=100000 --num-threads=8 --report-interval=1 --max-time=60 --mysql-host=localhost --mysql-port=3306 --mysql-user=dbadmin --mysql-password=SecurePass123 --mysql-db=testdb run
Kết quả mong đợi: Một bảng báo cáo hiển thị số lượng transactions (trans/sec), latency (95th percentile) và CPU usage. Ghi lại con số trans/sec này làm mốc so sánh.
Bước 2: Đo lường overhead của eBPF tracepoint đang chạy.
perf stat -e bpf_tracepoint:db_audit -a sleep 30
Kết quả mong đợi: Hiển thị số lần event bpf_tracepoint:db_audit được kích hoạt trong 30 giây. Con số này cho biết tần suất eBPF can thiệp vào luồng thực thi của DB.
Phân tích chi phí CPU và Memory của eBPF
eBPF code chạy trong kernel context, nếu code quá phức tạp sẽ gây tăng kernel CPU usage.
Bước 3: Sử dụng perf để profile kernel CPU usage liên quan đến eBPF.
perf top -e bpf_func
Kết quả mong đợi: Danh sách các hàm eBPF (bpf_prog_xxx) đang chiếm CPU cao nhất. Nếu thấy hàm của chính sách chặn SQL Injection chiếm quá 5% CPU toàn phần, bạn cần tối ưu logic eBPF.
Bước 4: Kiểm tra memory leak hoặc tăng memory usage bất thường của eBPF maps.
cat /sys/fs/bpf/*/maps | grep -E "map_name" && perf stat -e bpf_map:lookup -a sleep 10
Kết quả mong đợi: Xem số lần truy cập map. Nếu số lần lookup quá cao so với số request, chứng tỏ logic tra cứu trong eBPF đang gây overhead.
Verify kết quả đo lường
So sánh trans/sec của sysbench trước và sau khi kích hoạt eBPF.
- Overhead chấp nhận được: Giảm dưới 5-10% throughput.
- Overhead báo động: Giảm trên 15% hoặc tăng latency 95th percentile hơn 50%.
- Nếu vượt ngưỡng, bạn cần tối ưu eBPF program (giảm số lần map lookup, đơn giản hóa logic) hoặc điều chỉnh kernel parameters.
Troubleshooting Database bị treo hoặc chậm sau Hardening
Khi hardening, Database có thể bị hang (treo) hoặc timeout do chính sách bảo mật chặn quá mức hoặc kernel parameters bị đặt sai.
Chẩn đoán sự cố bằng eBPF Tracing
Thay vì nhìn log file truyền thống (chậm và thiếu context), dùng eBPF để trace hành vi kernel trong thời gian thực.
Bước 1: Sử dụng công cụ opensnoop của BCC để xem file nào đang bị chặn khi DB bị treo.
sudo /usr/share/bcc/tools/opensnoop -p -c "if (pid != ) return 0;"
Kết quả mong đợi: Danh sách các file mở gần nhất trước khi DB bị treo. Nếu thấy file log hoặc temp file bị chặn liên tục, có thể do AppArmor/SELinux policy quá chặt.
Bước 2: Trace system call bị từ chối (EACCES) bằng execsnoop hoặc syscall.
sudo /usr/share/bcc/tools/syscall -p -c "err != 0"
Kết quả mong đợi: Danh sách các system call trả về lỗi (negative value). Nếu thấy nhiều lỗi EACCES trên open hoặc write, đây là dấu hiệu chính sách SELinux/AppArmor đang chặn hoạt động hợp lệ.
Kiểm tra và điều chỉnh Kernel Parameters
Một số tham số hardening như net.core.somaxconn hoặc vm.overcommit_memory có thể gây treo nếu DB cần mở nhiều socket hoặc memory lớn.
Bước 3: Kiểm tra số lượng connection bị từ chối do buffer socket đầy.
netstat -s | grep -i "listen" | grep "refused"
Kết quả mong đợi: Nếu số "refused" > 0, bạn cần tăng net.core.somaxconn.
Bước 4: Tăng giá trị net.core.somaxconn trong runtime.
sysctl -w net.core.somaxconn=65535
Kết quả mong đợi: Thông báo net.core.somaxconn = 65535. DB sẽ không còn bị từ chối connection mới ngay lập tức.
Bước 5: Kiểm tra OOM Killer sau hardening.
dmesg | grep -i "out of memory" | tail -n 20
Kết quả mong đợi: Nếu thấy DB process bị kill, kiểm tra tham số vm.overcommit_memory.
Bước 6: Điều chỉnh vm.overcommit_memory nếu DB bị OOM do hardening memory.
sysctl -w vm.overcommit_memory=1
Kết quả mong đợi: Kernel sẽ cho phép overcommit memory, giúp DB chạy mượt hơn với các workload burst, nhưng cần cân nhắc rủi ro OOM nếu memory thực tế không đủ.
Verify kết quả troubleshooting
Chạy lại test tải sau khi điều chỉnh.
- Quan sát
perf top: Không còn các hàm kernel gây blocking.
- Quan sát
dmesg: Không còn thông báo OOM hoặc SELinux/AppArmor deny liên tục.
- Database hoạt động ổn định, latency trở về mức chấp nhận được.
Tự động hóa quy trình Hardening với Ansible và Terraform
Để đảm bảo tính nhất quán và khả năng mở rộng, bạn không nên cấu hình thủ công. Hãy dùng Infrastructure as Code (IaC).
Định nghĩa cấu hình Hardening bằng Ansible
Tạo playbook Ansible để áp dụng các tham số kernel, SELinux policy và cài đặt eBPF.
Bước 1: Tạo file playbook /etc/ansible/playbooks/db_hardening.yml.
- name: Apply Database Hardening
hosts: db_servers
become: yes
tasks:
- name: Set Kernel Parameters for DB
sysctl:
name: "{{ item.key }}"
value: "{{ item.value }}"
state: present
reload: yes
loop:
- { key: 'net.core.somaxconn', value: '65535' }
- { key: 'vm.overcommit_memory', value: '1' }
- { key: 'kernel.yama.ptrace_scope', value: '2' }
- { key: 'kernel.dmesg_restrict', value: '1' }
- name: Install eBPF tools
apt:
name: "{{ item }}"
state: present
loop:
- bpfcc-tools
- linux-headers-{{ ansible_kernel }}
- name: Deploy eBPF BPF program
copy:
src: /var/lib/bpf/db_audit.bpf.c
dest: /usr/local/src/db_audit.bpf.c
mode: '0644'
notify: compile_bpf
- name: Load eBPF program
command: bpftool prog load /usr/local/src/db_audit.bpf.o /sys/fs/bpf/db_audit map create name db_audit_map key_size 4 value_size 8 max_entries 1024
args:
creates: /sys/fs/bpf/db_audit
handlers:
- name: compile_bpf
command: clang -O2 -target bpf -c /usr/local/src/db_audit.bpf.c -o /usr/local/src/db_audit.bpf.o
Kết quả mong đợi: Playbook được lưu thành công. Khi chạy, nó sẽ cấu hình kernel, cài tools và deploy eBPF program tự động.
Tích hợp với Terraform để provision Server
Sử dụng Terraform để tạo server và kích hoạt Ansible module ngay khi server lên.
Bước 2: Tạo file main.tf để định nghĩa infrastructure.
provider "aws" {
region = "ap-southeast-1"
}
resource "aws_instance" "db_server" {
ami = "ami-0c55b159cbfafe1f0" # Ubuntu 22.04 LTS
instance_type = "m5.xlarge"
tags = {
Name = "SecureDB-Node"
Env = "Production"
}
user_data =
Kết quả mong đợi: Terraform tạo instance EC2, chạy user_data script để cài Ansible và tự động chạy playbook hardening.
Verify kết quả tự động hóa
Kiểm tra toàn bộ quy trình.
- Chạy
terraform apply và quan sát terminal.
- SSH vào server mới tạo:
ssh -i key.pem ubuntu@.
- Chạy lệnh kiểm tra:
sysctl net.core.somaxconn và bpftool prog list.
- Xác nhận: Tham số kernel đã đúng và eBPF program đã được load vào kernel.
Điều hướng series:
Mục lục: Series: Triển khai Database an toàn với Linux Kernel Hardening và eBPF
« Phần 6: Tích hợp eBPF với Kernel Hardening để bảo vệ bộ nhớ