Re: Am I compromised
On Sat, Dec 03, 2005 at 10:41:18PM +0000, Andrew M.A. Cater wrote:
> On Sat, Dec 03, 2005 at 08:17:33PM +0530, Ritesh Raj Sarraf wrote:
> > For now I've disabled php/perl on the server and it's working fine.
> >
> > I have one question which I think people here can give better ideas
> > on: The server is a webserver running multiple Virtual Hosts.
> > I can't/shouldn't restrict my users (Virtual Host owners) from
> > uploading any script/program to their webroot directory. Now if one
> > of my user is using a vulnerable script, say awstats, it effects the
> > whole server.
> >
>
> You can and should restrict your customers in the best interests of
> your OTHER customers and your own welfare.
yes. couldn't agree more.
given the potential danger of CGI scripts etc(*), your customers must be
aware that they will be audited by you, and that they can be disabled or
deleted at any time if they are found to cause a problem - security or
otherwise - on your system.
(*) this is effectively the same as them having a shell account on your
machine. any compromise that requires shell access can ALSO be achieved
with a script - including perl cgi and php scripts.
> > What is the best practise to handle such situations ?
>
> It may be worth providing safe/secure alternatives to unsafe software
> and to provide some security advice to indicate _why_ scripts are unsafe
> if not audited. Charge a small fee for auditing scripts and a larger
> fee for modifying them to be script safe??
you can make it easier/less work on yourself by installing and auditing
just one version of common scripts.
for example, install the latest debian package of awstats and tell your
customers that the system installed version is the ONLY version which is
acceptable. any other versions found on the system will be deleted on
sight, without notice.
to make it easy for your customers to access it, you can do one of two
things:
1. put a symlink in their cgi-bin directory called 'common', which points to
/usr/lib/cgi-bin/ (i.e. ~/cgi-bin/common/ -> /usr/lib/cgi-bin).
2. put a ScriptAlias in their VirtualHost config in apache, defining
/cgi-bin/common/ as /usr/lib/cgi-bin/
both of these do the same thing, they allow the customer to refer to common
cgi scripts (like awstats, formmail, etc) with:
http://their.domain/cgi-bin/common/script.name
one other thing you have to do is remember to check the logs for signs
of unapproved CGI scripts. having a security policy wont save your
systems if it isn't enforced.
btw, the fact is that 90+% of vhost web sites just want a formmail
script and nothing else. provide a good one and most of your CGI
auditing work is done.
craig
--
craig sanders <cas@taz.net.au> (part time cyborg)
Reply to: