Restrict SSH Access to Management Station - R80.40

[Simon_Macpherso]

Hello

There is a bug in R80.40 JHF GA take 67 which allows ssh connection access from any external IP to a management station, despite only specific IPs or networks being configured as trusted clients.

We have logged a TAC and R&D are investigating. In the interim, they have suggested the following to restrict access.

-------------------------

Configure ssh daemon in sshd_config (/etc/ssh/sshd.conf) to use different authentication method depending on the client address/hostname.

First remove default authentication methods:

PasswordAuthentication no

PubkeyAuthentication no

Then add desired authentication methods after a Match Address in the end of the file. Placing Match in the end of the file is important, since all the configuration lines after it are placed inside the conditional block until the next Match line.

For example:

Match Addres 127.0.0.*

  PubkeyAuthentication yes

Other clients are still able to connect, but logins will fail because there is no available authentication methods.

-------------------------

Have anyone used this to restrict traffic?

We need to restrict access to 4 /24 networks and a /32 host. 

More information about Match method in sshd_config

https://linux.die.net/man/5/sshd_config

Regards,

Simon

[PhoneBoy]

It’s leveraging fairly standard OpenSSH functionality, I don’t see an issue with the suggestion.

[John_Fleming]

Could be wrong here, but I think why trusted hosts doesn't do anything to ssh is because tcp wrappers support isn't compiled into sshd.

https://man7.org/linux/man-pages/man1/ldd.1.html

[Expert@MDS1:0]# fw ver
This is Check Point's software version R80.40 - Build 101
[Expert@MDS1:0]# ldd `which sshd` | grep -i wrap
[Expert@MDS1:0]#

[Expert@MDS1:0]# ldd `which xinetd` | grep -i wrap
libwrap.so.0 => /lib/libwrap.so.0 (0xf76a8000)
[Expert@MDS1:0]#

https://www.thegeekdiary.com/understanding-tcp-wrappers-in-linux/

I think if you wanted to use trusted hosts you would need to start sshd from xinetd instead of running sshd as its own daemon. Then you could prevent ssh hand shake of any kind of not passing tcp wrappers.

I will say your method is creative however.

[Simon_Macpherso]

My main concern is whether or not the below syntax for multiple hosts and networks is valid i.e. if it does not match on the first, it will proceed to the second and so on

e.g.

Match Address <ip address>/32

  PasswordAuthentication yes

Match Address <ip address>/24

  PasswordAuthentication yes

Match Address <ip address>/24

  PasswordAuthentication yes

Match Address <ip address>/24

  PasswordAuthentication yes

Match Address <ip address>/24

  PasswordAuthentication yes

I don't have out of band access to the management server and don't want to lock myself out. 

Regards,

Simon

[Yuri_Slobodyany]

I guess depends a lot on the issue/bug itself - is it an OpenSSH (by Checkpoint implementation) bug or Checkpoint component working WITH ssh bug ?

When you talk about "trusted hosts" - what do you mean? Where did you try to limit access to SSH ?

Their suggestion of setting authentication type per IP is quite exotic - haven't seen such one in production Linux system.  I do sometimes limit SSH access in sshd_config as a foolproof against someone misconfiguring security rules allowing ANY to ssh, but usually something like that is enough:

AllowUsers  admin@123.123.123.10 admin@10.88.88.*  yurisk

Taken from my post of 2011 and still working great 🙂 Two tips to secure SSH access from specific IPs to specific users in Checkpoint or any Linux 

[Simon_Macpherso]

Hello,

I dont think what I'm wanting to implement depends on the mentioned bug, which appears to be specific to R80.40. 

I said trusted clients, not hosts, i.e. limiting the access to the SMS from a specified list of hosts.

Adding the entry mentioned in my 2nd post above to  sshd_config worked, after also changing or removing the default authentication methods. 

Regards,

Simon

[cosmos]

I'm curious, does this R80.40 build ignore "add allowed-client host|network" entries in clish? I found R77.10 does, the hard way. Bumped a cluster up to 77.30 today (yes today, please don't ask) and thought I'd lost a member after the first reboot, because my client wasn't in the list. I'd hate to see a repeat...

No console either. Yay for field engineers and cprid_util 🙂

[Douglas_Rich]

Just installed R80.40 + Take 118 in AWS and this issue is still present.

This issue was present with a open sever vmware install on take 76 but is fixed after installing Take 118, but not fixed in AWS with the same Take.

The specific line  in "/etc/ssh/sshd_config" which seems to be the root cause is: "PasswordAuthentication yes"

"yes" is BAD!

===============

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes

===============

Change this to "no" and restart sshd "service sshd restart" and then the issue appears to go away.  Could be more to it, but this was the least single change that made a positive affect.