Show HN: Automatic account and SSH access provisioning tool for server admins
bastio.com
bastio.com
1. It's a huge security no-no. Much better would be having users run a daemon that polls for updates. At least that could probably be done while maintaining some semblance of security.
2. Admins don't need help with this, not really. Any competent admin will run Puppet (or Chef, or LDAP), which makes this stuff the most trivial thing you do.
I'd recommend a quick pivot (like let people run it themselves against their own servers) or just abort mission and chalk it up as a learning experience.
LDAP is a bit of a headache to set up for some shops.
Whereas your current method requires remote root SSH to be accessible from at least your network. Hacking you means immediate unfettered access to every one of your users.
I'd recommend a daemon and explicitly telling people to firewall off SSH from anywhere that isn't their own network.
I would note, though, that if we're hacked, the attacker doesn't get access to the users. We actually don't store the encryption keys for the deployment keys; the client does. Still, the daemon route is what we need to do. Thanks for the feedback.
Having an agent running on the servers would be much better.
First, it will not require unrestricted SSH root access to the servers. Most of the servers don't allow root to login through SSH at all.
Second, an agent restricts the harm that could be done if somebody hacks their servers. This could be achieved with restrictions (specific commands, IP addresses) to the key that is added to root's authorized_key, but there is no mention of that in the FAQ or the other docs.
Third, firewall management - good luck convincing somebody to modify the firewall to allow connections to the SSH service on all of their servers. A restricted agent will be a much easier sell.
When teaching users new to Unix systems I tell them to guard the root password / anything that gives you root as closely as possible.
When securing systems you generally even want to disable root logins period.
I don't feel comfortable with giving a 3rd party credentials to my servers and I don't recommend others do the same.
A downloadable product is really where you want to be headed with this. I'm okay running putty or winscp where I get to have full control of whatever keys I put in.
That feels like a big requirement. What is the gain of using your UI/service over using puppet in-house and creating your own UI?
I'd love to hear more about your use case and if you'd feel more comfortable having a daemon run on your servers (so that our service wouldn't have root login ability).
Say we have a daemon though - the daemon would require root access in order to create user accounts. If the management service is compromised, the user accounts can be created. That's why we've made it infeasible to access SSH keys even if the management server is compromised.
I'm not sure how accurate this quotation is, but Henry Ford may have said:
"If I had asked people what they wanted, they would have said faster horses."
As a consultant I feel it is my duty to advice people when they are asking me to implement something that is not in their best interests.
If someone has told you that "installing packages is difficult, just login as root", I think it is your duty to educate them as to why that is a bad idea.
Anyone familiar with security best practices would never even consider allowing an untrusted third-party to log in to their servers as root, which drastically reduces the size of your potential market.
Currently, your target market is: people who find it difficult to use configuration management tools, and who aren't aware of good security practices.
The pricing probably doesn't reflect how people would use this. The free plan is basically just a way to see how it works as you wouldn't need something like this for just one server. Maybe you should increase the free plan to a few servers so that I could see how useful it might be.
Makes it harder against a targeted attack, but does nothing for the average user.
You can mitigate the problem by having a really good intrusion detection system, but not eliminate it.
As far as injecting JS after server compromise: At that point, an equal concern is really attacker access to application memory, as we protect against the (admittedly edge) case where the attacker replaces the served Javascript but doesn't have access to memory. We've taken steps to reduce the opportunity for memory compromise.
Also, we are actually working on a reaction-oriented intrusion detection system that will take appropriate actions when invariants are tripped. But more importantly, we're moving to the daemon model, where customers have much more control over the security of their systems at the network level.
Many service providers, including DNS and hosting providers, use web-based control panels and must properly secure their systems. It's not a requirement that's unique to us. If you offer SaaS, you have to lock it down.
So while the risk you face may be the same, the damage that can be done is vastly greater. But I'm sure you're aware of that.
Assuming someone gains root level access to one of the boxes bastio is hosted on, then he could
1a. block all outgoing traffic from the server except for the service (to avoid alarms getting through) or 1b. replay the heartbeat sent by the server 2. retrieve the database 3. Sniff on all incoming traffic for the HttpOnly Cookies
The worst thing is you might not even know which customers' keys are compromised.
I'm sure you are thoughtful about security, but of course you are a great target because of the valuable loot (root access lot's of other servers)
A lot of your concerns are considerations for me too as I am thinking of launching a distributed SaaS. Just take it as input to your threat analysis :)
Yes, you're right that someone could intercept the HttpOnly cookies, but as you said, only if they were able to compromise the server, since we use SSL and won't have any XSS surface.
Also agree that alarm or heartbeat-based IDS stuff won't cut it here. We're working on an (agent-based, with signed code deployments) IDS (https://sentryhq.com/) that sits on the server and makes decisions to take certain actions not just when an attack matches some probably-out-of-date rule, but when some ever-growing list of invariants change. It's kind of like what banks use, except it responds automatically.
We will eventually be able to overcome all of these concerns (in the daemon-based model, wherein we don't store server keys) by validating OS user key distribution commands with secure emails to the people who requested them + nonces for confirmation. At that point, if we can enforce best practices amongst our customers, we can probably reduce the security problem to the trust problem, which is as solid as can be expected.
Actually, what do you think about such an IDS? Usually the tactic is "let my admins respond," but you are quite correct that that isn't sufficient, as your IDS may pick up the attack but the response may never come. We are thinking that the response isn't usually fast enough either.
it seems to me that a self-hosted solution (one-time fee or recurring license fee would be fine with me) would be ideal, otherwise i'd have to worry about security of not only my machines, but also yours. plus, i don't even allow root logins.
perhaps an agent model would provide good middle ground: provide a daemon that runs on the server and waits for account creation requests pushed from your service. these wouldn't be executable commands, but rather JSON or some DSL specifying account username, group, password, initial SSH key, skel, etc. a compromise of your machines wouldn't allow remote commands to be executed on your customers' machines (provided the daemon isn't exploitable).
Also, we set up Bastio so that we don't have unattended access to your servers. We keep everything encrypted until the moment when we need the keys for account provisioning or keypair deployment.
Where are your encryption keys stored in relation to our connection data?