Integrations
FortiGate
EvoHub receives FortiGate events through an automation stitch: a trigger on the event logs you care about, and a Webhook action that sends the log to EvoHub.
Set it up
Create the integration
In EvoHub, go to On-Call → Integrations → + Add Integration, choose FortiGate, pick an Escalation Policy and click Create Integration. Copy the Webhook URL.
Create the action
In FortiOS, go to Security Fabric → Automation, create an Action of type Webhook with protocol HTTPS, method POST, your webhook URL, and the HTTP body %%log%% — the triggering log as JSON. To keep the key out of the URL, remove ?key=… and add the header Authorization: Bearer <your integration key> instead.
The same action from the CLI:
config system automation-action
edit "evohub"
set action-type webhook
set protocol https
set method post
set uri "evohub.io/ingest/fortigate?key=YOUR_INTEGRATION_KEY"
set port 443
set http-body "%%log%%"
next
end
Warning
Every log that matches the trigger is one delivery. Trigger on specific event log IDs, not on traffic logs.
What EvoHub reads
| EvoHub alert | Taken from |
|---|---|
| Title | logdesc and the device name, for example Admin login failed on FGT-HQ-01. |
| Description | msg. |
| Labels | devname, devid, vd, logid, type, subtype, level, eventtype, action, user, srcip, dstip, srcport, dstport, policyid, ui, status, reason, time. |
Severity
| FortiOS log level | EvoHub severity |
|---|---|
| emergency, alert, critical | critical |
| error | high |
| warning | medium |
| notice | low |
| information, debug | info |
Resolve and deduplication
An alert is identified by the FortiGate and the log ID. While it is open, the same event again is recorded as Retriggered instead of paging again.
Log entries are events and FortiGate sends no recovery, so alerts stay open until someone resolves them in EvoHub.
Related
Was this page helpful?
