3 ms·

> No. Not even close. Rimuhosting owns the box in question. You can't possibly break into your own box. I don't think you're familiar with the common uses of "

> No. Not even close. Rimuhosting owns the box in question. You can't possibly break into your own box. I don't think you're familiar with the common uses of "bordering on". > What would you, as a security professional who was dumped into the role of running a hosting data center, do when a box on your network (which has thousands of other boxes) has been rooted and is sending out spam at a rate of a million messages per day, even if you know that your paying customer is not responsible for sending those messages? I'd stop the server without gaining root against the client's wishes, immediately inform the client, and try to get things cleaned up to everyone's satisfaction (except the security cracker who rooted the box, of course). I wouldn't gain root on the box in violation of the client's obvious wishes, particularly after articulating specific policy saying that you can remove my initial root access to the box if you like, and shut down specific services that are making my life difficult for reasons entirely unrelated to the client's running of the site, then send an email later pointing out my policy that fails to mention I might do this. Privacy is security, after all: http://blogs.techrepublic.com.com/security/?p=293 http://blogs.techrepublic.com.com/security/?p=293 Nothing you say in your hypothetical examples in any way justifies accessing the customer's data, particularly by breaking in to the system. Shut it down? Sure, if circumstances call for that. Start meddling with server configuration and establish what amounts to a rootkit on the system (in effect, if not in technical truth) without the client's permission? That's just shady. > No amount of hand-waving about your "rights" makes that less true. Perhaps you should stop waving your hands about that straw man, then.

SwellJoe 17y ago
I don't think you're familiar with the common uses of "bordering on". I'll promise to read up on it, if you'll learn the meaning of "not even close". Nothing you say in your hypothetical examples in any way justifies accessing the customer's data, particularly by breaking in to the system. Shut it down? Sure, if circumstances call for that. Start meddling with server configuration and establish what amounts to a rootkit on the system (in effect, if not in technical truth) without the client's permission? That's just shady. I will merely mention that most hosting provider customers not only accept this kind of thing, they demand it. If you spend a little time on web hosting forums (as I must because it is my industry) you will notice a very strong tendency for complaints to be system administration related. The customer expected more involvement than the hosting provider offered, and thus things went horribly awry. I agree with you, entirely, that if you ask the host to never login to your system, they should respect that wish. But, I can also state without hesitation that you and I (and most people here at HN) are thoroughly in the minority in wanting our hosting provider to never login to our hosting systems. The default mode for hosting providers is to drop in on the box within a couple of comments in their ticketing system...if it can't be solved with one or two replies, then it's safest to simply drop in and fix it. For most hosting customers this is not an invasion of privacy or "breaking in", it is "great support". Finally, as a security professional, I'm sure you're also aware that with access to the hardware, your host has root all the time. There is nothing you or I can do about it. Even more interestingly, the host also has the ability to login, poke around, and never tell you about it (and not leave a trail...just boot up a live CD, mount up the disk read only, and poke around til their heart's content). Also nothing you or I can do about that. With someone else having access to the hardware, you have nothing but good faith on the part of the hosting provider.
- apotheon 17y ago
  > I'll promise to read up on it, if you'll learn the meaning of "not even close". I don't see how "I know you are, but what am I?" is a very strong argument. > I will merely mention that most hosting provider customers not only accept this kind of thing, they demand it. Give it to customers who want it. Don't ask someone if he wants it, get a "no" answer, then turn around and do it anyway. The former is good customer service. The latter is shady and underhanded. > The default mode for hosting providers is to drop in on the box within a couple of comments in their ticketing system...if it can't be solved with one or two replies, then it's safest to simply drop in and fix it. For most hosting customers this is not an invasion of privacy or "breaking in", it is "great support". Most hosting customers don't have explicit suggestions from the host that if they don't want the hosting provider logging in to the system they can remove their SSH keys -- and, more to the point, most hosting customers don't do that then find out the hosting provider's support personnel have been rooting around (pardon the pun) in their data anyway. It's "breaking in" in this case only because the SSH key for access was removed, with the hosting provider's blessing, and they basically leveraged a local access vulnerability to give themselves root access. If the hosting provider had a policy that forbade customers from obstructing host administrators from logging in to the machine, articulated in the terms and conditions of use, I'd say go for it -- but that's not the situation in this case at all. > Finally, as a security professional, I'm sure you're also aware that with access to the hardware, your host has root all the time. In principle, sure -- but when there's a clearly encouraged expectation of privacy, it's really bad form to break in to the system against the customer's wishes by virtue of having access to the hardware. That's a betrayal of trust. > Even more interestingly, the host also has the ability to login, poke around, and never tell you about it (and not leave a trail...just boot up a live CD, mount up the disk read only, and poke around til their heart's content). Indeed. The fact it wasn't kept secret in this case just shows how little they value the customer's request that they don't log in to the system with root privileges and muck about with the customer's data. I didn't say they were necessarily malicious about it -- but that doesn't mean it's not bad. > With someone else having access to the hardware, you have nothing but good faith on the part of the hosting provider. . . . or, in this case, bad faith.

SwellJoe 17y ago

I don't think you're familiar with the common uses of "bordering on". I'll promise to read up on it, if you'll learn the meaning of "not even close". Nothing you say in your hypothetical examples in any way justifies accessing the customer's data, particularly by breaking in to the system. Shut it down? Sure, if circumstances call for that. Start meddling with server configuration and establish what amounts to a rootkit on the system (in effect, if not in technical truth) without the client's permission? That's just shady. I will merely mention that most hosting provider customers not only accept this kind of thing, they demand it. If you spend a little time on web hosting forums (as I must because it is my industry) you will notice a very strong tendency for complaints to be system administration related. The customer expected more involvement than the hosting provider offered, and thus things went horribly awry. I agree with you, entirely, that if you ask the host to never login to your system, they should respect that wish. But, I can also state without hesitation that you and I (and most people here at HN) are thoroughly in the minority in wanting our hosting provider to never login to our hosting systems. The default mode for hosting providers is to drop in on the box within a couple of comments in their ticketing system...if it can't be solved with one or two replies, then it's safest to simply drop in and fix it. For most hosting customers this is not an invasion of privacy or "breaking in", it is "great support". Finally, as a security professional, I'm sure you're also aware that with access to the hardware, your host has root all the time. There is nothing you or I can do about it. Even more interestingly, the host also has the ability to login, poke around, and never tell you about it (and not leave a trail...just boot up a live CD, mount up the disk read only, and poke around til their heart's content). Also nothing you or I can do about that. With someone else having access to the hardware, you have nothing but good faith on the part of the hosting provider.

apotheon 17y ago
> I'll promise to read up on it, if you'll learn the meaning of "not even close". I don't see how "I know you are, but what am I?" is a very strong argument. > I will merely mention that most hosting provider customers not only accept this kind of thing, they demand it. Give it to customers who want it. Don't ask someone if he wants it, get a "no" answer, then turn around and do it anyway. The former is good customer service. The latter is shady and underhanded. > The default mode for hosting providers is to drop in on the box within a couple of comments in their ticketing system...if it can't be solved with one or two replies, then it's safest to simply drop in and fix it. For most hosting customers this is not an invasion of privacy or "breaking in", it is "great support". Most hosting customers don't have explicit suggestions from the host that if they don't want the hosting provider logging in to the system they can remove their SSH keys -- and, more to the point, most hosting customers don't do that then find out the hosting provider's support personnel have been rooting around (pardon the pun) in their data anyway. It's "breaking in" in this case only because the SSH key for access was removed, with the hosting provider's blessing, and they basically leveraged a local access vulnerability to give themselves root access. If the hosting provider had a policy that forbade customers from obstructing host administrators from logging in to the machine, articulated in the terms and conditions of use, I'd say go for it -- but that's not the situation in this case at all. > Finally, as a security professional, I'm sure you're also aware that with access to the hardware, your host has root all the time. In principle, sure -- but when there's a clearly encouraged expectation of privacy, it's really bad form to break in to the system against the customer's wishes by virtue of having access to the hardware. That's a betrayal of trust. > Even more interestingly, the host also has the ability to login, poke around, and never tell you about it (and not leave a trail...just boot up a live CD, mount up the disk read only, and poke around til their heart's content). Indeed. The fact it wasn't kept secret in this case just shows how little they value the customer's request that they don't log in to the system with root privileges and muck about with the customer's data. I didn't say they were necessarily malicious about it -- but that doesn't mean it's not bad. > With someone else having access to the hardware, you have nothing but good faith on the part of the hosting provider. . . . or, in this case, bad faith.