r/VPS • u/HailSatan0101 • Sep 17 '24
Seeking Advice/Support Is this a Brute Force Attack?
2 days ago I created a user with the username "test" and password "test". I forgot to delete it afterward, and when I logged in, I noticed my server slowing down. I checked htop and saw a process running and using 100% of the memory. The program was called "./Opera". It said that "test" was running this program. I quickly deleted the user, stopped the program, and changed my root password. Since then, there have been various attempts to log in to my root account. I set up fail2ban today with a rule to ban all IP addresses permanently after 2 failed attempts. This is the list of IPs that have been trying to log in. Is this normal?
7
u/arkane-linux Sep 17 '24
This is "normal", bots are constantly pounding SSH on internet accessible machines in an attempt to login to machines with poor easily guessed login creds.
Do not expose machines to the internet unless needed. Do not use poor login creds when they are internet accessible.
Nuke the machine, who know what other trash managed to infect it.
3
u/Uhhhhh55 Sep 17 '24
If your port 22 is forwarded, no. Bots probe common ports on IPv4 all day long. Use a VPN, don't forward common ports, it's generally considered a silly thing to do.
1
u/HailSatan0101 Sep 17 '24
I forgot to mention this is a VPS server not my private machine
1
u/slate_ways Sep 17 '24 edited Sep 17 '24
This is pretty „common“. Just a lot of Bots out there scanning for open common Ports. As u/InfamousAgency6784 said, you don’t know what else the attacker did. You should consider to clean reinstall
2
u/hexaq2 Sep 17 '24
I translate (NAT) my SSH 22 port to a port around 10000-20000 range, i.e. something like 13432 for external use. Never had any hit on my SSH fail2ban in over 5 years.
2
u/dovi5988 Sep 18 '24
Not a question of if but a question of when they will come knocking. Put your IP in shodan and see what comes up.
1
u/Uhhhhh55 Sep 17 '24
My VPS has a firewall. If yours doesn't, I encourage you to explore you options
1
u/_vercingtorix_ Sep 18 '24
You can still have vpn.
install like openvpn server on the vps, get client keys over to a jump box on your local net, and then lock ssh down on all non vpn interfaces.
3
u/Alex0789 Sep 17 '24
A lot of these IPs are indeed involved in botnets, etc. https://prowl.lupovis.io/?ip=58.19.246.172 https://prowl.lupovis.io/?ip=107.189.255.179 https://prowl.lupovis.io/?ip=14.33.96.3
I checked a couple random, all came back malicious, but 76 IPs is not a DDOS unless they all do thousands of requests. You only got 169 requests, that's maybe twice or three times the number of IPs there.
2
u/rowneyo Sep 18 '24
You need to make some changes 1. Change your ssh port from the default 2. Disable password login 3. Disable root login via ssh 4. Enable passwordless ssh login via ssh key
1
u/RadiantLimes Sep 19 '24
Honestly I thought this was just standard practice for everyone running Linux servers but I guess not as seen above.
1
Sep 19 '24
[deleted]
1
u/Zorbithia Selfhost Sep 19 '24
In September 2024 if you aren't setting a non-default port for SSH then you are just asking for more annoyances/headaches (at a minimum...and potentially problems) than you would otherwise have to deal with. It's not something any competent sysadmin is doing, that's for sure.
1
u/dherhsc Sep 19 '24
I was under the impression that switching the ports from default for standard services was a bad idea. Is this only true for things like port 80 & 443 since outside services truly need to communicate with your machine? I know with ssh absolutely no one outside myself & my team should be using it.
Does it just mean that configuration becomes more complex? (in the sense that you have to pick a different port for every machine you access)
I got this impression from professormesser when studying form my A+ cert. My first thought was to change the default ports, but he immediately said I was wrong.
Note: I don't have any systems that you can ssh into via internet. Only local.
1
u/MurderShovel Sep 17 '24
It’s just normal scans. If you expose most common ports, people will be scanning for vulns in whatever is running on it. 3389 for RDP and 22 for SSH should typically at least be changed or even better locked behind a VPN. Harder to do with 80 or 443 if you’re running web servers other than keep it patched.
1
u/Zophirel Sep 18 '24 edited Sep 18 '24
Hi I'm a bit of a noob with cybersec, can you explain how the VPN protects the access to the ssh? Is the idea to connect the vps to a VPN and do the same thing with the client in order to share the "same" network or am i missing something? What would happen to websites hosted on the vps? Would they still be accessible through the VPS IP / domain or the VPN IP has to be used?
1
u/MurderShovel Sep 19 '24
You’re pretty close. The idea is that you are exposing as little attack surface as possible, in your case ports. Every port on your firewall should be closed except the ones you absolutely have to have open. If you leave 22 exposed for SSH to the whole internet, people will run through the entire IP space to see if you are running a vulnerable version of SSH or maybe just use weak passwords or default passwords.
With the VPN, you expose only the VPN port which typically has better security. Once you are “inside” the first wall using the VPN, you can access services like SSH which still have their own security.
It’s layers of security. Not only do you have to get past the VPN, you ALSO have to get past SSH. Harder than just SSH alone. Or adding rules to only allow access from your IP range. Another layer.
As far as running a web server, 443 is the default for HTTPS. Unless you want users to enter a different port, which is clunky, you have to expose it if you want it publicly accessible. The trick there is keeping your web server updated, patched, configured correctly, and secured.
1
u/legrenabeach Sep 17 '24
Excluding the whole test account whoopsie, I get that from time to time. I have set fail2ban on all my internet-exposed services to ban after 3 attempts, and for those services that are proxied via cloudflare, to ban the IP on cloudflare itself. I get waves of such attempted attacks, but with ssh keys and 3-strikes-ban, they don't get very far.
1
u/HailSatan0101 Sep 17 '24
Glad to see im not the only one.
1
u/legrenabeach Sep 17 '24
Not at all. Sometimes the attacks I get last for weeks on end. Then they suddenly stop, only to come back a few weeks or months later.
1
u/HailSatan0101 Sep 17 '24
Interesting. Well, I have a pretty strong password, so I should be safe.
1
1
u/Fmatias Sep 17 '24
Well, having a public IP means you will always have constant sniffing attempts to log in which is one of the reasons why you should not expose anything to the internet if you don’t have to. In your case it is made worse by the fact that you had the test account and that VPS is already compromised. Just destroy it and redeploy as fast as you can
1
u/Sky_Linx Sep 17 '24
Throw the box and rebuild. I really wonder what went into your mind when you created a user with those credentials in a server exposed to the Internet...
1
u/HailSatan0101 Sep 17 '24
The "test" user was not in the sudo group. I created it to carry out some tests and forgot to delete it.
The actor didn't carry out any other attacks. My guess is that the software he downloaded was for crypto mining.
What was interesting is that when I deleted the user and the software he was using, the software that was running stopped.
I created the user named test again with the password test, trying to trap the attacker and grab more details if he tries to connect. Interestingly, 10 seconds after I created the user, someone connected and started the software again. I have done a thorough cleanup of the server and deleted all users except the one I have, which is protected with a strong password.
2
u/Sky_Linx Sep 17 '24
Sorry to break it to you, but there are ways and conditions to escalate to root if the box and its contents are not secured properly.
1
u/HailSatan0101 Sep 17 '24
I am aware of privilege escalation.
The reason I created the user was to test privilege escalation on my server.
1
u/dovi5988 Sep 18 '24
There is no way of knowing if they are truly gone. I would burn the VPS and rebuild using a firewall only allowing your own IPs.
1
u/Modowok Sep 17 '24
i just heard of fail2ban today, since u put it at 2 failed attempts, then wouldn't that mean if you yourself messed up one day you'll be banned too? what would happen then?
2
u/HailSatan0101 Sep 17 '24
You could access it from your phone or another PC and just unban your IP.
1
u/dovi5988 Sep 18 '24
You can set a jail time so after X amount of time it's unbanned. In addition you can exclude known hours such as your VPN.
0
1
u/fellipec Sep 18 '24
It's pretty normal to bots try to brute force SSH machines on internet.
What should not be normal is people leaving machines exposed with password auth and insecure passwords. The bots are looking for that and they will find.
Now that your machine was compromised, you can't trust it anymore, who can assure there are no backdoors of any kind left on it?
1
u/rob94708 Sep 18 '24 edited Sep 18 '24
Using “test” as a password for test accounts is, well, a habit it would be best to break. Start using fully random unique passwords even for throwaways and you’ll save yourself a lot of future grief.
1
u/brunodevs Sep 18 '24
It is likely that it is some botnet trying to scan vulnerable hosts from zmap, there is a range of scripts that bruteforce to gain access to the VPS and infect in order to enhance the botnet.
1
1
u/sneycampos Sep 18 '24
You can configure you ssh to only allow via pub key and for your ip. take a look at tailscale
1
u/Playful-Order3555 Sep 18 '24
Use key based auth and disable password authentication entirely, this situation will never happen if you do that going forward
1
1
1
u/aamfk Sep 19 '24
Yeah why would you bring up a server without fail2ban in the first place ?
Rebuild the server.
14
u/InfamousAgency6784 Sep 17 '24
Redeploy. You obviously don't have anything in place to make sure the attack stopped there (though it is very likely, hence why the attacker just used the normal user to mine crypto or whatever).
General attempts against SSH are common and probably not connected at all. If anything, if you got those figures over more than an hour, you've probably not been singled out.
In the future, just move to (hardware or password-encryted) SSH keys and disable password authentication. With that setup, fail2ban becomes much less relevant and with recent SSH versions, fail2ban becomes obsolete when SSH does not accept passwords.