Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: Brian Rectanus <Brian.Rectanus@br...> - 2009-09-29 19:09:39
|
André Cruz wrote: > On Tue, Sep 29, 2009 at 5:04 PM, Brian Rectanus > <Brian.Rectanus@... <mailto:Brian.Rectanus@...>> wrote: > > I've read several posts about how to compile mod_security with a > static > build of apache but none of them worked, the latest was > http://thread.gmane.org/gmane.comp.apache.mod-security.user/1840/focus=1841 > > > Could you give your reasoning for building it static? I have never > seen a need for it. If there really is one, then maybe I can do > something to aide in this? > > > From a security standpoint it makes sense to only include the code that > you're going to need. I know exactly which modules I need so I build my > custom apache with only those modules and include them statically. The > whole dynamic loading of modules is just another piece of code I can > live without. > > I'm sure you'll agree this makes sense. Also, I sleep a little better > knowing that rogue modules cannot be loaded into the web server. :) No, I do not agree ;) This is normally the response I get and I think it is a flawed argument. Typically your entire system is based off of shared libraries, not just apache modules (unless you went to a lot of trouble). * Do you build Apache completely static (not just apache modules, but all the libs it links to as well? Otherwise any of those libs can be replaced as well. * Replacing libs is actually a good thing as it allows the library to fix an issue without having to rebuild the rest of the app. This would normally result in a faster fix time that requires a lot less work on your part. Normally I build with vendor/distribution supplied libraries as they have the time (generally) to keep them more up-to-date than I do. * If someone has the rights to install a rouge module, then they also generally have the rights to replace the httpd binary as well ;) * Building ModSecurity in this fashion is unsupported and definitely untested, so you risk there being a problem with the install, potentially lessening your security standpoint. * With static modules, you have no way to unload the module without rebuilding and that may take a while if there is something you discover later on in a production environment. With the module dynamically loaded you can just unload it via config if there is an issue. What would happen if there was an app change later on that exposed a false positive or other issue in ModSecurity. This may take your site offline until you rebuild, potentially costing you a lot of revenue. * I do agree you should not run with code you do not need, but that does not mean not building it as dynamic loadable modules. And if you want, build all your required modules static, but leave the option open for other modules, which are sometimes needed for resolving problems and debugging issues. thanks, -B -- Brian Rectanus Breach Security |