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
They are mostly useless.
The best you can do is to raise a complaint afterwards if they (and highly likely they will) refuse to resolve the situation.
If you push hard enough, they start to take the complaints seriously, but it does take some trying to get them out of their "It was under attack / malicious/suspicious activity, so we've put it in rescue mode, feel free to reinstall."
If you need a hand, I've got a few contacts besides "Anne", "Neil" and "Marc" who normally handle all front-line support.
Yes and like most of my experiences with the incident team, it told me everything that was in the incident reply with a slightly french accent.
Thanks, I'll give them a call tomorrow during office hours to get something moving.
Ah well, ovh hosts over 120.000 servers so I don't think it's weird there are bad moments with them. I got another server from OVH the other day, running with OSSEC to prevent the SSH attacks and the like.
I don't see what the big deal about a SSH brute force attack is. It's not as-if the attacked resource is on a shared cloud or something. These are dedicated machines.
I'll repeat, that it sucks to be a victim of crime/criminal intent then punished for it.
@pubcrawler If you managed a DC, what would you do? I would do the same attempt that OVH did.. only makes sense?
Brute force SSH @Jeffrey isn't some massive network absorption thing like a DDoS for instance.
I can't figure for the life of me how a company of OVH's size would even notice those blips in bandwidth.
Let's say they are proactive or have software that does the babysitting, the thing to do would be to let the machine owner/renter know of the type of problem exactly and provide a mitigation strategy.
The simplest thing would likely be a simple iptables rule to block SSH port to anyone other than a fix ip under the renters control. Also another simple rule to block IPs after so many attempts failed and only so many attempts per minute.
Could recommend moving SSH server to another port. Simple.
Obviously, these are moving target bandaids. But rather effective in most instances.
@pubcrawler True, they could have done that, and probably thought about it too..They're probably just too lazy to even do that.
Work with said customer to find a viable solution and not boot them straight off. Unless ShardHost isn't telling the full story, OVH kicked this particular server off without discussing it with them.
@concerto49 Oh? I thought they took it temporarily offline?
Booting into rescue mode is pretty much offline, only have access to files. No actual services etc.
I received the following ticket
"The intervention on ns228729.ovh.net has been completed.
This operation was closed at 2012-12-16 01:49:37
Here are the details of this operation:
Semi Hack
Date 2012-12-16 01:46:03, tommy.lovergne made Semi Hack:
no ping
Current In: 42.6 Mb/s
anti hack
reboot server
boot ok
ping and service ok
If you need any further information regarding this
intervention, please do not hesitate to contact our
technical support. "
The server however was offline with a nullroute in place.
I then contacted support, who told me the following:
"Dear customer,
Your server had an incoming attack which has caused network
disturbances for servers in your switch.
The technician had to launch a traffic aspirator, in order
to minimise the damage.
The protection has automatically been removed afterwards.
I have no further details about the origin of the attack,
you need to check your logs and set at least a good
firewall."
The server; however was not removed from the null until four hours later. By the time I even got a chance to check the server it had been restarted into FTP-Only rescue mode so I could take my files. Except this mode is not working.
At least they have "anti hack" for "semi-hack". Next they will be upgrading to autoboot, sigh
lol
+1 for traffic aspirator. WTF? is that.
Must be French for put yourself on a time out while we crush your server and keep your cash.
Have managed to speak to someone on the phone; and the server is now back online.
They did however confirm that the incoming traffic of 32.5 Mb/s prompted this as they needed to protect their network. I've requested fuller details of the attack including the PPS. If the PPS was low I will be moving all services away from OVH anyways as this is just too risky to continue with.
I managed to clarify
traffic aspirator = nullroute
I was not able to determine what a semi hack was or how the anti hack helps this.
You didn't actually get DDoS'd then (:
Try running a good 'stresser' (or a couple) and see what happens- you'll get an email saying how they spotted a 'defect' on your service and how they can't ping your external IP, and how they've disabled your server temporarily.
Odd, I usually experience 30-40Mbps constantly inbound, and my server was suspended when it was DoS'd at 90Mbps
Examining the logs, it was a SSH brute force from a single Chinese IP address.
As far as I know a bruteforce don't takes that much bandwith.
They're so persistent that it's borderline adorable.
He must of have used a lot of concurrent connections then, which doesn't consume bandwidth but does generate a lot of packets.
Their kimSufi's are great backup boxes. 500GB for about 10-11 EUR a month is cheap
Depends on the size of the attack, of course. This one would not seem disrupting to me, but I don't have all the details.
share the chinese ip please
We had a couple of servers at OVH (Kimsurfi) and we had some of these same issues, over a certain amount of bandwidth and packets per second and they seem to suspend your server.
When i was telling ppl not to buy anually at OVH I was attacked with pitch and forks by ppl that know better.
I dont deny that probably a US/UK/FR and similar customers probably have different treatment, but the facts that I have point out that romanian ones are treated very badly in the sense that "you have the right to give us the money after a thorough verification, whether we do our part or not depends on your luck".
Many low income ppl should consider that before paying them for too much in advance.
That is all.
Surprisingly, their service is actually great when you call them. Thats the best way to sort stuff out.
I've never had an issue. Had a server up within an hour contacting them via email (I did use french)
Just got their BHS special for a little over $150 USD for the year with up to 4 IPs free (some geo-located in the US)
A Kimsufi server that was a ~20 USD per month backup node went down one night. No intervention, I got a ticket with a message that the motherboard failed, and one was being installed. 42 minutes later the server was up according to Pingdom.
I've never had an issue, and actually like the automation. That's just my experience.
The Automation is the death of human interaction, sooner or later they'll have everything synced to one manned cluster of servers, and if a part fails, they'll just re-provision a new one and sync the data over again.
Then get minimal amounts of intervention to replace/repair the failed server. Automatic reboots, rescue mode, all of that, is the gateway to the idealistic robots own everythang!
@eastonch the dream of that is far, far away.. unless they fitted every server with a 10Gig NIC for the syncing.
That would be pretty awesome though.
OVH should clearly be avoided.