Re: Keeping the webserver safe
On Mon, 2008-10-06 at 20:53 +0200, Gerfried Fuchs wrote:
> * Joe <joe@jretrading.com> [2008-10-06 19:20:27 CEST]:
> > How can there be any way? If you allow users to upload executable
> > scripts, you might as well give them ssh access and be done with it. You
> > must enforce file create permissions on the upload system (ftp or
> > whatever) which do not include 'execute' for any user or group.
> Please don't give such bad advices - creating files without execute
> permissions doesn't mean that they can't get executed.
My personal favourite is putting all webserver dirs on partitions
mounted with nodev,nosuid,noexec. Plus I control exactly which users can
write where, remove all webserver access to the usual places
(/tmp, /var/tmp ...) and in the case of php making use of things like
disable_functions and openbase_dir (making things like ini_set
impossible to execute is a good idea). This ontop of other things like
mod_rewrite and mod_security may not make things like injection attacks
impossible but they may just make it too hard for the average script
kiddie/code monkey.
> > Commercial web servers which offer scripting *do* normally also offer
> > ssh access, but what the user has access to is only a virtual machine,
> > not shared with anyone else. Chroot is nowhere near enough.
This is not entirely true. Most hosting companies that offer scripting
only allow ftp access for changing files on the system, normally you
only get ssh access if you have a vps solution. I would also say that in
99.99% of cases a chroot will be enough to stop these kinds of data
leaks, it is not however a substitute for security auditing code
(nothing is).
> chroot is though far closer than advicing to forcing non-execute
> permissions on the user files, and escaping from a chroot far more
> challenging.
The big thing to remember is that no one method on it's own is security.
"Security is journey, not a destination." The more barriers you put in
the way the harder you make it for a potential attacker, everything from
denying information about exactly what software and versions are being
run (like making banners for things like apache and MTA's as generic as
possible) to extensive ACL setups, chroots, mount options, firewalls,
password policies and any more extreme methods can add to the overall
security of any system. At some points you might need to sacrifice some
usability to make things more secure, but you need to determine if the
benefits are worth the inconvenience. You should always keep an eye on
things like the security focus lists and your OS and distribution lists
to keep up with the latest vulnerabilities (for all major pieces of
software that are publicly exposed - in this case apache and php - hand
compiling the versions you use and knowing exactly what you turned on
and/or off in the build process can help you aviod some issues).
Security is never as simple as "do this". While it is a big part of
every systems administrators daily life, there are people out there for
whom it is the sole purpose of their work and even they cannot guarantee
things are 100% secure. You should do as many things as you can in the
time you have, and remember that taking that extra 2 hours to do things
before a deployment can save hours trying to clean up after having a
server compromised or the cost having valuable/sensitive corporate or
customer data stolen.
--
Nikolai Lusan <nikolai@lusan.id.au>
Reply to: