SSH just stops (891W router)

[cluovpemb]

Hello all. 

Over the weekend this router was put into production.  SSHv2 is configfured and was working fine.  Due to some circumstances, we had to avoid configuring any zone-pairs that included the self zone.  This of course left the router open somewhat.  SSH was secured but of course a few IP's from poorly regulated parts of the world spent the weekend trying to brute force log into the router.  No luck it seems.

Anyway, SSH continjued working, then we set up self zone-pairs (out to self and self to out).  As ssh can't be Inspected, we did a pass log for each direction.  This worked for a bit, then SSH just stopped working. 

I've seen this happen on 891W's in the lab here too, so is not something perhaps done by some unseen DoS attack or something. 

Logging is showing that the incoming packet to initiate SSH session is being passed.  There is no response packet (not sure if there would be one showing in the log?).  On the outside client end, it just get connection timed out. 

I enabled debugging of ip ssh however I'm a bit new to debugging, so all I can say is that after enabling that, nothing new is logged nor comes up on console. 

Reloaded the router, no change. 

I have no clue here.  Not even sure what to enable in logging to see what might be failing.  Please assist!

[cluovpemb]

Sorry, forgot to mention but SSH from an internal system to the inside interface works.  Also, SSH from the inside systems to the IP of the WAN interface also works, so just from th Internet t the WAN interface is not working. 

And there was, but no longer, an ACL on he WAN intterface that I created ad hoc this weekend to block those IP's that were trying to get in.  The ACL is unbound from the interface and also deleted.  The ACL had been to deny those IP's, then permit ip any any though. 

[Julio Carvajal]

Hello Colin,

I need to see the configuration.

Please post the ZBFW configuration between the zone pairs out to self, self to out ( You got to have a pass on both of them)

Regards,

Julio

[cluovpemb]

Ah but that is the interesting part.  Having pass on both of them should work, but it ends up failing.  Looking at the class-default: drop action on the self-to-out zone, it was dropping packets.  We added pass log to this.  Then checked logs and it was dropping the SSH return packets going from self to out.  The initial out-to-self SSH requests were coming through the firewall showing a pASS_PKT for that. 

I have to review the config again to better understand but the solution was to add an ACL allowing self to out port 22 basically.  Here's the relevant config:

Policy Maps:

policy-map type inspect Out_To_Self

class type inspect SSH

  pass log

class class-default

  drop

policy-map type inspect Self_To_Out

class type inspect SSH

  pass log

class class-default

  drop log

Class Map:

Class Map type inspect match-any SSH (id 2)

   Match protocol  ssh

   Match access-group name  ssh

Access List:

Extended IP access list ssh
    20 permit tcp any eq 22 any (87 matches)

But, not that I review this I am curious. 

This class map SSH is being used in both directions.  But for the out-to-self direction, the ACL states to permit tcp any source who uses port 22, to get to any on the router.  Effectively if a hacker sets his source port to 22, he can get to "any" on the router (ie:  defeats the ACL at least).  Because it's match-any, he doesn't have to use actual ssh protocol.  Is that right? 

[Julio Carvajal]

This class map SSH is being used in both directions.  But for the out-to-self direction, the ACL states to permit tcp any source who uses port 22, to get to any on the router.  Effectively if a hacker sets his source port to 22, he can get to "any" on the router (ie:  defeats the ACL at least).  Because it's match-any, he doesn't have to use actual ssh protocol.  Is that right?

That is correct, the configuration does not need the ACL to work.. It should be working with just the match protocol SSH,

or using an ACL on each direction. Out to in permiting tcp any host outside_interface eq 22

and self_to out permiting tcp host outside_interface eq 22 any

Regards,

Julio

[cluovpemb]

I'll look at the ACL option you mentioned  But I can say this for sure, having just match protocol ssh within the self to out and out to self zone pairs with pass actions did not work, or more accurately, it worked when first conigured but then about a half day later it stopped working (nothing done by me).  While no longer being able to get out-to-self SSH to work, I reviewed the logs and did see a pass_pkt for my session inbound, but no other packets logged.  In fact, I clear logging, then try ssh from outside to self, then do sh logging and there is only one line, the pass-pkt.  On the outside at my computer, the ssh client times out. 

If I disable the self-to-out pair, leaving just the out-to-self pair, ssh inbound works fine.  If I then immediately re-enable the self-toout pair, ssh from out-to-self stops working, same logginb behavior as above.

This was prior to implementing any ACL's or what not - this was purely in the config we did over the phone (which was perfectly working at the time, which is why this is so confusing )

[Julio Carvajal]

Hello Colin,

Doest not make sense, Let us know if the ACL option works for your .

If not we can get deeper into this

Regards

[cluovpemb]

Just putting this issue on hold for a little bit while dealing with a few other concerns on this security setup (see my other posts)   I''ve made a note to get back to dealing with this SSH issue soon. 

[Julio Carvajal]

Hello Colin,

Sure.