5 ms·

Did you read the article? They edited my partition to add their key to my authorized_keys, logged in with it, and turned off my webserver. Whatever that is, it'

by aaronsw 17y ago

Did you read the article? They edited my partition to add their key to my authorized_keys, logged in with it, and turned off my webserver. Whatever that is, it's not asking to assist me.

brk 17y ago
I did read the article. Based on what you wrote, they offered to help investigate the issue in October, November, December if you would give them root access. For some reason you had an issue with this (it's actually extremely common on any shared box that you do not own). After the server that you lease from them (I omit calling it "your" server on purpose) continued to have issues that impacted customers outside of yourself, they logged into the box and (based on your article again) seemed to resolve the root (pun intended) issue rather quickly. This seems to have occurred 2-3 months after the initial root access request. The response of shutting off Apache was a bit extreme, but given the history, not terribly surprising either.
- mbreese 17y ago
  If you rent an apartment, you don't call it "the apartment that I rent", you call it "my apartment". Also, the landlord owns the place, but that doesn't give the landlord carte blanche to enter the apartment anytime they feel like it. Sure, they "own" it, but that does not make it any less wrong for them to barge in and gain access. If they need access, they must provide sufficient notice and must do it for a specific reason. This is a very similar situation. Particularly interesting to me is that they had the technical means to restrict the virtual machine via a configuration change, but instead chose to "trespass". According to their terms and conditions, "Misuse of System Resources" is prohibited, but their only listed recourse is to "restrict, suspend, or terminate" the account. It is arguable that they had no right to access the data for his server, since they had other means to restrict or otherwise limit the VPS (which they already did). They should have just paused the VPS without accessing the data and send him an email. Adding your SSH key to a customer's server without notice or approval is a good way to tarnish a reputation among the hacker crowd (their customer base). I wouldn't allow them to have root access either. Their argument would have been much stronger had they provided any sort of evidence of CPU load of his server. However, that probably would have shown how oversold the machine really was.
  - brk 17y ago
    * Also, the landlord owns the place, but that doesn't give the landlord carte blanche to enter the apartment anytime they feel like it.* Of course not, but the landlord does generally have the right to enter the property if there is an emergency (water is dripping from your unit into the unit below you). The hosting company here did not just drop in to see if he had any good scripts or pr0n to steal, they did so after resource issues.
    - apotheon 17y ago
      The apartment manager wouldn't have the ability to "pause" the apartment and wait for permission from the tenant to enter, though. The situation isn't strictly analogous.
      - brk 17y ago
        How is pausing an entire slice and thereby killing ALL services better than just shutting down one daemon?
        apotheon 17y ago
        It's better the same way that your apartment complex manager turning off the water to your apartment if there's a problem is better than going inside when you explicitly told him not to, checking all your faucets, and going through your underwear drawer, when you're not there.
        jrockway 17y ago
        Rimuhosting didn't go through this guy's underwear drawer, though. They went in and turned off the faucet that was damaging the apartment below.
        apotheon 17y ago
        > Rimuhosting didn't go through this guy's underwear drawer, though. How do you know? They rooted the system against the explicitly stated wishes of the customer. What makes you think they wouldn't do other sketchy things while they're at it?
sho 17y ago
You make it sound more difficult than it is. In other words, they mounted your partition, cat mykey.txt > authorized_keys, then ssh'd in and shut down your misbehaving app. They probably have a script for it since I bet it happens all the time. You're dangerously close to whining, did you know.
- _pius 17y ago
  You make it sound more difficult than it is. Hmm. I'm sorry, but I don't see how this matters at all Sho. Do the ethics change based on whether you have a rootkit or you do everything by hand?
  - sho 17y ago
    Ethics? Ethics don't enter into it, this is pure business necessity. Fact is, a $20/month VPS account has no rights and if it causes trouble it will be shut down, simple as that. Pay $250/month for an account at Rackspace (or whoever) and you will be treated very differently.
    - SwellJoe 17y ago
      Pay $250/month for an account at Rackspace (or whoever) and you will be treated very differently. Actually, the reason you pay $250 (more, probably) at Rackspace, is because they will login to your box on a regular basis to "manage" things. Rackspace is focused on "managed hosting"; they help you administer your system, which is why people pay a big premium for it. Most hosting customers have no idea what they're doing, and they need a lot of hand-holding, and a "grownup" to make sure things stay sane on their systems.
      - sho 17y ago
        True. A rackspace account is more like $450 for a single server. They keep their prices secret for a reason.
- pyre 17y ago
  How hard it was for them to do something isn't the issue. From the blog post: > In December they set a CPU cap on my VPS. Then from their response email to shutting down Apache: > We can set it so that you get a fixed amount of CPU (and then we don’t mind how much CPU want to use). My first reaction is, "Huh?" They state that they don't care about your local CPU usage if they bother to put a cap on your usage of the actual CPU. Yet they didn't do that. Instead they broke into his box to shutdown a rogue process that was 'using too much cpu.' That doesn't make any sense.
jhancock 17y ago
You could have used a tool I wrote http://shellshadow.com http://shellshadow.com Then you could have watched them investigate the problem.
- velofille 17y ago
  That looks handy. you can use screen to do a similar thing which is much easier to install on the actual Linux server, and works with windows, Linux and mac One person starts a screen session, and the other person uses screen -x to share it.
  - jhancock 17y ago
    Screen is a good tool and does have a collaborative feature. But it requires the following: 1 - install screen and configure the collaboration on your server 2 - create a user on your server for the other person to login 3 - the other person logging in must be able to route directly to your server. The ip for the server must be public and SSHD listener must accept connect from anywhere. 4 - The other person can login and "collaborate" with your screen session whether you are logged-in/watching or not. The only security is to shut down your screen session or change your screen config file / stop the sharing. 5 - with screen you cannot interactively/quickly change modes between read-write, read-only, etc... ShellShadow works as a client terminal relay. You setup a session between you and another user. You use the ShellShadow client (enhanced PuTTY) for your collaboration. There is nothing to setup and manage on your server. In fact your server is oblivious to the collaboration. One extra cool feature is this works with any terminal you can connect to: your Cisco router, your iPhone CLI, etc...

by aaronsw 17y ago

Did you read the article? They edited my partition to add their key to my authorized_keys, logged in with it, and turned off my webserver. Whatever that is, it's not asking to assist me.

brk 17y ago

I did read the article. Based on what you wrote, they offered to help investigate the issue in October, November, December if you would give them root access. For some reason you had an issue with this (it's actually extremely common on any shared box that you do not own). After the server that you lease from them (I omit calling it "your" server on purpose) continued to have issues that impacted customers outside of yourself, they logged into the box and (based on your article again) seemed to resolve the root (pun intended) issue rather quickly. This seems to have occurred 2-3 months after the initial root access request. The response of shutting off Apache was a bit extreme, but given the history, not terribly surprising either.

mbreese 17y ago
If you rent an apartment, you don't call it "the apartment that I rent", you call it "my apartment". Also, the landlord owns the place, but that doesn't give the landlord carte blanche to enter the apartment anytime they feel like it. Sure, they "own" it, but that does not make it any less wrong for them to barge in and gain access. If they need access, they must provide sufficient notice and must do it for a specific reason. This is a very similar situation. Particularly interesting to me is that they had the technical means to restrict the virtual machine via a configuration change, but instead chose to "trespass". According to their terms and conditions, "Misuse of System Resources" is prohibited, but their only listed recourse is to "restrict, suspend, or terminate" the account. It is arguable that they had no right to access the data for his server, since they had other means to restrict or otherwise limit the VPS (which they already did). They should have just paused the VPS without accessing the data and send him an email. Adding your SSH key to a customer's server without notice or approval is a good way to tarnish a reputation among the hacker crowd (their customer base). I wouldn't allow them to have root access either. Their argument would have been much stronger had they provided any sort of evidence of CPU load of his server. However, that probably would have shown how oversold the machine really was.
- brk 17y ago
  * Also, the landlord owns the place, but that doesn't give the landlord carte blanche to enter the apartment anytime they feel like it.* Of course not, but the landlord does generally have the right to enter the property if there is an emergency (water is dripping from your unit into the unit below you). The hosting company here did not just drop in to see if he had any good scripts or pr0n to steal, they did so after resource issues.
  - apotheon 17y ago
    The apartment manager wouldn't have the ability to "pause" the apartment and wait for permission from the tenant to enter, though. The situation isn't strictly analogous.
    - brk 17y ago
      How is pausing an entire slice and thereby killing ALL services better than just shutting down one daemon?
      - apotheon 17y ago
        It's better the same way that your apartment complex manager turning off the water to your apartment if there's a problem is better than going inside when you explicitly told him not to, checking all your faucets, and going through your underwear drawer, when you're not there.
        jrockway 17y ago
        Rimuhosting didn't go through this guy's underwear drawer, though. They went in and turned off the faucet that was damaging the apartment below.
        apotheon 17y ago
        > Rimuhosting didn't go through this guy's underwear drawer, though. How do you know? They rooted the system against the explicitly stated wishes of the customer. What makes you think they wouldn't do other sketchy things while they're at it?

sho 17y ago

You make it sound more difficult than it is. In other words, they mounted your partition, cat mykey.txt > authorized_keys, then ssh'd in and shut down your misbehaving app. They probably have a script for it since I bet it happens all the time. You're dangerously close to whining, did you know.

_pius 17y ago
You make it sound more difficult than it is. Hmm. I'm sorry, but I don't see how this matters at all Sho. Do the ethics change based on whether you have a rootkit or you do everything by hand?
- sho 17y ago
  Ethics? Ethics don't enter into it, this is pure business necessity. Fact is, a $20/month VPS account has no rights and if it causes trouble it will be shut down, simple as that. Pay $250/month for an account at Rackspace (or whoever) and you will be treated very differently.
  - SwellJoe 17y ago
    Pay $250/month for an account at Rackspace (or whoever) and you will be treated very differently. Actually, the reason you pay $250 (more, probably) at Rackspace, is because they will login to your box on a regular basis to "manage" things. Rackspace is focused on "managed hosting"; they help you administer your system, which is why people pay a big premium for it. Most hosting customers have no idea what they're doing, and they need a lot of hand-holding, and a "grownup" to make sure things stay sane on their systems.
    - sho 17y ago
      True. A rackspace account is more like $450 for a single server. They keep their prices secret for a reason.
pyre 17y ago
How hard it was for them to do something isn't the issue. From the blog post: > In December they set a CPU cap on my VPS. Then from their response email to shutting down Apache: > We can set it so that you get a fixed amount of CPU (and then we don’t mind how much CPU want to use). My first reaction is, "Huh?" They state that they don't care about your local CPU usage if they bother to put a cap on your usage of the actual CPU. Yet they didn't do that. Instead they broke into his box to shutdown a rogue process that was 'using too much cpu.' That doesn't make any sense.

jhancock 17y ago

You could have used a tool I wrote http://shellshadow.com http://shellshadow.com Then you could have watched them investigate the problem.

velofille 17y ago
That looks handy. you can use screen to do a similar thing which is much easier to install on the actual Linux server, and works with windows, Linux and mac One person starts a screen session, and the other person uses screen -x to share it.
- jhancock 17y ago
  Screen is a good tool and does have a collaborative feature. But it requires the following: 1 - install screen and configure the collaboration on your server 2 - create a user on your server for the other person to login 3 - the other person logging in must be able to route directly to your server. The ip for the server must be public and SSHD listener must accept connect from anywhere. 4 - The other person can login and "collaborate" with your screen session whether you are logged-in/watching or not. The only security is to shut down your screen session or change your screen config file / stop the sharing. 5 - with screen you cannot interactively/quickly change modes between read-write, read-only, etc... ShellShadow works as a client terminal relay. You setup a session between you and another user. You use the ShellShadow client (enhanced PuTTY) for your collaboration. There is nothing to setup and manage on your server. In fact your server is oblivious to the collaboration. One extra cool feature is this works with any terminal you can connect to: your Cisco router, your iPhone CLI, etc...