Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

potential security concern with non-root level account

Posted on 2006-07-13
5
Medium Priority
?
284 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 672 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 664 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 664 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 learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

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
We’ve all felt that sense of false security before—locking down external access to a database or component and feeling like we’ve done all we need to do to secure company data. But that feeling is fleeting. Attacks these days can happen in many w…
Please read the paragraph below before following the instructions in the video — there are important caveats in the paragraph that I did not mention in the video. If your PaperPort 12 or PaperPort 14 is failing to start, or crashing, or hanging, …

609 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