Log & Report FortiGate — Cấu hình gửi log Local, FortiAnalyzer, Syslog

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

Ba tuần sau sự cố băng thông, khách hàng của chị Lan bị kiểm toán bảo mật yêu cầu cung cấp log firewall trong 6 tháng gần nhất để phục vụ điều tra một sự cố rò rỉ dữ liệu nghi vấn. Anh Nam tra lại thì phát hoảng: FortiGate của khách chỉ lưu log cục bộ, dung lượng ổ đĩa nhỏ, log cũ hơn 3 tuần đã bị ghi đè (log rotation) từ lâu.

Chị Lan giải thích: "Đây là lỗi thiết kế thường gặp nhất — nhiều người nghĩ FortiGate 'tự động lưu log' là đủ, nhưng disk nội bộ trên thiết bị firewall chưa bao giờ được thiết kế để lưu trữ dài hạn. Muốn giữ log lâu dài và phục vụ điều tra, bắt buộc phải gửi ra ngoài — tới FortiAnalyzer hoặc syslog server."

Từ bài học đó, VNExperts đưa vào quy trình chuẩn: mọi FortiGate triển khai cho khách hàng doanh nghiệp đều phải cấu hình ít nhất một đích log ngoài, không phụ thuộc hoàn toàn vào disk nội bộ.

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

2.1 Ba loại đích đến của log

FortiGate hỗ trợ gửi log đồng thời tới nhiều đích khác nhau, mỗi đích có vai trò riêng:

• Local Disk: log lưu ngay trên ổ đĩa nội bộ FortiGate (chỉ có ở model có SSD/eMMC). Phục vụ FortiView Historical và tra cứu nhanh, nhưng dung lượng giới hạn và bị xoay vòng khi đầy.
• FortiAnalyzer: giải pháp log tập trung chính thức của Fortinet — thu thập log từ nhiều FortiGate, hỗ trợ report, phân tích tương quan sự kiện (event correlation), và lưu trữ dài hạn theo chính sách retention cấu hình được.
• Syslog Server: gửi log theo chuẩn syslog (RFC 5424) tới bất kỳ hệ thống SIEM nào (Splunk, ELK, QRadar...) — phù hợp khi doanh nghiệp đã có hạ tầng giám sát tập trung riêng và muốn tích hợp FortiGate vào đó thay vì dùng thêm FortiAnalyzer.

⚠️ Lưu ý: Ba đích này không loại trừ nhau — một FortiGate hoàn toàn có thể vừa log Local Disk, vừa gửi FortiAnalyzer, vừa gửi Syslog cùng lúc, mỗi nơi phục vụ một mục đích khác nhau (xem nhanh tại chỗ / báo cáo tập trung / tích hợp SIEM).

2.2 Cấu hình gửi log tới FortiAnalyzer (CLI)

config log fortianalyzer setting
    set status enable
    set server "10.10.5.20"
    set upload-option realtime
    set conn-timeout 10
end

• upload-option realtime: gửi log ngay khi phát sinh — khuyến nghị cho môi trường cần giám sát gần thời gian thực. Tùy chọn khác là 1-minute hoặc 5-minute để gom log gửi theo lô, giảm tải khi băng thông WAN hạn chế.
• Sau khi cấu hình server, FortiGate cần được Authorize trên FortiAnalyzer (thực hiện phía FortiAnalyzer: System Settings > Fabric Connectors hoặc trực tiếp trong quá trình đăng ký thiết bị mới) thì log mới được nhận và xử lý đầy đủ.

2.3 Cấu hình gửi log tới Syslog server (CLI)

config log syslogd setting
    set status enable
    set server "10.10.5.30"
    set port 514
    set mode udp
    set facility local7
    set format default
end

• mode có thể là udp (mặc định, RFC 5424 qua UDP) hoặc reliable (TCP, đảm bảo không mất log khi mạng chập chờn — nên cân nhắc dùng reliable cho log phục vụ compliance/audit).
• format có thể chọn default (định dạng log gốc FortiOS, dễ đọc bằng con người) hoặc csv/rfc5424 tùy hệ thống SIEM đầu nhận yêu cầu định dạng cụ thể.
• FortiGate hỗ trợ cấu hình tối đa nhiều syslog server song song (syslogd, syslogd2, syslogd3, syslogd4) — hữu ích khi cần gửi cùng lúc tới nhiều SIEM khác nhau (ví dụ một cho SOC nội bộ, một cho bên thứ ba giám sát).

2.4 Chọn mức log log-Filter (loại log nào được gửi)

Không phải mọi loại sự kiện đều cần gửi tới mọi đích. FortiGate cho phép lọc riêng theo từng đích bằng config log <đích> filter:

config log fortianalyzer filter
    set severity information
    set forward-traffic enable
    set local-traffic disable
end

• severity: mức tối thiểu được gửi (emergency, alert, critical, error, warning, notification, information, debug) — chọn information là mức phổ biến cho môi trường production, cân bằng giữa đủ chi tiết và không quá tải log.
• forward-traffic: log traffic đi qua FortiGate (qua Firewall Policy) — đây là nguồn dữ liệu chính cho điều tra sự cố và cho FortiView.
• local-traffic: log traffic đến/đi từ chính FortiGate (quản trị, heartbeat...) — thường tắt ở production để giảm nhiễu, chỉ bật khi cần debug riêng thiết bị.

2.5 Log Allowed Traffic ở mức Policy — điều kiện tiên quyết

Dù đã cấu hình đích log đầy đủ, nếu Firewall Policy không bật ghi log, sẽ không có dữ liệu traffic nào được gửi đi. Trong GUI, mỗi policy có tùy chọn:

• Log Allowed Traffic > Security Events: chỉ ghi log khi có sự kiện UTM (IPS, AV, Web Filter chặn...) — nhẹ tải nhưng thiếu dữ liệu traffic thông thường.
• Log Allowed Traffic > All Sessions: ghi log mọi session đi qua policy, kể cả traffic bình thường không vi phạm gì — cần thiết cho FortiView đầy đủ và cho điều tra sự cố, nhưng tiêu tốn nhiều dung lượng log hơn.

🔄 Khác biệt version FortiOS: Hành vi và tên gọi hai tùy chọn trên giữ nguyên qua các bản 7.0/7.2/7.4. Điểm khác biệt đáng chú ý là ở 7.2 trở đi, mặc định policy mới tạo có xu hướng bật sẵn "All Sessions" nhiều hơn so với 7.0 (tùy vào profile mặc định khi tạo) — nên luôn kiểm tra lại thay vì giả định.

2.6 Kiểm tra trạng thái kết nối log

diagnose log fortianalyzer stats
diagnose log test fortianalyzer

Lệnh diagnose log test fortianalyzer gửi một log test tới FortiAnalyzer để xác nhận kết nối và cấu hình đúng, hữu ích khi mới thiết lập hoặc nghi ngờ log không tới nơi dù cấu hình có vẻ đúng.

3. Hỏi & Đáp

Nếu chỉ có một FortiGate nhỏ (không có nhiều thiết bị), có cần FortiAnalyzer không hay dùng Syslog server là đủ?

Với một FortiGate đơn lẻ và doanh nghiệp đã có sẵn hệ thống SIEM/syslog, gửi thẳng syslog là lựa chọn hợp lý và tiết kiệm chi phí. FortiAnalyzer phát huy giá trị rõ nhất khi cần quản lý log tập trung cho nhiều FortiGate, cần report có sẵn theo mẫu Fortinet, hoặc cần phân tích tương quan sự kiện sâu hơn khả năng của syslog thô.

Log Local Disk và log gửi ra ngoài (FortiAnalyzer/Syslog) có giống hệt nhau về nội dung không?

Về nguyên tắc, cùng một bộ filter/severity sẽ sinh ra nội dung log tương đương, nhưng mỗi đích có config log <đích> filterriêng — nếu không đồng bộ, hai nơi có thể nhận lượng log khác nhau. Luôn kiểm tra filter của từng đích khi cần đối chiếu.

Vì sao gửi log rồi mà FortiAnalyzer vẫn không thấy dữ liệu?

Nguyên nhân phổ biến nhất là thiết bị chưa được Authorize trên FortiAnalyzer sau khi cấu hình server ở phía FortiGate, hoặc do tường lửa trung gian chặn cổng log (mặc định TCP 514 cho FortiAnalyzer, có thể khác tùy phiên bản) — nên dùng diagnose log test fortianalyzer để xác minh nhanh.

4. Quiz

Câu 1: Đích log nào phù hợp nhất để lưu trữ dài hạn phục vụ điều tra sự cố kéo dài nhiều tháng?

• A. Local Disk
• B. FortiAnalyzer hoặc Syslog server ngoài
• C. FortiView Real-time
• D. Bộ nhớ RAM của FortiGate

Câu 2: Tùy chọn nào trên Firewall Policy cần bật để FortiView có đầy đủ dữ liệu traffic thông thường (không chỉ sự kiện bảo mật)?

• A. Log Allowed Traffic > Security Events
• B. Log Allowed Traffic > All Sessions
• C. Enable NAT
• D. Enable Application Control

Câu 3: Chế độ mode reliable trong cấu hình syslog có ý nghĩa gì?

• A. Gửi log qua UDP nhanh hơn
• B. Gửi log qua TCP để tránh mất log khi mạng chập chờn
• C. Mã hóa toàn bộ log bằng TLS
• D. Tự động sao lưu log ra USB

Câu 4: Lệnh nào dùng để xác minh nhanh kết nối và cấu hình log tới FortiAnalyzer đang hoạt động đúng?

• A. diagnose sys session list
• B. diagnose log test fortianalyzer
• C. diagnose sniffer packet
• D. diagnose debug flow

👉 Đáp án

Câu 1: B Local Disk có dung lượng giới hạn và bị ghi đè khi đầy, không phù hợp lưu trữ dài hạn.

Câu 2: B "All Sessions" ghi log mọi phiên, kể cả traffic bình thường — cần thiết để FortiView và điều tra có đủ dữ liệu.

Câu 3: B reliable dùng TCP thay vì UDP mặc định, đảm bảo log không bị rơi khi có sự cố mạng tạm thời.

Câu 4: B Đây là lệnh chuyên dụng gửi log test và xác nhận trạng thái kết nối tới FortiAnalyzer.

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

🧭 Điều hướng