Thiết kế firewall default deny cho web server mà không phá DNS

Linux Security Serial · S06E20

Chúng ta chuyển từ identity sang đường đi của packet. Firewall tốt không phải là ruleset dài; đó là policy có thứ tự, default rõ ràng và không làm mất đường quản trị.

Ở tập trước, chúng ta đã chốt nftables cho người đã quen UFW: mô hình rule, chain và stateful filtering và lưu artefact kế thừa. Tập này dùng chính dữ liệu đó, không xóa trạng thái cũ để sửa theo cảm tính.

Trả lời ngắn: default deny firewall Linux

Thiết kế firewall default deny cho web server mà không phá DNS và cập nhật không phải là một thao tác bật/tắt đơn lẻ. Trong tập này, ta giới hạn phạm vi ở default deny firewall Linux, giữ nguyên các lớp khác để có thể xác định nguyên nhân và rollback.

Phạm vi và giả định

Case study dùng một VPS Ubuntu có quyền console hoặc recovery, một dịch vụ web đang chạy và lịch thay đổi có thể ghi lại. Hãy thay placeholder bằng dữ liệu của bạn, đọc output trước khi áp dụng, và không đóng phiên quản trị cuối cùng khi chưa có đường quay lui.

Trạng thái cần chốt: planned. Nếu môi trường thực tế khác giả định, dừng ở bước inventory và ghi ngoại lệ thay vì áp dụng nguyên xi.

Quy trình thực hiện

Lập bảng port, source, destination, protocol và owner.
Test từ localhost, private network và Internet để phân biệt bind address với firewall.
Áp dụng default-deny từng lớp, giữ recovery rule và ghi ruleset trước/sau.
Kiểm tra IPv4, IPv6, Docker bridge và các rule do service tự tạo.

Khung lệnh kiểm tra

ip -br addr
ip route
ss -lntup
sudo ufw status verbose
sudo nft list ruleset
sudo iptables-save 2>/dev/null | head -80

Khối lệnh trên ưu tiên quan sát. Lệnh có thể thay đổi cấu hình phải được tách ra, kiểm tra syntax/dry-run và thực hiện trong cửa sổ thay đổi. Với SSH, firewall hoặc PAM, luôn giữ console/recovery session.

Đọc kết quả và bằng chứng đạt

Dùng nc/curl từ đúng vị trí kiểm thử, đọc counter/log của rule và xác nhận service không cần public đã bind loopback hoặc private address.

Artefact bắt buộc của tập này là firewall-ruleset.txt. Ghi timestamp, hostname, phiên bản công cụ, người thực hiện và phần output đã che secret. Artefact phải nằm ngoài máy chủ đang hardening hoặc được backup độc lập.

Lỗi dễ gặp và cách xử lý

Chỉ kiểm tra IPv4, quên IPv6, chặn nhầm console hoặc để Docker mở port ngoài policy là những lỗi khiến firewall “xanh” nhưng hệ thống vẫn lộ.

Nếu kết quả sai, không sửa nhiều lớp cùng lúc. Giữ output trước thay đổi, quay về cấu hình gần nhất đã biết là tốt, rồi kiểm tra từng lớp từ identity, process, socket, filesystem đến log. Một control chỉ được gọi là thành công khi chức năng cần bảo vệ vẫn hoạt động.

Trade-off cần chấp nhận

Hardening luôn đổi lấy một phần tiện lợi, hiệu năng hoặc khả năng debug. Mức bảo vệ hợp lý phụ thuộc dữ liệu, exposure, năng lực on-call, RPO/RTO và yêu cầu compliance; không có checklist chung thay thế cho quyết định có lý do.

Checklist trước khi đóng tập

Đã lưu baseline trước và sau thay đổi.
Đã kiểm tra cả happy path và failure path.
Đã xác nhận quyền truy cập, log và dịch vụ vẫn đúng mục tiêu.
Đã ghi rollback, ngưỡng dừng và owner.
Đã cập nhật artefact để tập sau có dữ liệu kế thừa.

Vấn đề còn mở cho tập sau

Nếu kiểm tra đạt, tập sau sẽ tiếp tục với Egress filtering: vì sao server bị xâm nhập vẫn cần bị chặn đường gọi ra ngoài; nếu chưa đạt, artefact của tập này là điểm dừng để sửa trước khi đi tiếp.