Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Context:

  • Small business, mostly a software house for web applications but also some desktop software.
  • Many external collaborators, so a variety of outside users with access to the servers.
  • Single physical server, with Linux and Xen as a virtualization solution - each VM has specific uses and controlled access. External users can access two of them
  • The (virtual) servers provide a variety of services: LAMP stack, email, DNS, etc. This question pertains to my concerns with local user access
  • Users can SSH into two of the VMs

Requirements

  • Give users access to common development tools, both for web (PHP, Ruby on Rails, etc) and standalone applications (gcc, g++, etc); this includes not only compilers and the like but also editors. Right now, they have full shell access.
  • Users must be able to use source control on the server: svn and git
  • Some have access to MySQL databases

Question

What steps should I take in order to:

  1. Provide a full shell to the users if possible, or equivalent solution that meets the requirements above in a safe manner
  2. Automate monitoring of dangerous activities where possible (as in sudo/su notifications)
  3. Minimize effects if a user gets his hands on a 0day privilege escalation exploit before someone patches it on the server - is this even possible?
share|improve this question
    
Tough question--providing a shell and compiler to users gives them a lot of power. But what do you want to secure against? Just privilege escalation? Reading or modifying other users' data? Leveraging of your server as a launchpad for further attacks? –  user502 Jan 12 '11 at 20:25
    
Yeah, perhaps it's too broad and I should split the question? My main concern is privilege escalation as I have other things in action preventing tampering: tripwire, correct perms, users partition mounted with no suid.. I'm looking for ways I can protect (read: mitigate risks) on such an open system: shell+compiler. –  tomeduarte Jan 12 '11 at 21:40
1  
Just to clarify: •Users can SSH into the server is that the physical server, or each of the virtual servers? –  AviD Jan 13 '11 at 6:20
    
Only the two virtual servers they have access two. I'll edit the original question about that. –  tomeduarte Jan 13 '11 at 11:00

3 Answers 3

up vote 9 down vote accepted

If users must have SSH to your server, a useful tool to protect your server root is chroot - this will let you give them the apparent functionality of server root, without actually giving them the crown jewels.

Alternatively, as you use virtual machines anyway, why not provide them with virtual server instances?

Both of these will allow you to run monitoring tools (such as tripwire) in order to check for changes to files. Logging should be done outside the users' environment.

With entries in /etc/sudoers you can limit what activities users are allowed to carry out under su.

share|improve this answer
    
I wasn't aware that sshd was chrootable, never seen it setup like that nor ever did it that way. Thanks, +1 if I could :). I have tripwire on the critical system files and sudoers only allows the system administrators. –  tomeduarte Jan 12 '11 at 21:44

You can also restrict users to using bash 4 (removing other shells) and record all commands and send copies to a separate log server.

Bash: History to Syslog (http://blog.rootshell.be/2009/02/28/bash-history-to-syslog/)

This can help you audit user activities and, more importantly, perform forensics when someone does something bad. I would also do the full legal disclosure thing - all activities are recorded and audited, violators will be prosecuted, etc.

Deploying OSSEC (Host-based Intrusion Detection System) would help as well; it has many built-in rules to detect and alert you to bad things. OSSEC can alert you to all sudo/su activity.

share|improve this answer

Do not forget about tunneling, port forwarding. By default AllowTcpForwarding is yes in sshd_config file and it allows users to forward arbitrary ports. It may cause much more trouble than you can guess. (This is not an ideal stackexchange style answer but I could not find a better answer, it's hard to summarize port forwarding with a few sentences) You should learn more about port forwarding before allowing access.

Port forwarding in a nutshell

SSH permits multiplexing data streams over a single SSH connection. One or more of these streams can be a port forward, such that traffic to a port on the attacker's client computer is sent over the SSH connection to a specified port on a specified host from the server. This means that if your shell server has access to, for instance, a MySQL server, then anyone who connects to the SSH box can access the MySQL server directly. They can then use their own client tools rather than being limited to the software you've supplied on the SSH box.

share|improve this answer
    
I think I'll look this up, never heard of exploiting it and looks like a good tip. –  tomeduarte Jan 12 '11 at 21:45
    
OSCP training contains an entire module dedicated to port forwarding, tunneling and related attack types. So it's really important –  Nathan B. Jan 12 '11 at 22:18

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.