topic Re: ASA ports 2000 and 5060 open to outside in Network Security

ASA ports 2000 and 5060 open to outside

markus.albisser1 — Wed, 01 Apr 2020 06:23:00 GMT

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

Re: ASA ports 2000 and 5060 open to outside

Cristian Matei — Wed, 01 Apr 2020 07:38:48 GMT

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.

Re: ASA ports 2000 and 5060 open to outside

Marvin Rhoads — Wed, 01 Apr 2020 09:41:54 GMT

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

Re: ASA ports 2000 and 5060 open to outside

Cristian Matei — Wed, 01 Apr 2020 13:41:42 GMT

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.

Re: ASA ports 2000 and 5060 open to outside

markus.albisser1 — Wed, 01 Apr 2020 14:46:00 GMT

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

Re: ASA ports 2000 and 5060 open to outside

Cristian Matei — Wed, 01 Apr 2020 15:02:09 GMT

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.

Re: ASA ports 2000 and 5060 open to outside

markus.albisser1 — Wed, 01 Apr 2020 15:19:41 GMT

Hi Christian

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

Thanks

Markus

Re: ASA ports 2000 and 5060 open to outside

markus.albisser1 — Wed, 01 Apr 2020 15:23:38 GMT

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

Re: ASA ports 2000 and 5060 open to outside

Cristian Matei — Wed, 01 Apr 2020 17:36:43 GMT

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.

Re: ASA ports 2000 and 5060 open to outside

markus.albisser1 — Thu, 02 Apr 2020 04:56:17 GMT

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

Re: ASA ports 2000 and 5060 open to outside

Cristian Matei — Thu, 02 Apr 2020 05:29:30 GMT

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.

Re: ASA ports 2000 and 5060 open to outside

markus.albisser1 — Thu, 02 Apr 2020 06:50:01 GMT

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

Re: ASA ports 2000 and 5060 open to outside

Cristian Matei — Thu, 02 Apr 2020 07:15:54 GMT

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.

Re: ASA ports 2000 and 5060 open to outside

markus.albisser1 — Thu, 02 Apr 2020 09:42:43 GMT

Hi Cristian

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

Thanks

Markus

Re: ASA ports 2000 and 5060 open to outside

Cristian Matei — Thu, 02 Apr 2020 10:14:03 GMT

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.

Re: ASA ports 2000 and 5060 open to outside

markus.albisser1 — Thu, 02 Apr 2020 13:05:25 GMT

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

Re: ASA ports 2000 and 5060 open to outside

Cristian Matei — Sat, 04 Apr 2020 17:24:36 GMT

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.

Re: ASA ports 2000 and 5060 open to outside

markus.albisser1 — Mon, 06 Apr 2020 04:27:12 GMT

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

Re: ASA ports 2000 and 5060 open to outside

Cristian Matei — Mon, 06 Apr 2020 08:00:08 GMT

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.

Re: ASA ports 2000 and 5060 open to outside

markus.albisser1 — Tue, 07 Apr 2020 06:59:20 GMT

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