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

[Cristian Matei]

Hi,

   1. Can you post your "show run nat" and any included objects, "show run access-group" and "show run access-list" for global ACL or the ACL applied inbound on the outside interface? Can you also post the output of a "packet-tracer" for that specific TCP traffic?

  2. Are you saying that the if you initiate a session from the outside it is successful, or just that you get a TCP RST, like the port scanner does as well?

Regards,

Cristian Matei.

[markus.albisser1]

Hi Christian

Thanks for your reply. Of course difficult to upload the config here, due to the fact that I cannot share it on a almost public place here and also the fact that it has 18'000 lines, most of them used by objects, object-groups, ACLs and NAT statement. But i will post some traces below a bit later, between a client and the firewall, probably that will help.

And yes, I try with the powershell command Test-NetConnection on port 2000 and I see the SYN, SYN/ACK, ACK and then the FIN/ACK and ACK. So a normal behavior, it seems that the session setup is totally ok and the firewall replies as if the port would be open.

Let me provide you some more information a bit further down.

Thank you

Markus

[Cristian Matei]

Hi,

 @markus.albisser1 There is another reply of mine further down the line. I had similar experiences, and in the end, depending on the vendor, we upgraded or TAC case. It was a software issue. What version are you running? Usually, in high-sec environments, a stable version is chosen, aggressive penetration testing performed, and any flaws get fixed via TAC.

   Post the information you were speaking about.

Regards,

Cristian Matei.

[markus.albisser1]

Hi Christian

This might be that we have a bug here. Our current ASA version is 9.8(4)15.

Thanks

Markus

[Marvin Rhoads]

I've seen some scanning tools report these as false positive. I never did quite figure out why.

[Cristian Matei]

Hi,

   It may depend if the firewall sends or not a TCP RST? When running some extended penetration testing against different FW vendors 2 years ago, the outcome was different even for the same vendor but just different OS version, somehow as expected. For example on the ASA, you can configure "service resetinbound" and will send a TCP RST for any denied packed inbound, if the flow is "low-sec-lvl to high-sec-lvl"; by default this is disabled so that the ASA plays dead. no TCP RST being sent.

Regards,

Cristian Matei.

[markus.albisser1]

Hi Christian

I created two print screens here, one from the client -> ASA and one of the log in the ASA ASDM from the blocked traffic. The TCP session is initiated and then closed again in a correct way, tested with the Test-NetConnection and port 2000. At the same time when this test reported a TcpTestSucceeded: True, the ASA firewall gets the deny on the outside ACL.

Thanks

Markus

[Cristian Matei]

Hi,

   I don't see any matching between the IP's involved in the two captures, those looks to be two different sessions. Can you confirm that?

Regards,

Cristian Matei.

[markus.albisser1]

Hi Christian

Sorry for that and the confusion. Let me give you some insights which IP address has a NAT to which:
-> 192.168.169.134: This is the internal address of the client, the client's public IP address then is 178.83.228.141
-> 194.116.x.x: This is the public IP address of the destination on the ASA, the internal address of this then is 10.x.x.x

In fact, over the Internet, the IP address 178.83.228.141 communicates with 194.116.x.x. Does this makes sense?

Thanks

Markus

[Cristian Matei]

Hi,

    What version are you running on the ASA? From the client where the packet capture has been performed, if you still run Wireshark and try to just telnet on that port of 2000, what happens?

Regards,

Cristian Matei.

[markus.albisser1]

Hi Christian

Our current ASA version is 9.8(4)15. The print screen above shows the Wireshark output with the Test-NetConnection command in Powershell. I doublechecked with Telnet, it is exactly the same (SYN Client -> ASA / SYN ACK ASA -> Client / ACK Client -> ASA), with the difference that the FIN/ACK will not come immediately as the Telnet session is still established (connected Telnet screen. This is also confirmed with the netstat -an, which shows the connection as established:

TCP 192.168.169.134:2194 194.116.x.x:2000 ESTABLISHED

Thanks

Markus

[Cristian Matei]

Hi,

  Can you post the output of a packet-tracer, by simulating the exact same traffic, with the source being the public IP you're using for your Test-NetConnection? Could you also perform a packet capture on your outside interface to catch this traffic, ensure to use the "trace" keyword and afterwards perform a "show cap xyz 1 trace detail"? Here's a guide to help you with the packet-tracer if you're not really familiar:

https://community.cisco.com/t5/security-documents/asa-using-packet-capture-to-troubleshoot-asa-firewall/ta-p/3129889

Regards,

Cristian Matei.

[markus.albisser1]

Hi Cristian

Please find attached the output from the trace and the packet-capture commands.

Thanks

Markus

[Cristian Matei]

Hi,

   Couple of observations:

        1. Both the capture and packet-tracer confirm a DROP.

        2. Capture and packet-tracer are not for the same traffic, the destination is different, so it's either 10.6x.x.x, either 194.116.x.x. At the same time it looks that 10.6x.xx.xx is NAT'ed into 194.116.x.x. With the capture there was no reply, and there was no request for 10.6x.x.x. So what re you trying to simulate exactly?

Regards,

Cristian Matei.