IPS and App Control inspect then allow the app

Lessons · FortiGate series · IPS and App Control

Hero · inspect on the policy, then allow the app

Why “disable IPS” is the wrong ticket

The day-one ticket is always a business app. The subject line says IPS. The log often says Application Control — or says nothing, because the policy still uses certificate-inspection and the IPS engine never saw the body.

Three silent or noisy states look identical to the user (“app is down”):

• Sensors exist, not attached to the policy the session actually matched.
• Attached, but SSL/SSH Inspection is certificate-inspection — handshake and SNI only. Payload signatures and require_ssl_di application signatures stay blind.
• Attached with deep-inspection, and the hit is a broad category Block (Proxy, P2P, Unknown Applications) or a signature whose default action is drop — not “IPS is broken.”

Sensor then app — two profiles

FortiOS runs one IPS engine. Application Control uses the same protocol decoders — that is why it can identify apps on non-standard ports. The objects you edit are still two profiles:

Path · inspect, then decide the app

Policy → SSL → classify → signature

Walk it left to right. If the log is empty, stop at the first stage that has no evidence. Do not start by editing signatures.

IPS vs App Control vs SSL

Pick the object from the question you are actually answering. Mixing them is how Teams becomes “an IPS outage.”

Runbook Side A / B / C

Order is the whole job. SSL first so the engine can see. Sensors second. Policy attach last — that is when inspection starts. Then Monitor before Block.

Side A — SSL/SSH Inspection (the inspect gate)

1. Decide certificate vs full

   Security Profiles > SSL/SSH Inspection. SSL Certificate Inspection inspects the certificate / handshake only. Full SSL Inspection inspects the encrypted payload. Outbound internet with IPS + App Control needs Full SSL Inspection on the policy that carries those profiles. Source: FortiOS 7.6 Administration Guide — Configuring an SSL/SSH Inspection profile.

2. Use a named profile

   Lab uses the built-in deep-inspection profile (Full SSL Inspection, multiple clients to multiple servers). Production: clone to ssl_lan_wan, install Fortinet_CA_SSL on endpoints, exempt pinning destinations. That cert-trust work is the SSL lesson — here the gate is simply: payload or not.

3. Do not skip this because “flow mode”

   IPS and Application Control both run in flow-based and proxy-based policies. Flow vs proxy does not replace SSL inspection. Ciphertext is still ciphertext.

Side B — IPS sensor, then Application Control sensor

1. Create the IPS sensor

   Security Profiles > Intrusion Prevention > Create New. Name ips_lan_wan. Optional: Block malicious URLs (local drive-by URL DB), Botnet C&C = Block or Monitor. Under IPS Signatures and Filters, Create New → Type = Filter. Severity Critical / High / Medium, Action = Monitor for the pilot (or Default if you accept FortiGuard’s default). Packet logging off until you need a pcap. Source: FortiOS 7.6 — Configuring an IPS sensor.

2. Know filter math

   A filter is AND across attribute groups (severity AND OS AND application) and OR inside a group. Linux + Apache in one filter = signatures that apply to both. Two filters if you wanted all Linux or all Apache. Entries are top-down; first matching set wins. Source: Signature-based defense — IPS filters.

3. Create the Application Control sensor

   Security Profiles > Application Control > Create New. Name app_lan_wan. Clone behavior from default (monitor) or start from block-high-risk only after a monitor week. Categories: Monitor Botnet/P2P/Proxy first, then Block those three. Leave Unknown Applications at Monitor/Allow on day one. Add Application and Filter Overrides for the business apps you must never drop (SAP, Teams). Source: FortiOS 7.6 — Configuring an application sensor; Basic category filters and overrides.

Side C — attach, log, then narrow the false positive

1. Attach all three on the matching policy

   Policy & Objects > Firewall Policy — edit policy 10 (LAN → WAN, src 203.0.113.0/24, service ALL, action Accept). Security Profiles: SSL/SSH Inspection = deep-inspection, IPS = ips_lan_wan, Application Control = app_lan_wan. Log Allowed Traffic = All Sessions during the pilot. CLI: set utm-status enable then the three profile names.

2. Prove a hit before you block

   Generate the business app and one known-bad (eicar HTTP, or a P2P test you own). Log & Report > Security Events > Intrusion Prevention and Application Control. You want subtype=ips / subtype=app-ctrl, profile matching the sensor, policyid=10. Monitor week: action should be detected, not dropped, except for Botnet/P2P you already chose to Block.

