"Trusting" a vulnerability scanner in FirePower

[lonelyadmin]

Maybe trust is too strong of a word...

I have an AS5516-X active/standby pair with the integrated FirePower SFR managed by a single FPMC VM.  Everything is the latest version (as of this posting). Classic layout inside, outside, and DMZ. I send all IP traffic to the SFR for inspection with the standard policy map for all traffic flowing through the ASA.

I have several vulnerability scanners through out my network which generate an enormous amount of events in the FirePower console, which is to be expected. I'm looking for an easy way to either suppress or ignore traffic to and from those IP addresses. I wasn't sure if just white listing the IP was the recommended solution. Or if there is some other way to not completely ignore activity to and from those IP addresses.

I considered trying to ignore events based on classification, but that seemed a bit laborious...and I'd always be chasing the events. Also, it seems like you'd slowly end up ignoring all events.

I'd like to know what others have done in circumstances such as this.

Thanks!

[Aref Alsouqi]

You can create a prefilter rule and fastpath the scanner IP address, that will bypass any further inspection of the traffic coming from the scanner.

[Marvin Rhoads]

For an ASA with Firepower service module you should exempt the traffic in the redirect ACL in the class-map / policy-map configuration that steers traffic to the service module. That's because "Prefiltering is supported on Firepower Threat Defense devices only. Prefilter configurations have no effect on other devices "

Reference: https://www.cisco.com/c/en/us/td/docs/security/firepower/660/configuration/guide/fpmc-config-guide-v66/prefiltering_and_prefilter_policies.html?bookSearch=true#id_32280

[Marius Gunnerud]

I agree with Marvin here, bypassing firepower all together is the best option here.

[Aref Alsouqi]

You rock Marvin. You are right, for some reason I had the FTD in my mind when I replied to this post.

[1_am_r00t]

@Marvin Rhoads I was using the same approach you've mentioned (excluding redirection of Vuln.scanner to Snort using class-map/policy-map) - unfortunately on FTD managed by FMC I haven't found a similar option. Are you aware of a similar approach on FTD platform except "duplicating" the ACP in Prefilter to Fastpath Vuln.scanner flows? 

[Marvin Rhoads]

@1_am_r00t fastpathing the flow with a prefilter policy rule would be the way to go in an FTD environment.

[1_am_r00t]

okay so unfortunately still no other way than duplicating all req. ACP entries in the Prefilter policy. pity. thanks anyway!

[Marvin Rhoads]

For a given vulnerability scanner you would only need one Fastpath rule allowing it to access any host.

If you want it to match the destination address and port restriction of the parent ACP thought then, yes you are correct. However I would argue that wanting to scan with those restrictions in place should also come with the IPS/Snort restrictions in place. Otherwise you are scanning with half the firewall turned off which is not representative of the network as it normally operates.