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.
Comments
A powered-off VPS would not in any way register on our anti-abuse system, and never has over the entire course of the automated program.
Had similar problem (but not with VirMach): My vps was frequently turned off due to "excessive resources use". Funny thing, web-control panel showed just normal cpu/disc/network load, corresponding to idle vps. So either this resource-use peak was extremely short (so control panel could not catch it) or it was some kind of "mystery load".
It was empty updated debian netinstall, with everything turned off. I even stopped sshd and crond (as the very last remaining services) and used web-interface to log in. There was really nothing running, just kernel related things (cpu/memory/io scheduler, etc). Still "excessive use of resources". And what's worse, provider used some kind of script checking it, and it powered down vps immediatelly, without checking what actually was causing it. They could not even tell me if it was cpu, disc or network load. With no top/iotop/atop screenshot, what is owner supposed to do? The only thing: cancel vps and move elsewhere...
not trying to derail the topic, but for anyone else who has the same issue of attackers trying to get into via SSH and spiking resource usage(if you check your logs, they likely are),
The first thing you need to do is change the SSH port, it will reduce 99.9% of the bots that are trying common passwords sometimes at the rate of 1000 per second or more (don't take a word from people harping about why security isn't about obscurity, since we are solving a different problem here).
Then ensure you use key based access and disable password access.
finally, Install fail2ban
This isn't limited to Virmach but to a lot of other hosts as well, The hosts could either provide the templates with the above or do what bigger hosts do, i.e, have a mechanism to throttle CPU usage and only provide the CPU that the customer has been allotted.
For me it feels like giving extra disk space for free and then complaining about the user actually using it.
That's too many steps for people who leave their servers idling all the time. Just installing fail2ban should work.
@VirMach - soon 4 days on ticket without response. How long is a normal waiting time for a ticket regarding the manual change of an operating system (Windows) which actually existed as an automated install when the service was initially purchased? #759579
Just to add onto this, Fail2Ban can go completely berserk on default settings, relative to the resources on a smaller package. It should be optimized to utilize a lower amount of resources or it can actually end up causing high CPU and I/O usage by itself.
So if you change the SSH port, the issue with that is reduced but there are a lot of other ports people scan.
Windows re-install/installs are on hold. We're trying to do them in bulk but basically, we want to strip the license from our image and have a new trial template up for re-installs as it'll make it faster for us to process them. I'll admit it dragged out longer than we thought so we might have to just proceed with the ISO mounts instead (it's just more time-consuming because we have to also install virtio network/disk drivers or it'll take a performance hit.)
I keep SSH on port 22, but password authentication is disabled during the first minute.
If I can install from ISO, root login is disabled too. Otherwise, I don't bother with that.
Recently I deployed UFW and I'm seeing 100 port scan packets every hour.
I don't have fail2ban yet as there's no attack so far.
@VirMach
Also got the same email today. My vps has keyhelp installed for over a year now. It's semi idling. Just use it for mail, incoming only since Virmach blocked port 25 and I dont use it to send anyway.
Says I use too much cpu when my keyhelp barely uses anything
https://imgur.com/a/WzsVr7v
Unfortunately keyhelp devs say to keep things as is since they have safeguards placed.
Before I installed keyhelp i did the standard sop but after it installed it reverted back ssh to default port, etc
@Ympker @v3ng @Tony40
I had that happen to me with a Debian netinstall as well. I was able to log on and verify, there was a memory leak which led to severe swapping and eventually high CPU usage.
They're not just randomly sending out warnings, their script is legit and they are clearly detecting something. I have more VPS with VirMach than I'd care to admit, and I have no trouble using them normally. The few people repeatedly trying to shit on them here on LET are incredibly transparent, and incredibly pathetic. I'm sure problems can arise now and again, as with any provider, but overall VirMach is solid.
I can faintly hear OP's world crumbling from afar.
The only thing to add is to make sure you configure and test fail2ban. The defaults may or may not be correct (e.g., openvz needing modified firewall command, etc) or even be enabled for ssh.
That shows very little. You need monitoring for like a week.
Forest and trees.
Thank you!
Anyway to reliably monitor this please? Would appreciate advice from ppl here.
New relic, nodequery, PRTG, etc.
Virmach did the same to my VPS and didn't inform me that they had suspended my VPS. SOmetimes I only found out when I tried to login to it. If you actually try to use your Virmach VPS they suspend it. Total waste of time. Avoid.
This sound strange to me, as I always had the best experience with VirMach. I just noticed a few times my vps was re-started when checking uptime, but that is no big problem for me, if downtime is just a few minutes. Honestly, I even prefer they do not bother me with emails in such cases :-)
What about you set a weak password and your vps got compromised ?
Your suggestion to change the port is good advice to avoid log noise from automated brute force attempts. However, even without this I suspect it is highly unlikely that alone would result in resource consumption issues for most people and providers.
Perhaps there are many IP addresses assigned to a small resource system or a system comes under some sort abnormal targeted SSH dictionary attack from multiple simultaneous bots? Those situations should be rare.
I'd be interested to see evidence that SSH brute force attempts alone resulted in service usage usage problems or suspension. I've never seen that be an issue at virmach or anywhere else.
Best advice - just eat the cost and move on. Some vendors are just not worth the aggravation as they muddle their way through becoming a high volume vendor and all the difficulties and engineering it requires to make a solid repeatable performance for a very very high percentage of users. Just move on
I had my VPS suspended a few times by a good amount of providers and the only reason was attack on port 22. There are usually no other ports the attackers are interested in, they do try to scan the FTP port and MySQL 3306 port but that runs on a local interface by default. The other issue being these attacks fill up the logs fairly quickly and is annoying to filter through these messages to find stuff that is actually useful.
Once I learnt this, I always change the port on any public facing server. After that I never had any problem of providers suspending me (like for over 6-7 years now).
Again, this isn't about security but about noise reduction and resource usage.
I have been a VirMach customer since 2015 and run many services at various VirMach locations. I have not received a suspension notices in the past 5 years, even though I do have services running on most that burst for a few minutes regularly all day long.
Besides changing the port, disabling password authentication, and only allowing white listed IPs to access ssh I also try to buy a VM that has the appropriate RAM +30% and cpu cores for its intended use case and set "vm.swappiness=0" in the appropriate OS sysctl location to avoid as much disk swapping as possible.
You can say that VirMach does not always answer tickets in a timely manner and you would be right, but the fact that I can do most things myself with out needing to make a ticket works for me 99.9% of the time. I also find that for what I pay them, they have been surprising reliable over the years.
Just my two cents.
If you can say, which providers, and what were the specs of the systems?
These are some pretty reliable providers, I wouldn't name any as I don't want to be pointing fingers at any particular hosts. Basically any host that doesn't do any kind of CPU limiting will be on the list (It isn't their fault, the software isn't available to them).
This was a few years ago, so specs were usually around 2gigs/2vcpu/20-25ishGig system.