3. Tune the object that actually hit

   IPS false positive: IPS Signatures and Filters → Create New → Type = Signature → that attack → Action Allow or Monitor; or Edit IP Exemptions (Exempt IPs) for 203.0.113.50. Application Control false positive: Application and Filter Overrides → that one app = Monitor/Allow — or exclude the child signature. Retest the original user. Do not unset ips-sensor.

config ips sensor
    edit "ips_lan_wan"
        set comment "LAN-WAN pilot — monitor C/H/M"
        set block-malicious-url enable
        set scan-botnet-connections block
        config entries
            edit 1
                set severity critical high medium
                set location all
                set action pass
                set status enable
                set log enable
            next
        end
    next
end

config application list
    edit "app_lan_wan"
        set comment "Monitor, then block high-risk categories"
        set other-application-log enable
        set unknown-application-action pass
    next
end

config firewall policy
    edit 10
        set name "LAN-WAN-inspect"
        set srcintf "LAN"
        set dstintf "WAN"
        set srcaddr "LAN_203_0_113"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set utm-status enable
        set inspection-mode flow
        set ssl-ssh-profile "deep-inspection"
        set ips-sensor "ips_lan_wan"
        set application-list "app_lan_wan"
        set logtraffic all
    next
end

One session after go-live

After attach, every new session on policy 10 should leave a trail. If it does not, you are still in Side A/C, not in signature tuning.

# IPS monitor (pilot) — traffic continues
type=utm subtype=ips eventtype=signature action=detected
policyid=10 profile="ips_lan_wan" srcip=203.0.113.40
attack="Eicar.Virus.Test.File" severity="info"

# IPS block — this is the user-down ticket if it is a false positive
type=utm subtype=ips eventtype=signature action=dropped
policyid=10 profile="ips_lan_wan" attackid=…

# Application Control
type=utm subtype=app-ctrl eventtype=app-ctrl-all
app="BitTorrent" appcat="P2P" action=block profile="app_lan_wan" policyid=10

# Empty Security Events for 203.0.113.40 on 443 → check ssl-ssh-profile
# and whether policy 10 is actually first-match

Traps + proof

Proof · Security Events, not a green session counter

show firewall policy 10
# must include ssl-ssh-profile, ips-sensor, application-list

diagnose autoupdate versions
# IPS and Application definitions current — stale DB = missed apps, not a policy bug

get system ips
# engine status; fail-open default is disable (sessions drop if the IPS engine fails)

# Exempt IPs example — scanner 203.0.113.50, one signature entry
config ips sensor
    edit "ips_lan_wan"
        config entries
            edit 2
                set rule 29844
                set action pass
                set log enable
                config exempt-ip
                    edit 1
                        set src-ip 203.0.113.50 255.255.255.255
                    next
                end
            next
        end
    next
end

Sources

• FortiOS 7.6 Administration Guide — Configuring an IPS sensor (Security Profiles > Intrusion Prevention; Filter vs Signature; Allow / Monitor / Block / Reset / Default / Quarantine; Exempt IPs; packet logging)
• FortiOS 7.6 — Signature-based defense (filter AND/OR; top-down entries; predefined sensors all_default, all_default_pass, default, high_security, protect_client, protect_http_server, wifi-default)
• FortiOS CLI — config ips sensor (action pass|block|reset|default; exempt-ip; log-packet; scan-botnet-connections)
• FortiOS 7.6 — Configuring an application sensor (Security Profiles > Application Control; default / wifi-default / block-high-risk; category filters and overrides; excluding signatures)
• FortiOS — Application Control uses IPS protocol decoders; SSL-based application detection and require_ssl_di on some signatures
• FortiOS 7.6 — Configuring an SSL/SSH Inspection profile (Certificate Inspection vs Full SSL Inspection / deep-inspection)
• FortiOS — IPS signature filter options (signature-hold-time; on-hold monitors, does not block)
• FortiOS — IPS configuration options (fail-open default disable)
• FortiOS — Inspection mode feature comparison: Intrusion Prevention and Application Control in both flow and proxy

Related: SSL deep inspection + cert trust · Security profiles + SSL · Policy first match · Zone, policy, NAT flow · FortiGate interview · Troubleshooting command center