6 ms·

This for maintenance reporting. How do the hell they know if one of your HD has died ? It's not mandatory. And the ssh key added enforces the source IP address

This for maintenance reporting. How do the hell they know if one of your HD has died ? It's not mandatory. And the ssh key added enforces the source IP address of requests.

tptacek 14y ago
One way would be to publish a HTTP/JSON API for fetching a specific set of stats from a server given an authorization key, provide a reference implementation, and allow customers to build their own if they're not comfortable with that. Root SSH logins don't seem like a particularly good solution for this problem.
- hosay123 14y ago
  Surprised to read this from a security guy. 1) discard time-tested crypto implementation 2) write your own. 3) run it as root so it can read sensors 4) feel safer Everything aside, most of these colo machines are set to netboot in order to implement their rescue system. Never poked around, but wouldn't be surprised those DHCP requests hit other machines on the segment. OVH seem to be more sensible than most when it comes to network configuration, but I wouldn't be surprised this happens in other places (the difference between a $50 Ethernet switch and a $5000 Ethernet switch right there) Edit: since some don't seem to understand the basics of security, or perhaps out of an ill-placed sense of loyalty: running a web server + CGI combo as root on an Ethernet segment exposed to other colo customers, in place of a 20 year old service designed for exactly this scenario, when its sole user already has hardware access (and reboot + netboot access) to the machine is fucking stupid. I'm making no argument here, just calling out terrible advice for what it is.
  - tptacek 14y ago
    ?!
    - hosay123 14y ago
      Which bit didn't you understand?
      - tptacek 14y ago
        Every single one of your numbered points. 1) discard REMOTE SHELL solely for OS statistics 2) write your own TINY WEB APPLICATION SERVED BY NGINX/APACHE 3) run it as SOME USER THAT can read STATISTICS DATA 4) BE safer
        hosay123 14y ago
        1. > One way would be to publish a HTTP/JSON API for fetching a specific set of stats from a server > given an authorization key 2. > provide a reference implementation, and allow customers to build their own if they're not comfortable with that. Implies 3: entire point of the implementation is to read sensors, which requires root, or further messing with the security properties of the base system (e.g. sudo), and expecting users to do this correctly. So basically what you're advocating is to encourage users to run custom HTTP servers as root. Edit: and I see you edited your comment, and now advocating running nginx as root.
        tptacek 14y ago
        I have no idea what you're talking about or who you think you're arguing with but it isn't me. Especially amusing that whoever would say these crazy things you're saying would still be better off than giving remote root SSH away for stats collection. Sheesh.
        hosay123 14y ago
        It's OK, we all give bad advice sometimes. You clearly just advocated replacing SSH with a custom HTTP server that effectively always requires root, and furthermore to advocate users mess with this root-running code. I don't understand why you can't see this.
- mahyarm 14y ago
  Why don't you use SNMPv3, which is purpose built for this stuff? https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol#Version_3 https://en.wikipedia.org/wiki/Simple_Network_Management_Prot...
  - tptacek 14y ago
    And then why don't I find a large glass jar filled with live wriggling cockroaches and compete with my coworkers to see how many of them I can swallow whole? SNMP is awful. SNMP implementations are scarier than web apps (though admittedly not as scary as SSH logins). SNMP is harder to secure. It would be much harder for customers to provide their own trusted implementation of SNMP. I could go on.
  - danielweber 14y ago
    There's what SNMP was built for, and then what it actually does. I've been (un)fortunate enough to implement it more than once. Only a certain class of clients demand it because they already have built a big SNMP infrastructure.
- grosskur 14y ago
  Porkchop might be a good starting point: https://github.com/disqus/porkchop https://github.com/disqus/porkchop
- maximegarcia 14y ago
  The SSH access is for deploying the rtm binary (setup, config, updates). Only one host is allowed to reach servers through ssh via the ssh key in question. # cat .ssh/authorized_keys2 from="213.186.50.100" ssh-rsa AAAAB3NzaC[...]hBIuk57cDxs= root@cache.ovh.net For harvesting data, the rtm binary is run by crontab, and does send msg. OVH are not polling the servers. # cat /etc/crontab */1 * * * * root /usr/local/rtm/bin/rtm 46 > /dev/null 2> /dev/null If customers are not comfortable with that, they can opt out, according to the documentation (removing the ssh key and/or the rtm binary).
catwell 14y ago
No. This is so their technicians can easily log into your servers and solve problems if you need them too. Lots of their customers are newbies so they sell technical help as a service. It is documented here: http://help.ovh.co.uk/InstallOvhKey http://help.ovh.co.uk/InstallOvhKey and http://help.ovh.co.uk/Intervention http://help.ovh.co.uk/Intervention as well as the way to disable this "backdoor". Note that there is more information available if you switch to the French language...

This for maintenance reporting. How do the hell they know if one of your HD has died ? It's not mandatory. And the ssh key added enforces the source IP address of requests.

tptacek 14y ago

One way would be to publish a HTTP/JSON API for fetching a specific set of stats from a server given an authorization key, provide a reference implementation, and allow customers to build their own if they're not comfortable with that. Root SSH logins don't seem like a particularly good solution for this problem.

hosay123 14y ago
Surprised to read this from a security guy. 1) discard time-tested crypto implementation 2) write your own. 3) run it as root so it can read sensors 4) feel safer Everything aside, most of these colo machines are set to netboot in order to implement their rescue system. Never poked around, but wouldn't be surprised those DHCP requests hit other machines on the segment. OVH seem to be more sensible than most when it comes to network configuration, but I wouldn't be surprised this happens in other places (the difference between a $50 Ethernet switch and a $5000 Ethernet switch right there) Edit: since some don't seem to understand the basics of security, or perhaps out of an ill-placed sense of loyalty: running a web server + CGI combo as root on an Ethernet segment exposed to other colo customers, in place of a 20 year old service designed for exactly this scenario, when its sole user already has hardware access (and reboot + netboot access) to the machine is fucking stupid. I'm making no argument here, just calling out terrible advice for what it is.
- tptacek 14y ago
  ?!
  - hosay123 14y ago
    Which bit didn't you understand?
    - tptacek 14y ago
      Every single one of your numbered points. 1) discard REMOTE SHELL solely for OS statistics 2) write your own TINY WEB APPLICATION SERVED BY NGINX/APACHE 3) run it as SOME USER THAT can read STATISTICS DATA 4) BE safer
      - hosay123 14y ago
        1. > One way would be to publish a HTTP/JSON API for fetching a specific set of stats from a server > given an authorization key 2. > provide a reference implementation, and allow customers to build their own if they're not comfortable with that. Implies 3: entire point of the implementation is to read sensors, which requires root, or further messing with the security properties of the base system (e.g. sudo), and expecting users to do this correctly. So basically what you're advocating is to encourage users to run custom HTTP servers as root. Edit: and I see you edited your comment, and now advocating running nginx as root.
        tptacek 14y ago
        I have no idea what you're talking about or who you think you're arguing with but it isn't me. Especially amusing that whoever would say these crazy things you're saying would still be better off than giving remote root SSH away for stats collection. Sheesh.
        hosay123 14y ago
        It's OK, we all give bad advice sometimes. You clearly just advocated replacing SSH with a custom HTTP server that effectively always requires root, and furthermore to advocate users mess with this root-running code. I don't understand why you can't see this.
mahyarm 14y ago
Why don't you use SNMPv3, which is purpose built for this stuff? https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol#Version_3 https://en.wikipedia.org/wiki/Simple_Network_Management_Prot...
- tptacek 14y ago
  And then why don't I find a large glass jar filled with live wriggling cockroaches and compete with my coworkers to see how many of them I can swallow whole? SNMP is awful. SNMP implementations are scarier than web apps (though admittedly not as scary as SSH logins). SNMP is harder to secure. It would be much harder for customers to provide their own trusted implementation of SNMP. I could go on.
- danielweber 14y ago
  There's what SNMP was built for, and then what it actually does. I've been (un)fortunate enough to implement it more than once. Only a certain class of clients demand it because they already have built a big SNMP infrastructure.
grosskur 14y ago
Porkchop might be a good starting point: https://github.com/disqus/porkchop https://github.com/disqus/porkchop
maximegarcia 14y ago
The SSH access is for deploying the rtm binary (setup, config, updates). Only one host is allowed to reach servers through ssh via the ssh key in question. # cat .ssh/authorized_keys2 from="213.186.50.100" ssh-rsa AAAAB3NzaC[...]hBIuk57cDxs= root@cache.ovh.net For harvesting data, the rtm binary is run by crontab, and does send msg. OVH are not polling the servers. # cat /etc/crontab */1 * * * * root /usr/local/rtm/bin/rtm 46 > /dev/null 2> /dev/null If customers are not comfortable with that, they can opt out, according to the documentation (removing the ssh key and/or the rtm binary).

catwell 14y ago

No. This is so their technicians can easily log into your servers and solve problems if you need them too. Lots of their customers are newbies so they sell technical help as a service. It is documented here: http://help.ovh.co.uk/InstallOvhKey http://help.ovh.co.uk/InstallOvhKey and http://help.ovh.co.uk/Intervention http://help.ovh.co.uk/Intervention as well as the way to disable this "backdoor". Note that there is more information available if you switch to the French language...