Show HN: Automatic account and SSH access provisioning tool for server admins(bastio.com)
bastio.com
Show HN: Automatic account and SSH access provisioning tool for server admins
https://bastio.com/
15 comments
How is what we're doing less secure than, say, provisioning servers through a provider like Linode that gives customers a web-based access panel? (One can use their provisioning tools to create users with root access.) Also, running a daemon may make folks more comfortable, but the reality is that the daemon still has the ability to add users, which in turn can be used to log in. Running things through a daemon certainly makes monitoring and firewall setup more manageable, though, and we're working on it.
LDAP is a bit of a headache to set up for some shops.
LDAP is a bit of a headache to set up for some shops.
A daemon could be smart. Only allowing certain operations (e.g. adding non-root users) and it could send email directly to the account holder informing them every time it does so. SSH access doesn't even need to be open for a daemon to poll. Even if a hacker managed to add an account they might not be able to use it.
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.
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 think you're right - we should include those instructions for now, and provide a bastion-as-a-service later. The daemon route is clearly preferable for customers, so we'll build that out (we already have manual key-adding confirmation, and we record the IPs of people who attempt to download/upload keys).
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.
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.
I personally don't feel comfortable using your service - too much of a security risk giving Databracket LLC unrestricted root access. I guess most other security-minded people would not feel at ease as well.
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.
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.
Thanks, that's a great point that the agent is an easier sell. We're going to add one soon so people won't feel uncomfortable opening up their SSH ports. We've heard this a lot and really appreciate the feedback on this point.
The idea is nice but the execution is flawed.
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.
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.
"We require that you deploy our public key to your root account’s authorized_keys file so that we can provision users on your behalf."
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?
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?
Well, we talked to server admins (mostly at companies that run servers on behalf of web design or web services clients) and heard that they didn't want us to impose the requirement of adding another package to their deploy scripts. They'd have to keep the version up to date, make sure it's installed on their machines, etc. That's feedback was really the only reason why chose to impose this requirement for the beta.
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).
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).
> That's feedback was really the only reason why chose to impose this requirement for the beta.
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.
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.
Just about anything would be better than 100% root access and "employed measures to make sure that we never have unattended access to your servers", and there's no reason you can't offer two solutions.
You'll have to develop a cryptographic scheme makes sure that when your management service is compromised, it does not affect the servers the management server controls. We've done that work.
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.
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 going to comment on the security of giving somebody an ssh key to your root account... But it's a good idea to look at something like puppet to do this.
Example: https://github.com/credativ/puppet-ssh-hiera
Example: https://github.com/credativ/puppet-ssh-hiera
$4 a month per server for a rsync script I could write myself combined with our existing ldap infrastructure? If it were a nice open sourced tool I would consider it but at hundreds to thousands a month I could never justify it to myself let alone my boss.
I can largely do all this with Ansible and it's flexible enough that I could probably get pretty close to being as easy as a good web UI. They devs behind Ansible are also working on Ansible Commander which will provide a UI. The UI will likely be the difference maker, so you should include screenshots so that I don't have to create a new account for yet another service I may never again log into.
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.
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.
Thanks, we've removed the server limit for the moment and put up a screenshots page. Any feedback you have on the UI and how we could make it more useful to you than Ansible (besides our autogenerated scripts) would be awesome.
Hello guys. Founder of https://commando.io. Commando.io is a web based interface to execute commands on remote servers over SSH. You can write commands in bash, perl, python, ruby, or even node.js. We seem to share some of the same ideas and vision. When you generate a public key in bastio.com do you also add a password to the key as well? I.E. if somebody were to compromise your server, they would need the SSH key password to SSH into other users servers?
If someone were to compromise our server, it is extremely unlikely that they would be able to recover the SSH keys. The keys remain encrypted except when they're needed to perform an action initiated by an authenticated user.
Sorry, but this sets off my bullshit detector.
If someone compromises your server he also has access to the routines decrypting the ssh keys.
How do you encrypt them?
Hi - It's not enough to compromise the Bastio servers. Some of the data facets needed to successfully decrypt the SSH keys are stored securely in the browser. This is why we can't deploy OS users or keys if a Bastio user is not logged in and active.
That is better but not good enough. If your servers were compromised, that attacker could add JS code to your page that quietly farms that facets that are securly stored in the browser, when the user logs in.
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.
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.
It's harder than it sounds, as we use HttpOnly cookies and, much more importantly, have little to no XSS attack surface.
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.
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.
Of course the requirement exists for all SaaS providers. But while a break in on Evernote reveals my notes (which would be bad, but not lethal), a break in at bastio might compromise the servers where I host my SaaS products, triggering a very nasty chain reaction.
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 :)
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 :)
Yeah, definitely, it's all an input to the threat analysis. Thanks for the great discussion. It's interesting stuff and fun+important to just think through.
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.
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.
When I try to add my first server, I am getting: `Please upgrade to add more servers.` So far not a good experience.
I'm sorry, but LDAP does this on a much larger scale for free. Nice idea, however wrong way to go about it big time.
why on earth do you need remote shell access to the machine?!
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).
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).
No serious shop will use this. If you release it as an open source project, perhaps someone might find it useful. If they aren't using LDAP/Puppet/Chef/etc . Checkout freeipa.org and https://oss.gonicus.de/labs/gosa .
Hi, one of the creators here. We build this because we run our own machines and wanted a easier way to manage our OS user accounts and SSH keys across machines. We put together a beta service to do just that, and would love to hear what you think.
I can't imaging trusting a 3rd party to provision userId's and SSH keys for my servers. Am I missing something here?
I was thinking the same. Perhaps if the setup procedure included a limited-access account that could only run useradd/userdel, I'd consider trying it, but definitely not while root.
Thanks for the feedback. For the one-time server enrollment process, would you be more comfortable having us set up a limited account using a script we provide? We were thinking that there's not necessarily a whole lot of difference between a user who has useradd permissions and a user with root permissions.
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.
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.
I'm not sure I'd even go that far. A set of commands showing how to lock down account permissions would work just as well, while allowing me to remain in control. That is a good point though, as Bastio would be able to create unrestricted administrative users anyway.
Where are your encryption keys stored in relation to our connection data?
Where are your encryption keys stored in relation to our connection data?
There are multiple layers of encryption and the keys are distributed in such a way that the client must login and provide the data facet we store in the browser. The combination of this and other data facets provides the combination that unlocks the private key we use to conduct deployments.
with a catchy domain like bastio, perhaps you should try pivot into doing something actually more useful like bastion host as a service w/ 2-factor openvpn authentication.
We were originally going to create a bastion but got some early feedback that server admins wanted user management, and a bastion as a side feature. We've got two-factor auth right now. Would you use a bastion + user management, or if not, what's your need for the bastion besides the need for a solid, secure, locked-down entry point?
to be honest, it'd have to be coupled w/ ec2 or some other cloud providers, that presets proper deployments with firewall/authentications. that'll be then something i'll definitely be interested in.
did you write your own valid email address checker regex?
It doesn't follow http://tools.ietf.org/html/rfc5233
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.