SSH access to a person doing web development

I've always been running the servers solo, having just one login accout to do stuff. However now the need has arisen to allow another person shell access to run commands such as php and the likes of find and grep. Without going into too many details, what would be the safest way(s) to limit their interaction with the rest of the system? For instance, limit the programs they may run, limit access to filesystem in general et cetera. Basically, limit everything to just their scope of work, which is developing a single e-commerce website on a server that also hosts email services, DNS and multiple unrelated websites, but without going overboard with security. Currently no jails are used there. Any general pointers on what to do, where to start, etc? This is all new to me. I know how to do limited SFTP access and it's working nicely, but not when it comes to a full-fledged shell.
 
However now the need has arisen to allow another person shell access to run commands such as php and the likes of find and grep.
Just give them a user account, they don't need any 'elevated' privileges to do this. Create a group that has write permissions on the web root, make this user a member of that group, so they can edit those files.

Without going into too many details, what would be the safest way(s) to limit their interaction with the rest of the system?
Regular users can't change any of the configuration. You need root access for most of those.
 
what would be the safest way(s) to limit their interaction with the rest of the system?
No access to live systems. Instead, install a development system, host all the code in some SCM (e.g. git), set up a deployment pipeline allowing for automated deployments to the live system following some approval process. Well, you asked for the safest way. :cool:
 
No access to live systems. Instead, install a development system, host all the code in some SCM (e.g. git), set up a deployment pipeline allowing for automated deployments to the live system following some approval process. Well, you asked for the safest way. :cool:
This would also allow you to easily implement DTAP. Development code would get checked out to a development server, etc.
 
SirDice I was going to give them a non-root account, was just worried they may have access to other sensitive places like logs (fixable by permissions, I know) or tmp directory or some other place in the filesystem "I never knew existed", basically any place where other has read access... I just don't know how bad that can be, or just irrelevant if the system itself has mostly stock defaults.

zirias@ Fine advice of course, which I support, but it sure will take time and resources, which I'm trying to balance against a possible security risk.

Then again, nothing preventing them from slipping in a piece of PHP code that scours the FS afterwards, even a development system won't save from that.
 
Then again, nothing preventing them from slipping in a piece of PHP code that scours the FS afterwards, even a development system won't save from that.
That's why you typically have some approval process before deployment to prod, with only trusted people being able to approve a change after manual review ;)
 
@SirDice I was going to give them a non-root account, was just worried they may have access to other sensitive places like logs (fixable by permissions, I know) or tmp directory or some other place in the filesystem "I never knew existed", basically any place where other has read access... I just don't know how bad that can be, or just irrelevant if the system itself has mostly stock defaults.
You already trust them enough to write code that's being run on the system. If you don't trust them to treat the system and the information it contains with respect you shouldn't trust any of their code either.
 
I'm a contractor, for many of the jobs I have to present a certificate of conduct, or VOG as it's called in Dutch, before I'm even allowed to touch anything. Many of the systems I have to deal with store a lot of private information. Most of the time I have full access to everything because the job requires it. But just because I have the access doesn't mean I can just nose around in that private data. I would be fired on the spot and probably taken to court too. Then lose my VOG and won't be able to get a job somewhere else.
 
You already trust them enough to write code that's being run on the system. If you don't trust them to treat the system and the information it contains with respect you shouldn't trust any of their code either.
That's fair...ish, but what it really boils down to is probably separating that particular website from everything else, development or not. So that means a jail (good idea? never worked with those) or a separate system.
 
That's fair...ish, but what it really boils down to is probably separating that particular website from everything else, development or not. So that means a jail (good idea? never worked with those) or a separate system.
Development should really be done on a separate, closed to the outside world, system. You don't want to run a half finished, possibly buggy and vulnerable, website on the same system as your production websites.
 
SirDice You know with Magento development (which is what's going to be happening there) it's extremely hard to find a contractor. I'd be happy to find a reputable company but it's an absolute hell. Their websites are all similar, most of the time you never know if there's one guy working there, or a team, where they come from, can they speak English so that the work is efficient, et cetera. Off-topic, but if you have any specific magento-dev-related recommendations, I'm all ears. I did manage to find outstanding regular website developers though by a happy accident.
 
So that means a jail (good idea? never worked with those) or a separate system.
Running a webserver in a jail is a good idea. You can run sshd in that jail so that the web-developer can ssh directly into the jail.

And you can extend this to running two jails a development-jail and a production-jail.

If you never used FreeBSD jails, this is the time to start with it.
 
Don't have the development website be accessible from the internet though. Companies get easily hacked that way. The "front door" (the production websites) was properly secured but they had a test/development website accessible and hackers got into their network through that.
 
Well, that would be interesting in the jail case. Doesn't a jail prevent just that?
Both production and development sites often have connections to backend servers further up the network. Your "front door" production site might be properly secured but they'll walk in via that half finished, potentially buggy and vulnerable, test/development website. Those development servers (or jails) typically have all sorts of tools and utilities installed that are then weaponized against you. You've given your attackers a stepping stone and they'll put a foot in the door, to pry open and get more access. Best not to give them the opportunity at all.
 
Well, that would be interesting in the jail case. Doesn't a jail prevent just that?
In some cases, if your Jailed machine gets compromised (i.e they can log in it as a user or root), they might now be behind certain firewalls. So they can start mapping the network and testing for ports.
 
As you'll have gathered, there's no "best" way to do this. Always going to be compromises, always going to suck up some of your time and resources.

A jail or two will allow you to compartmentilize (is that a word?) certain functionality/areas - but then you've got to set them up and maintain them.

With PHP contractors we've worked with we've never let them have any access to the production systems, only development. But then we have to code review all their changes (and sometimes they "forget" files they've changed) so any deployment is a time-sapping exercise. Yes there are lots of tools to automate this, but then you've got to learn them and none of them are bullet proof.

So to start with (especially with a contractor you've not worked with before) - a completely separate dev. server is the way to go. Allow them ssh, use a high port (yes, it's not remotely bulletproof but will save some log noise), use AllowUsers, insist on no-password loings (i.e. use keys), if they've got a static IP block the ssh traffic to that IP and so on. Make sure any dev. passwords and accounts are very different to real production accounts. If they trash development that's annoying but at least your production server(s) are OK.

See what tools you can find that can diff dev. to prod and then at least you might have a clean diff list (but if they've just tweaked some files to try something that isn't needed it breaks down ...)

And at this point you might need a test server in the middle - so you copy their dev. changes to the test server, test, then deploy to production.

Treat all development and test servers (and backups) as production - same firewall rules, same lockdown processes, etc.
 
even with a jail the user can view the host system files , I dont know if is a ezjail bug o missed configuration
 
You could use a version control system like git. There he can only check in and out production code and never touch the system. Everything runs on his own computer.
 
Magento requires CLI access in most cases for development, that's to enable modules, do indexing and flushes and so on. I think the best way would probably be to let them develop everything locally, starting from a dump of what you give them, but many resist for some reason. I don't know if that's a standard practice. That way you'd only need to code review, without having to worry about another user on your systems. But unfortunately code review is out of my reach completely, no way I'd be able to unobfuscate some piece of code slipped in and the changes made during development may be numerous.

The developers may have their own security concerns over the code that I give them, if they're not starting from scratch.

So that basically leaves it to an issue of trust, meaning it has to be someone you know personally inside and out or someone with a certificate similar to SirDice's VOG.

Unless I missed some knowledge shared in this thread, any PHP code without audit will be a potential security hole. I'm not sure if "minimizing" threats is not similar to security through obscurity in principle.
 
Allowing random people shell access to a server is asking for trouble. Don't do it.

The safest thing would be to run your prod web service in a jail. Then also run a test/dev instance in another jail. When your developer has finished their work, simply rsync the work they've done to the prod jail.

If the test/dev jail becomes compromised you can easily restore it from the prod jail (minus passwords and anything else that's sensitive). It requires a little planning.
 
Back
Top