cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

1112
Views
0
Helpful
7
Replies

Scan Shows Ports Open Due to FTD Rule Actions

Ever since we moved to the new NGFWs, the way our ACPs are setup and ordered, outside scans show ports open because of the way FTD processes rules.  Due to it processing a layer 7 rule, it passes the traffic to SNORT for evaluation and therefore it lets some packets through before it actually blocks the connection.  I understand that, and that is documented.  However, the unfortunate result of that is that scans or tests will show ports as potentially open, even when they're not.  

 

We've tested this with ports that show as open on the scan.  We can't ever make a successful connection, but the scan thinks it's open because a few packets are let through at first instead of it being blocked since it takes time for the firewall to evaluate the traffic.

 

We've called TAC and they told us that our rules are ordered correctly and that it is just the way it works.  I understand that, but is there any way to avoid having those ports show as "open" when they're actually not, other than somehow avoiding layer 7 rules, which isn't an option at this point?  We're getting a penetration test done in a little bit, and I'm concerned that the report is going to come back showing all of these vulnerabilities since the ports appear open when they're actually not.  Has anyone run into something like this, or is it possible we have a misconfiguration somewhere?  Hope that all makes sense. 

 

I guess to sum it up, should a scan/test show ports as potentially open in the situation where a layer7 rules has to be analyzed by the SNORT engine, which causes the firewall to pass a few packets through before everything is blocked?

1 ACCEPTED SOLUTION

Accepted Solutions

I've never used geolocation in my life, but since it's a matter to find a match for the source ip address of the first packet against an internal database I'm very skeptical about this being the cause of your issue.

Sure you do not have any application rule in your access policy?

Maybe some rule intended for outbound traffic where source zone field has been mistakenly left with default value (any)?

View solution in original post

7 REPLIES 7
Marius Gunnerud
VIP Advisor

How have you configured blocking on the rule? Block, Block with reset, Interactive Block, Interactive block with reset ?

--
Please remember to select a correct answer and rate helpful posts

It is currently set to "Block."  However, in the past, I believe it was set to "Block with reset", but we have since changed that, but we haven't noticed any change in behavior as far as those few packets getting through and ports "appearing" open.  Should it be set one way or the other in order to correct a situation like this?

Massimo Baschieri
Participant

That's expected behaviour, application recognition needs from three to seven packects to pass by (if I remember correctly) in order to work, best practice is to avoid application rules from the outside and, to be honest, I can't think about any practical reason for doing that, you already know the applications you are publishing, why you need to filter on that?

Thanks for the reply, Massimo.  As an example, our actual rule where this is happening is on the rule that we have that blocks any non USA ip from coming into our network.  Due to that rule using Geolocation, it has to send a few packets through before it is able to analyze everything in order to block it and shut it down.  That's the rule that things are getting through on and the reason ports appear "open."

 

We don't want to get rid of that because we feel that it's more beneficial to have that in place than to not have it in place.  However, knowing that, is it still expected behavior for ports to appear open even when they're not?  I just want to confirm that we don't have a misconfiguration somewhere.  I know it's hard to tell by not seeing the config, but does my situation sound like something that could happen?  I haven't been too successful in finding anyone else really talking about a situation like this.

I've never used geolocation in my life, but since it's a matter to find a match for the source ip address of the first packet against an internal database I'm very skeptical about this being the cause of your issue.

Sure you do not have any application rule in your access policy?

Maybe some rule intended for outbound traffic where source zone field has been mistakenly left with default value (any)?

So two things resolved this issue.  We decided that we had to drop the geolocation rule.  It was getting hung up on that rule because it had to pass the traffic to SNORT for analysis which was causing a few packets to get through.  We know it was doing that based off the packet tracer analysis.  I'd like to have that enabled, but we just can't if we want the firewall to do what I think it should do.

 

Either way, once we disabled that rule, based off the packet tracer, it was then hitting another rule that had the source zone set to "any" but was intended to be outbound traffic only.  So exactly was Massimo suggested.  We changed the source zone to only inside and dmz, and now everything appears to be getting dropped correctly.  In the end, I believe it was a combination of two rules that were causing the issue.  Thank you so much for pointing us in the right direction.  We really appreciate the help!

I am uncertain that this is expected behaviour for Geolocation.  This is basically a list of subnets downloaded to Firepower so, without further testing, I would expect the traffic to be dropped upon match.  However, the behaviour you are describing is what is expected when using Application match criteria in the ACP.  I don't suppose you have defined any items in the Application area of the ACP rule as well?

--
Please remember to select a correct answer and rate helpful posts
Create
Recognize Your Peers
Content for Community-Ad