0

I seem to be getting a lot of different connections (ssh) on this Ubuntu server I am sshed into. Are these just brute force attempts?

When running netstat -tnpa | grep 'ESTABLISHED.*sshd' why do I get at end of each line "root@p" and "[accep" respectively?

Furthermore, when running grep sshd.\*Failed /var/log/auth.log | tail -20 I seem to get a lot of different "invalid users". Why is that so? Lastly, ps auxwww | grep sshd: outputs two "[accepted]". Why is that so?

Thank you

enter image description here

enter image description here

Update:

Another interesting thing happened now. I ran netstat -tnpa | grep 'ESTABLISHED.*sshd' again and an IP in the form "103.100.xxxx" from Hong Kong apparently was listed. I had then run cat /var/log/auth.log | tail -100 and gotten the following

Feb 16 17:58:25 838396123831 sshd[227710]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=103.100.210.xxx  user=root
Feb 16 17:58:26 838396123831 sshd[227708]: Received disconnect from 103.136.xxxxp ort 33268:11: Bye Bye [preauth]
Feb 16 17:58:26 838396123831 sshd[227708]: Disconnected from invalid user hero 103.136.xxxx port 33268 [preauth]
Feb 16 17:58:27 838396123831 sshd[227710]: Failed password for root from 103.100.xxxx port 40810 ssh2
Feb 16 17:58:27 838396123831 sshd[227710]: Received disconnect from 103.100.xxxx port 40810:11: Bye Bye [preauth]
Feb 16 17:58:27 838396123831 sshd[227710]: Disconnected from authenticating user root 103.100.xxxx port 40810 [preauth]

Then I ran grep sshd.\*Failed /var/log/auth.log | tail -20 and spotted Feb 16 18:00:42 838396123831 sshd[227760]: Failed password for invalid user ircbot from 103.136.xxxxx port 47546 ssh2

I then run grep sshd.\*Failed /var/log/auth.log | tail -100 and see


Feb 16 17:53:24 838396123831 sshd[227596]: Failed password for root from 103.136.xxxx port 33470 ssh2
Feb 16 17:55:57 838396123831 sshd[227652]: Failed password for root from 103.136.xxxxx port 47406 ssh2

Feb 16 17:58:24 838396123831 sshd[227708]: Failed password for invalid user hero from 103.136.xxxxx port 33268 ssh2 Feb 16 18:00:42 838396123831 sshd[227760]: Failed password for invalid user ircbot from 103.136.xxxxx port 47546 ssh2

What does this mean? What is happening? Was or is any other person managed to log in to the server via ssh? "Last" command does not list any other Ip addresses except mine so...

Yohan
  • 3
  • Thanks so much. That is what I suspected. One last question. If no one except me has managed to successfully ssh into my server why does netstat -tnpa | grep 'ESTABLISHED.*sshd' print more? What does the "root@p" and "[accep" for example mean? @Kusalananda – Yohan Feb 16 '21 at 18:28
  • The root user is the one running sshd, always, and it forks off a sshd for each established connection. If you have logged into this machine using SSH, then this is what I would expect to see. But I would leave it to some other Linux person to say for certiain that it looks ok (I'm not a Linux user, I run OpenBSD). – Kusalananda Feb 16 '21 at 18:33
  • Oh ok. If a user is running "ssh root@ipaddressofmyserver" then even if they fail to authenticate and log in, when they run that ssh command will netstat -tnpa | grep 'ESTABLISHED.*sshd' show them? – Yohan Feb 16 '21 at 18:38
  • And thanks for explaining "root@p" but what is "[accep" ? @Kusalananda – Yohan Feb 16 '21 at 18:39
  • I believe so, yes. Someone else may have to back me up on that. The p is actually pts/0, see your 2nd screenshot. You can also see the full string [accepted] there. – Kusalananda Feb 16 '21 at 18:40
  • Oh, thanks. Why "root@pts/0" and "[accept]" ? What is each for? How are they different? – Yohan Feb 16 '21 at 18:42
  • It's just a way that sshd lets you know what each instance of itself is for. The pts/0 one is the one that accepts incoming connections. The [accepted] is a sshd that has accepted an incoming connection (started for this purpose by the first one). Can't say much more than that I'm afraid. I'm sure there are other answers on this site that mentions these. – Kusalananda Feb 16 '21 at 18:46
  • "started for this purpose by the first one" - What first one are you referring to? – Yohan Feb 16 '21 at 18:49
  • The one marked pts/0, which is listening for connections. – Kusalananda Feb 16 '21 at 18:51
  • "pts" is a pseudo terminal right? How is it listening for connections? – Yohan Feb 16 '21 at 18:52
  • Nothing of this is in your actual question. – Kusalananda Feb 16 '21 at 18:57
  • Read man journalctl, sudo journalctl -b 0 $(type -p sshd) – waltinator Feb 16 '21 at 19:34
  • I read the manpage and understand it. How is sudo journalctl -b 0 $(type -p sshd) helpful though? What am I seeing? @waltinator I mean which question of mine are you answering by this – Yohan Feb 16 '21 at 20:08
  • Nothing of this is in your actual question. -- Yes, I know. This question came up in my head when you explained the full form of "root@p" and "[accep" , So how is pts/0 listening for connections if it is just a pseudo terminal? @Kusalananda – Yohan Feb 16 '21 at 20:09

1 Answers1

0

The netstat command is giving you what is happening within your Linux system. Firstly, your Linux server is directly exposed to the internet. Attackers will always try to guess the username and password to SSH service.

The most secure way to SSH into a Linux server is through VPN. This means that the SSH server will sit behind the VPN gateway and only accessible through VPN. But VPN is not always possible.

The easiest way to lock-down your SSH server is by editing the /etc/ssh/sshd_conf file. In this file, whitelist the users allowed to SSH. Source IP can be trick since some users are mobile, or their ISP is using dynamic IP

A better dynamic way to protect SSH is by installing fail2ban

  • Thanks. So the "ESTABLISHED" in the netstat command output does not mean another person has successfully sshd but that it was an in progress attempt? – Yohan Feb 17 '21 at 16:35
  • When anyone attempts to SSH into a server, a TCP three-way handshake must be completed first. The client will first send a TCP SYNC packet, server will respond with a TCP SYNC/ACK, then client will respond with a TCP ACK, and then a TCP connection is established. At this stage, no username or password have been sent yet. At this stage, netstat command will show that the connection is "ESTABLISHED". In other words, a connection must be "ESTABLISHED" before a legitimate user logs in or a rogue user attempts to brute-force. – Bruce Malaudzi Feb 17 '21 at 17:40