Follow The dependable way to get Palo Alto or FortiGate logs into a file you can analyze is syslog. Forward the firewall’s logs to a small Linux collector running rsyslog, and export the collector’s file. For history that’s already on the box, FortiGate can download raw logs from its GUI. On PAN-OS, the practical source of history is usually Panorama, Strata Logging Service or your SIEM.
Firewalls see every connection in and out, and they’re now a target in their own right. Their logs answer “where did that host talk to?” and “who logged into the firewall at 3 a.m.?” Prime Core has 2093 detection rules for firewall logs, mapped to 554 MITRE ATT&CK techniques. Among them: command-and-control over common protocols (T1071), exfiltration over alternative channels (T1048) and network scanning (T1046).
Before you start
Check what’s actually logged. Firewalls log only what their rules tell them to, and the defaults are thinner than people assume.
- On PAN-OS, the predefined intrazone-default and interzone-default rules don’t log by default. Denied traffic that falls through to them leaves no trace unless someone overrode them to log.
- On FortiGate, logging is set per policy (security events only, or all sessions). Logging of traffic hitting the implicit deny policy is off by default.
Check where history lives. On-box storage is limited and rolls over. Smaller FortiGate models without a disk log to memory, which a reboot wipes. If you run Panorama, Strata Logging Service, FortiAnalyzer or FortiCloud, they almost certainly hold more history than the firewall. Start there.
Don’t forget the firewall’s own logs. Admin logins and config changes (System and Config logs on PAN-OS, event logs on FortiGate) matter as much as traffic, now that edge devices are a favorite entry point.
Route A: Forward syslog to a collector
This captures events from now on, and it’s the setup you want in place before the next incident.
On the Linux collector, create /etc/rsyslog.d/10-firewall.conf:
module(load="imudp")
input(type="imudp" port="514" ruleset="firewall")
ruleset(name="firewall") {
action(type="omfile" file="/var/log/firewall/fw.log")
}
Then restart rsyslog, and check that it listens with ss -ulpn | grep 514. Open UDP 514 from the firewall’s management or logging interface to the collector, and nothing else.
On PAN-OS:
- Device → Server Profiles → Syslog: add the collector, UDP, port 514.
- Objects → Log Forwarding: create a profile that sends Traffic and Threat logs to that syslog profile.
- Attach the profile to your security rules. Separately, forward System and Config logs under Device → Log Settings.
- Commit.
On FortiGate (CLI):
config log syslogd setting
set status enable
set server "10.0.0.50"
set port 514
set format default
end
The default format writes key=value pairs. When you need a slice for analysis, cut it from the collector’s file:
grep '2026-10-19' /var/log/firewall/fw.log > fw_1019.log
How dates look depends on the vendor format, so adjust the pattern to match.
Route B: Pull history from the device
FortiGate: in Log & Report, open the log view you need (Forward Traffic, Security Events, System Events), filter the time range, and download the raw log, a text file of key=value lines.
How to Download Logs from FortiGate GUI
- Log in to the FortiGate Web UI. [1]
- Go to Log & Report in the left-hand navigation menu. [1]
- Select the desired log category (e.g., Traffic Log > Forward Traffic or System Events). [1, 2]
- Set your time filters or select specific log rows (hold Ctrl to select multiple rows). [1, 2]
- Click the Download (or Download Raw Log) icon. [1, 2]
- Choose your format (Text, CSV, or JSON, depending on your FortiOS version) or select Download and combine for large log sets (v7.6+). [1]
Note: Direct GUI downloads have a hard cap (typically 400,000 log entries on the device, or 2,000–40,000 via FortiGate Cloud). For larger backups, use the CLI command execute backup disk/memory alllogs ftp/tftp. [1, 2]
What to look for
| Pattern | What it can mean |
|---|---|
| Repeated outbound sessions to the same rare external IP at regular intervals | Command-and-control beaconing |
| One internal host sending far more bytes out than usual | Exfiltration |
| Many destination ports from one source in a short window | Scanning, from outside or from a compromised internal host |
| Threat log hits (IPS, antivirus, spyware, URL filtering) | The firewall’s own detections; check what happened after them |
| Admin logins to the firewall from unusual IPs, config changes at odd hours | Someone working on the firewall itself |
Upload, sanitize and review in LogTotal
- Upload. Open logtotal.com and drop in the file.
- Sanitize. Look it over before you continue.
- Review.
When it goes wrong
| Symptom | Likely cause | Fix |
|---|---|---|
| No denied traffic in the logs | Default rules don’t log | Enable logging on the default and implicit deny rules |
| Collector receives nothing | Network ACL, wrong port or protocol, rsyslog not listening, or (PAN-OS) profile not attached or not committed | Check each hop; tcpdump -n udp port 514 on the collector |
| FortiGate logs gone after a reboot | Memory-only logging on a diskless model | Forward to syslog or FortiAnalyzer |
| Timestamps don’t match other sources | Firewall time zone or NTP | Fix NTP; note the device time zone |
| Long log lines cut off | UDP message size limits | Switch to TCP syslog |
FAQ
Should I export from Panorama or FortiAnalyzer instead?
If you have them, usually yes. They keep more history and cover many firewalls at once.
What about Cisco, Check Point, Juniper?
The syslog-collector approach works for all of them; they’ll get their own guides.
