New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Anybody else this popular?
jaypeesmith
Member
I just built this VPS today and look what greeted me on my first login:
There were 762 failed login attempts since the last successful login.
At least they failed, right?
Comments
What about the 600 successful attempts?
Probably an old client that had the same IP and is like "Fuck, but I'm 100% sure that this is the right password"
@cassa This already happened to me as well when I cancelled a VPS and tried to connect later cauz I forgot it's not mine anymore. But for sure not 700 times..
This happens regularly on Online.net servers.
Just change the SSH port and use fail2ban / denyhosts or SSH keys.
Yeah happened to me with my Online.net box lol.
I always change the SSH port anyway though.
How long was the interval between when the VPS was first configured/booted and when you logged in? Could it be the usual frequent brute force attempts on port 22 at the IP address your new VPS uses?
In case it matters, I have seen large numbers (hundreds) of failed login attempts in just a few hours on my home computers, with IP addresses provided by the ISP (DHCP).
As Nekki points out, if the successful login attempts on your first login is greater than 1, then you have a problem.
I just disable root's password over ssh altogether. No point in messing with changing ports when it doesnt take long to scan a range of ports for the right one.
On most of my Boxes I tend to firewall SSH to a few trusted IP's only unless I have no other choice.
No root login, fail2ban, and rigorous sshd config seems to work on my mail server. Fail2ban cut it down from several attempts per second to less than a dozen per hour. It never stops though.
sshd_config:
@jaypeesmith Could you list a few of the IPs? Just a hunch..
All good suggestions, but @jaypeesmith said that this was the first login after creating the VPS. If @jaypeesmith is a typical VPS customer, then he/she must login once to change the configuration to include all those excellent recommendations.
It reminds me of the days when consumers would install a fresh Windows computer, but it would be infected with malware before they could finish downloading the updates and patches from Microsoft. I wonder whether that still happens now?
I am not saying that @Jaypeesmith's VPS is infected with malware, but it is known that VPSs are subjected to brute force login attempts the instant they are created. Hopefully the templates create sufficiently random passwords when the VPSs are instantiated so that they thwart these crude attempts.
Hmmm! It happens.
(Logit attempts by various means)
I have had my dedi colocated for 40 days. In that time I've had about 130k failed logon attempts. After that i installed fail2ban and changed shh port. I had disabled root login from beginning.
Happened to me on my Online.net/OneProvider Server as well.
Absolutely! It wasn't anything that really instilled fear in me. It was more a situation of me wondering if this has to do with certain networks/IP ranges being more popular and thus being more of a target for these types of attempts.
But, nonetheless, there are many good suggestions here.
With only 6 character reasonable random password out of set 64 and fail2ban set to 1hr, it would take 1 million computers 954 days for full brute force attack.
64 ^ 6 / 3 attempts / 1mil IPs / 24hrs = 954.44 days
Now, everyone has longer password than 6 characters (right?) and anyone with resources to procure 1mil IP does not need to hack low end VPSs
aaaaaaand this is where IPv6 works.
Anyone with 1mil failed login attempts per hour, and lets' it go for 954 days, deserves to get hacked
Use ssh keys, change port.
I just use ssh keys and then change the port so my auth log isn't filled with a bunch of failed attempts.
In general, I doubt that one IP range is targeted more than others that are used for the same purpose (in your case, VPSs). Many attacks are random.
Some attackers can and do apply different strategies based on how the targeted IP range is being used, which they can easily determine. Is it home users? Mobile phones? Web hosting or other similar servers?
Does the IP address range belong to a high value target, such as a financial institution, a government agency, a defense contractor, a firm with high value data, personal data, or valuable intellectual property? They are attacked in much greater numbers by fools and script kiddies, but they are also the focus of carefully planned advanced persistent threats, too.
I once got a brand new DO droplet, left it unattended for about a week as was on holiday and as soon as I logged in as root, it turned out that there were several thousand failed login attempts and that somehow caused a kernel panic? After about 7 hours DO managed to fix my droplet and now working as expected.
Exactly. There seem to be a huge list of servers utilizing ipv6 along with cloudflare proxies to brute force servers. My WordPress site was getting too much attention that I had to implement this: http://blog.droidzone.in/2015/05/30/block-cloudflare-ips/
I had to block the entire allocation of ipv4 blocks used by cloudflare. Attacks have dropped to zero from a few every 20 minutes. The irony is that all my sites utilize cloudflare.
Bruteforce, got to love them.
I have a dedicated honeypot for bruteforces, quite amusing to watch them.
As per cloudflare, just drop these IPs:
103.21.244.0/22
103.22.200.0/22
103.31.4.0/22
104.16.0.0/12
108.162.192.0/18
141.101.64.0/18
162.158.0.0/15
172.64.0.0/13
173.245.48.0/20
188.114.96.0/20
190.93.240.0/20
197.234.240.0/22
198.41.128.0/17
199.27.128.0/21
That's what the script does.
@KwiceroLTD would you mind sharing some more information about your honeypot? Sounds interesting!
Yep, that is probably correct. If you have a VPS connected to the internet you will get continual hack attempts. It is the nature of the web. Just have a very strong password and restrict IP address access if you can.
Everybody is making great suggestions about what the end customer should do to secure their VPS after they login for the first time, however the case we are discussing is that the VPS falls under attack the instant it is created, before the customer has a chance to login for the first time.
A VPS is initialized with the chosen operating system and then it boots up. It is on the public Internet, accessible by all. It is subjected to attacks. At some later point in time, the customer logs in using a root or Administrator account. That time could be a few seconds later, or a much longer period, who knows?
OPENVZ:
Some VPSs start with OpenVZ templates running various distros of Linux. They are installed with an unknown default root password. The customer uses SolusVM or another control panel to change the VPS's root password so they can get in.
Is the unknown default root password truly random (before the customer changes it in the control panel)? Does it change every time the customer wipes the VPS and creates a new installation? Is it the same every time? Is it the same for all copies of the OpenVZ template that is used? As an end customer, I do not know how it works. You can bet that I am quick to change the password after I install a new VPS OpenVZ template. The question I have is: Can an attacker exploit the default root password on a new OpenVZ OS installation before the customer has time to change it in the SolusVM (or other) VPS control panel?
Furthermore, providers do not always keep up with OpenVZ template updates. Whether or not they do, the VPS may have other vulnerabilities that can be exploited by attackers until it is patched. (I am referring to vulnerabilities that are not related to a brute force attack on port 22.)
KVM:
A few KVM providers offer templates of preconfigured installations, where the customer supplies a root password at initialization time. If you use those KVM templates, your VPS may still be subject to some the same issues that apply to an OpenVZ template, above, other than default root password.
In most KVM cases, the customer installs from a .iso disk image of the operating system installer CD or DVD. The real vulnerability here is that the customer uses an unencrypted VNC connection to control the VPS during installation. An attacker playing man-in-the-middle can see those communications, including the passwords that the customer creates during the OS installation process. It is up to the customer to go back and change the root / Administrator passwords using a secure connection to the VPS after the installation is complete and the VPS has been rebooted. Until then, the VPS is still vulnerable if an outside party has been watching or recording the communications during OS installation.
Furthermore, the .iso images may not be the latest versions of the OS installers. They may have unpatched vulnerabilities, and it is incumbent upon the customer to update their VPS with the latest OS patches after installation. Of course, it is important to keep your VPS patched and updated as a routine part of system administration.
I hope these comments clarify some of my thinking about new VPS installation security issues.