Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 1414 invoked by uid 500); 25 Jun 2003 20:16:56 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 1401 invoked from network); 25 Jun 2003 20:16:55 -0000 Date: Wed, 25 Jun 2003 16:16:38 -0400 From: Glenn To: dev@httpd.apache.org Subject: Re: [PATCH] modify httpd.conf-dist defaults Message-ID: <20030625201638.GA4732@netspace.org> References: <20030624232029.GA9260@netspace.org> <20030625145134.GA22502@netspace.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, Jun 25, 2003 at 12:31:41PM -0400, Joshua Slive wrote: > > Rather than rehashing the thread about default config files, how about > > httpd.conf-compat? Or a comment at the top of httpd.conf-dist that says > > "These defaults are aimed at compatibility with previous releases. > > Look for commented sections with more secure, recommended defaults."? > > I don't think that statement is true. The default config is a balance > between most-secure, most-functional, and least-likely-to-surprise. It's > simply my opinion that two of your changes don't make the appropriate > balance. Ok. I can accept that, even though we're talking the default config for new installations. Security is my top priority and the Apache configuration is _very_ flexible and likewise _very_ complex. Until I slowly learned the Apache directives one by one and had lots of experience with different configurations, I took the examples in the default httpd.conf as gospel, which was a mistake since my priorities are different than the ones you listed above. For newbies, and even experienced admins, it would be nice if there were some examples of secure usage of groups of configuration directives, and why. I'd be more than happy to contribute to such a document if it existed. Cheers, Glenn # Security recommendation # Do not serve any files unless explicitly allowed by other directives # (see 'order', 'allow', 'deny', and 'satisfy' directives) # # # order deny,allow # deny from all # satisfy all # # # If the above is uncommented, you will need to explicitly allow # access to any path that contains files you wish to serve, meaning you # need a (or ) block containing appropriate 'order' # and 'allow' directives that include paths specified for DocumentRoot, # Alias, or any other paths. Typically, this will be directives that # allow everything in the subpath except that which is explicitly denied, # such as # #DocumentRoot /path/to/my/document/root # # order allow,deny # allow from all # # # deny from all # # Security recommendation # Disable expansion of query string into command line args for certain queries # (see 'CGICommandArgs' directive) # If you do not understand the above, you probably want to disable it by # uncommenting the following line. # #CGICommandArgs off # # Way back when the internet was a safer, more naive place, it was convenient # for the server to take query strings that did not contain an '=' sign and # to parse and pass it to a CGI program as command line args. The default # behavior in Apache is to maintain this behavior for backwards compatibility, # although it is generally regarded as unsafe practice today. Most CGI # programs do not take command line parameters, but among those that do, many # are unaware of this method of passing arguments to it and are therefore # vulnerable. This includes any generic program that takes command line # arguments and that was not specifically written to protect against this. # PHP in CGI-mode protects against this by ignoring command line arguments # if certain environment variables are present. This is counter-intuitive to # those familiar with unix command lines, but is necessary for security since # the PHP CGI program has no way of knowing if CGICommandArgs if off or on. # CGICommandArgs has been available in Apache since 1.3.24 # Security recommendation # Do not serve files used to modify the web server configuration and protect # against serving certain types of temporary files. # (see 'AccessFileName', 'order', 'allow', 'deny', and 'satisfy' directives) # FilesMatch takes a regular expression (a.k.a. regex) as a parameter. # (see 'FilesMatch' for more information about regular expression syntax) # # # order allow,deny # deny from all # satisfy all # # # Unless modified by 'AccessFileName', files named .htaccess often contain # authorization information and so serving the file to web clients should be # disallowed for security reasons. Since it is common practice to name # password files used for authentication as .htpasswd, and the above rule # protects those files as well. Also protected are some common backup files. # Certain unix text editors automatically make temporary and backup files # when editing a file. A common convention is to surround the filename with # '#' signs, as in #my_filename#, or to copy the file an rename it with '~' # at the end, as in my_filename~. Although editing files on a live website # is discouraged, if an editor such as Emacs or Pico creates such a backup # file with loose permissions, Apache will think it is a different type of # file and will serve it, by default, as clear text. This is risky when the # file is processed on the server-side, such as a PHP file that contains a # database username and password. If someone can download the code in clear # text, then the database account might be compromised. You should consider # not editing such files on a live website; edit a separate copy and move it # into place. If you use other editors that have different filename renaming # conventions for automatic backup files, you might wish to extend the regex # in the FileMatch directive above to disallow serving of those files, too.