Best practice hardening FortiGate — Bảo vệ chính thiết bị firewall khỏi tấn công

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

Sau khi hoàn tất triển khai cho một khách hàng, anh Nam nhận được yêu cầu bổ sung: đội bảo mật nội bộ của khách hàng sẽ chạy một đợt security audit lên toàn bộ thiết bị mạng, bao gồm FortiGate. Anh Nam hơi lo — thiết bị đang chạy ổn định, chức năng đầy đủ, nhưng anh chưa từng nghĩ tới việc tự thiết bị firewall cũng có thể là mục tiêu bị tấn công.

"Một firewall cấu hình đúng chức năng nghiệp vụ không có nghĩa là nó đã được 'harden'," chị Lan giải thích. "Hardening là thu hẹp bề mặt tấn công (attack surface) của chính thiết bị — không chỉ traffic đi qua, mà cả việc ai có thể đăng nhập vào quản trị nó, từ đâu, và bằng cách nào."

Bài này tổng hợp các nguyên tắc hardening FortiGate theo khuyến nghị chính thức của Fortinet, áp dụng được cho mọi quy mô từ SMB đến Enterprise.

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

2.1 Không cho phép truy cập quản trị từ WAN

Nguyên tắc quan trọng nhất: không nên mở HTTPS/SSH quản trị trên interface WAN hướng ra internet. Fortinet khuyến nghị quản trị nên thực hiện qua interface tin cậy (trusted management interface) — nơi máy quản trị phải ở cùng vị trí vật lý, hoặc truy cập qua kết nối tin cậy như VPN, lý tưởng nhất là kết nối out-of-band (không đi qua chính FortiGate đang quản lý).

config system interface
    edit "wan1"
        unset allowaccess
        set allowaccess ping
    next
end

Ở ví dụ trên, interface wan1 chỉ cho phép ping (phục vụ health-check từ bên ngoài nếu cần), toàn bộ https, ssh, http quản trị bị gỡ bỏ khỏi WAN.

2.2 Nếu bắt buộc phải mở quản trị trên interface public — dùng Local-in Policy

Có tình huống không tránh khỏi việc cần truy cập quản trị từ ngoài (ví dụ chi nhánh nhỏ không có VPN). Khi đó, local-in policy là công cụ kiểm soát chi tiết nhất — kiểm soát traffic đến/đi từ chính FortiGate (khác với firewall policy thông thường chỉ kiểm soát traffic đi qua), khái niệm đã giới thiệu ở Local-In Policy — kiểm soát traffic đến chính FortiGate.

config firewall local-in-policy
    edit 1
        set intf "wan1"
        set srcaddr "Trusted-Admin-IPs"
        set dstaddr "all"
        set action accept
        set service "HTTPS" "SSH"
        set schedule "always"
        set logtraffic enable
    next
    edit 2
        set intf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "HTTPS" "SSH"
        set schedule "always"
        set logtraffic enable
    next
end

Policy 1 chỉ cho phép nhóm địa chỉ Trusted-Admin-IPs truy cập HTTPS/SSH, policy 2 chặn mọi nguồn còn lại — đúng nguyên tắc default-deny.

⚠️ Lưu ý: Từ FortiOS 7.4.4 trở lên, FortiGate mặc định đã có sẵn một local-in policy chặn các nguồn IP nằm trong danh mục ISDB nguy hiểm (Malicious-Malicious.Server, Tor-Exit.Node, Tor-Relay.Node) áp dụng cho mọi interface. Nếu tự thêm local-in policy dạng "deny all" thủ công, cần đặt đúng thứ tự để không vô tình chặn luôn các policy nhóm Admin-In/Implicit-In mặc định — nếu không cẩn thận có thể tự khóa quyền quản trị của chính mình.

2.3 Chỉ dùng giao thức mã hóa — không dùng HTTP/Telnet

config system global
    set admin-https-redirect enable
    set admin-ssh-port 22
end

Bật admin-https-redirect để mọi kết nối HTTP tới port quản trị tự động chuyển hướng sang HTTPS. Telnet không nên bật trên bất kỳ interface nào — vì Telnet truyền cả username/password dạng plaintext, dễ bị bắt gói (sniff) nếu kẻ tấn công chen được vào giữa đường truyền.

2.4 Đổi port quản trị mặc định (tùy chọn, tăng thêm một lớp che giấu)

config system global
    set admin-sport 8443
    set admin-ssh-port 2222
end

Đây không phải biện pháp bảo mật cốt lõi (security through obscurity), nhưng giúp giảm đáng kể số lượng bot quét cổng mặc định tự động — nên xem là lớp bổ sung, không thay thế cho local-in policy và trusted hosts.

2.5 Trusted Hosts cho từng tài khoản Admin

Đã giới thiệu ở Quản lý Admin: profile, quyền hạn, Trusted Hosts, nhưng cần nhấn mạnh lại trong bối cảnh hardening: mỗi tài khoản admin nên giới hạn rõ dải IP được phép đăng nhập.

config system admin
    edit "admin_it"
        set trusthost1 203.0.113.0 255.255.255.0
        set accprofile "super_admin"
        set password ENC ***
    next
end

⚠️ Lưu ý: Trusted Hosts cấu hình dưới tài khoản admin chỉ áp dụng cho các giao thức quản trị chuẩn (HTTPS/SSH/Telnet/SNMP...). Nếu cần kiểm soát chi tiết hơn theo interface, theo dịch vụ cụ thể, hoặc theo Geo-IP, nên kết hợp thêm local-in policy — trusted hosts và local-in policy bổ sung cho nhau, không thay thế lẫn nhau hoàn toàn.

2.6 Xác thực đa yếu tố (2FA) cho tài khoản quản trị

Mọi tài khoản có quyền super_admin nên bắt buộc bật 2FA — dùng FortiToken (mobile app hoặc hardware token) hoặc email-based OTP:

config system admin
    edit "admin_it"
        set two-factor fortitoken
        set fortitoken "FTK200XXXXXXXXX"
    next
end

Đây là lớp phòng thủ quan trọng: dù mật khẩu bị lộ (phishing, brute-force, hay rò rỉ từ nơi khác), kẻ tấn công vẫn cần thêm mã OTP thời gian thực mới đăng nhập được.

2.7 Chính sách khóa tài khoản khi đăng nhập sai nhiều lần

config system global
    set admin-lockout-threshold 3
    set admin-lockout-duration 60
end

admin-lockout-threshold 3: khóa tài khoản sau 3 lần nhập sai mật khẩu liên tiếp. admin-lockout-duration 60: khóa trong 60 giây trước khi cho thử lại — giá trị này nên cân nhắc tăng lên (vài phút) với hệ thống thường xuyên bị dò mật khẩu tự động, để tăng chi phí thời gian cho kẻ tấn công brute-force.

2.8 Vô hiệu hóa các dịch vụ không dùng đến

Rà soát và tắt các dịch vụ quản trị không thực sự cần thiết trên từng interface — nguyên tắc chung của hardening là "chỉ bật đúng những gì cần dùng":

• Tắt SNMP nếu không có hệ thống giám sát nào dùng tới.
• Tắt FTM (FortiToken Mobile push) trên interface không liên quan nếu không dùng.
• Rà soát định kỳ danh sách tài khoản admin, xóa các tài khoản không còn sử dụng (nhân viên đã nghỉ việc, tài khoản tạm thời của đối tác triển khai...).

2.9 Giám sát và ghi log các sự kiện quản trị

config log setting
    set neighbor-event enable
end

Bật logging cho các sự kiện đăng nhập, thay đổi cấu hình, và local-in policy (mục 2.2) giúp phục vụ điều tra sự cố sau này — một firewall được harden tốt vẫn cần khả năng phát hiện khi có nỗ lực xâm nhập, không chỉ dựa vào việc "chặn được hết".

2.10 Checklist hardening nhanh

•  Không mở HTTPS/SSH quản trị trên interface WAN
•  Nếu bắt buộc mở public, dùng local-in policy giới hạn nguồn cụ thể
•  Chỉ dùng HTTPS/SSH, tắt hoàn toàn HTTP/Telnet
•  Cân nhắc đổi port quản trị mặc định
•  Trusted Hosts cho từng tài khoản admin
•  Bật 2FA cho toàn bộ tài khoản super_admin
•  Cấu hình admin-lockout-threshold hợp lý
•  Rà soát và tắt dịch vụ không dùng đến
•  Bật logging đầy đủ cho sự kiện quản trị và local-in policy
•  Backup cấu hình định kỳ, mã hóa file backup

3. Hỏi & Đáp

Đổi port quản trị mặc định có thực sự giúp bảo mật không?

Chỉ là lớp bổ sung (giảm nhiễu từ bot quét tự động cổng mặc định), không phải biện pháp bảo mật chính. Kẻ tấn công có chủ đích vẫn có thể quét toàn bộ dải port để tìm ra port quản trị thật. Nên kết hợp với trusted hosts và local-in policy làm lớp bảo vệ chính.

Có nên tắt hoàn toàn quyền truy cập quản trị qua GUI, chỉ dùng CLI không?

Không cần thiết trong đa số trường hợp — GUI và CLI đều dùng chung cơ chế xác thực và có thể kiểm soát bằng trusted hosts/local-in policy như nhau. Việc tắt GUI hoàn toàn chỉ nên cân nhắc trong môi trường có yêu cầu compliance đặc biệt nghiêm ngặt, và sẽ gây bất tiện đáng kể cho vận hành hàng ngày.

Local-in policy và firewall policy thông thường có xung đột nhau không?

Không xung đột vì phục vụ hai mục đích khác nhau: local-in policy kiểm soát traffic đến/đi từ chính FortiGate (quản trị, health-check...), còn firewall policy thông thường kiểm soát traffic đi qua FortiGate giữa các mạng. Một gói tin nhắm tới chính địa chỉ IP quản trị của FortiGate sẽ được xử lý bởi local-in policy, không phải firewall policy.

4. Quiz

Câu 1: Vì sao không nên mở HTTPS/SSH quản trị trên interface WAN hướng ra internet?

• A. Vì FortiOS không hỗ trợ HTTPS trên WAN
• B. Vì điều đó mở rộng bề mặt tấn công, để lộ cổng quản trị cho toàn bộ internet dò quét
• C. Vì HTTPS trên WAN làm giảm hiệu năng xử lý traffic
• D. Vì license cơ bản không cho phép cấu hình này

Câu 2: Local-in policy khác firewall policy thông thường ở điểm nào?

• A. Local-in policy kiểm soát traffic đến/đi từ chính FortiGate, còn firewall policy kiểm soát traffic đi qua thiết bị
• B. Local-in policy chỉ áp dụng được cho VPN
• C. Hai loại policy này hoàn toàn giống nhau
• D. Local-in policy chỉ hoạt động khi bật VDOM

Câu 3: Vì sao nên bật 2FA cho tài khoản super_admin?

• A. Để tăng tốc độ đăng nhập
• B. Để dù mật khẩu bị lộ, kẻ tấn công vẫn cần thêm mã OTP thời gian thực mới đăng nhập được
• C. Vì FortiOS bắt buộc 2FA cho mọi tài khoản
• D. 2FA chỉ cần thiết cho tài khoản đọc-only (read-only)

Câu 4: Tham số admin-lockout-threshold dùng để làm gì?

• A. Giới hạn số lượng tài khoản admin tối đa
• B. Khóa tài khoản sau một số lần nhập sai mật khẩu liên tiếp, giảm rủi ro brute-force
• C. Giới hạn số phiên đăng nhập đồng thời
• D. Đặt thời gian hết hạn mật khẩu

👉 Đáp án

Câu 1: B Mở cổng quản trị trực tiếp ra internet khiến thiết bị trở thành mục tiêu bị dò quét, brute-force, hoặc khai thác lỗ hổng liên tục từ bất kỳ đâu trên thế giới, thay vì chỉ giới hạn trong phạm vi mạng tin cậy.

Câu 2: A Local-in policy xử lý traffic có đích đến chính là FortiGate (quản trị, ping, health-check...), trong khi firewall policy thông thường xử lý traffic đi qua thiết bị giữa các vùng mạng khác nhau.

Câu 3: B 2FA thêm một lớp xác thực độc lập với mật khẩu — dù mật khẩu bị lộ qua phishing hay rò rỉ dữ liệu, kẻ tấn công vẫn không có mã OTP thời gian thực để hoàn tất đăng nhập.

Câu 4: B admin-lockout-threshold quy định số lần nhập sai mật khẩu liên tiếp trước khi tài khoản bị tạm khóa, làm tăng đáng kể chi phí thời gian cho các cuộc tấn công dò mật khẩu tự động.

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

🧭 Điều hướng