Mailing List Archive: Gentoo: Security

about php security.. big apache+php deploy

Index | Next | Previous | View Threaded

miguel.filipe at gmail

Dec 21, 2004, 12:16 PM

Post #1 of 12 (894 views)
Permalink

about php security.. big apache+php deploy

Hi there,

To put things simple, I'm a bit worried with php, here's why:

I don't know SHIT about securing php instalations...
I've read about hardened-php, and I wondered if someone uses it, and
how reliable and intrusive they are ( false positives interest me
especially).
Also I would like to receive input from mod_security users...from what
I understood, if that's enabled, then in a php forum I cannot
write/quote SQL code in my posts... (sql injection prevention..)

The problem is a big server, 6000 acounts with
apache+suexec+user_dir+php, on a solaris machine.
I plan to try changing config options and security settings so it
becomes a bit more hardened.

Any advices are welcome.

ps: don't "advice" me to close the server, deny funcionality, etc,
these won't do... the server exists, has the acounts and I got to live
with it...

--
Miguel Sousa Filipe

--
gentoo-security [at] gentoo mailing list

krispykringle at gentoo

Dec 21, 2004, 4:07 PM

Post #2 of 12 (857 views)
Permalink

Re: about php security.. big apache+php deploy [In reply to]

On Tue, Dec 21, 2004 at 07:16:06PM +0000, Miguel Filipe wrote:
> I don't know SHIT about securing php instalations...
> I've read about hardened-php, and I wondered if someone uses it, and
> how reliable and intrusive they are ( false positives interest me
> especially).

Never tried it. Speaking as a critic, I'd say it's about damn time
that some of the PHP developers realized a security initiative was in
order. And it's been showing a lot of public progress, in the form of
vulnerability reports, so I'd say it's making a lot of good progress.

> Also I would like to receive input from mod_security users...from what
> I understood, if that's enabled, then in a php forum I cannot
> write/quote SQL code in my posts... (sql injection prevention..)

Don't know anything about this, but to say that a) PHP magic quotes
claims to fix this, but allegedly does so imperfectly (as is my
underestanding, at least) and b) a well-written app should understand
and counter this risk (and a well-written language should provide the
means to do so).

> The problem is a big server, 6000 acounts with
> apache+suexec+user_dir+php, on a solaris machine.
> I plan to try changing config options and security settings so it
> becomes a bit more hardened.

PHP safe mode is a start, but not a finish. SUexec is limited to CGIs,
if I'm not mistaken; if you're running mod_php this won't help. I
think I saw a similar thing for mod_php, but i can't recall the
name. Nonetheless, I think this is of real importance for both
security and ease of use (users can have scripts do more if they run
as the use, after all--more in a good way).

--
Dan Margolis
Gentoo Security/Audit

haimat at lame

Dec 21, 2004, 7:33 PM

Post #3 of 12 (857 views)
Permalink

Re: about php security.. big apache+php deploy [In reply to]

---------- quoting Miguel Filipe ----------
> Also I would like to receive input from mod_security users...from what
> I understood, if that's enabled, then in a php forum I cannot
> write/quote SQL code in my posts... (sql injection prevention..)

mod_security can do a lot more than that. You can parse and filter whole
http streams from and to the server with it. For example, you can filter
for "wget" (or SQL stmts or whatever) in REQUESTs, GETs etc. and - if
found - redirect to 404 page. Or you can fake your server signature to
"Microsoft-IIS/5.0" (not 100% fail safe). Things like that -- have a look!

Some more Apache/PHP hardening: I use chroot'ed Apache sites. Not for the
whole Apache installation, but for every single virtual host. You can do
that with "mod_diffprivs" [1]. With this mod it's also possible to run
this virtual host under another user account. But since only root can make
such system calls (and you do not want to run Apache as root), I use a
kernel patch called "erup" [2] to give normal user accounts this
privileges.

This way you can run every hosted website under it's own jail and with it's
own user account (which is good for jail'ed SSH accounts as well...).

For more information please visit your local google page ;)
HTH! Greetings, Matthias

