Securing webserver

R

redeye

Verified User
Joined
May 11, 2004
Messages
145
I've now been trying to get our webserver more secure. Biggest problem is that users can view eachother documents, using exec, shell_exec, and all the other tricks.

Safe mode isn't prefered, openbasedir is installed on php, disable functions isn't possible because of the high amount live websites on the system that rely on them.

The only options I found are suPHP and fastCGI to run the procesess under users id.

Who can advise what steps to take and why.

I've tried suPHP, but can't get php to build as CGI, don't know why :(


Please, I'm getting desparate.

ThX Redeye
 
Common guys, I can't imagine that I'm the first one with this, insecure, potential high risc installation of DA.

Yeah yeah, I know, it's not a DA issue, but DA installs allmost everything where you think you are safe, but you arn't.

Help me out here.
 
I don't really see how this is a DA issue, especially since you've told us you don't want to use safemode.

What method built in to php would you like to see DA use?

Jeff
 
no da issue

I know it isn't a DA issue, I wrote that, but it'e mods a common problem, that everyone that is not running in safe has. I'm asking other users how to solve this, because there must be more users having this problem.

I would like to be able to run apache more secure, with UID an GID for instance. I think DA would be doing their customers a favor by supporting an more secure alternative then only safemode.
 
I'm still confused; what do you mean by running apache more securely?

Apache is already running as user apache. What would you prefer.

I'm looking for some constructive help here; to understand specifically what you're asking for.

Jeff
 
He wants php secure. Apache is already secure enuf, imo. We also tried installing suPHP. But since we're are using PHP5, I suspected suPHP from not being compatible (couldn't get PHP5 compiled as CGI either). I'm going to work that out sometime, when PHP5 is more common.

Jochem
 
The basedir restriction should take care of this :confused:

As far as I know users can't access files outside their /home/[username]. Because of the basedir restriction (if set correctly offcourse).
 
Very true (don't forget to add /tmp too, for uploads and stuff).

But I would choose suPHP anyway: it execute php scripts under the user's name, and therefor makes it easier to find an abusing user. And it's better then phpsuexec, because it doesn't restrict the user (it's less secure then phpsuexec, tho).

Jochem
 
fusionictnl said:
The basedir restriction should take care of this :confused:

As far as I know users can't access files outside their /home/[username]. Because of the basedir restriction (if set correctly offcourse).
Click to expand...

True, but when you use, shell_exec, exec, etc, basedir restriction is bypassed, and I can view every file in every webdir hosted on the same maching when I know the exact path, but that isn't hard. So even includefiles with db info (usrname/pass) of other users.
 
XBL said:
Very true (don't forget to add /tmp too, for uploads and stuff).

But I would choose suPHP anyway: it execute php scripts under the user's name, and therefor makes it easier to find an abusing user. And it's better then phpsuexec, because it doesn't restrict the user (it's less secure then phpsuexec, tho).

Jochem
Click to expand...

That's what I'm trying to do, but I have to compile php in cgi mode, and that won't work. Even with --enable-cgi, php stays in CLI mode. I'm not the only one with this problem.

These are my compile settings:

#!/bin/sh
./configure \
--with-apxs \
--with-curl \
--with-curl-dir=/usr/local/lib \
--with-gd \
--with-gd-dir=/usr/local/lib \
--with-gettext \
--with-jpeg-dir=/usr/local/lib \
--with-kerberos \
--with-mcrypt \
--with-mhash \
--with-mysql \
--with-pear \
--with-png-dir=/usr/local/lib \
--with-xml \
--with-openssl \
--with-zlib \
--with-zlib-dir=/usr/local/lib \
--with-zip \
--with-imap=/usr/local/imap-2000e \
--enable-bcmath \
--enable-cgi \
--enable-calendar \
--enable-ftp \
--enable-magic-quotes \
--enable-sockets \
--enable-track-vars
 
Running php in CGI could cause new problems. So be sure to take all the patches with is.. Google arround and read all there is on suexec en suphp ;)
 
I'm trying suphp, but can't get it to work.

To use suPHP, the manual says to enable php-cgi ;)

I get internatserver errors. http-log gives unable to access. /home/........... etc.



Files are owned, and readable.

Searching the web, done that the past 2 weeks. I'm stuck, and nobody could help sofar. :(
 
Last edited:
Since some 'problems' with phpbb I really am thinking of implementing suphp on our shared servers...
But the problem is I can't make any mistakes, one thing fails and I have too much downtime (testserver is other config).

Oh btw, the openbasedir restriction doesn't take care of everything, you should use it in combination with safe mode (yeah, that's from my experience :(). 2nd note: DA tends to put a # before the open basedir line in httpd.conf's while updating to next version, so you have to do that all over again each time you update to next version. (and than make DA rewrite the configs)
 
redeye said:
That's what I'm trying to do, but I have to compile php in cgi mode, and that won't work. Even with --enable-cgi, php stays in CLI mode. I'm not the only one with this problem.

These are my compile settings:

#!/bin/sh
./configure \
--with-apxs \
--with-curl \
--with-curl-dir=/usr/local/lib \
...
Click to expand...


I've had this problem in the past. Remove the "--with-apxs"
and compile to get the cgi version.
 
You must log in or register to reply here.
Back
Top