Chuyển tới nội dung chính

Bảo Mật systemd Service Hiệu Quả

Giới Thiệu​

systemd là hệ thống khởi tạo và quản lý dịch vụ (init system) tiêu chuẩn trên hầu hết các bản phân phối Linux hiện đại. Mọi ứng dụng, từ máy chủ web đơn giản đến cơ sở dữ liệu phức tạp, thường được quản lý như một service systemd. Việc cấu hình và bảo mật đúng cách các service này là yếu tố then chốt để bảo vệ toàn bộ hệ thống Linux của bạn khỏi các mối đe dọa tiềm ẩn. Bài viết này sẽ hướng dẫn bạn cách áp dụng các biện pháp bảo mật nâng cao cho các systemd service, dựa trên nguyên tắc đặc quyền tối thiểu và cô lập tài nguyên.

📋 Thời gian: 25 phút | Độ khó: Trung bình

Yêu Cầu​

Để thực hiện theo hướng dẫn này, bạn cần:

  • Một hệ thống Linux đang chạy systemd (ví dụ: Ubuntu, CentOS, Debian, Fedora).
  • Quyền truy cập root hoặc quyền sử dụng sudo.
  • Kiến thức cơ bản về Linux command line và cách chỉnh sửa file văn bản.
  • Hiểu biết cơ bản về cách hoạt động của systemd service.

Các Bước Thực Hiện​

Bước 1: Hiểu về systemd Unit File và Vị Trí​

Các cấu hình cho systemd service được định nghĩa trong các file gọi là "unit file" với đuôi .service. Chúng thường được tìm thấy ở các vị trí sau:

  • /etc/systemd/system/: Dành cho các service tùy chỉnh hoặc ghi đè cấu hình.
  • /usr/lib/systemd/system/: Dành cho các service được cài đặt bởi các gói phần mềm.
  • /run/systemd/system/: Dành cho các service được tạo động trong thời gian chạy.

Bạn nên tạo hoặc chỉnh sửa các unit file trong /etc/systemd/system/ để đảm bảo cấu hình của bạn không bị ghi đè khi cập nhật gói phần mềm.

Để tạo một service mới hoặc chỉnh sửa service hiện có, bạn sẽ làm việc với một file .service cụ thể. Ví dụ, chúng ta sẽ tạo một service mẫu có tên mywebapp.service.

# Mở hoặc tạo một unit file mới
sudo nano /etc/systemd/system/mywebapp.service

Bước 2: Giảm Thiểu Quyền Hạn (Least Privilege)​

Nguyên tắc đặc quyền tối thiểu là chạy service với quyền hạn thấp nhất có thể để thực hiện công việc của nó. Điều này giới hạn thiệt hại nếu service bị xâm nhập.

2.1. Chạy Service với Người Dùng và Nhóm Riêng​

Luôn chạy các service dưới một người dùng và nhóm chuyên dụng, không phải root.

# /etc/systemd/system/mywebapp.service
[Unit]
Description=My Web Application
After=network.target

[Service]
# ✅ Chạy service với user và group riêng
User=mywebapp
Group=mywebapp
WorkingDirectory=/srv/mywebapp
ExecStart=/usr/bin/python3 /srv/mywebapp/app.py
Restart=always

[Install]
WantedBy=multi-user.target

⚠️ Lưu ý: Bạn cần tạo user và group mywebapp trước khi khởi động service này:

sudo groupadd --system mywebapp
sudo useradd --system --no-create-home --shell /sbin/nologin -g mywebapp mywebapp
sudo mkdir -p /srv/mywebapp
sudo chown -R mywebapp:mywebapp /srv/mywebapp

2.2. Ngăn Chặn Leo Thang Đặc Quyền​

Ngăn chặn service tự động giành thêm đặc quyền.

# ...
[Service]
# ...
# ✅ Ngăn chặn service giành thêm đặc quyền
NoNewPrivileges=yes
# ...

2.3. Sử dụng DynamicUser (systemd 235+)​

Nếu ứng dụng không cần một user cố định hoặc bạn muốn tự động tạo và xóa user khi service khởi động/dừng, DynamicUser=yes là một lựa chọn tuyệt vời. systemd sẽ tự động tạo một user và group tạm thời cho service và xóa chúng khi service dừng.

# ...
[Service]
# ✅ Tự động tạo user/group tạm thời
DynamicUser=yes
# ...

💡 Mẹo: Khi sử dụng DynamicUser=yes, bạn không cần tạo user/group thủ công. systemd sẽ quản lý nó. Nếu service cần ghi vào một thư mục, hãy sử dụng RuntimeDirectory= hoặc StateDirectory= để systemd tạo và cấp quyền đúng cho user động.

Bước 3: Cô Lập Hệ Thống File và Network​

Hạn chế quyền truy cập của service vào hệ thống file và mạng.

3.1. Hạn Chế Truy Cập Hệ Thệng File​

Ngăn chặn service đọc/ghi vào các phần không cần thiết của hệ thống file.

# ...
[Service]
# ...
# ✅ Bảo vệ các thư mục hệ thống quan trọng khỏi việc ghi
ProtectSystem=full
# ✅ Bảo vệ thư mục Home của tất cả người dùng
ProtectHome=yes
# ✅ Cung cấp thư mục /tmp và /var/tmp riêng tư cho service
PrivateTmp=yes
# ✅ Cung cấp một /dev riêng tư cho service (chỉ các thiết bị cần thiết)
PrivateDevices=yes
# ✅ Cung cấp một danh sách người dùng riêng tư, ảo. Service chỉ thấy user của nó.
PrivateUsers=yes
# ✅ Hạn chế service chỉ có thể thấy các namespace PID của riêng nó
PrivateNetwork=yes # -> Sẽ được thảo luận kỹ hơn bên dưới
# ✅ Chỉ cho phép đọc vào các thư mục đã cho
ReadOnlyPaths=/usr/share/mywebapp:/etc/mywebapp
# ✅ Chỉ cho phép ghi vào các thư mục đã cho
ReadWritePaths=/var/log/mywebapp:/var/lib/mywebapp
# ✅ Tạo một thư mục riêng tư chỉ tồn tại khi service chạy
RuntimeDirectory=mywebapp
# ✅ Thiết lập Root Directory ảo (chroot)
# RootDirectory=/srv/mywebapp/chroot # Yêu cầu chuẩn bị chroot environment
# ...

⚠️ Cảnh báo: ProtectSystem=full sẽ biến /usr, /boot, /etc thành chỉ đọc. ProtectSystem=strict sẽ làm tương tự và cả /sys cũng thành chỉ đọc. Hãy cẩn thận khi sử dụng, đảm bảo service không cần ghi vào các vị trí này.

3.2. Hạn Chế Quyền Truy Cập Mạng​

Kiểm soát những gì service có thể làm trên mạng.

# ...
[Service]
# ...
# ✅ Cung cấp một network namespace riêng tư. Service chỉ có thể truy cập mạng qua các cấu hình được chỉ định.
PrivateNetwork=yes
# ✅ Hạn chế các họ địa chỉ IP mà service có thể sử dụng (ví dụ: AF_INET cho IPv4, AF_INET6 cho IPv6)
RestrictAddressFamilies=AF_INET AF_INET6
# ✅ Chỉ cho phép kết nối đến các địa chỉ IP cụ thể
IPAddressAllow=192.168.1.0/24 10.0.0.1
# ✅ Chặn kết nối đến các địa chỉ IP cụ thể
IPAddressDeny=192.168.2.0/24
# ✅ Hạn chế các cổng mà service có thể lắng nghe
# BindsTo= # Không phải là hạn chế trực tiếp, nhưng đảm bảo service chỉ lắng nghe trên giao diện cụ thể
# ...

💡 Mẹo: Nếu bạn sử dụng PrivateNetwork=yes, bạn cần cấu hình rõ ràng cách service truy cập mạng (ví dụ: thông qua một cổng được chuyển tiếp hoặc bằng cách không sử dụng PrivateNetwork và thay vào đó sử dụng IPAddressAllow/IPAddressDeny). PrivateNetwork=yes cung cấp sự cô lập mạnh mẽ nhất.

Bước 4: Hạn Chế Khả Năng Kernel và Lời Gọi Hệ Thống (System Calls)​

Giới hạn các khả năng cấp kernel (capabilities) và các lời gọi hệ thống (system calls) mà service có thể thực hiện.

4.1. Giới Hạn Kernel Capabilities​

CapabilityBoundingSet định nghĩa tập hợp các khả năng tối đa mà một tiến trình có thể có.

# ...
[Service]
# ...
# ✅ Giới hạn các khả năng kernel mà service có thể sử dụng
# Loại bỏ tất cả các khả năng và chỉ thêm những cái cần thiết.
# Ví dụ: CAP_NET_BIND_SERVICE để lắng nghe trên cổng < 1024
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
# Nếu muốn xóa tất cả và không thêm gì:
# CapabilityBoundingSet=
# ...

4.2. Lọc Lời Gọi Hệ Thống​

SystemCallFilter cho phép bạn chỉ định danh sách các lời gọi hệ thống mà service được phép thực hiện.

# ...
[Service]
# ...
# ✅ Chỉ cho phép các lời gọi hệ thống cơ bản cần thiết cho một web server đơn giản
SystemCallFilter=@system-service @network-client @basic-io
# Hoặc tự định nghĩa danh sách:
# SystemCallFilter=read write open close stat fstat lseek mmap mprotect munmap exit_group
# Thêm một số lời gọi hệ thống cụ thể cần thiết.
# SystemCallFilter=~@cpu-emulation @obsolete @debug @privileged @resources @module @mount @raw-io @swap
# ...

