cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7853
Views
5
Helpful
4
Replies

Cisco ASA nmap scan results

krishnadig
Level 1
Level 1

Hi,

When the outside interface of Cisco ASA is scanned, it lists several ports which are open. However when I check the listening ports on firewall, it just shows SSH.

 ciscoasa#sh asp table socket

 Protocol  Socket    Local Address               Foreign Address         State

TCP       0000f124  192.168.0.11:22             0.0.0.0:*               LISTEN

However, incase I try to telnet ASA outside interface IP on any of the nmap scan ports (example port TCP/3389), I get a response followed by a RESET. See below log

telnet x.x.x.x  3389

Trying x.x.x.x...

Connected to x.x.x.x.

Escape character is '^]'.

Connection closed by foreign host.

And the syslog on firewall below: (1.1.1.1 >> source IP & x.x.x.x >> ASA outside IP)

%ASA-6-302013: Built inbound TCP connection 403410235 for outside:1.1.1.1/40700 (1.1.1.1/40700) to identity:x.x.x.x/3389 (x.x.x.x/3389)
%ASA-6-302014: Teardown TCP connection 403410235 for outside:1.1.1.1/40700 to identity:x.x.x.x/3389 duration 0: 00:00 bytes 0 TCP Reset-I

Can someone please explain why such a behavior, despite firewall isn't listening to port TCP/3389?

And help the remediation for it as well? 

Thank you.

Krishna

1 Accepted Solution

Accepted Solutions

The connection is established due to TCP intercept. The ASA establishes the handshake with the TCP intercept issue being enabled by default for management connections. So the ASA looks like it is listening. More info here http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/conns_connlimits.html

To not have the ASA complete the handshake you can create a connection limit policy for packets destined to the ASA interface and set an embryonic connection limit.

View solution in original post

4 Replies 4

Panos Kampanakis
Cisco Employee
Cisco Employee

Nadiq,

There is probably a translation rule that is picking this up and the ACL is probably allowing the packet. I suggest to run packet tracer to see how the packet is being processed to see what rule you are hitting. The packet tracer command will be something like

packet-tracer input outside tcp 1.1.1.1 40700 x.x.x.x 3389 detail

Hi Panos,

Thank you for your response. There is no configuration,on the firewall for the detected open ports. Intact this is firewall is configured only for L2L VPNs, and nothing else.

There is a control plane ACL applied on outside interface to permit ISAKMP and ESP ports from trusted peers, and deny untrusted peers; and permit IP any any rule at the end. (https://www.reddit.com/r/networking/comments/45g8dp/heads_up_if_you_are_patching_asas_for_cve20161287/)

Here is the packet tracer output. Although the output shows a drop, in reality firewall sends an ACK followed by a Reset immediately after (logs visible in original post)..

ASA# packet-tracer input outside tcp 1.1.1.1 2211 x.x.x.x 3389

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xa7d1fd58, priority=12, domain=capture, deny=false
hits=937238457, user_data=0xa8089948, cs_id=0x0, l3_type=0x0
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0000.0000.0000

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xa71c8038, priority=1, domain=permit, deny=false
hits=13067487424, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0000.0000.0000

Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 4
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in x.x.x.x 255.255.255.255 identity

Phase: 5
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside

Phase: 6
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside-in in interface outside control-plane
Additional Information:
Forward Flow based lookup yields rule:
in id=0xa80e9f88, priority=120, domain=permit, deny=false
hits=6714911, user_data=0xa7b13640, cs_id=0x0, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 7
Type: MGMT-TCP-INTERCEPT
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xa721c070, priority=0, domain=mgmt-tcp-intercept, deny=false
hits=6663225, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=6
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xa724c960, priority=0, domain=permit-ip-option, deny=true
hits=365387778, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 9
Type: ROUTE-LOOKUP
Subtype: output and adjacency
Result: ALLOW
Config:
Additional Information:
found next-hop x.x.x.x using egress ifc outside
adjacency Active
next-hop mac address 0000.0c07.ac14 hits 37928

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

ASA# sho run | i 3389
ASA#

To overcome the IKE Vulnerability, implemented control plane ACL below


sh run | i control-
access-list internet-control-plane extended permit object-group ipsec-vpn-svcs object-group vpn-peers object-group internet-interfaces

==>> Allow only trusted VPN peers
access-list internet-control-plane extended deny object-group ipsec-vpn-svcs any object-group internet-interfaces

==>> Deny untrusted VPN peers
access-list internet-control-plane extended permit ip any any

==>> Permit rest all traffic

The connection is established due to TCP intercept. The ASA establishes the handshake with the TCP intercept issue being enabled by default for management connections. So the ASA looks like it is listening. More info here http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/conns_connlimits.html

To not have the ASA complete the handshake you can create a connection limit policy for packets destined to the ASA interface and set an embryonic connection limit.

Yes, I agree may be due to TCP intercept. 

I dug further on this topic, and found other ASA's configured in same manner having OS 8.2(5.xx) dont behave like this; however the previous versions do. I am trying a version upgrade from 8.0 to 8.2; hopefully it fixes it. Fingers crossed!!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card