Skip to main content
podvarka
New Member
March 14, 2024
Question

FortiNAC 9.4 False positive events

  • March 14, 2024
  • 1 reply
  • 924 views

Hello,

did anybody solved similar behaviour, please ?

 

During NAC control; sometimes happens this :

scenario 1

                device is rebooted

                FortiNAC gets information (via trap) that port went up

                it tries to check compliance of device, but this is not fully booted and does not answer on all expected ports

scenario 2

                device is switched off during test (in many devices it really happens; seldomly but we see it);

scenario 3

                device check starts, but connection is broken (because it is behind WAN; again quite rare cases, but real)

 

result of test

                FortiNAC evaluates it as intrusion and disables port and send mesage (via email)

 

                after delay (5 minutes) port is released and check is run again; result of check is OK

 

question

                how to make postponed evaluation and send mesage after second consequent problem; but not as global parameter, individually for particular evaluation rule

                (with some scripting ? remember status rule for particular device ... ?)

 

there is possibility to trigger rule based on frequency; but due to  amount of ports in network, we choosen frequency of regular rechecking of devices longer and if we react to second consequent event, it could take long time

desired solution is to split actions to two steps :

                in first event to make action – shut down port;

release it after period time (5 minutes for instance),

recheck and if device will not be recognized as good to allow, shut down the port and send email

 

Best regards,

 

Petr

1 reply

ebilcari
Staff
Staff
March 15, 2024

Based on your description, this setup is configured to do Device Profiling with "Rule Confirmation Settings" checked. The point of enabling "Confirm Device Rule on Connect" is to deregister the host as soon as it is not compliant. Configuring a delay here removes the main purpose of this feature.

What I would suggest in this case it to create multiple DPR and for this type of devices with a "slow start" and specific method that take time to be verified, disable the "Confirm Device Rule on Connect" and enable "Confirm Device Rule on Interval" option.

Keep in mind that DPR are mostly used for dummy/IoT devices. In end hosts with a proper OS, using Persistent Agent and quarantine the non compliant host is the recommended way.

Emirjon
Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
Virtual event | September 2026. SASE summit. The age of autonomous trust. Register here!