I understand that with that price for providing a server, they need to do some user validation - thus the requirement for address and phone.
But that issue with background services or cron - for that price, that's exactly why I'd consider their service. May I know what might be the reason why they don't allow this?
Nonsense. There are plenty of cheap hosts that don't do that sort of validation.
>May I know what might be the reason why they don't allow this?
Either they copypasta'd a boilerplate AUP -- in which case they're inept. Or they don't know how to properly virtualize and manage those provisions -- in which case they're also inept.
> Nonsense. There are plenty of cheap hosts that don't do that sort of validation.
And then their users run warez hosts and botnet slaves, which then get DDoSed, saturating their neighbors' links. No matter how well you virtualize and manage your provisions, if one user has caused your incoming 10G to be saturated on layer 2, there's not much you can do at layer 3 to QoS that.
Personally, the combination of "nearly free" and "personally identifiable such that there won't be people translating 'cheap' into 'good for one-off masks for illicit activity'" is a real selling point to me.
They, apparently, own their own datacenters and tout HIPAA compliant hosting. If they can't deal with incoming DoS traffic at the edge of their network I would be concerned...
People who run botnet slaves large enough to get DDoSed by their fellow botnet masters are smart enough to own Voip numbers for verification. The verification keeps 12year olds off not really anyone else. But it also stops legitimate users from signing up.
>No matter how well you virtualize and manage your provisions, if one user has caused your incoming 10G to be saturated on layer 2, there's not much you can do at layer 3 to QoS that.
well, you can blackhole the target. Essentially, you tell your upstream to drop all traffic to one of your /32s (the one being targeted) at it's upstream. It finishes the job for the attacker, which is sad, but so long as you are willing to lose the customer in question, it solves the problem for you.
For details of how to set this up if you are a he.net bandwidth customer, see:
nearly all other bandwidth providers provide similar facilities; there are a few other things you can do to make this sort of thing more robust.
But the point is that there are things you can do about incoming DDoS attacks... if you are willing to kill all traffic to the target IP address.
I mean, for most ISPs this isn't automated... in my case, my pager goes off; I log into my quagga box, and I start typing. So you still see downtime, and yeah, you want to avoid it. But there are things that can be done.
When I say "QoS", I'm referring to the quality of service of the other tenants sharing that uplink until you blackhole the DDoS. From my perspective running a VPS slice, there are periods where my uplink just dies—and there's nothing that can be done to "smooth" these away at the hypervisor level.
But that issue with background services or cron - for that price, that's exactly why I'd consider their service. May I know what might be the reason why they don't allow this?