sonic-net / sonic-buildimage

Scripts which perform an installable binary image build for SONiC
Other
707 stars 1.35k forks source link

[security] SSH server should not listen on all interfaces #13575

Open jusherma opened 1 year ago

jusherma commented 1 year ago

Description

SONiC's SSH daemon is configured to listen on all interfaces, including those meant to pass routed traffic. It also allows 10 concurrent unauthenticated sessions before it begins rejecting some subsequent connections (30%). At 100 concurrent unauthenticated sessions, sshd rejects all subsequent connections.

MaxStartups 10:30:100

If an attacker makes malicious connections to the SSH server, it can consume all available SSH sessions (even without needing to authenticate), locking legitimate users out of using SSH.

Steps to reproduce the issue:

Run these commands in parallel, where 172.31.0.2 is the IP assigned to Ethernet0 of the SONiC router and 172.31.0.6 is an unassigned IP address

arpspoof -i eth1 -t 172.31.0.2 172.31.0.6 > /tmp/arpspoof 2>&1 &
srvr -SAa -i eth1 172.31.0.6 > /tmp/srvr 2>&1 &
hping3 172.31.0.2 -p 22 -S -a 172.31.0.6 -i u10000 -q

Describe the results you received:

$ sudo tail /var/log/auth.log
Dec  3 00:46:29.495668 sonic ERR sshd[600]: error: beginning MaxStartups throttling
Dec  3 00:46:29.495874 sonic INFO sshd[600]: drop connection #13 from [172.31.0.6]:1860 on [172.31.0.2]:22 past MaxStartups

# Legitimate users are locked out now
$ ssh -v cisco@172.31.0.2
OpenSSH_8.7p1 Debian-4, OpenSSL 1.1.1m  14 Dec 2021
...
debug1: kex_exchange_identification: banner line 0: Exceeded MaxStartups
kex_exchange_identification: Connection closed by remote host
Connection closed by 172.31.0.2 port 22

Describe the results you expected:

Attackers should not be able to flood the SSH server with unauthenticated sessions via routed interfaces.

Suggested Mitigation Steps

  1. Configure the SSH daemon to only listen on the management interface by default to reduce attack surface
  2. Implement fail2ban to reject SSH connections from malicious/abusive clients
  3. Reduce the LoginGraceTime configuration parameter to minimize the impact of successful DoS attacks
gechiang commented 1 year ago

@qiluo-msft please help consider the suggestion (2 and 3) as 1 is some thing we can not do as we need inband connection in some deployment that has no mgmt interface

qiluo-msft commented 1 year ago

I would like to argue that "Implement fail2ban to reject SSH connections from malicious/abusive clients" may be not necessary. We could reject SSH connection by AAA server.

@liuh-80 to check possibility of "Reduce the LoginGraceTime".

liuh-80 commented 1 year ago

Currently sonic are using the default value for 'LoginGraceTime', which is 120 second. Reduce the default value will have risk to break some existing pipelines.