Port TCP/7070 and TCP/554 always open on ASA

alex.dersch · ‎02-26-2011

Hello Members,

i just ran a NMAP scan on the outside interface of a ASA 5520. It seems that the TCP Ports 7070 and 554 are open on all NAT interfaces and the outside interface of the firewall. I tried telnet on port 554 and 7070 and got connected.

Any reasons for the open ports?

How to close those ports?

regards

alex

mirober2 · ‎02-26-2011

Hi Alex,

It sounds like you are translating a host that is listening on these ports to the outside interface IP of the ASA. Do you have this setup in your NAT/static config?

One quick way to narrow this down if you're not sure of the config is to telnet on 554 again and then look at the output of 'show conn port 554' on the ASA. You'll see something like this, which will tell you which host is actually listening on these ports and being translated to the outside IP:

TCP outside :12345 inside :554, idle 0:00:19, bytes 194602, flags UIOB

The ASA doesn't listen on these ports for anything by default. To see which ports are open on the firewall itself, you can check the output of 'show asp table socket'. For example, this shows my firewall is listening on TCP/443 and TCP/22 for ASDM and SSH access:

Protocol  Socket    Local Address               Foreign Address         State
SSL       0008038f  172.18.254.18:443           0.0.0.0:*               LISTEN
TCP       000bff4f  172.18.254.18:22            0.0.0.0:*               LISTEN

Hope that helps.

-Mike

alex.dersch · ‎02-26-2011

Hi Mike,

thanks for your reply. I did a telnet OUTSIDE interface 554 and i got a connect. then i did the show asp table socket. and this is the output

NOS-CH-WBN-FW01# show asp table socket

Protocol Socket    Local Address               Foreign Address         State
SSL       0000285f 10.0.128.2:443              0.0.0.0:*               LISTEN
SSL       00004bdf 172.16.2.25:443             0.0.0.0:*               LISTEN
TCP       00009f8f 172.16.2.25:22              0.0.0.0:*               LISTEN
TCP       0000d2bf 10.0.128.2:22               0.0.0.0:*               LISTEN
SSL       0000ea2f x.x.x.x:443            0.0.0.0:*               LISTEN
DTLS      0001116f x.x.x.x:443            0.0.0.0:*               LISTEN
DTLS      00013b1f 172.16.2.25:443             0.0.0.0:*               LISTEN
TCP       02a7a5f8 172.16.2.25:22              172.24.7.11:20436       ESTAB

on the outside interface it listens only for SSL and DTLS.

regarding the NAT addresses i tried to connect to the real devices on the ports 554 and 7070 and the devices are not listening on the ports. And i have a ACL on the outside interface permitting only tcp 5060 with a defined source address.

access-list OUTSIDE_access_in extended permit object-group TCPUDP object-group DM_INLINE_NETWORK_3 object-group DM_INL INE_NETWORK_4 eq sip

regards

alex

mirober2 · ‎02-26-2011

Hi Alex,

Sorry if my last post wasn't clear. You should do a 'show conn all port 554' after telnetting to the outside IP. This should give you the information you're looking for as it will tell you the real IP address that you are connecting to.

-Mike

alex.dersch · ‎02-26-2011

Mike,

i get only this output
after telnetting to the outside interface

NOS-CH-WBN-FW01# show conn all port 554
89 in use, 4688 most used

i'm getting confused now

regards

alex

alex.dersch · ‎02-26-2011

Hello Mike,

here is the NMAP output

Starting Nmap 5.00 ( http://nmap.org ) at 2011-02-26 19:46 Mitteleuropäische Zeit
NSE: Loaded 30 scripts for scanning.
Initiating Parallel DNS resolution of 1 host. at 19:46
Completed Parallel DNS resolution of 1 host. at 19:46, 0.14s elapsed
Initiating SYN Stealth Scan at 19:46
Scanning x.x.x.x [1000 ports]
Discovered open port 554/tcp on x.x.x.x
Discovered open port 443/tcp on x.x.x.x
Discovered open port 7070/tcp on x.x.x.x
Completed SYN Stealth Scan at 19:46, 4.47s elapsed (1000 total ports)
Initiating Service scan at 19:46
Scanning 3 services on x.x.x.x
Service scan Timing: About 66.67% done; ETC: 19:49 (0:00:59 remaining)
Completed Service scan at 19:48, 116.20s elapsed (3 services on 1 host)
Initiating OS detection (try #1) against x.x.x.x
Retrying OS detection (try #2) against x.x.x.x
Initiating Traceroute at 19:48
x.x.x.x: no reply to our hop distance probe!
Completed Traceroute at 19:48, 30.03s elapsed
NSE: Script scanning x.x.x.x.
NSE: Starting runlevel 1 scan
Initiating NSE at 19:48
Completed NSE at 19:49, 20.41s elapsed
NSE: Script Scanning completed.
Host x.x.x.x is up (0.030s latency).
Interesting ports on x.x.x.x:
Not shown: 797 closed ports, 200 filtered ports
PORT STATE SERVICE VERSION
443/tcp open ssl/https?
| html-title: SSL VPN Service
|_ Requested resource was https://x.x.x.x/+CSCOE+/logon.html
554/tcp open rtsp?
7070/tcp open realserver?

mirober2 · ‎02-28-2011

Hi Alex,

I would recommend setting up a packet capture on each of your interfaces of the ASA. This will not only let you see the traffic coming to the outside interface, but you can see if it is passing through the ASA to another host (and you'll be able to see the real address of the host that is responding). If you are only seeing the packets on your outside interface, then we would have to investigate to see why the ASA is responding to that traffic.

Here is the guide to setting up packet captures on the ASA:
https://supportforums.cisco.com/docs/DOC-1222

Also, here are a couple of examples that I would suggest:

capture outside interface outside match tcp any any eq 554
capture inside interface inside match tcp any any eq 554
capture dmz interface dmz match tcp any any eq 554

show capture outside
show capture inside
show capture dmz

Let us know what you find.

-Mike

alex.dersch · ‎02-28-2011

Hey Mike,

i captured the ingress traffic on the outside and all the egress interfaces. always with the same result. i get 4 packets on the ingress interface (see screenshot) but no packets on any egress interface. It seems the packet terminates on the ASA. I attached also the pcap file.

regards

alex

mirober2 · ‎03-01-2011

Hi Alex,

It looks like NMAP is giving you a false positive for these ports. You can see in the captures that even though the SYN packets arrive from your scanner at the outside interface, there are no replies. The captures just show 4 SYNs from NMAP, but NMAP is not receiving anything back (either from the ASA or from any other host).

-Mike

alex.dersch · ‎03-01-2011

Hi Mike,

when i did the packet capture i did not use NMAP. I established a telnet session on port 554 and i got a connect.

regards

alex

mirober2 · ‎03-01-2011

Hi Alex,

Thanks for clarifying. In either case (NMAP or Telnet), according to the captures you took the ASA is not responding to the TCP/554 requests. That leaves us with a couple of possibilities:

1. The captures were only unidirectional

Are you sure you created the captures bi-directionally (i.e. client -> server, and server -> client?). What were the commands generated by ASDM when you used the packet capture wizard?

2. If the captures are bi-directional, something else may be responding to your Telnet/NMAP requests

If this is the case, a Wireshark capture on your client PC should help answer this. In other words, if you see only SYNs on the ASA's bi-directional capture, but on your Wireshark capture you see 2-way communication, something elsewhere in the network is intercepting your Telnet/NMAP connection.

-Mike

BrianSekleckiGE · ‎04-08-2020

I'm seeing this as-well.

show conn all

show asp table socket

It shows only SSH/22 listening.

But when I NMAP, I'm seeing "open":

21/tcp FTP Open

554/tcp RTSP Open

5060/tcp SIP Open

I assumed it was "service-policy global_policy global" doing application-level inspection and Layer4 proxy?

FW01# conf t
FW01(config)# policy-map global_policy
FW01(config-pmap)# class inspection_default
FW01(config-pmap-c)# no inspect ftp
FW01(config-pmap-c)# no inspect rtsp
FW01(config-pmap-c)# no inspect skinny
FW01(config-pmap-c)# no inspect h323 h225
FW01(config-pmap-c)# no inspect h323 ras
FW01(config-pmap-c)#

But I removed all of that jazz, and the problem persists.

Cristian Matei · ‎04-08-2020

Hi,

Do you have any NAT statements and/or ACL's allowing that traffic? Are you performing the NMAP scan from the Internet, some hops away from the ASA or from where?

Regards,

Cristian Matei.