footnote:
[1] http://lw.ftw.zamosc.pl/mdp/
[2] http://www.wijata.com/software/#ERUP

--
That's weird. It's like something out of that twilighty show about
that zone.

-- Homer Simpson
Treehouse of Horror VI

--
gentoo-security [at] gentoo mailing list

klaus at it-austria

Dec 22, 2004, 3:03 AM

Post #4 of 12 (857 views)
Permalink

Re: about php security.. big apache+php deploy [In reply to]

On Tue, Dec 21, 2004 at 07:16:06PM +0000, Miguel Filipe wrote:
> Hi there,
>
> To put things simple, I'm a bit worried with php, here's why:
>
> I don't know SHIT about securing php instalations...
> I've read about hardened-php, and I wondered if someone uses it, and
> how reliable and intrusive they are ( false positives interest me
> especially).
> Also I would like to receive input from mod_security users...from what
> I understood, if that's enabled, then in a php forum I cannot
> write/quote SQL code in my posts... (sql injection prevention..)
mod_security has the advantage, that malicious access is immediatly
intercepted and does not hit your php apps, but is quite tricky,
when it comes to false positives.

if you know your applications well, you can be quite restrictive
and prevent all sorts of sql injection, but if you know your applications
well, you could fix them to do proper input validation.

at least you can use mod_security as an IDS an log malicious access
... may help in some cases
>
> The problem is a big server, 6000 acounts with
if 6000 acounts means 6000 application spaces you are quite in trouble

my suggestion is to lock down the whole apache+php in an own chroot
to separate it from the system.
separation of the applications one from the other would be fine,
but this would break usage of VirtualHosts and would need an apache
instance per application.
> apache+suexec+user_dir+php, on a solaris machine.
> I plan to try changing config options and security settings so it
> becomes a bit more hardened.

the problem with those settings is that some applications
won't work correctly, and the settings doesn't help if your
php version is broken (-> the Never... worm)

>
>
> Any advices are welcome.
>
> ps: don't "advice" me to close the server, deny funcionality, etc,
> these won't do... the server exists, has the acounts and I got to live
> with it...
>
> --
> Miguel Sousa Filipe
>
> --
> gentoo-security [at] gentoo mailing list
>
>

--
gentoo-security [at] gentoo mailing list

gentoo at pertl

Dec 22, 2004, 3:56 AM

Post #5 of 12 (857 views)
Permalink

Re: about php security.. big apache+php deploy [In reply to]

On Tue, Dec 21, 2004 at 06:07:23PM -0500, Dan Margolis wrote:

DM> PHP safe mode is a start, but not a finish. SUexec is limited to CGIs,
DM> if I'm not mistaken; if you're running mod_php this won't help. I
DM> think I saw a similar thing for mod_php, but i can't recall the
DM> name. Nonetheless, I think this is of real importance for both
DM> security and ease of use (users can have scripts do more if they run
DM> as the use, after all--more in a good way).

I use suphp[1], it runs php-scripts as a different user and is very
similar to suexec.

HTH
Roman

[1] http://www.suphp.org

--
gentoo-security [at] gentoo mailing list

miguel.filipe at gmail

Dec 22, 2004, 6:23 AM

Post #6 of 12 (857 views)
Permalink

Re: about php security.. big apache+php deploy [In reply to]

On Tue, 21 Dec 2004 21:37:43 +0200, Matan Peled <chaosite [at] gmail> wrote:
> Miguel Filipe wrote:
>
> >Hi there,
> >
> >To put things simple, I'm a bit worried with php, here's why:
> >
> >I don't know SHIT about securing php instalations...
> >I've read about hardened-php, and I wondered if someone uses it, and
> >how reliable and intrusive they are ( false positives interest me
> >especially).
> >
> >Also I would like to receive input from mod_security users...from what
> >I understood, if that's enabled, then in a php forum I cannot
> >write/quote SQL code in my posts... (sql injection prevention..)
> >
> I'm pretty sure thats not the case... You can write as much sql ('SELECT
> * from foo', etc), it just won't be ran. Which is kindof the idea,
> protecting your database.
>
> >The problem is a big server, 6000 acounts with
> >apache+suexec+user_dir+php, on a solaris machine.
> >
> What exactly does this server do? vhosts?
>

hosts accounts for university students.

> >I plan to try changing config options and security settings so it
> >becomes a bit more hardened.
> >
> >
> Ummm... Not that it makes much of a difference to me, I'll answer you
> the best I can anyway (It isn't much, I know ;)... But why are you
> asking on gentoo-security and gentoo-server about a Solaris box?
>
> Wouldn't the php-hardened lists (if they exist) be better for that purpose?
>

Well, the thing is, in gentoo we do have a good comunity, ppl reply,
and participate,
and the questions I'm asking about are related and applicable to
gentoo apache+php install too (has long has we don't put grsec,
selinux, or rsbac in it).
Allthough I should also ask in such a list, if it exists...

> >Any advices are welcome.
> >
> >ps: don't "advice" me to close the server, deny funcionality, etc,
> >these won't do... the server exists, has the acounts and I got to live
> >with it...
> >
> >
> Thats the general way to secure a server, yes. You do have to go and
> decide exactly what services you can get rid of - the less services, the
> less possible security holes.
>
> - Mif
>
>
>

--
Miguel Sousa Filipe

--
gentoo-security [at] gentoo mailing list

miguel.filipe at gmail

Dec 22, 2004, 6:29 AM

Post #7 of 12 (857 views)
Permalink

Re: about php security.. big apache+php deploy [In reply to]

Hi,
thanks for the reply

On Wed, 22 Dec 2004 11:03:35 +0100, Klaus Wagner <klaus [at] it-austria> wrote:
> On Tue, Dec 21, 2004 at 07:16:06PM +0000, Miguel Filipe wrote:
> > Hi there,
> >
> > To put things simple, I'm a bit worried with php, here's why:
> >
> > I don't know SHIT about securing php instalations...
> > I've read about hardened-php, and I wondered if someone uses it, and
> > how reliable and intrusive they are ( false positives interest me
> > especially).
> > Also I would like to receive input from mod_security users...from what
> > I understood, if that's enabled, then in a php forum I cannot
> > write/quote SQL code in my posts... (sql injection prevention..)
> mod_security has the advantage, that malicious access is immediatly
> intercepted and does not hit your php apps, but is quite tricky,
> when it comes to false positives.
>
> if you know your applications well, you can be quite restrictive
> and prevent all sorts of sql injection, but if you know your applications
> well, you could fix them to do proper input validation.
>
> at least you can use mod_security as an IDS an log malicious access
> ... may help in some cases
> >
> > The problem is a big server, 6000 acounts with
> if 6000 acounts means 6000 application spaces you are quite in trouble
>
> my suggestion is to lock down the whole apache+php in an own chroot
> to separate it from the system.
> separation of the applications one from the other would be fine,
> but this would break usage of VirtualHosts and would need an apache
> instance per application.

thought about it and can't do at, we don't use vhosts but use
user_dir, for 6000 users.. on a diferent filesystem... (/home)
Which means I cannot share the /home via hard-link inside a chroot.
Basically, making a chroot inside /home is the only possibility, but
i'm not shure if I wan't to do that.
chroot would be much easier if a "small" scenario.

> > apache+suexec+user_dir+php, on a solaris machine.
> > I plan to try changing config options and security settings so it
> > becomes a bit more hardened.
>
> the problem with those settings is that some applications
> won't work correctly, and the settings doesn't help if your
> php version is broken (-> the Never... worm)
>

I know that, I'm quite alert to those kind of things.. .
But has all sysadmins, I have too much work on my hands :)

> >
> >
> > Any advices are welcome.
> >
> > ps: don't "advice" me to close the server, deny funcionality, etc,
> > these won't do... the server exists, has the acounts and I got to live
> > with it...
> >
> > --
> > Miguel Sousa Filipe
> >
> > --
> > gentoo-security [at] gentoo mailing list
> >
> >
>

--
Miguel Sousa Filipe

--
gentoo-security [at] gentoo mailing list

mastamind at quantentunnel

Dec 22, 2004, 7:13 AM

Post #8 of 12 (857 views)
Permalink

Re: about php security.. big apache+php deploy [In reply to]

my idea of securing apache (with or without using php) is to run apache 2 and
its perchild mpm. this module allows us to specify the number of servers per
virtual host and the user and group under which these apache processes should
run. there should be a group for each account which contains two users. one
user who is allowed to write all the files they want to serve and one user
under which the apache process runs. the files are owned by the write-user
and by the account-group. the access rights should be 0640. because the
apache process is member of the account-group it can read the files. but it
cannot write them because he is not the owner of the files. this would give
the best security because it is enforced by the kernel.
but this does not prevent us from being victims of sql injection. additionally
this system does not secure those files written by php scripts since those
files are always writeable to the apache process. the effort to use this
system is to create 6000 groups and users and maybe to migrate from apache 1
to 2. the users and groups maybe can be created with a script so it would not
be such a lot of work.
with linux as host os you could maybe use lids to deny writeable access to the
files of each user_dir for the httpd executable. i like lids because it is
really easy to use and quite simple compared to selinux or other things. this
way you would have to exchange the kernel and create the acl for the each
user_dir. i do not know if you can do that with solaris as well.
these two methods here may not be appropriate for your system now but in
future they may be usefull.

bj�rn

--
gentoo-security [at] gentoo mailing list

o.schad at web

Dec 22, 2004, 10:31 AM

Post #9 of 12 (857 views)
Permalink

Re: about php security.. big apache+php deploy [In reply to]

Am Dienstag, 21. Dezember 2004 20:16 schrieb mir Miguel Filipe:
> To put things simple, I'm a bit worried with php, here's why:
>
> I don't know SHIT about securing php instalations...

That's a good point to start from :-)

Try following options in php.ini

register_globals = Off
; don't allow sockets to prevent loading malicious code from outside
allow_url_fopen = Off
; Disable funtions that allows to execute system commands or to show
; source code of php-scripts
disable_functions = system, exec, shell_exec, passthru, show_source

And in in the configuration file of apache setup a per directory or per
vhost statement for every user like this

<VirtualHost 192.168.0.1:80>
DocumentRoot /var/www/vhost1/html
ServerName www.vhost1.com
# restrict php to this directory
php_admin_value open_basedir /var/www/vhost1
# each user gets his own upload directory
php_admin_value upload_tmp_dir /var/www/vhost1/tmp
# each user get his own session directory
php_admin_value session.save_path /var/www/vhost1/session
</VirtualHost>

HTH

mfg
Oli

miguel.filipe at gmail

Dec 23, 2004, 12:29 PM

Post #10 of 12 (857 views)
Permalink

Re: about php security.. big apache+php deploy [In reply to]

Well, thanks for all the replies,

I've read a few stuff on the php documentation, these emails, and in
other sites..

I'm now running php with safe_mode enabled, and also trying out your
php.ini options, which I like, and looking into others..

I will not chroot apache+php in my /home, its just a lot of work,
putting services on a acounts partition (which is mounted nosuid) and
not practical in my case.

I will look at mod_security, and learn more about it before using it..
I will see if hardened-php works on solaris.

But for know I'll try more conservative approach.
I'm hardening the php config, and creating a apache+php policy that
users should comply (which reflects the php configs).
Since this change will break user apps, and I have to write
documentation explaining why, and tell them to correct their php code.

These approach is not so powerfull, but can prevent many ways of
explointing bad php code, i've been "pen-testing" a test machine just
for the porpuse of verifying its effectiveness.

I have a specific problem/question now.
How can I use:
safe_mode_exec_dir
and
open_basedir
in my case, since since I'm not using vhosts but user_dir?
for know I have:
safe_mode_exec_dir = .
open_basedir = /home

I know I can pass php config options on the apache config file like this:
<Directory /docroot>
php_admin_value open_basedir /docroot
</Directory>
the problem is that it-s not a specific path but related to the user.
It shoud be something like:
php_admin_value open_basedir ~user/public_html

references:
http://terra.di.fct.unl.pt/docs/php/features.safe-mode.php.htm
http://pt.php.net/register_globals
http://www.securityfocus.com/infocus/1706

On Wed, 22 Dec 2004 18:31:17 +0100, Oliver Schad <o.schad [at] web> wrote:
> Am Dienstag, 21. Dezember 2004 20:16 schrieb mir Miguel Filipe:
> > To put things simple, I'm a bit worried with php, here's why:
> >
> > I don't know SHIT about securing php instalations...
>
> That's a good point to start from :-)
>
> Try following options in php.ini
>
> register_globals = Off
> ; don't allow sockets to prevent loading malicious code from outside
> allow_url_fopen = Off
> ; Disable funtions that allows to execute system commands or to show
> ; source code of php-scripts
> disable_functions = system, exec, shell_exec, passthru, show_source
>
> And in in the configuration file of apache setup a per directory or per
> vhost statement for every user like this
>
> <VirtualHost 192.168.0.1:80>
> DocumentRoot /var/www/vhost1/html
> ServerName www.vhost1.com
> # restrict php to this directory
> php_admin_value open_basedir /var/www/vhost1
> # each user gets his own upload directory
> php_admin_value upload_tmp_dir /var/www/vhost1/tmp
> # each user get his own session directory
> php_admin_value session.save_path /var/www/vhost1/session
> </VirtualHost>
>
> HTH
>
> mfg
> Oli
>
>
>

--
Miguel Sousa Filipe

--
gentoo-security [at] gentoo mailing list

pauldv at gentoo

Dec 24, 2004, 5:51 AM

Post #11 of 12 (857 views)
Permalink

Re: about php security.. big apache+php deploy [In reply to]

On Wednesday 22 December 2004 14:29, Miguel Filipe wrote:
> Hi,
> thanks for the reply
> thought about it and can't do at, we don't use vhosts but use
> user_dir, for 6000 users.. on a diferent filesystem... (/home)
> Which means I cannot share the /home via hard-link inside a chroot.
> Basically, making a chroot inside /home is the only possibility, but
> i'm not shure if I wan't to do that.
> chroot would be much easier if a "small" scenario.

You can still use a bind mount, or as the disk is remote, just mount /home at
two locations. Preferably mounting readonly in the web tree (yes I know that
some applications will not like it. Those applications have a broken idea
about security)

Paul

ps. In such an environment it is also paramount to run php in safe mode. Users
that complain about this should know better.

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv [at] gentoo
Homepage: http://www.devrieze.net

--
gentoo-security [at] gentoo mailing list

miguel.filipe at gmail

Dec 24, 2004, 7:10 PM

Post #12 of 12 (857 views)
Permalink

Re: about php security.. big apache+php deploy [In reply to]

Its a solaris 7, I don't have bind mounts there. thanks anyway

On Fri, 24 Dec 2004 13:51:17 +0100, Paul de Vrieze <pauldv [at] gentoo> wrote:
> On Wednesday 22 December 2004 14:29, Miguel Filipe wrote:
> > Hi,
> > thanks for the reply
> > thought about it and can't do at, we don't use vhosts but use
> > user_dir, for 6000 users.. on a diferent filesystem... (/home)
> > Which means I cannot share the /home via hard-link inside a chroot.
> > Basically, making a chroot inside /home is the only possibility, but
> > i'm not shure if I wan't to do that.
> > chroot would be much easier if a "small" scenario.
>
> You can still use a bind mount, or as the disk is remote, just mount /home at
> two locations. Preferably mounting readonly in the web tree (yes I know that
> some applications will not like it. Those applications have a broken idea
> about security)
>
> Paul
>
> ps. In such an environment it is also paramount to run php in safe mode. Users
> that complain about this should know better.
>
> --
> Paul de Vrieze
> Gentoo Developer
> Mail: pauldv [at] gentoo
> Homepage: http://www.devrieze.net
>
> --
> gentoo-security [at] gentoo mailing list
>
>

--
Miguel Sousa Filipe

--
gentoo-security [at] gentoo mailing list

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads