2

I got this log entry chain (and similar repeatedly) on my server:

Nov 24 07:38:59 server sshd[28676]: SSH: Server;Ltype: Version;Remote: 54.38.81.12-40482;Protocol: 2.0;Client: OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
Nov 24 07:38:59 server sshd[28676]: SSH: Server;Ltype: Kex;Remote: 54.38.81.12-40482;Enc: aes128-cbc;MAC: umac-64-etm@openssh.com;Comp: none [preauth]
Nov 24 07:39:00 server sshd[28676]: SSH: Server;Ltype: Authname;Remote: 54.38.81.12-40482;Name: anonymous [preauth]
Nov 24 07:39:00 server sshd[28676]: Accepted none for anonymous from 54.38.81.12 port 40482 ssh2
Nov 24 07:39:01 server sshd[28681]: refused local port forward: originator 127.0.0.1 port 46338, target 167.114.159.146 port 80
Nov 24 07:39:01 server sshd[28681]: refused local port forward: originator 127.0.0.1 port 47552, target 167.114.159.146 port 80
...
Nov 24 07:39:19 server sshd[28681]: Disconnected from 54.38.81.12

I’m pretty sure this was a hacking attack but how to tell if it was successful? Especially unclear is the “Accepted none for anonymous” message. Does it mean that I’ve got a user account named anonymous that is allowed to log in with no password and the hacker logged in as anonymous and tried to forward some local ports (and there may be some that were forwarded successfully so they didn’t get logged)?

Tried to log in as anonymous in a standard way from local network (ssh anonymous@server) but got a permission denied message.

If I’ve not been hacked, how do I protect against this kind of attack? Already installed fail2ban because of other suspicious log entries but this happened after the installation.

Edit 1:

Checked the /etc/ssh/sshd_config file and found that PermitEmptyPasswords was set to no. So that should be OK.

Edit 2:

I’m not experienced with the /proc file system but this is what I discovered:

user@server:~$ sudo file /proc/5931/exe
/proc/5931/exe: broken symbolic link to /usr/bin/sshd
user@server:~$ sudo which sshd
/usr/sbin/sshd

OK, the file utility says it’s a broken symbolic link but if I try sudo hexdump /proc/5931/exe I get data. Is that normal?

Edit 3:

Now I know what’s the reason of Edit 2. I mix two systems together. I run a chrooted Debian Stretch on a Synology NAS. And there are processes from both that Debian and the Synology DSM in the /proc file system. Each of the systems has another location of the sshd executable.

Edit 4:

This is what less /proc/*/cmdline shows:

/usr/bin/sshd^@
sshd: user [priv]
sshd: user@pts/4^@
/usr/sbin/sshd^@
sshd: user [priv]
sshd: user@pts/3^@

Edit 5:

I know that what’s shown here isn’t the suspicious login itself. (Replace user with my user name (thoroughly anonymized that output).) The problem is that I’d need to catch the process while the anonymous user is logged in. He suddenly disconnects so I can’t watch the process live. How do I forge a trap so I could react to the anonymous user login?

Realized that the user anonymous is present only on the Synology DSM system. Is it possible that the logs from the DSM system are written also to the chrooted Debian? Tried to disable the FTP and SFTP services because that user belongs to the ftp group but the user remains there. There’s neither a passwd nor a usermod command on the DSM system so I’m not sure how to disable access for that user. anonymous has his shell set to /sbin/nologin so it should not even be possible to log in via SSH and try port forwards.

Edit 6:

Examined the SSH config on the Synology DSM system. Well, there were some settings I changed:

#PermitEmptyPasswords no -> uncommented

# allow the use of the none cipher
#NoneEnabled no # uncommented
  • 1
    linuxquestions.org/questions/linux-newbie-8/… indicates that PermitEmptyPasswords might possibly be related to the "accepted none". The default for that according to the man page on my system is no and that's likely what you'd want. – a CVn Nov 24 '18 at 13:49
  • Assuming Linux for a second, check /proc/28681, particularly the target of /proc/28681/exe and the contents of /proc/28681/cmdline (or whichever PID is currently in fashion on your system), as well as thoroughly review your sshd_config and authentication stores in use. Edit your question to indicate your findings. You may have had a breach bad enough that someone got root, and if you have, then nothing you do on that system can be trusted. – a CVn Nov 24 '18 at 13:49
  • Edited the question to reflect my findings. – Cigydd Nov 25 '18 at 6:33
  • What you show doesn't immediately stand out to me as horrible, which only makes this more curious. – a CVn Nov 25 '18 at 11:54
  • Edited again to add info on the anonymous user and the Synology DSM. – Cigydd Nov 26 '18 at 17:33
0

Edit 6 seems to have solved the issue (at least such kind of attack logs disappeared):

Examined the SSH config on the Synology DSM system. Well, there were some settings I changed:

#PermitEmptyPasswords no -> uncommented

# allow the use of the none cipher
#NoneEnabled no # uncommented

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.