Solved I see many ESTABLISHED connections from one IP to my ssh (port 22) without authentication. Is this a new attack on ssh that I am not aware off?

B

bigbrother

I noticed that on my public ssh server at port 22, I see a large number of ssh ESTABLISHED connections, that do not authenticate and stay in the ETABLISHED state sending keep alives.
Specifically, in the nestat I see many entries of the form:

tcp4 12 0 myIP:.22 156.0.96.22.52574 ESTABLISHED
(many similar lines with different foreign IP ports)
there are near 200 as wc -l showed.


while in the /var/log/auth.log only the following:
Sep 14 10:59:18 zafora sshd[35994]: Connection from 156.0.96.22 port 56876 on myIP port 22
Sep 14 10:59:19 zafora sshd[35994]: Connection closed by authenticating user root 156.0.96.22 port 56876 [preauth]

in tcpdump I see many keep alive packets to keep the connection open from that IP

11:11:54.904130 IP 156.0.96.22.49533 > myIP.22: Flags [.], seq 2648994253:2648994254, ack 3798949150, win 258, length 1
11:11:54.904279 IP myIP.22 > 156.0.96.22.49533: Flags [.], ack 1, win 1027, options [nop,nop,sack 1 {0:1}], length 0

There are no strange processes, nothing else for that IP in nestat. No user login.

The large number of established connections made the connection to port 22 hang from another host and normal users were not able to connect.
The connection hand while waiting for the remote protocol version. Even from the same host if I did 'ssh localhost' I was not able to connect.

I have added the following rules to mitigate the problem on my firewall:

$fwcmd add allow tcp from any to me 22 in via $oif setup limit src-addr 10
$fwcmd add deny tcp from any to me 22 in via $oif setup

(oif is the external interface and fwcmd is a function for processing and executing the firewall commands using ipfw).


Unless the purpose is to cause resource exhaustion on my server, I cannot understand the meaning of this.

This foreign IP is not on my local LAN, it is from a differnet condinent.


What you do in such cases? Just ipfw deny ?
 
bigbrother said:
public ssh server
Click to expand...
Ask yourself if you really need this. If you answer yes you should be using strong key based authentication like ed25519.
Also moving off port 22 will save you some log space.

It's 2023. You Should Be Using an Ed25519 SSH Key (And Other Current Best Practices) - Brandon Checketts

I often have to ask other IT professionals for the Public SSH key for access to a server or for other tasks. I really cringe when they ask me what that is or how to create one. I kindof cringe when they give me one from PuttyGen in its native format. I feel a little […]
www.brandonchecketts.com
 
This is a public SSH server for many students so they connect from wherever the are without using any VPN.

For that past 15 years there were no serious problems (there is fail2ban in place) . But I keep an eye every day to spot strange behavior.
By default it accepts passwords or RSA/ED25519 keys. Its up to the users to decide what to use.
 
Wasn't there recently a hack where one would let the sshd timeout during login, and then try to exploit some race happening due to that timeout?
Should be fixed by now, but maybe somebody is trying...
 
There is a fix but it dont work so well and has to be disabled in some cases. Causing very long login times and poor overall SSH/SCP performance. SSH-Forwarding takes a hit too.
 
PMc said:
Wasn't there recently a hack where one would let the sshd timeout during login, and then try to exploit some race happening due to that timeout?
Should be fixed by now, but maybe somebody is trying...
Click to expand...
You have mentioned this advisory https://www.freebsd.org/security/advisories/FreeBSD-SA-24:08.openssh.asc
As I have understood researchers have a working PoC on 32 architecture and it takes about 10 hours to exploit.
There was no working PoC for 64 architecture for that time and possibility of success was much less then on 32 architecture.

What about large number of established connections - it can be different scanners like nmap, which try to determent ssh version (without login attempt)
 
Thanks for the info, do you have any suggestion for parameters in /etc/ssh/sshd_config for better security even for latest version of sshd running on 22 public accessible? The advisory suggested LoginGraceTime=0 What about
others like:

channeltimeout global=60
ClientAliveInterval 30
ClientAliveCountMax 3
 
bigbrother said:
Thanks for the info, do you have any suggestion for parameters in /etc/ssh/sshd_config for better security even for latest version of sshd running on 22 public accessible? The advisory suggested LoginGraceTime=0
Click to expand...
No, that is a workaround. It doesn't improve things, and after sshd got patched, is has no benefit.
 
You must log in or register to reply here.
Back
Top