Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi All,
We have a number of web servers in our datacenter which are accessible from the internet (ports 80/443). But we don't expose their sshd ports to the internet.
Our web developers want to work from home, and very easily use ssh and git from their home clients to their web servers, and are asking for port 22 (or higher) on each web server to be exposed.
They want to use ssh keys to authenticate (hopefully with a passphrase).
Some of us are concerned that a compromised client could cause the company significant grief, potentially to all our web servers at once, and don't want to take the risk.
Is there a solution that we might all be happy with, potentially? Or, maybe some good practice we can use to limit their expectations?
Thanks for any help.
Svejk
They want to use ssh keys to authenticate (hopefully with a passphrase).
No need to say "hopefully": just enforce it.
Quote:
Originally Posted by svejkit
Some of us are concerned that a compromised client could cause the company significant grief, potentially to all our web servers at once, and don't want to take the risk.
The problem here is you haven't defined what you consider "grief"... Draft a company policy that defines (un)acceptable use and repercussions and ensure all developers agree. If you own the personal computers they work on then ensure auditing and reporting (and where appropriate: checks on licensing, malware, viruses, PUA) is enabled. Set up auditing on all accessible hosts and make them log to a central impenetrable syslog host. Deny users the right to 'su' and only allow them specific commands via the use of Sudo (also see rootsh). Ensure proper host hardening. Create a new host and assign it the role of SSH gateway. Allow developers to only SSH tunnel into that bastion host as unprivileged user with pubkey auth and set up SSH tunnels from there into the private network range. This may not cover all bases but at least it enables you to build audit trails, verify users movement and take action if corrections seem necessary.
If these are "production" web servers then your web developers shouldn't be going anywhere near them and shouldn't have the ability to push any code to them.
However, if you are going to do this then you should also consider some form of two factor authentication for their ssh connection and possibly the use of a "jumpbox" server to minimise your attack footprint. Users can ssh to the jumpbox with two factor authentication and then make use of internal ssh tunnels to access specific hosts.
Exposing SSH like that is not worth the risk, even if you are using Key Authentication. I think it would be best to have them VPN in before being able to SSH. Whatever solution you come up with, it is essential that you implement least privilege. Developers, who naturally think about how to make things easier and simpler, are not the best security folks.
The problem here is you haven't defined what you consider "grief"... Draft a company policy that defines (un)acceptable use and repercussions and ensure all developers agree. If you own the personal computers they work on then ensure auditing and reporting (and where appropriate: checks on licensing, malware, viruses, PUA) is enabled. Set up auditing on all accessible hosts and make them log to a central impenetrable syslog host. Deny users the right to 'su' and only allow them specific commands via the use of Sudo (also see rootsh). Ensure proper host hardening. Create a new host and assign it the role of SSH gateway. Allow developers to only SSH tunnel into that bastion host as unprivileged user with pubkey auth and set up SSH tunnels from there into the private network range. This may not cover all bases but at least it enables you to build audit trails, verify users movement and take action if corrections seem necessary.
Have someone OTHER than the web developers preform backups of the data on a regular basis. The most dreaded nightmare would be a disgruntled employee destroying everything from home just as they quit their job.
Have someone OTHER than the web developers preform backups of the data on a regular basis.
No idea why your reply required you quoting me but since you did: making (and hopefully testing) backups commonly is an automated process not involving any human interaction. (So if you allow any human to make backups, especially web developers, then you've obviously got yourself a recipe for disaster...)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
