Fortinet FortiGate
Integration with Wazuh

1. Choose the collection path

FortiGate can forward traffic, administrative, VPN, and security-profile events without a Wazuh agent on the firewall. This guide develops the integration approach from the OpenSIEM Deployer FortiGate collection article, with configuration checks against vendor documentation.

Path A: FortiGate → UDP syslog / 514 → Wazuh manager

Path B: FortiGate → UDP syslog / 514 → Linux collector
        rsyslog → local file → Wazuh agent → TCP / 1514 → manager

Manager → decoding and rules → alerts → indexer → dashboard

The Wazuh agent uses its encrypted message protocol on TCP 1514 by default; this connection is not HTTPS. That encryption covers the collector-to-manager hop. UDP syslog from the firewall remains unencrypted and has no delivery acknowledgment. Use a protected network or a deliberately designed TLS-capable relay for crossings that require encryption.

The examples use UDP to keep the receiver and sender aligned. If you choose TCP instead, validate FortiOS mode, receiver framing, and port configuration together. FortiOS reliable mode uses RFC 6587; TCP by itself does not imply TLS.

2. Prepare addresses, versions, and log scope

The example addresses below are placeholders for a private lab. Replace them consistently:

Record FortiOS and Wazuh versions, time synchronization, VDOM/HA context, expected log categories, and retention requirements. Back up relevant configuration and inspect current syslog destinations before editing. Do not overwrite an existing logging destination used by another service; choose an available supported destination slot where necessary.

The FortiOS examples follow the 7.4 CLI family; confirm available options on the exact release. For Path B, first enroll the collector using Deploying Wazuh agents on Linux endpoints. For a new central platform, see Wazuh all-in-one installation and validation.

3. Configure FortiGate forwarding

After reviewing the existing destination and the correct VDOM context, configure native key-value output. The source IP must belong to the firewall and be routable to the receiver.

config log syslogd setting
    set status enable
    set server "10.20.0.10"
    set mode udp
    set port 514
    set facility local7
    set source-ip "10.20.0.1"
    set format default
end

Use set mode udp for this example, rather than assuming an older set reliable option exists. Start with format default and the native FortiGate decoder path. CEF is an alternative format, not a guarantee of richer or correct field extraction in every Wazuh version.

Control which events are generated and forwarded

config log syslogd filter
    set severity information
    set forward-traffic enable
end

show full-configuration log syslogd setting
show full-configuration log syslogd filter

This is a minimal forwarding filter, not a complete logging policy. It leaves other categories at their existing settings. Review event, VPN, IPS, antivirus, web-filtering, and local-traffic requirements explicitly. Severity filtering and category filtering both affect which records leave the firewall.

Traffic must also be logged by the relevant firewall policy. On a selected existing policy, set logtraffic all enables traffic logging; apply it only where the intended coverage and volume justify it. Do not create a new allow policy merely to generate logs. Security-profile records similarly depend on the configured inspection profile and actual matching activity.

4. Path A: receive syslog directly on Wazuh

Add the following <remote> block inside the manager's existing <ossec_config> in /var/ossec/etc/ossec.conf. Preserve the separate secure agent listener on port 1514.

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
  <allowed-ips>10.20.0.1</allowed-ips>
  <local_ip>10.20.0.10</local_ip>
</remote>

allowed-ips is mandatory for Wazuh syslog reception. Use the source address actually observed at the manager, especially if NAT, HA, or VDOM routing changes it. Bind local_ip to an interface address present on the manager. An IP allowlist limits accepted sources but does not authenticate UDP messages.

sudo /var/ossec/bin/wazuh-remoted -t
sudo systemctl restart wazuh-manager
sudo systemctl --no-pager --full status wazuh-manager
sudo ss -lunp | grep ":514"
sudo tail -n 60 /var/ossec/logs/ossec.log

