FTD firewall allowing embryonic TCP connections

[sanchezeldorado]

Hello!

I'm using Arctic Wolf for security scanning, and they're telling me that port like 135 and 3389 are open. I have an externally accessible server with 1 to 1 NAT setup, then my ACLs only permit web traffic. When I do a packet capture, and try to initiate an RDP connection to the external IP address, I can see that RDP is forwarded through the firewall, the initial tcp SYN packet gets to the server and the server responds to my client PC. Only after that, does the firewall block the connection. I know it's ultimately blocking traffic, but it's causing our security scans to freak out.

This can't be a unique situation. I have three related questions.

1. Why is the SYN packet getting through in the first place without an ACL to allow it? (I suspect it may be because I'm using application and URL rules in the policy)

2. Can I stop it?

3. What do other people do to appease their security scanning software?

[MHM Cisco World]

then my ACLs only permit web traffic
1:1 NAT
are you use real IP address in acl no mapped IP ?

[sanchezeldorado]

My ACLs don't specify a source IP address, only the outside zone. The destination IP address is the mapped IP address. For example:

Rule: WebServerHTTPS
source zone: outside
destination zone: DMZ
source network: any
destination network: 192.168.200.20 (web server's internal IP)
application: HTTP or HTTPS
action: Allow

[Eric R. Jones]

I believe I understand what your asking. Could this be an issue with the pre-filter policy if your using the FMC to manage the device(s)?

[sanchezeldorado]

I have a couple items in my pre-filter policy, but nothing inbound. The only items in my pre-filter policy are over VPN, or for specific outbound traffic. Also, when I run system support firewall-engine-debug, I can see it analyzing the ACP rules until it matches my rule denying all inbound traffic and blocking with reset.

[Rob Ingram · Accepted solution]

@sanchezeldorado it takes 3-5 packets for the FTD to determine the application in a connection, so the correct access control rule may not be matched immediately. Once the application is known the connection is handled based on the matching rule.

Change your access control rules to use the ports (80/443), as this does not require inspection and can be processed quicker.

[sanchezeldorado]

Unfortunately I can't test this to find out for sure, but I'm confident you have the right of it. My client wants to keep the application rules, so I'm going to be blocking specific ports from my external router for things like netbios, ssh, rdp, etc... Thank you for your input!

[Alan Inman]

Do you have a Geoblocking rule in place? If so, you'll need to move your ACL above it. Geoblocking requires a few packets to flow in to be inspected. This creates a false-positive with vulnerability scanners. It will show the ports are open even though they are not. 

[sanchezeldorado]

Hey Alan, Do you have any documentation supporting this? Rob's answer about application filtering makes sense because it needs to have packets to determine what an application is, but geo blocking should be able to determine the source based on the first packet.

[Alan Inman]

I do. Check this and this out. One of the links points to another Cisco Forum post where a person poses this exact same question. That is where I found the answer. I used NMAP before and after to check the ports. Before placing the rule above the GeoBlocking, the ports showed open even though we had a block rule in place. After placing the rule above the GeoBlock rule the ports showed closed.