SSH working even though deny ip any any applied

Answered Question
Sep 27th, 2014
User Badges:

Hi All,

I have the following configured in my ASA:

access-list outside_access_in extended deny ip any any

access-group outside_access_in in interface outside

ssh 0.0.0.0 0.0.0.0 inside
ssh 0.0.0.0 0.0.0.0 outside

However, I am still able to SSH to the outside interface (public IP) from anywhere on the internet.  Why?  I get that the SSH argument is for any any, but shouldn't a catchall deny ip any any prevent that access unless explicitly permitted, since denying ip also denies tcp?

I would think I would need the below statement before the deny ip any any in order to allow SSH:

access-list outside_access_in extended permit tcp any any eq 22

access-list outside_access_in extended deny ip any any

 

Correct Answer by Marvin Rhoads about 2 years 10 months ago

Since the destination of the ssh traffic is the ingress interface itself, the packet flow never has to move into the stage of inspecting the ACL for handoff to the next steps in the internal flow (match xlate, inspections etc.). Please refer to this diagram.

You can always check how / if and ASA will handle an incoming packet using packet-tracer. For example:

packet-tracer input outside tcp <source address> 1025 <outside interface address> 22

...would show this use case.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Marvin Rhoads Sat, 09/27/2014 - 08:22
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 Firewalling, Network Management, VPN

Since the destination of the ssh traffic is the ingress interface itself, the packet flow never has to move into the stage of inspecting the ACL for handoff to the next steps in the internal flow (match xlate, inspections etc.). Please refer to this diagram.

You can always check how / if and ASA will handle an incoming packet using packet-tracer. For example:

packet-tracer input outside tcp <source address> 1025 <outside interface address> 22

...would show this use case.

Dean Romanelli Sat, 09/27/2014 - 09:07
User Badges:

Hi Marvin,

Thanks for your reply.  If I am understanding your comment and the provided link correctly, then there is theoretically no way to protect the outside interface IP address from unauthorized SSH attempts other than tightening up the ssh 0.0.0.0 0.0.0.0 outside statement to call only the IP/subnet that should be allowed to SSH to the address, correct?

If so, would this also apply to ICMP? Meaning that there is no way to prevent pings to the outside interface IP address because it comes before the ACL check in the packet flow?

Marvin Rhoads Sat, 09/27/2014 - 09:40
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 Firewalling, Network Management, VPN

Yes - ssh, http(s) and icmp are special cases as they talk directly to the interface. For those we typically use the respective commands for each and allow (or disallow) those protocols to the interface itself vs. via an access-list. i.e.:

ssh <address, mask> outside

http <address, mask> outside

icmp permit <address, mask> outside

You CAN use access-lists if your specify the "control-plane" option with the access-group (although I've only read about it and never actually seen that used in practice).

You should definitely tighten down (or disallow) incoming access to your public interface. A common recommendation when we do security assessments is to allow management access only from trusted networks.

 

Dean Romanelli Sat, 09/27/2014 - 14:09
User Badges:

Thank you Marvin.  I completely understand now.  I appreciate your help.

Actions

This Discussion