cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
386
Views
0
Helpful
4
Replies

SSH working even though deny ip any any applied

Dean Romanelli
Level 4
Level 4

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

 

1 Accepted Solution

Accepted Solutions

Marvin Rhoads
Hall of Fame
Hall of Fame

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.

View solution in original post

4 Replies 4

Marvin Rhoads
Hall of Fame
Hall of Fame

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.

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?

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.

 

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

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