Re: [PLUG] apache security

[Julien Vehent <julien@linuxwall.info>]

That's quite a good question ! serverfault.com has some good posts on 
the subject: http://serverfault.com/questions/21061/securing-php-webservers

On 01/31/2011 03:36 PM, Mike Sheinberg wrote:
> I don't know if I have the time to go through
> each and every PHP script but I am trying to only throw up the bare
> essentials needed, very slowly so I can watch and monitor the situation.

for all GET requests:
tail -f /var/log/apache/*

Your forms are certainly using POST requests, so you won't see the form 
datas in the logs.
You can experiment with mod_dumpio. I have no experience with it (but 
I'm interested in the result).
http://httpd.apache.org/docs/2.2/mod/mod_dumpio.html


> I've been looking into security modules for Apache (stuff like
> mod_chroot and mod_security) but there seem to be some drawbacks for
> each one (either compatibility, complexity, or some loophole).  Has
> anyone had any experience with mod_chroot specifically - was it a
> worthwhile install?

I've never been satisfied with the way apache handles security. So when 
I switched to Nginx, I looked into running it in a chroot.
I do that now, and every website I setup on my personal hosting server 
runs in /var/www/<specific chroot> with it's own nginx, php and/or perl 
stack.

One exception though: the databases. mysql and postgresql are running 
outside the chroot, and applications connect to them over TCP sockets.

I also put a haproxy in front of everything. Haproxy has a HTTP 
validation module that checks that incoming requests are RFC compliant. 
It sanitizes things a bit.
If the request is clean, it forward it to the corresponding nginx instance.

It makes me sleep better. If one of the PHP code I'm not responsible for 
(or even that I wrote, I'm not much of a php developper) contain a major 
security hole, it won't affect the system globally. Eventually the 
database will suffer a bit, but damages should be much more limited.



In one of my previous company, where security was a major (financial) 
issue, we had requests inspection in front of the reverse proxies. It's 
basically what mod_security does: a regular expression that verifies 
that datas coming from the outside comply to a defined rule.

It's the most efficient solution I've worked with. But it's hard, 
because, to build your rule set, you need to identify ALL of the 
variables (names and values) that are going to pass through the 
inspection engine.

For example:

You have a form contact that contain 4 fields: name, email, subject, text.
Each of these field need to be standardized during the development of 
the form (it makes it easier). You will name them:
  * app1_contactform_name
  * app1_contactform_email
  * app1_contactform_subject
  * app1_contactform_text

Then, you identify the type of data accepted in each field:

  * app1_contactform_name       -> [[:alpha:]]{0,40}
  * app1_contactform_email      -> a email validation regex
  * app1_contactform_subject    -> [[:alnum:]]{0,80}
  * app1_contactform_text       -> [[:alnum:]]{0,1000}

You put these rules in your inspection engine, and if a rule doesn't 
validate, the engine will drop the request. It's violent though, no 
fancy colored error message sent back to the user.

In my experience, this is doable when building a new application and on 
simple applications.

> FYI - I don't have physical access to this server and it is public
> facing (hence all my earlier ip tables questions). I run integrity
> checkers daily on the file-system so I can see whenever files are
> modified anywhere - and I also plan on taking good backups and using
> plenty of logging. So with all that mind, is there any good apache
> security tips that someone can recommend or that have really helped you
> guys out? I plan to run about 10 sites on this box, utilizing mostly php
> and python scripts. I have also been pouring over php.ini security tips
> as well and I realize now that someone previously set register_globals
> to 'on' which I've read is a huge no-no.

If you don't have physical access, set up a syslog/backup server that 
you physically control. If your server is compromised,it will make 
investigation easier.


Julien
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug