08-17-2017 01:20 PM - edited 03-12-2019 02:50 AM
I recently had an issue where my FMC VM was virtually down due to the CPU being pegged at 100%. The GUI was inaccessible but I was able to login via SSH and issue a restart. After 30 mins the FMC had still not shutdown so I had to force it down with power off command.
I was surprised to find that during the FMC issue all the users browsing behind FMC managed sensors reported that they were unable to browse. I thought the sensor only needed to communicate with the FMC for logging, reporting and configuration. What feature or rule on the sensor is causing the sensor to require the FMC to be live just allow traffic to flow thru?
The sensors in question are Firepower services on ASA if that makes a difference and I am running 6.2.0.2 on them
Thanks,
Diego
08-21-2017 10:08 PM
The sensors should indeed continue to operate normally and enforce policy when the managing FMC is unavailable.
I just checked in my lab and confirmed as follows:
I deployed a policy blocking search engines and monitoring all other URLS (making sure to add log option). Confirmed it was working and then disconnected the FMC NIC from vSphere. Confirmed FMC is not reachable from the network. Then I went back to the client PC and verified I can browse to a new non-cached site and even authenticate. I also confirmed that search engines continue to be blocked.
I then reconnected the FMC network adapter and, after a few minutes, went back in and confirmed that the queue of events was drained from the sensor and showing up on FMC. I saw my new connections that occured while FMC was unreachable and tht they are hitting the expected rules.
This was on 6.2.0.2 as well although I am running a vFTD as opposed to an ASA with Firepower service module but it should work the same.
08-25-2017 10:55 AM - edited 08-25-2017 10:56 AM
Marvin,
Did you have file block policies in your testing? I think there might be something there that requires FMC communication. While reviewing my polices I noticed that I _did not_ have "local analysis" checked off. I havce since checked it off and re-applied the policies. It now seems to be working as you described. See attached file.
08-25-2017 12:59 PM - edited 08-26-2017 07:57 PM
That's a very good observation. I do have my file policy set for local malware analysis. It's part of the standard setup I used based on what I learned on class a couple of years back
08-28-2017 10:38 AM
I am trying to determine the pros and cons and/or differences between using "local malware analysis" or not but I can't find anything very detailed.
From the help, "When a device detects an eligible file, it sends the file's SHA-256 hash value to the Firepower Management Center". Also from the help, "Using a local malware inspection engine, the device examines an eligible file, blocks it if the file contains malware and the file rule is configured to do so, and generates malware events".
What is not clear is if both inspection techniques use the same database and/or engine. Is the local inspection equally as accurate, up-to-date and powerful as the one used by the FMC?
From my experience it would be a big negative if using FMC based lookup makes the sensor dependent on communication to the FMC for regular operation because it would require us to add redundancy to our FMC architecture which we currently don't have. I would only want to do this if it was clear that FMC side features like malware lookup are far more effective than sensor side lookups.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide