Solved

potential security concern with non-root level account

Posted on 2006-07-13
5
281 Views
Last Modified: 2010-04-22
I'm assigning a lot of points (I think) in hopes that I can distribute the points according to the number of answers I get. I hope that's not considered lame.

Recently as a systems admin I was asked to create a non-root level access account on a web server. The environment is two web servers with one of those servers also providing the staging environment. This was put into place before my time and I've fought ever since to get the client to aquire a staging server on separate hardware. Also, there is only port 22 access open to the environment from the client's IP and our IP. Also, obviously port 80 is open to the world.

The question is or the debate is whether creating a non-root level account for the client on one of the web servers is a security risk worth worrying about. The account would have ssh access to the box and be able to make changes to the directory structure underneath the staging directories.

My concerns are that not only is this a bad idea because we have the burden of making sure the sites that are hosted are available but also that maybe there is something I'm overlooking in terms of write access to the filesystem. This new user would only have write level access via a group membership to /var/www/html/staging while being barred the same access to the production environment that is located under /var/www/html/production. What are the potential problems with this scenario? Also is it trivial to gain root level access once an account is created?
0
Comment
Question by:ekeyser
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
5 Comments
 
LVL 24

Accepted Solution

by:
slyong earned 168 total points
ID: 17105153
Hi,

looking at your posting, I realized that you don't really trust your client very much (which is a good thing as a system admin).  Running the staging and production server on the same hardware already opens up a whole lot of security issues like they can upload exploit codes into the staging and I am not sure whether the codes are being reviewed before moving to production system.

Coming back to your question about non-root access, the best bet I could think of is doing a chroot environment to cage them into just /var/www/html/staging so that they won't move out from there.

One point that I am concerned about is the web servers, are they different web servers running?  You also have to check the permission of the staging web server.  If someone can upload a piece of exploit code and ask the web server to run it, the system can be quite easily compromised.

0
 
LVL 18

Assisted Solution

by:decoleur
decoleur earned 166 total points
ID: 17116155
ekeyser-

you are right there are issues with this configuration.

allowing your client non root access to a production system is a "bad" idea.

If I have SSH access to a system on your network, I can cause problems for you:
For example I can use the SSH service on the server as a gateway into your network and gain access to any machine that is accessible on the network to your production machine using a technique called tunneling over SSH.
If I have SSH access to a system on your network I can upload files onto your machine using SCP that I can use later on.
If I have SSH access to your machine I can execute commands that could call upon local binaries (that I jut put there) or remote services that could provide the ability to perform an escalation of priviledges that would result in the gaining root level access on your machine.


allowing your client to use the production system as a staging environment is also a "bad" idea.

For example if I am using a machine for staging an application that I am developing, I am doing a lot of work on it, this can cause problems.
I could be developing a dynamic application that has a scripted environment that could become unstable and lock up the application or the machine.
I could be developing an application and shutdown the wrong service and kill the production application.

... i could go on for a while.

IMHO it takes too much time to set up a chroot jail and it is not fool proof, restricted bash can also be gotten around.

I would look at getting a virtualization server and set up a vmware image for the client and let them have at it, that way you can mitigate their impact on other resources... prefereably in a different DMZ from your internal and production environment. And if they hose it, you can always roll back to a previous snapshot.

hope this helps

-t
0
 
LVL 40

Assisted Solution

by:noci
noci earned 166 total points
ID: 17118202
Non production environments should NEVER be on production systems...

At least assuming that code gets a review when placed on the production system.
Normaly you build an DTAP train.
Development   - clear enough... (per developer if needed)
Test - Tests (integration tests) all development parts put together (development team is in the lead)
          (still fixing bugs etc.)
Acceptance (frozen code, this is the release to go to production when ready. test in jurisdiction
   of customers, systems management & auditors, production alike server. it passes or flunks as a whole.)
Production ( noaccess except for maintenance & backup).

These needn't be real servers of course, Virtal servers (Xen, VMware, LPAR, Virtual Server, User mode Linux) might help here too. Some of these virtualisation tools might also have extra benefits
Xen & VMware-ESX allow moving executing virtual machines from one physical system to another without stopping the virtualized systems.

Also there are a lot of exploits in the world that get a moderate severity because you need local access to the system to exploit them..., but if you have LOCAL access, these kind of Vuln's are HIGH risk.




0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Hello EE, Today we will learn how to send all your network traffic through Tor which is useful to get around censorship and being tracked all together to a certain degree. This article assumes you will be using Linux, have a minimal knowledge of …
Fine Tune your automatic Updates for Ubuntu / Debian
Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…
This is my first video review of Microsoft Bookings, I will be doing a part two with a bit more information, but wanted to get this out to you folks.

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question