Re: Security question concerning jail or virtualization
On 14/03/14 13:50, Martin Braun wrote:
> Hi
>
> I have recently experienced a server being "hacked" due to a security
> problem with a PHP application that made it possible for the "hacker" to
> gain a web shell.
Has that problem been rectified?
If not then virtualization won't solve the problems, at best it'll just
restrict the types of problems - you can still find the content hijacked
and traffic redirected.
>
> Due to this experience I would like to know what the best way to limit
> such problems is, especially when hosting web servers for users who may
> or may not installed unsecure applications on the web server.
If user applications can access to OS then you have a permissions
problem - the php application flaw was just the vector.
>
> What does the big hosters do? What do they use?
A range of measures.
>
> The solution can't be too complecated to maintain and I would prefer
> each user being completely seperated from the main OS and from other users.
Your preference *is* how "the big hosters" do things.
>
> I have been thinking about running Debian inside FreeBSD Jails or "The
> Warden". I have also been thinking about using Xen and installing
> several Debians on Debian.
>
> What is the best (and if possible simplest) way to deal with this?
The "simplest" way to do things is to install a very basic Debian stable
the use the Virtualmin script to install the rest of the Debian packages
needed for the server. Setup accounts for each user, their applications
will then run in $user/public_html.
>
> Kind regards
It's a trivial attack[*1]) and bad php alone usually is not the cause.
Check php.ini and ensure you haven't accidentally enabled dangerous
configurations e.g. shell_exec, passthru, system etc. If you *do* have
a compelling reason for enabling those functions consider whitelisting
and input filters. But don't rely on those alone - bad php is often the
cause (don't trust unknown php e.g. user submitted extensions and
plugins for CMS - even when you trust the intentions of the writer
that's no reason to trust the code). Make sure data is sanitized and if
you have a compelling reason to enable OS commands with php consider
wrapping them in java.
If you have allow_url_fopen enabled make sure you have a compelling
reason for it. I've never found one, by my experience far from covers
all use cases.
Ensure that open_basedir is enabled in php.ini
*Double and triple check your webuser permissions*
Test your security:-
As the web user (change /var/www to suit your situation e.g.
$user/public_html)
$
Search_Dir="/var/www";Problems="passthru|shell_exec|system|phpinfo|base64_decode|popen|exec|proc_open|pcntl_exec|python_eval|fopen|fclose|readfile";
grep -RPl --include=*.{php,txt} "($Problems)" $Search_dir
Install and run ClamAV and don't forget that perl may be where the
malware is based.
When you are certain that you system is clean and secure, backup the
static files to a remote location and md5 or pgp them so you can check
them against you web server at a later point to *prove* your system
hasn't been breached.
Then install an IDS.
[*1]can be as simple as weak file permissions or a dodgy cms allowing an
attacker to upload the following
<?php
echo shell_exec('cat '.$_GET['command']);
?>
Hope that helps - it's a big question, and so is the answer.
Web applications is a nebulous description, like the information about
your server - so a detailed response is beyond the limits of a post (and
my available time).
I'm glad you asked though instead of making the mistake of looking for a
"silver bullet" solution on a random web page. It's not just irritating
for you when you server gets cracked - it affects all of us.
Kind regards
P.S. Don't forget to check Google Webmaster in case your site/s have
been reported so that you can request the necessary changes.
Reply to: