ASA ports 2000 and 5060 open to outside

[markus.albisser1]

Hi all

A pen test shows us that several resources which are published to the Outside via an ASA-5545 (also with a Firepower device attached to the ASA as a module) replies on the ports tcp/2000 and tcp/5060, which is the Skinny and SIP protocol. Even if there is no ACL configured and also explicitly a blocking rule on the top of this outside ACL, the tcp port scan replies. And, I can see on the log that this traffic is blocked by the ACL.

I found many articles about this, most of them are telling that the SIP/Skinny inspection needs to be disabled on the inspection_default rule. I took the inspects away for these two protocols, but the situation is still the same. 

Does anyone has an idea why these two ports still replies on a port scan and what can be done against it? Here is my inspection_default, for you reference.

Thanks a lot for your inputs.

Markus

class inspection_default
inspect dns preset_dns_map
inspect esmtp
inspect ftp
inspect h323 h225
inspect h323 ras
inspect http
inspect ip-options
inspect netbios
inspect pptp
inspect rsh
inspect rtsp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect xdmcp

[markus.albisser1]

Hi Cristian

I added here a little drawing with the situation. You are correct, 194.116.x.x is the public IP address on the ASA outside Interface, 10.65.x.x the DMZ IP address on the ASA encrypted Interface.

Therefore the IPs should be correct and the same. And you are right, based on the trace and capture, this is blocked. But based on the Wireshark on the client 192.168.169.134, there is a SYN/ACK coming back from the ASA. 

Thanks

Markus

[Cristian Matei]

Hi,

     Wireshark on client show the connection being successful, while capture on the ASA shows only 3 SYN packets coming in; so who's lying/faulty? The packet capture on the ASA happens ingress immediately after the RX ring, so there is nothing that can block the ASA from capturing any received packets.

Regards,

Cristian Matei.

[markus.albisser1]

Hi Cristian

Of course I don't understand your point. The ASA blocks these SYN connections, but Wireshark gets a SYN/ACK back. When the ASA would reply to a SYN with a SYN/ACK and reports a "deny tcp src outside...", there will not be a blocked message, rather than a permit log entry which is "Built inbound TCP connectionfor outside..." (which then is based on a permit statement in the ACL).

Let me know if you have any other ideas, otherwise I will go via Cisco TAC.

Thanks

Markus

[Cristian Matei]

Hi,

   Open a TAC case, and in case you don't forget, also post here what as actually happening. What i was trying to say is that, per the Wireshark capture, the client sends SYN and ACK (as it somehow receives a SYN-ACK back from the ASA. If you look at the packet capture on the ASA, which is done before any kind of policy being applied by the ASA (so it's not a capture of allowed packets but a capture of received packets), the ASA was only showing received SYN packets, no ACK or FIN as the client looked to be sending per the Wireshark capture.

Regards,

Cristian Matei.

[markus.albisser1]

Hi Cristian

For sure I will post it here when it comes to a TAC case. 

I had a chat with a colleague, he told me that this behavior can come from the Firepower module on the ASA, that as soon Application inspection is enabled, the Firepower needs to have the first packets to identify what the traffic is. Means the 3-way handshaking needs to be established for this check. And that the result I can see on the ASA log (denied traffic based on the ACL) is then the result on this, that the previous actions cannot be logged from the ASA directly as this is a Firepower task. 

This could exlain why I can see a fully established connection on the client but not on the ASA.

Could that makes sense for you?

Thanks

Markus

[Marvin Rhoads]

On an ASA with Firepower service module, the order of operations for a new connection checks the ACL prior to directing the packet to the stateful inspection process and then on to the service module for further inspection. An ACL DROP action will terminate the processing.

[markus.albisser1]

Hi Marvin

Thanks for your input. This also was my intend, but then it makes no sense that I get with a syn/syn ack/ack a fully established session when the outside ACL blocks this first request from the beginning. Also the pictures which Cisco has documented shows that the ACL applies before the FP module. 

Unless there is any other inputs I am waiting on pending questions I assume there is no other way than to open a TAC case.

Thanks

Markus

[Cristian Matei]

Hi,

   The ACL/ASA comes before FPWR. Open a TAC case.

Regards,

Cristian Matei.

[markus.albisser1 · Accepted solution]

Hi all

I just want to give all of you an update about the threat I opened here in the forum. During the further investigation with Cisco but also with our provider we figured out that this reply on the ports tcp/2000 and tcp/5060 does not come from the ASA firewall, it comes from the Fortigate firewall which is sitting in front of the ASA and which is responsible to route the Internet traffic to two different providers.

https://kb.fortinet.com/kb/documentLink.do?externalID=FD36152

Actually we are working with the provider on the way how to close this listening on these ports.

I want to thank you all for your inputs here to help to fix the problem.

Thank you

Markus

[Marvin Rhoads]

Ah, the dread ALGs. These used to vex me in my Netscreen days.

Cisco has them too - the inspect lines in the default class-map. Though they usually aren't quite so problematic with Cisco.

Thanks for letting us know the root cause.

[Florin Barhala]

Very helpful thread!

Thanks for sharing, mate!

How did you close these ports after all:

 - FW rule on Fortigate?

 - disable ALG inspection?

What role does the upfront Fortigate has for the network?

[markus.albisser1]

Hi Florin

The trick in our situation was to change the setting from "set default-voip-alg-mode proxy-based" to "set default-voip-alg-mode kernel-helper-based". There are no ACLs which blocks the traffic. Because we don't use VoIP via this Fortigate we were able to do this.

In our situation, the FG is here to terminate the local Internet breakout with two independent providers. For this, also BGP needs to be terminated. In fact, the FG is used as a router, at least in this particular vDOM.

Thanks

Markus