ASA SSH inspection

[al_tzamp79]

Hello,

I am trying to understand how inspection works on the ASA and although Cisco documentation on the subject is very analytical, after some testing on a 5520, a few questions have come up.

The Lab setup is the following:

PC -> (inside)ASA(outside) -> Router

SSH is originated from the PC to the Router through a 5520 ASA

With a default ASA confg (implicit ACLs, no NAT, default inspection policy) SSH passes through the ASA and return packets are allowed as if SSH was inspected. But SSH is not enabled in default ispection policy. How is it that it can establish a full session?

I have tried 3 different ASA software versions and they all behave the same.

Should this be happening? Is it normal ASA behaviour or a bug? I haven't found anything in the books to explain this.

By the way the same happens with RDP, HTTP (If you disable HTTP inspection in default inspection policy, it still goes through) and FTP-passive(if you disable it in default inspection policy. FTP-active will establish a control session but will not establish a data channel)

[balaji.bandi]

Not sure how your access policies look here? (if you do not have any implicitly deny this will work as expected by default)

can you post your configuraiton ?

[al_tzamp79]

Is this enough?

ASA Version 9.1(7)32
!
hostname XXXXXXX
!
interface GigabitEthernet0/0
nameif inside
security-level 100
ip address 1.1.1.1 255.255.255.0
!
interface GigabitEthernet0/1
nameif outside
security-level 0
ip address 2.2.2.2 255.255.255.224
!
interface GigabitEthernet0/2
!
interface GigabitEthernet0/3
!
interface Management0/0
!
ftp mode passive
no failover
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-771-151.bin
asdm history enable
arp timeout 14400
no arp permit-nonconnected
route outside 0.0.0.0 0.0.0.0 XXXXXXX 1
route inside XXXXXXX 255.0.0.0 XXXXXX 1
!
class-map global-class
match default-inspection-traffic
!
!
policy-map global-policy
class global-class
inspect tftp
!
service-policy global-policy global

[Muhammad Awais Khan]

Hi,

Your understanding is correct. If traffic traverse from high security level interface to lower security level like inside to outside, return traffic will be allowed. ASA is maintaining the state of each connection and that is how return traffic allowed and it utilizes the inspection defined under the global service-policy by default.

Once you remove no inspect ssh, did you clear the connections by issuing "clear connection" or did you try to test from other device ?

[al_tzamp79]

But ssh is not part of the default inspection policy. Moreover there is no option for ssh inspection at all in the cli (f.e. if I could make a class-map with an ACL selecting TCP/22 and apply inspection within a policy-map like in a router). So there's nothing to disable, or add. It just works..!
No problem with that, just want to know if this is normal behavior for an ASA.
"clear conn" was issued every time before I tested.

[johnd2310 · Accepted solution]

Hi,

By default, the asa allows traffic from high security-level interface to low security-level interface. Traffic from low security-level interface to high security-level interface is denied by default. This is why it is working in your case. You cannot configure ssh inspection because the asa cannot look inside the ssh packet. You can only enable inspection on traffic like ftp where the asa can look deep into the packet and open the required ports for the traffic. With ftp inspection disabled, the firewall does not look into the traffic and you have to open the required return ports manually.

To control traffic from the inside to outside, put an access-list on the inside interface.

Thanks

John

[al_tzamp79]

This is true but the way I understand this "hi to low security-level" is that it is a one direction permit. Instead I see that return traffic, which is "low to high security-level, is allowed too. This is not clear in the documentation. Only if it were "inspected", then, I'd expect return traffic to be allowed.
I have a Cisco router background and this is the way things work there with ZBF. No entries enter the state table unless inspect is applied to the respective traffic. 

[balaji.bandi]

Stateful firewall - A Stateful firewall is aware of the connections that pass through it. It adds and maintains information about a user's connections in a state table, referred to as a connection table. It then uses this connection table to implement the security policies for users' connections. An example of the stateful firewall is PIX, ASA,

[al_tzamp79]

First of all thank you all for your answers.

I have to say that I am aware of what a stateful firewall is, but the question was about weather this feature needs to be configured or not in order to be used. Having in mind how ZBF works on a Cisco router I thought it was a Bug. From your answers I understand that what I have experienced is considered to be default ASA behaviour and I leave it to that. Time for me to move on and play with NAT in ASA 8.3+

Best Regards,

Alexandros