Restart only after the configuration check succeeds. Confirm that Wazuh owns the expected UDP socket. An rsyslog listener already bound to that address/port will conflict; choose one receiver for this path. In Docker, publish 514/udp explicitly and bind to an address available inside the container, not the host-only address. Keep changes in the deployment's persistent configuration.

5. Path B: receive on a Linux collector

This alternative uses rsyslog to write a dedicated file and a Wazuh agent to forward it. The following package and ownership examples target Debian/Ubuntu; adjust them for the collector's distribution and service identity.

sudo apt-get update
sudo apt-get install -y rsyslog
sudo install -d -o syslog -g adm -m 0750 /var/log/fortigate

Create /etc/rsyslog.d/30-fortigate.conf after checking existing inputs. Load imudp only once, and avoid a second listener on the same address/port.

module(load="imudp")

ruleset(name="fortigate_input") {
    if ($fromhost-ip == "10.20.0.1") then {
        action(type="omfile"
               file="/var/log/fortigate/firewall.log"
               template="RSYSLOG_TraditionalFileFormat"
               fileOwner="syslog" fileGroup="adm" fileCreateMode="0640")
    }
    stop
}

input(type="imudp" address="10.20.0.10" port="514"
      ruleset="fortigate_input")

The dedicated ruleset writes accepted sender messages and stops further processing of that input. Restrict UDP 514 in the host/network firewall as well. Ensure the directory is writable by rsyslog and the resulting file is readable by the agent's log collector; verify permissions instead of making the file world-readable.

sudo rsyslogd -N1
sudo systemctl restart rsyslog
sudo systemctl --no-pager --full status rsyslog
sudo ss -lunp | grep ":514"

Continue only if validation succeeds. On the collector's agent, add this block to the existing /var/ossec/etc/ossec.conf:

<localfile>
  <location>/var/log/fortigate/firewall.log</location>
  <log_format>syslog</log_format>
</localfile>

sudo /var/ossec/bin/wazuh-logcollector -t
sudo systemctl restart wazuh-agent
sudo tail -n 60 /var/ossec/logs/ossec.log
sudo grep ^status /var/ossec/var/run/wazuh-agentd.state

Configure log rotation and retention before sustained ingestion, and verify rsyslog reopens the rotated file and the agent continues reading new records. A local file provides a useful diagnostic boundary, but UDP input can still lose events and a finite agent queue is not unlimited outage storage. Measure peak volume and recovery behavior.

6. Validate the built-in decoder with a real event

Use one complete FortiGate record from the actual ingestion path. Preserve field order, quoting, and the syslog wrapper when testing; redact sensitive values without changing their structure. On the manager, inspect the installed files and open the rule tester:

sudo ls /var/ossec/ruleset/decoders/*fortigate*
sudo ls /var/ossec/ruleset/rules/*fortigate*
sudo /var/ossec/bin/wazuh-logtest

Paste the event as a single line. Inspect preprocessing, the selected decoder, extracted fields, and the final rule. Check addresses, ports, action, user, event type/subtype, policy ID, and device identity where those fields are present. Do not assume every FortiOS log type produces the same field set.

The Wazuh 4.14.0 source includes 0100-fortigate_decoders.xml and 0391-fortigate_rules.xml. Decoder names and rule IDs are implementation details, not FortiOS compatibility labels. A decoder with a historical version suffix may still match a newer event format; the actual test result is what matters.

If parsing fails, first check output format, truncation, relay-added prefixes, and quoting. Add a local decoder only for a demonstrated gap, under /var/ossec/etc/decoders/, with positive and negative event samples. Do not edit packaged files under /var/ossec/ruleset/ or import a second overlapping parent decoder without checking how it affects existing matches.

7. Tune one detection after the baseline works

Custom rules should address an operational requirement rather than turn every traffic record into an alert. As a concrete example, the referenced Wazuh 4.14.0 ruleset uses rule 81606 for a FortiGate login failure. Only use the following child rule if wazuh-logtest confirms that your target event matches that parent.

Choose an unused custom ID in Wazuh's 100000–120000 range. If 100620 is available, place this example in /var/ossec/etc/rules/fortigate-local.xml:

<group name="fortigate,local,">
  <rule id="100620" level="6">
    <if_sid>81606</if_sid>
    <description>FortiGate: failed administrative login requiring review.</description>
    <group>authentication_failed,</group>
  </rule>
</group>

This raises the review priority of a known login-failure match; it is not a brute-force correlation rule. If your installed ruleset selects a different parent, adapt the rule to the verified match instead of copying the ID blindly.

sudo /var/ossec/bin/wazuh-analysisd -t
sudo /var/ossec/bin/wazuh-logtest
# After syntax and matching checks pass:
sudo systemctl restart wazuh-manager

Test the intended failure event, a successful login, and unrelated traffic. Only the target event should select the new rule. Saved rules are available to a new logtest session; live analysis requires the manager restart. In a cluster, use the supported configuration synchronization workflow.

8. Verify receipt, analysis, and dashboard visibility

Observe the receiver

On whichever host receives syslog, capture a small sample while generating an approved event on the firewall:

sudo tcpdump -ni any -c 10 -s 0 -A 'src host 10.20.0.1 and udp dst port 514'
# Path B only, after the first accepted event creates the file:
sudo tail -n 20 /var/log/fortigate/firewall.log

A normal authorized administrative login/logout can validate system-event forwarding. A known permitted or denied connection through a policy with logging enabled can validate traffic records. Record the event time, device/VDOM, and expected category. Do not assume the two tests validate IPS, VPN, or antivirus coverage.

Separate received records from alerts

If packets or collector records exist but the dashboard is empty, inspect the manager's analysis results. Wazuh's alerts index is not a store of every event. For example, the referenced ruleset assigns some routine traffic matches level 1, which may fall below your configured alert threshold.

JSON archives, when enabled, can show received events that produce no alert. They are disabled by default. For a controlled diagnostic window, enable <logall_json>yes</logall_json> in the manager's existing <global> block, restart it, and generate a fresh event. Inspect /var/ossec/logs/archives/archives.json, then restore the previous setting if continuous archiving is not intended. Plan disk capacity and access controls before retaining all firewall traffic.

Find matching alerts

sudo tail -n 100 /var/ossec/logs/alerts/alerts.json
# Dashboard query against the alerts data view:
# rule.groups:fortigate

In the dashboard, choose wazuh-alerts-*, a recent time range, and rule.groups:fortigate. Inspect the event document rather than relying only on a chart count. Direct syslog may appear under the manager's agent identity; collector ingestion uses the collector agent identity. Identify the firewall using verified device fields, sender/location, and event content.

For the optional custom rule, filter rule.id:100620. If alerts exist in the manager file but not the dashboard, investigate Filebeat, indexer ingestion, time filters, and data-view selection. Searching wazuh-archives-* additionally requires archive forwarding and a configured archive data view.

9. Troubleshoot the failing stage

Keep one verified sample for each required category and document the receiver, decoder, final rule, and searchable fields. That evidence makes future FortiOS upgrades, decoder changes, and ingestion regressions easier to assess.

10. Sources and references

• OpenSIEM Deployer — Collect Fortinet FortiGate Logs in Wazuh — source resource for this guide.
• Fortinet — FortiOS 7.4.7 syslog destination CLI
• Fortinet — log settings and targets
• Fortinet — log types and policy logging examples
• Wazuh — syslog reception
• Wazuh — architecture, ports, and transport
• Wazuh 4.14.0 — packaged FortiGate decoders
• Wazuh 4.14.0 — packaged FortiGate rules
• Wazuh — custom rules and validation
• Wazuh — event archives
• rsyslog — UDP inputs and ruleset binding
• rsyslog — file output and permissions

The resource's integration workflow is expanded here with vendor-backed configuration checks. No deployment on a FortiGate appliance is claimed; validate commands and event samples against the releases and policies in your environment.