Loading...

Firewall Policy FortiGate: cấu trúc, thứ tự xử lý, Implicit Deny, Policy Lookup

1. Liên hệ thực tế

Sang nhóm bài mới — Security Policy & Inspection — anh Nam được giao viết lại toàn bộ Firewall Policy cho một chi nhánh đang tái cấu trúc mạng. Anh viết một Policy tổng "Allow All LAN to WAN" đặt lên đầu danh sách cho nhanh, định bụng sau đó thêm các Policy chặn cụ thể (như chặn SSH ra ngoài) phía dưới.

Chị Lan xem qua, lắc đầu: "Anh đặt sai thứ tự rồi. FortiGate xét Policy từ trên xuống, dừng lại ngay khi gặp Policy đầu tiên khớp điều kiện — Policy chặn SSH của anh đặt phía dưới sẽ không bao giờ được xét tới, vì Policy Allow All phía trên đã khớp và xử lý xong traffic đó trước rồi."

Anh Nam giật mình: "Vậy nghĩa là thứ tự Policy quan trọng ngang với nội dung Policy?"

Chị Lan: "Đúng vậy — đây là nguyên tắc nền tảng nhất của Firewall Policy trên FortiGate mà ai cũng phải nắm trước khi viết bất kỳ policy nào."

Bài này giải thích cấu trúc cơ bản của Firewall Policy, thứ tự xử lý (Policy Lookup), khái niệm Implicit Deny, và cách quan hệ với Intrazone đã học ở bài Zone.


2. Kiến thức cốt lõi

2.1 Firewall Policy là gì

Mọi traffic đi qua FortiGate đều phải khớp với một Firewall Policy mới được xử lý tiếp — Policy là tập hợp điều kiện (nguồn, đích, dịch vụ, thời gian...) đi kèm hành động (cho phép, từ chối, áp UTM profile...). Nếu traffic không khớp bất kỳ Policy tường minh nào, nó sẽ bị chặn bởi cơ chế mặc định gọi là Implicit Deny.

config firewall policy
    edit 10
        set name "lan-to-wan-web"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "HTTP" "HTTPS"
        set nat enable
    next
end

2.2 Policy Lookup — thứ tự xét từ trên xuống

Policy Lookup là quá trình FortiGate duyệt qua danh sách Policy để tìm điều kiện khớp với traffic đang đến — quá trình này diễn ra tuần tự từ trên xuống dưới, và dừng lại ngay khi gặp Policy đầu tiên khớp, dù phía dưới có thể còn Policy khác cũng khớp điều kiện.

Policy Lookup: xét từ trên xuống, dừng ở match đầu tiên Thứ tự kiểm tra (từ trên xuống) Policy ID 10 (cụ thể nhất) Policy ID 20 Policy ID 30 (chung nhất) Implicit Deny (Policy 0) Match đầu tiên thắng — Policy càng cụ thể nên đặt càng gần đầu danh sách Không có match nào → rơi vào Implicit Deny, traffic bị chặn hoàn toàn

Đây chính là nguyên tắc bị vi phạm trong tình huống mở đầu bài — Policy chung ("Allow All") đặt trước Policy cụ thể ("Deny SSH") khiến Policy cụ thể không bao giờ có cơ hội được xét tới. Nguyên tắc thiết kế đúng: Policy càng cụ thể/đặc thù, càng nên đặt gần đầu danh sách; Policy càng tổng quát, càng nên đặt gần cuối.

⚠️ Lưu ý: Số ID của Policy (Policy ID) không quyết định thứ tự xử lý — thứ tự thực tế là thứ tự hiển thị trong danh sách (sequence), có thể sắp xếp lại bằng cách kéo-thả trên GUI hoặc dùng tham số before/afterkhi thao tác qua API/CLI. Một Policy ID nhỏ hơn không đồng nghĩa với việc nó được xét trước.

2.3 Implicit Deny — Policy 0 ẩn ở cuối danh sách

Implicit Deny là một Policy ẩn, luôn tồn tại ở cuối cùng của danh sách, với điều kiện match tất cả (nguồn/đích/dịch vụ đều là "any") và hành động mặc định là deny. Đây chính là Policy 0 mà log traffic thường ghi nhận khi một kết nối bị chặn mà không khớp Policy tường minh nào.

⚠️ Lưu ý: Tham số duy nhất có thể chỉnh trên Implicit Deny là bật/tắt logging cho traffic bị chặn bởi nó — không thể sửa điều kiện hay hành động của Policy này. Muốn ghi log traffic vi phạm, cần bật logging cho Implicit Deny — mặc định tùy chọn này có thể đang tắt tùy phiên bản/model, nên kiểm tra lại nếu cần audit đầy đủ traffic bị chặn.

2.4 Quan hệ giữa Forward Policy, Intrazone, và Implicit Deny

Với các Zone đã cấu hình intrazone (học ở bài Zone), thứ tự xử lý đầy đủ khi FortiGate xét một gói tin là:

Thứ tự đầy đủ khi FortiGate xét traffic qua Firewall 1. Forward Policy Toàn bộ policy tường minh 2. Intrazone Chỉ xét nếu cùng Zone 3. Implicit Deny Chặn mặc định (Policy 0) Một Policy DENY tường minh vẫn được xét ở bước 1 — trước cả intrazone

Điểm dễ nhầm: một Policy DENY tường minh do người quản trị tạo (ví dụ để chặn cụ thể traffic giữa 2 interface trong cùng Zone) vẫn thuộc nhóm Forward Policy ở bước 1 — được xét trước khi FortiGate kiểm tra tới quy tắc intrazone. Nghĩa là nếu đã có Policy DENY tường minh khớp traffic đó, cấu hình intrazone allow phía sau sẽ không có cơ hội can thiệp — traffic đã bị chặn từ bước 1 rồi.

2.5 Policy views trên GUI — hai cách hiển thị danh sách

Để dễ quản lý danh sách Policy dài, GUI của FortiGate cung cấp hai kiểu xem:

  • Interface Pair View (mặc định) — nhóm các Policy theo từng cặp interface nguồn/đích (ví dụ tất cả Policy từ wan1sang internal gom vào một nhóm), giúp dễ tìm theo luồng traffic cụ thể.
  • By Sequence — hiển thị toàn bộ Policy theo đúng thứ tự xử lý thực tế, không phân nhóm. GUI tự động chuyển sang view này khi có Policy dùng any hoặc nhiều interface cùng lúc trong nguồn/đích, vì trường hợp đó không thể phân nhóm theo cặp interface cố định được nữa.

⚠️ Lưu ý: Khi debug lỗi liên quan tới thứ tự Policy, luôn chuyển sang By Sequence để nhìn đúng thứ tự xử lý thật — Interface Pair View dù tiện tra cứu nhưng có thể khiến người xem hiểu lầm về thứ tự ưu tiên giữa các nhóm khác cặp interface.

2.6 Nguyên tắc thiết kế Policy — tổng hợp

Nguyên tắcLý do
Policy cụ thể đặt trên, Policy chung đặt dưới Tránh Policy chung "nuốt" mất traffic trước khi tới Policy cụ thể
Deny rules đặt trước Allow rules liên quan Đảm bảo traffic bị cấm được chặn trước khi Policy Allow rộng hơn xử lý
Luôn đặt tên (name) rõ ràng cho từng Policy Dễ tra cứu log, dễ bảo trì khi danh sách dài
Bật logging cho Implicit Deny Có dữ liệu audit traffic bị chặn ngoài ý muốn
Rà soát lại thứ tự sau mỗi lần thêm Policy mới Tránh vô tình đặt Policy mới ở vị trí làm "che" Policy cũ

3. Hỏi & Đáp

Nếu hai Policy có điều kiện giống hệt nhau nhưng hành động khác nhau (một Allow, một Deny), FortiGate sẽ theo Policy nào?

FortiGate luôn áp dụng theo Policy nào xuất hiện trước trong thứ tự xử lý (theo sequence, không phải theo ID). Nếu Policy Allow đặt trước Policy Deny cùng điều kiện, traffic sẽ được phép đi qua và Policy Deny phía sau vĩnh viễn không có cơ hội được xét.

Có cách nào tự động sắp xếp lại Policy theo mức độ cụ thể không?

Không có tính năng tự động sắp xếp theo mức độ cụ thể — việc này hoàn toàn phụ thuộc vào người quản trị tự thiết kế và sắp xếp thủ công (kéo-thả trên GUI hoặc dùng before/after qua CLI/API). Đây là lý do cần rà soát định kỳ khi danh sách Policy phát triển theo thời gian.

Traffic bị Implicit Deny chặn có được NAT không?

Không — Implicit Deny chặn hoàn toàn traffic trước khi có bất kỳ xử lý nào khác (NAT, UTM profile...) được áp dụng. Traffic bị Implicit Deny chặn coi như chưa từng được phép đi tiếp trong luồng xử lý của FortiGate.

Vì sao Policy DENY tường minh lại được xét trước cả Intrazone, dù cả hai đều là cơ chế "chặn"?

Vì bản chất kỹ thuật khác nhau — Policy DENY tường minh là một entry cụ thể trong danh sách Forward Policy do người quản trị tạo ra, còn intrazone là một thuộc tính mặc định gắn với chính Zone, chỉ được kiểm tra sau khi đã duyệt hết toàn bộ Forward Policy mà không tìm được match nào. Forward Policy luôn có độ ưu tiên cao hơn các cơ chế mặc định như intrazone hay Implicit Deny.


4. Quiz

Câu 1: FortiGate xử lý Firewall Policy theo thứ tự nào?

  • A. Theo Policy ID từ nhỏ đến lớn
  • B. Theo thứ tự hiển thị trong danh sách (sequence), từ trên xuống dưới
  • C. Ngẫu nhiên mỗi lần có traffic mới
  • D. Theo bảng chữ cái tên Policy

Câu 2: Implicit Deny có đặc điểm gì?

  • A. Có thể chỉnh sửa điều kiện match tùy ý
  • B. Luôn nằm ở cuối danh sách, match tất cả, hành động mặc định là deny, chỉ chỉnh được logging
  • C. Chỉ áp dụng cho traffic IPv6
  • D. Có thể xóa hoàn toàn khỏi cấu hình

Câu 3: Nếu đặt Policy "Allow All" ở đầu danh sách và Policy "Deny SSH" cụ thể hơn ở phía dưới, điều gì sẽ xảy ra?

  • A. FortiGate tự động ưu tiên Policy cụ thể hơn
  • B. Policy "Deny SSH" sẽ không bao giờ được xét tới vì traffic đã khớp Policy "Allow All" trước
  • C. Cả hai Policy đều được áp dụng đồng thời
  • D. FortiGate báo lỗi cấu hình xung đột

Câu 4: Một Policy DENY tường minh do người quản trị tạo cho traffic giữa 2 interface cùng Zone được xét ở bước nào trong thứ tự xử lý?

  • A. Sau khi đã kiểm tra intrazone
  • B. Cùng lúc với Implicit Deny
  • C. Ở bước Forward Policy, trước cả khi kiểm tra intrazone
  • D. Không bao giờ được xét vì cùng Zone

Câu 5: View nào trên GUI hiển thị đúng thứ tự xử lý thực tế của toàn bộ Policy, không phân nhóm theo cặp interface?

  • A. Interface Pair View
  • B. By Sequence
  • C. Category View
  • D. Grouped View

👉 Đáp án

Câu 1: B FortiGate xử lý Policy theo thứ tự hiển thị trong danh sách (sequence) từ trên xuống dưới, dừng lại ở Policy đầu tiên khớp điều kiện — không liên quan tới giá trị Policy ID.

Câu 2: B Implicit Deny luôn nằm ở cuối danh sách, match mọi điều kiện (any/any), hành động mặc định là deny, và tham số duy nhất chỉnh được là bật/tắt logging.

Câu 3: B Vì Policy Lookup dừng lại ở match đầu tiên, Policy "Allow All" đặt trước sẽ xử lý xong traffic trước khi FortiGate kịp xét tới Policy "Deny SSH" cụ thể hơn ở phía dưới.

Câu 4: C Policy DENY tường minh vẫn thuộc nhóm Forward Policy, được xét ở bước đầu tiên — trước khi FortiGate kiểm tra tới quy tắc intrazone của Zone.

Câu 5: B By Sequence hiển thị toàn bộ Policy theo đúng thứ tự xử lý thực tế mà không phân nhóm, phù hợp khi cần debug chính xác thứ tự ưu tiên giữa các Policy.


📚 Bài viết thuộc khóa học FortiGate của VNExperts

🧭 Điều hướng

⬅️ Bài trước🏠 Mục lục khóa họcBài kế tiếp ➡️
Routing động cơ bản: OSPF trên FortiGate Mục lục khóa học FortiGate Address Object, Address Group, Internet Service Database (ISDB)