cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2579
Views
0
Helpful
2
Replies

Best practices for ACP on FMC

ABaker94985
Spotlight
Spotlight

I've been looking for best practices and found this: https://www.cisco.com/c/en/us/td/docs/security/firepower/650/configuration/guide/fpmc-config-guide-v65/best_practices_for_access_control.html.

 

I feel as if I'm missing something still. Last Friday I was investigating a report from our cloud WAF provider that stated hosts outside their WAF range could access our public web servers. There was indeed a rule that only permitted the WAF IPs to access the servers, but I had inadvertently created a rule to block bad applications that was a couple lines previous to the WAF rule. Unfortunately, it was taking too long to process the bad application rule, and 30 or so packets were getting through to the websites while the FMC processed the bad application block rule. Consequently, any IP could access the web servers directly without going through the WAF - the entire web page would pull up, even though the FMC said the connection was blocked. After deleting the block bad application rule, behavior went back to what was expected. 

 

The problem is that we had a similar problem previously when we were doing geoblocking and URL file close to the top of the ACP. Too many packets were getting through the Firepowers we were expecting to be blocked that the host-based firewall ended up blocking.

 

Besides ordering the rules, which is prone to human error, is it possible to block traffic to the DMZ and internal hosts until the FMC;snort makes a decision? Or should we look at doing something else? Any guidance would be appreciated. Thanks

1 Accepted Solution

Accepted Solutions

Hi,

This is the problem with application detection verdicts as they need to
have couple of packets (usually less than 10) till the app is detected.
Hence, we use ports as much as possible if its known. Having that said,
most of time you want get malicious payload delivered in 1st 10 packets so
risk is minimal and with preprocessor I would say it's extremely low unless
it's very sophisticated.

***** please remember to rate useful posts

View solution in original post

2 Replies 2

Hi,

This is the problem with application detection verdicts as they need to
have couple of packets (usually less than 10) till the app is detected.
Hence, we use ports as much as possible if its known. Having that said,
most of time you want get malicious payload delivered in 1st 10 packets so
risk is minimal and with preprocessor I would say it's extremely low unless
it's very sophisticated.

***** please remember to rate useful posts

Thanks, Mohammed.  I understand what you are saying, but we had over 30 packets go through the FTD and entire web page pull up, with the FMC showing this was blocked. At this point, we've not restricted to ports on the rules, so I'll check on doing that. I realize being more granular speeds up processing. Also, the TAC engineer said that he's seen this behavior before and didn't seem too surprised. I'm concerned about unexpected behavior more or less being the norm. My concern is that more packets are getting through elsewhere that we're missing. I don't see any connectivity issues between the FTDs and FMC, nor are either heavily loaded. 

 

I could see this causing other issues, but is there any way all packets to the DMZ or internal host could be blocked before allowing a single packet through to the destination during the time the FMC makes the verdict?

Review Cisco Networking for a $25 gift card