4 ms·

I assumed that the problem was that if a master is accessible on your intranet, it could be hit with some sort of XSS attack from browsers inside the firewall.

by twic 7y ago

I assumed that the problem was that if a master is accessible on your intranet, it could be hit with some sort of XSS attack from browsers inside the firewall. But apparently there are 6000 people just straight up exposing their masters to the internet: https://gbhackers.com/saltstack-salt/ https://gbhackers.com/saltstack-salt/

NikolaeVarius 7y ago
> This whole "don't have your salt master exposed to the internet" thing has me annoyed. The whole point of salt is to manage boxes all over the place. I manage around 500 machines. Most of them are behind the firewalls of incompetent admins who have spent hours in the past trying to set up port forwards when salt-minion crashed so I could access the box again. I'm about to test binding salt-master to localhost and salt-minion to localhost and then setting up spiped to wrap the traffic... Some companies need better DevOps apparently
- dijit 7y ago
  Nitpick: this is purely an operations/sysadmin problem. The DevOps grouping doesn't apply too much, Operations-minded staff should be focusing on keeping things locked down. Unless, you know, you're not hiring those people and instead are hoping that developers take the Ops burden. ;)
  - deleted 7y ago
    [deleted]
  - dijit 7y ago
    People downvoting: I guess I hit a nerve, but could you explain why? Development and Operations are different disciplines and the idea was to remove silos, not make one person responsible for both.
Spivak 7y ago
But that's like half the point of SaltStack. It's supposed be secure enough to run on the public internet to manage road-warrior endpoints. "I found this site called Alexa that lists a bunch of companies that just straight up expose their web servers to the internet. Crazy." And I have some bad news about how many companies are exposing their VPN servers to the internet too.
- tilolebo 7y ago
  It's really not. You also wouldn't expose your database just because it's password-protected? I bet all these public servers have a firewall running to protect other services. Shouldn't be hard to include the saltstack port(s) and whitelist the relevant IP addresses. Also,the main difference with your example is that the clients that connect to webservers and vpns are either not known in advance or don't have static IP addresses.
  - saltyguy22 7y ago
    You can't really compare Salt to a password protected database. SSH is probably a better comparison as both use public key crypto and plenty of servers are exposed on the internet via it. Its just that salt hasn't been audited as heavily as OpenSSH or other implementations of SSH so its risky exposing Salt to the internet, but I can see why some admins might do that.
  - Spivak 7y ago
    Anyone who's putting their Salt master on the internet is having to deal with clients without fixed addresses. And it's not uncommon to have to deal with clients that aren't known advance which is when autosign scripts are used. Sans the current CVE this is otherwise a service that is safe to expose to adversarial networks.
    - tilolebo 7y ago
      From Algolia's outage retrospective: What we did so far: We’ve secured the impacted SaltStack service by updating it and adding additional IP filtering, allowing only our servers to connect to it. So clearly unrestricted access wasn't a necessity. I understand it's a pain, I've been running a 1000+ server stack with puppet on a public network and relied on iptables to secure it. But I'd rather cope with the daily iptable rules update than having to fight a 0-day exploit...
panarky 7y ago
Including DigiCert? https://news.ycombinator.com/item?id=23062904 https://news.ycombinator.com/item?id=23062904

by twic 7y ago

NikolaeVarius 7y ago

> This whole "don't have your salt master exposed to the internet" thing has me annoyed. The whole point of salt is to manage boxes all over the place. I manage around 500 machines. Most of them are behind the firewalls of incompetent admins who have spent hours in the past trying to set up port forwards when salt-minion crashed so I could access the box again. I'm about to test binding salt-master to localhost and salt-minion to localhost and then setting up spiped to wrap the traffic... Some companies need better DevOps apparently

dijit 7y ago
Nitpick: this is purely an operations/sysadmin problem. The DevOps grouping doesn't apply too much, Operations-minded staff should be focusing on keeping things locked down. Unless, you know, you're not hiring those people and instead are hoping that developers take the Ops burden. ;)
- deleted 7y ago
  [deleted]
- dijit 7y ago
  People downvoting: I guess I hit a nerve, but could you explain why? Development and Operations are different disciplines and the idea was to remove silos, not make one person responsible for both.

Spivak 7y ago

But that's like half the point of SaltStack. It's supposed be secure enough to run on the public internet to manage road-warrior endpoints. "I found this site called Alexa that lists a bunch of companies that just straight up expose their web servers to the internet. Crazy." And I have some bad news about how many companies are exposing their VPN servers to the internet too.

tilolebo 7y ago
It's really not. You also wouldn't expose your database just because it's password-protected? I bet all these public servers have a firewall running to protect other services. Shouldn't be hard to include the saltstack port(s) and whitelist the relevant IP addresses. Also,the main difference with your example is that the clients that connect to webservers and vpns are either not known in advance or don't have static IP addresses.
- saltyguy22 7y ago
  You can't really compare Salt to a password protected database. SSH is probably a better comparison as both use public key crypto and plenty of servers are exposed on the internet via it. Its just that salt hasn't been audited as heavily as OpenSSH or other implementations of SSH so its risky exposing Salt to the internet, but I can see why some admins might do that.
- Spivak 7y ago
  Anyone who's putting their Salt master on the internet is having to deal with clients without fixed addresses. And it's not uncommon to have to deal with clients that aren't known advance which is when autosign scripts are used. Sans the current CVE this is otherwise a service that is safe to expose to adversarial networks.
  - tilolebo 7y ago
    From Algolia's outage retrospective: What we did so far: We’ve secured the impacted SaltStack service by updating it and adding additional IP filtering, allowing only our servers to connect to it. So clearly unrestricted access wasn't a necessity. I understand it's a pain, I've been running a 1000+ server stack with puppet on a public network and relied on iptables to secure it. But I'd rather cope with the daily iptable rules update than having to fight a 0-day exploit...

panarky 7y ago

Including DigiCert? https://news.ycombinator.com/item?id=23062904 https://news.ycombinator.com/item?id=23062904