⚠️ Cảnh báo: Việc lọc lời gọi hệ thống có thể rất phức tạp và dễ làm hỏng service nếu không cẩn thận. Luôn kiểm tra kỹ lưỡng. SystemCallFilter= có thể được kết hợp với các nhóm đã định nghĩa sẵn của systemd (ví dụ: @basic-io, @network-client, @system-service). ~ phủ định một nhóm.

Bước 5: Tải Lại systemd và Kiểm Tra Service​

Sau khi chỉnh sửa unit file, bạn cần tải lại cấu hình systemd và khởi động/khởi động lại service.

# Tải lại cấu hình systemd
sudo systemctl daemon-reload

# Khởi động service
sudo systemctl start mywebapp.service

# Kiểm tra trạng thái service
sudo systemctl status mywebapp.service

# Xem nhật ký của service
journalctl -xeu mywebapp.service

✅ Khi service khởi động thành công, bạn sẽ thấy trạng thái "active (running)".

Troubleshooting​

  • Service không khởi động:

    • Nguyên nhân: Cấu hình sai trong unit file, thiếu quyền, lỗi ứng dụng.
    • Cách xử l:
      • Kiểm tra kỹ cú pháp trong unit file.
      • Sử dụng journalctl -xeu mywebapp.service để xem nhật ký lỗi chi tiết. Các lỗi liên quan đến bảo mật (ví dụ: Permission denied, Operation not permitted) thường xuất hiện ở đây.
      • Tạm thời gỡ bỏ từng directive bảo mật một để xác định directive nào gây lỗi.
      • Đảm bảo user/group được chỉ định trong User= và Group= tồn tại và có quyền truy cập vào các file/thư mục cần thiết.

  • Service không thể ghi vào file/thư mục:

    • Nguyên nhân: ProtectSystem=, ProtectHome=, ReadOnlyPaths= hoặc các quyền thư mục không đúng.
    • Cách xử lý:
      • Kiểm tra ReadWritePaths= đã được cấu hình đúng chưa.
      • Đảm bảo service có quyền ghi vào RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory= nếu sử dụng chúng.
      • Kiểm tra quyền hạn của user/group của service trên các thư mục đó.

  • Service không thể kết nối mạng:

    • Nguyên nhân: PrivateNetwork=yes, RestrictAddressFamilies=, IPAddressAllow= hoặc IPAddressDeny= quá hạn chế.
    • Cách xử lý:
      • Nếu PrivateNetwork=yes, hãy đảm bảo service không yêu cầu kết nối mạng bên ngoài nếu không được cấu hình rõ ràng.
      • Kiểm tra lại các quy tắc IPAddressAllow= và IPAddressDeny=.

  • Service gặp lỗi lạ hoặc crash:

    • Nguyên nhân: SystemCallFilter= hoặc CapabilityBoundingSet= quá hạn chế, ngăn chặn service thực hiện các thao tác cần thiết ở cấp kernel.
    • Cách xử lý:
      • Đây là phần khó nhất để debug. Bắt đầu với một bộ lọc SystemCallFilter= ít hạn chế hơn hoặc loại bỏ nó hoàn toàn để xem service có chạy không.
      • Dần dần thêm các lời gọi hệ thống hoặc khả năng kernel vào cho đến khi service hoạt động ổn định.

Kết Luận​

Bảo mật các systemd service là một phần không thể thiếu trong việc bảo vệ hệ thống Linux của bạn. Bằng cách áp dụng các nguyên tắc đặc quyền tối thiểu và cô lập tài nguyên thông qua các directive của systemd, bạn có thể giảm đáng kể bề mặt tấn công và hạn chế thiệt hại nếu một service bị xâm nhập.

Best practices:

  1. Luôn bắt đầu từ ít hạn chế nhất: Khi triển khai một service mới, hãy bắt đầu với cóu hình bảo mật tối thiểu và dần dần thêm các hạn chế từng bước một, kiểm tra kỹ lưỡng sau mỗi thay đổi.
  2. Kiểm tra kỹ lưỡng: Sau mỗi thay đổi cấu hình bảo mật, hãy kiểm tra toàn bộ chức năng của service để đảm bảo không có gì bị gián đoạn.
  3. Sử dụng user và group chuyên dụng: Không bao giờ chạy service với quyền root trừ khi thực sự không còn lựa chọn nào khác.
  4. Cô lập file system: Hạn chế quyền truy cập file của service chỉ vào những đường dẫn cần thiết.
  5. Hạn chế mạng: Kiểm soát chặt chẽ các kết nối mạng mà service có thể thực hiện.
  6. Giám sát nhật ký: Thường xuyên kiểm tra nhật ký của service bằng journalctl để phát hiện sớm các vấn đề bảo mật hoặc lỗi cấu hình.
  7. Cập nhật systemd: Đảm bảo hệ thống của bạn luôn được cập nhật phiên bản systemd mới nhất để tận dụng các tính năng bảo mật và sửa lỗi mới.

Việc đầu tư thời gian để cấu hình bảo mật đúng cách cho các service systemd sẽ mang lại lợi ích lớn trong việc duy trì một hệ thống Linux an toàn và ổn định.

Xem thêm: