Local-In Policy — kiểm soát traffic đến chính FortiGate

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

Sau đợt audit bảo mật, khách hàng yêu cầu anh Nam giới hạn nghiêm ngặt: chỉ cho phép đúng dải IP 172.16.200.0/24 (mạng quản trị nội bộ) được SSH và HTTPS vào FortiGate, chặn hoàn toàn các nguồn khác — kể cả từ trong LAN.

Anh Nam nghĩ ngay tới Firewall Policy quen thuộc, định tạo một Policy deny cho traffic tới IP của chính FortiGate. Nhưng chị Lan chỉnh lại: "Firewall Policy thông thường chỉ kiểm soát traffic đi xuyên qua FortiGate tới đích khác — traffic đến chính FortiGate (như SSH/HTTPS quản trị) lại thuộc phạm vi khác, gọi là Local-In traffic, phải dùng Local-In Policy để kiểm soát."

Anh Nam thử tạo luôn một Local-In Policy deny-all để chắc ăn, nhưng chị Lan ngăn lại kịp thời: "Cẩn thận — làm vậy có thể tự khóa luôn quyền truy cập quản trị của chính mình đấy."

Bài này giải thích khái niệm Local-In Policy — công cụ kiểm soát traffic đến thẳng chính FortiGate, khác biệt với Firewall Policy thông thường, và những cạm bẫy cần tránh khi cấu hình.

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

2.1 Local-In Policy khác Firewall Policy ở điểm nào

Trong khi Firewall Policy (Forward Policy) kiểm soát traffic đi xuyên qua FortiGate từ một interface tới interface khác (ví dụ LAN ra Internet), Local-In Policy kiểm soát traffic có đích đến là chính FortiGate — như các kết nối quản trị (SSH, HTTPS, ping) hoặc dịch vụ khác chạy trực tiếp trên thiết bị (VPN endpoint...).

Đây chính là khái niệm anh Nam nhầm lẫn ở đầu bài — dù cả hai đều gọi chung là "Policy", chúng kiểm soát hai loại traffic hoàn toàn khác nhau về đích đến.

2.2 So sánh với Trusted Hosts đã học ở bài Admin Management

Ở bài Quản lý Admin, chúng ta đã học Trusted Hosts — cũng giới hạn nguồn được truy cập quản trị, nhưng gắn theo từng tài khoản admin cụ thể. Local-In Policy hoạt động ở tầng cao hơn, độc lập với tài khoản — áp dụng cho toàn bộ interface, kiểm soát trước cả khi FortiGate xét tới việc xác thực tài khoản nào.

2.3 Cấu hình Local-In Policy cơ bản

config firewall address
    edit "Mang-quan-tri"
        set subnet 172.16.200.0 255.255.255.0
    next
end

config firewall local-in-policy
    edit 1
        set intf "port1"
        set srcaddr "Mang-quan-tri"
        set dstaddr "all"
        set action accept
        set service "SSH" "HTTPS"
        set schedule "always"
    next
    edit 2
        set intf "port1"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "SSH" "HTTPS"
        set schedule "always"
    next
end

Đúng theo nhu cầu ở đầu bài — Policy ID 1 cho phép dải 172.16.200.0/24 SSH/HTTPS vào port1, Policy ID 2 chặn toàn bộ nguồn khác cho cùng dịch vụ đó.

⚠️ Lưu ý quan trọng: Không giống Firewall Policy (Forward) có sẵn Implicit Deny ẩn ở cuối, Local-In Policy theo mặc định không có Implicit Deny riêng cho từng interface — nếu muốn chặn hẳn toàn bộ nguồn khác ngoài dải cho phép, phải tự tạo tường minh một Policy deny-all đặt ở cuối danh sách (như Policy ID 2 trong ví dụ trên), tương tự cách viết deny any any thủ công.

2.4 Cạm bẫy nguy hiểm — tự khóa quyền quản trị của chính mình

Đây chính là điều chị Lan cảnh báo anh Nam ở đầu bài. FortiOS có hai nhóm Local-In ẩn tự động sinh ra dựa trên cấu hình truy cập quản trị hiện có: Admin-In và Implicit-In. Nếu thêm một Local-In Policy dạng deny-all mà không đặt đúng thứ tự (đặt trước các Policy allow tường minh), traffic quản trị hợp lệ cũng có thể bị chặn theo, kể cả khi bạn không cố ý nhắm tới nó.

Cần lưu ý: sơ đồ trên chỉ mô tả đúng luồng của traffic quản trị (đích đến là chính FortiGate) — Local-In Policy khôngphải là bước bắt buộc mà mọi loại traffic đều phải đi qua. Traffic forward thông thường (LAN ra Internet, giữa các VLAN...) có đích đến là nơi khác, không chạm tới Local-In Policy — nó chỉ được xét bởi Firewall Policy như đã học trước đó, hoàn toàn độc lập với luồng Local-In. Nếu traffic quản trị (SSH/HTTPS tới chính FortiGate) bị Local-In Policy chặn (Deny), gói tin bị hủy ngay lập tức — không bao giờ tới được bước xác thực tài khoản phía sau — đồng nghĩa admin bị khóa hoàn toàn khỏi giao diện quản trị, dù trước đó chưa từng có vấn đề gì với tài khoản hay Trusted Hosts.

⚠️ Lưu ý cực kỳ quan trọng: Trước khi thêm bất kỳ Local-In Policy deny-all nào, luôn đảm bảo đã có Policy allow tường minh cho chính dải IP quản trị bạn đang dùng, đặt ở vị trí trước Policy deny đó. Nên test trên một phiên kết nối song song (ví dụ giữ nguyên một cửa sổ console đang đăng nhập) trước khi áp dụng thay đổi diện rộng, để có đường lùi nếu cấu hình sai gây mất kết nối quản trị.

2.5 Ứng dụng khác của Local-In Policy — không chỉ riêng SSH/HTTPS

Ngoài quản trị, Local-In Policy còn kiểm soát được các dịch vụ khác chạy trực tiếp trên FortiGate — ví dụ giới hạn nguồn được kết nối VPN, hoặc chặn traffic có TTL bất thường (dấu hiệu tấn công) chỉ nhắm riêng vào chính thiết bị mà không ảnh hưởng traffic forward xuyên qua.

Một ví dụ khác — dùng Address Object loại Geography để chỉ cho phép quản trị từ đúng quốc gia công ty đặt trụ sở:

config firewall address
    edit "Chi-Viet-Nam"
        set type geography
        set country "VN"
    next
end

config firewall local-in-policy
    edit 5
        set intf "wan1"
        set srcaddr "Chi-Viet-Nam"
        set dstaddr "all"
        set action accept
        set service "HTTPS"
        set schedule "always"
    next
end

3. Hỏi & Đáp

Nếu FortiGate chưa từng có Local-In Policy nào, traffic quản trị có bị chặn không?

Không — mặc định không có Local-In Policy nào được định nghĩa sẵn, nên không có giới hạn bổ sung nào từ tầng này. Việc kiểm soát truy cập quản trị lúc đó hoàn toàn phụ thuộc vào cấu hình allowaccess trên interface và Trusted Hosts theo từng tài khoản, như đã học ở các bài trước.

Local-In Policy có áp dụng được cho traffic IPv6 không?

Có — tồn tại phiên bản riêng config firewall local-in-policy6 dành cho IPv6, cấu trúc tham số tương tự phiên bản IPv4 nhưng là một khối cấu hình độc lập.

Muốn tạm thời tắt một Local-In Policy để debug mà không xóa hẳn, làm thế nào?

Dùng tham số set status disable trên chính Policy ID đó thay vì xóa — giữ nguyên cấu hình để bật lại sau khi debug xong, tránh phải gõ lại từ đầu.

Có nên đặt Local-In Policy deny-all cho tất cả interface, kể cả cổng LAN nội bộ không?

Cần cân nhắc kỹ theo yêu cầu thực tế — nếu chỉ cần giới hạn quản trị từ WAN (Internet), không nhất thiết phải áp deny-all lên cả cổng LAN nội bộ, trừ khi có yêu cầu bảo mật nghiêm ngặt như tình huống mở đầu bài. Áp deny-all tràn lan lên mọi interface mà không tính toán kỹ dễ dẫn tới tình huống tự khóa quyền truy cập ngoài ý muốn.

4. Quiz

Câu 1: Local-In Policy khác Firewall Policy (Forward) ở điểm cốt lõi nào?

• A. Local-In Policy chỉ áp dụng cho IPv6
• B. Local-In Policy kiểm soát traffic có đích đến là chính FortiGate, còn Firewall Policy kiểm soát traffic đi xuyên qua tới đích khác
• C. Không có sự khác biệt nào, hai tên gọi cho cùng một tính năng
• D. Local-In Policy chỉ dùng được trên GUI, không dùng được CLI

Câu 2: Khác với Firewall Policy có sẵn Implicit Deny, Local-In Policy có đặc điểm gì?

• A. Cũng có Implicit Deny tự động y hệt Firewall Policy
• B. Theo mặc định không có Implicit Deny riêng — muốn chặn hẳn nguồn khác phải tự tạo Policy deny-all tường minh
• C. Luôn chặn toàn bộ traffic nếu chưa cấu hình gì
• D. Không thể tạo Policy deny trên Local-In Policy

Câu 3: Rủi ro lớn nhất khi thêm một Local-In Policy deny-all mà không đặt đúng thứ tự là gì?

• A. Không có rủi ro gì đáng kể
• B. Có thể vô tình chặn luôn traffic quản trị hợp lệ, gây mất kết nối quản trị tới chính FortiGate
• C. Chỉ ảnh hưởng tới hiệu năng, không ảnh hưởng bảo mật
• D. Tự động được FortiGate ngăn chặn, không thể xảy ra

Câu 4: Traffic nào sẽ được xét qua Local-In Policy?

• A. Mọi traffic đi qua FortiGate, kể cả traffic forward LAN ra Internet
• B. Chỉ traffic có đích đến là chính FortiGate (traffic quản trị)
• C. Chỉ traffic UDP
• D. Local-In Policy không bao giờ được xét tới trong thực tế

Câu 5: Trusted Hosts và Local-In Policy khác nhau chủ yếu ở điểm nào?

• A. Không có sự khác biệt, hai tên gọi của cùng một cơ chế
• B. Trusted Hosts gắn theo từng tài khoản admin cụ thể, Local-In Policy áp dụng theo interface và xử lý ở tầng traffic sớm hơn
• C. Local-In Policy chỉ dùng được cho VPN, không dùng được cho SSH/HTTPS
• D. Trusted Hosts chỉ hỗ trợ IPv6

👉 Đáp án

Câu 1: B Local-In Policy kiểm soát traffic có đích đến là chính FortiGate (như SSH/HTTPS quản trị), trong khi Firewall Policy (Forward) kiểm soát traffic đi xuyên qua FortiGate tới một đích khác.

Câu 2: B Local-In Policy theo mặc định không có Implicit Deny riêng cho từng interface — muốn chặn hẳn các nguồn khác ngoài dải cho phép, người quản trị phải tự tạo tường minh một Policy deny-all đặt ở cuối danh sách.

Câu 3: B Nếu Policy deny-all đặt sai thứ tự (không có allow rule tường minh đặt trước cho đúng dải quản trị), traffic quản trị hợp lệ có thể bị chặn theo, khiến admin mất quyền truy cập vào chính FortiGate.

Câu 4: B Local-In Policy chỉ được xét cho traffic có đích đến là chính FortiGate (như SSH/HTTPS quản trị) — traffic forward thông thường (đi xuyên qua tới đích khác) không chạm tới Local-In Policy, mà chỉ chịu sự kiểm soát của Firewall Policy.

Câu 5: B Trusted Hosts gắn theo từng tài khoản admin cụ thể và được xét sau khi đã xác định traffic hợp lệ tới dịch vụ quản trị, còn Local-In Policy áp dụng chung theo interface và xử lý ở tầng traffic sớm hơn, trước cả bước xác thực tài khoản.

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

🧭 Điều hướng