Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
podvarka
New Contributor

FortiNAC 9.4 False positive events

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 1
ebilcari
Staff
Staff

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
If you have found a solution, please like and accept it to make it easily accessible for others.
Labels
Top Kudoed Authors