On Mon, 2008-10-06 at 20:53 +0200, Gerfried Fuchs wrote: > * Joe <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
