Hello everybody, I have an epidemic. Just recently I have found out there has been an attacker trying to get into my self hosted web server.The first instance of this happened on May 10th, of which the attacker tried unsuccessfully to log in as root over ssh. Luckily I had the root account disabled from ssh, and fail2ban banned the attacker's ip address after 4 failed attempts.

The 2nd instance happened today (May 26th) around 6 pm local time. This time trying multiple user names. If one user name and password didn't work , then the attacker would move on to the next common user name.

I know for a fact, that this person is using a vpn/proxy as the person's ip address was different on the 2nd attempt.

I am not too sure how to thwart off an attack like this, nor am I sure what will happen next. So far, the steps I have taken is to turn disable ssh for now, until I can think of another port to put it on.

What actions should/can I take to thwart off this attacker? Will it be safe to wait before I re-forward a brand new ssh port?

Some helpful information: My server is port forwarded through the home router, and only a select few of ports are forwarded to the outside world. Also my web server does not use the default ssh port, instead I was using a custom ssh port number.

It's probably not a person or at least not directly. You have remote root access disabled, that is excellent. Also be sure to use keys for all the other accounts and disable password authentication. Then they can't get in without both one of your keys and its passphrase. Lastly continue to do as you are doing with either fail2ban or sshguard.

Here is some reading on what is probably going on:

https://bsdly.blogspot.com/2013/10/t...s-learned.html
https://bsdly.blogspot.com/2012/04/i...n-seconds.html

https://bsdly.blogspot.com/2013/02/t...igh-ports.html

https://bsdly.blogspot.com/2009/04/s...-are-back.html

tldr; if it's visible on the net, bots are going to be jiggling the doorknobs all the time

1 members found this post helpful.

then how can you know that this is the same person?

fwiw, i have the same setup as you down to non-standard port and fail2ban, so i have an interest in this.
can't say i've had similar problems though.
if you don't use ssh keys, now is the time to start using them (well actually you should've used them from the very start).

1 members found this post helpful.

Make sure you pay attention to the warnings about changes to the server's public key. If you get a warning like this, say "no" and check the public key fingerprint through out-of-band means; don't say "yes" unless you have verified the public key fingerprint somehow.

Just asking, but what is so special about a break-in attempt? On all publicly available servers I run my auth.log is thousands of lines long with SSH and SMTP attacks. 24/7. Most are scripts, because it is mostly the same pattern which is used. The root user with a variety of passwords, and then a list of user names in alphabetic order.

It seems logical, if you have an open port, access is attempted.

I am not sure if disabling SSH root access is useful. If I can log in, I am sudoer. However, I log in using key authentication, and for the sudo command a cracker needs my password in addition. That is a security step over just root access.

So I have root access disabled, and SSH only through key authentication.

On some servers I run fail2ban, which is IMHO an excellent tool for repeated break-in attempts. But it is a nuisance on mail servers. If there is just one user on the network making a mistake with the password and periodic mail check is enabled, fail2ban simply stops all mail traffic for the network until you have found the culprit.

Changing the SSH port is also a good idea. It does not provide any additional security. But many cracking scripts only try port 22. So you reduce the number of attacks. Not more, not less.

jlinkels

[citation needed]

The scripts seem to find me on whichever port I have. I've found that turning of password authentication makes more of a difference and that the scripts mostly give up then. I still get occasional probes but not the 1000s of login attempts like when passwords are turned on.

probably he meant that is the default port and that's why it is tried first/most.

Was not mentioned (or just I missed) there is a port-knocking feature, see here: https://linux.die.net/man/1/knockd - if you wish.

Agreed. And I also tried to point out that using a different port is not offering better protection. They find you, but hopefully less often.

jlinkels

What I also should add is that some people are in favor of closing SSH on the external IP address completely and only use a VPN to connect over SSH. That makes breaking in over SSH impossible as SSH is no longer exposed to the outside world.

jlinkels

Thank you, all of you for your advice. I know that it isn't a big deal to begin with, but this was my first time ever seeing something like this occurring on my self hosted web server. So far I have changed the ssh port I was previously using (2220), and I will monitor my ssh/fail2ban logs in case anything else happens. I'll also research how to implement these "Anti-Bruteforce Rules" from this article. As this seems like it will be a good layer to add to my server.

Turbocapitalist thanks for those articles, it seems to be exactly what I was facing with. Sometime later today I will implement ssh keys and disable password authentication. I have also been thinking about two factor authentication through ssh as a possible secondary solution. That vpn idea also sound very interesting, as well as elimination of any known threats.

And you guys are right, I don't know if this is the same person, or simply a script-kiddy/bot. I just assumed it was the same person, but at the end of the day I'll never know.

^ you haven't mentioned keys.
you really, really need to use ssh keys. forget about 2FA, that's overthinking.