# IPS and App Control inspect then allow the app Source: https://ai.techclick.in/blog_fortinet_fortigate_ips_application_control_tuning Markdown: https://ai.techclick.in/blog_fortinet_fortigate_ips_application_control_tuning.md Publisher: Techclick Infosec Pvt Ltd FortiGate IPS sensor matches exploits. Application Control classifies the app. Both need SSL inspection on the firewall policy. Monitor, then tune the signature — never detach the sensor. Lessons · FortiGate series · IPS and App Control This page vs SSL deep inspection This lesson is which Security Profile does the work, and how you tune it . Certificate trust, Fortinet_CA_SSL on the endpoint, and exemptions for pinning live on the SSL page. Do not debug signatures on ciphertext. SSL deep inspection + cert trust · Security profiles + SSL · Policy first match Hero · inspect on the policy, then allow the app Mood, not a wiring diagram. Exact path is in the SVG: matching firewall policy → SSL/SSH Inspection → IPS engine decode → Application Control classify → IPS signatures → action. A sensor sitting in Security Profiles with no policy attach is a museum piece. Quick answer An IPS sensor is a bag of FortiGuard (and custom) exploit signatures plus filters — severity, OS, protocol, CVE — with action Allow / Monitor / Block / Reset / Default / Quarantine. An Application Control sensor classifies the application (Teams, BitTorrent, SAP) and then Allow / Monitor / Block / Quarantine that app or category. Both attach as Security Profiles on the firewall policy, together with an SSL/SSH Inspection profile. Certificate inspection does not decrypt payload; Full SSL Inspection does. False-positive tune = one signature, one application override, or Exempt IPs — not unset ips-sensor . ## 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.” Do not detach the sensor for a scanner A vulnerability scanner at 203.0.113.50 will trip high-severity signatures on the SAP box. That is the sensor working. Exempt that source (or that one signature) on ips_lan_wan . If you unset ips-sensor on policy 10, you just opened every other host on 203.0.113.0/24 . ## 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: #### IPS sensor config ips sensor . GUI: Security Profiles > Intrusion Prevention. Job: is this packet an exploit? Filters by severity, target (client/server), protocol, OS, application, CVE. Actions per filter or per signature. #### Application Control sensor config application list . GUI: Security Profiles > Application Control. Job: which application is this session? Categories + Application and Filter Overrides. Actions Allow / Monitor / Block / Quarantine. #### SSL/SSH Inspection config firewall ssl-ssh-profile . Prerequisite, not a third “threat” profile. Certificate inspection = handshake. Full SSL Inspection = payload. No payload, no useful IPS or app ID on 443. #### Firewall policy The attach point. set utm-status enable then ips-sensor , application-list , ssl-ssh-profile on the policy the session hits. Profile-based NGFW. Policy-based NGFW puts applications on the security policy itself — out of scope here. Say this out loud IPS asks “is this an attack?” Application Control asks “which app is this?” SSL inspection decides whether either of them can see the payload. All three must sit on the matching firewall policy. Path · inspect, then decide the app Feel of the fork: inspect first, then allow or block the application. Exact order is the next SVG — policy match, SSL, classify, signature, action. Artwork labels are mood, not FortiOS field names. ## 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. Flow 1 · one session on policy 10 Firewall policy match, SSL inspection, Application Control classify, IPS signature, then action - Client 203.0.113.40 FortiGate · policy 10 LAN → WAN · flow inspection 1. Policy hit first-match IPv4 utm-status enable 2. SSL inspect cert = SNI only deep = payload 3. App Control app_lan_wan classify the app 4. IPS sensor ips_lan_wan exploit match Application Control uses IPS protocol decoders. Empty IPS + App logs = stop at stage 1 or 2, not stage 4. Allow / Monitor action=detected · session continues this is the pilot setting Block / Reset / Quarantine action=dropped · app dies tune the hit, not the sensor App / WAN only if allowed Bypass: policy 10 has no ips-sensor / application-list, or SSL is certificate-inspection on 443. Do not add Exempt IPs until Log & Report shows subtype=ips or subtype=app-ctrl for this client. Read left → right. The gold box is one firewall policy. IPS and App Control are profiles on that policy, not a second hop in the rack drawing. ## 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.” Question on the wire Object Factory starting point If you get this wrong Is this an exploit / CVE / overflow? IPS sensor — Security Profiles > Intrusion Prevention default (signature default action). Also all_default , all_default_pass , high_security , protect_client , protect_http_server You block a scanner by detaching IPS and leave the rest of LAN naked. Which application is this session? Application Control sensor — Security Profiles > Application Control default monitors all apps. block-high-risk is the named block sensor. wifi-default for offload Wi-Fi You Block Unknown Applications on day one and drop every app the engine has not named yet. Can the engine see HTTPS payload? SSL/SSH Inspection — Security Profiles > SSL/SSH Inspection certificate-inspection (handshake). deep-inspection / custom-deep-inspection (Full SSL Inspection) Empty UTM logs on 443, or apps show as SSL / HTTPS.BROWSER instead of Teams. Does this session even hit UTM? Firewall policy — Policy & Objects > Firewall Policy Must set IPS + Application Control + SSL on the matching policy Sensors exist; traffic matches a wide ALL-ALL accept with no profiles. Factory names, not folklore IPS: all_default uses each signature’s FortiGuard default action; all_default_pass is pass/monitor for everything — a log-only bag, not a protect profile; high_security filters Critical/High/Medium and sets Block. App Control: default monitors; block-high-risk is the block starting point. Clone them. Do not edit the factory objects in place. ## 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) #### 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. - #### 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. - #### 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 - #### 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. - #### 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. - #### 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. https://192.0.2.1/ · Security Profiles › Intrusion Prevention › ips_lan_wan Training mock · not live Security Profiles › Intrusion Prevention › ips_lan_wan ### Edit IPS Sensor Name ips_lan_wan Block malicious URLs Enable Botnet C&C Block IPS Signatures and Filters 1 filter · severity C/H/M · Monitor Filter Type Filter Action Monitor Cancel OK Source: FortiOS Administration Guide — Configuring an IPS sensor. Action Monitor = allow and log ( action=detected ). Block / Reset / Quarantine drop. Default = FortiGuard’s per-signature default. After OK, the sensor still inspects nothing until a firewall policy references it. ### Side C — attach, log, then narrow the false positive - #### 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. - #### 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. - #### 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 . https://192.0.2.1/ · Policy & Objects › Firewall Policy › 10 LAN-WAN-inspect Training mock · not live Policy & Objects › Firewall Policy › 10 ### LAN-WAN-inspect Incoming / Outgoing LAN → WAN Source LAN_203_0_113 SSL/SSH Inspection deep-inspection Inspection mode Flow-based IPS ips_lan_wan Application Control app_lan_wan Cancel OK Source: FortiOS — Configuring a firewall policy + Inspection mode feature comparison (IPS and Application Control both valid in flow and proxy). Missing any one of the three profile dropdowns = empty Security Events for that session. FortiOS CLI — sensors, then attach on policy 10 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 CLI action names vs GUI IPS GUI Monitor is CLI set action pass with set log enable — traffic continues, log writes action=detected . GUI Block is CLI block (drop). GUI Default is CLI default (FortiGuard per-signature). Application Control unknown apps: unknown-application-action pass|block . Do not invent set action monitor under config ips sensor . ## 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. Flow 2 · log subtype decides the tune Empty log vs ips vs app-ctrl decides whether to fix SSL, Exempt IPs, or an application override - User: app is down do not unset ips-sensor Security Events subtype for this src? Empty UTM log policy miss or SSL cert-only subtype=ips signature / Exempt IPs subtype=app-ctrl app override / category Fix attach + deep SSL one signature or Exempt IPs one app override On-hold signatures are not a false-positive exemption config system ips · signature-hold-time — new/updated signatures log as “signature is on hold” and monitor until hold expires. They do not block. Do not confuse hold with Exempt IPs. Exempt IPs is the scanner/server carve-out on one entry. Proof: same user, same URL, action=detected after the tune — then leave the rest of ips_lan_wan in place. Diamond = read the log first. Three different fixes. Detaching the sensor is never the fourth. What a healthy vs dropped log looks like # 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 Mood of the proof desk. Green is a log row with the right subtype and profile name, plus the original user test. Session count on the policy is not IPS evidence. Trap What you see Fix Sensor not on the policy Security Events empty. show firewall policy 10 has no ips-sensor / application-list Attach ips_lan_wan , app_lan_wan , and SSL on the policy that actually matches. First-match wins — a wide ALL-ALL above policy 10 bypasses UTM. Certificate inspection on 443 Apps show as SSL / HTTPS.BROWSER. IPS payload signatures never fire. Some app signatures tagged require_ssl_di stay dark Full SSL Inspection on that policy. Endpoint must trust Fortinet_CA_SSL. Exempt pinning sites — see the SSL lesson. Block Unknown Applications day one Random SaaS dies. Log: unknown / unclassified, action=block unknown-application-action pass . Monitor a week. Override the business app. Then Block the high-risk categories you named. Scanner false positive SAP or the vuln scanner is dropped. subtype=ips, one attackid, src 203.0.113.50 Exempt IPs on that signature, or set that signature Action to Monitor/Allow. Leave filter 1 in place. Edited factory default Every policy that still points at default inherits your Block Clone to ips_lan_wan / app_lan_wan . Factory objects stay factory. On-hold treated as a bug Log: “signature is on hold”; traffic not blocked Expected after a FortiGuard IPS update for signature-hold-time . It monitors until hold expires. Not an Exempt IPs problem. Pilot checklist — do not skip show firewall policy 10 lists ssl-ssh-profile deep-inspection , ips-sensor ips_lan_wan , application-list app_lan_wan . - Client 203.0.113.40 generates one IPS row and one Application Control row in Security Events. policyid=10 , profile names match. - Pilot action on the C/H/M IPS filter is Monitor ( action=detected ). Botnet/P2P may already Block. - False-positive tune is one signature or one application override. show ips sensor ips_lan_wan still has the severity filter. - Original user test of SAP / Teams succeeds after the carve-out. Repeat the same URL, do not declare victory on a different host. Proof commands 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 fail-open is not a tune config ips global / set fail-open enable makes the IPS engine pass traffic when it cannot inspect. Default is disable (drop). That is a conserve-mode / engine-failure knob, not a false-positive control. Do not enable it to “fix Teams.” ## Knowledge check Six judgment items. Submit to score. Reasons point back to the section to re-read. Q1 Microsoft Teams is down. The ticket subject is “disable IPS.” What is the first move? unset ips-sensor on every LAN-WAN policy until Teams works Log & Report > Security Events: is subtype ips or app-ctrl, which profile, and is SSL/SSH Inspection certificate-inspection or deep-inspection on the matching policy? Switch the VDOM to NGFW policy-based mode so applications sit in the policy config ips global set fail-open enable Correct: b . The ticket name is not the object. Empty logs or certificate-inspection mean you never reached IPS. subtype=app-ctrl means you are tuning Application Control, not the IPS sensor. Re-read Why + Flow. Q2 Operational difference between an IPS sensor and an Application Control sensor? IPS matches exploit signatures (CVE, overflow, injection). Application Control classifies the application (Teams, BitTorrent, SAP) and then Allow / Monitor / Block that app They are two GUI names for the same config ips sensor object Application Control only runs in proxy mode; IPS only runs in flow mode IPS runs on FortiAnalyzer; Application Control runs on the FortiGate Correct: a . Shared IPS engine and protocol decoders — still two Security Profiles. Both are valid in flow and proxy. Re-read Sensor then app. Q3 Policy 10 has ips-sensor and application-list. SSL/SSH Inspection is certificate-inspection. What is true on HTTPS? Payload IPS signatures and require_ssl_di application signatures still fire because inspection-mode is flow certificate-inspection decrypts HTTP/2 bodies Certificate inspection sees handshake and SNI only. Payload IPS and most SSL-tagged application signatures stay blind until Full SSL Inspection (deep-inspection) You must disable IPS whenever you use certificate-inspection Correct: c . Flow vs proxy does not decrypt. Full SSL Inspection is the inspect gate. Re-read Side A and the choose table. Q4 Scanner 203.0.113.50 trips a high-severity IPS signature against SAP. Safest tune? unset ips-sensor on policy 10 until the scan window ends Add an IPS Signatures and Filters entry for that signature (Action Monitor or Allow) and/or Exempt IPs for 203.0.113.50; leave the rest of ips_lan_wan in place Point every policy at all_default_pass set fail-open enable so signatures never drop Correct: b . Exempt IPs / one-signature action is the documented false-positive path. Detaching the sensor or fail-open opens the rest of the LAN. Re-read Traps + Side C. Q5 You clone the factory Application Control sensor default onto policy 10 and set Unknown Applications to Block on day one. What happens? default already blocks every category, so nothing changes wifi-default is the only monitor sensor block-high-risk is log-only default monitors applications. Blocking Unknown Applications on day one drops sessions the engine has not classified yet — start Monitor, then override categories Correct: d . Factory default = monitor. block-high-risk is the named block starting point, after a monitor week. Re-read How to choose + Side B. Q6 You created ips_lan_wan and app_lan_wan. Security Events for the test client stay empty. Most likely miss? The matching firewall policy does not have utm-status with ips-sensor, application-list, and ssl-ssh-profile all set — a sensor with no policy inspects nothing FortiGate requires Apply Policy on the chassis after every sensor edit, like ASM Flow-based policies cannot run IPS You must reboot after each IPS filter change Correct: a . Attach is the unit of control. There is no ASM-style Apply Policy on FortiGate UTM profiles. IPS and App Control both run in flow mode. Re-read Flow + Side C. Check answers Reset ## 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 --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt