We are configuring a minimal Apache web server and will occasionally be talking to it with curl, the TRACE method and ab.<\/p>\n
A secure server is one that permits only as much as what is really needed. Ideally, you would build a server based on a minimal system by enabling additional features individually. This is also preferable in terms of understanding what\u2019s going on, because this is the only way of knowing what is really configured. Starting with a minimal system is also helpful in debugging. If the error is not present in the minimal system, features are added individually and the search for the error goes on. When the error occurs, it is identified to be related to the last configuration directive added.<\/p>\n
Our web server is stored in Let\u2019s go through this configuration step-by-step.<\/p>\n We are defining ServerName<\/em> as localhost<\/em>, because we are still working in a lab-like setup. In production the fully qualified host name of the service has to be entered here.<\/p>\n The server requires an administrator e-mail address, primarily for display on error pages. This is defined in ServerAdmin<\/em>.<\/p>\n The ServerRoot<\/em> directory indicates the main or root directory of the server. It is a symbolic link set as a trick in Tutorial 1. We\u2019ll make good use of this, because by reassigning this symbolic link we will be able to test a series of different compiled versions of Apache without having to change anything in the configuration file.<\/p>\n We then assign the user and group to User<\/em> and Group<\/em>. This is a good idea, because we want to prevent the server from running as a root process. In fact, the master or parent process will be running as root, but the actual server or child processes and their threads will be running under the name defined here. The www-data<\/em> user is the name normally used on Debian\/Ubuntu systems. Other distributions use different names. Make sure that the user name and associated group you choose are actually present on the system.<\/p>\n The PidFile<\/em> specifies the file that Apache writes its process ID number to. The path selected is the default. It is mentioned here so you don\u2019t have to look for this path in the documentation later on.<\/p>\n ServerTokens<\/em> defines how the server identifies itself. Productive tokens are defined using Prod<\/em>. This means that the server identifies itself only as Apache<\/em> without the version number and loaded modules which is a bit more discreet. Let\u2019s not fool ourselves: The version of the server can be easily determined over the internet, but we still don\u2019t have to send it along as part of the sender for every communication.<\/p>\n UseCanonicalName<\/em> tells the server which host names<\/em> and ports<\/em> to use when it has to write a link to itself. The On<\/em> value defines that the ServerName<\/em> is to be used. One alternative would be to use the host header sent by the client, which however we don\u2019t want in our setup.<\/p>\n The TraceEnable<\/em> directive prevents certain types of spying attacks on our setup. The HTTP TRACE<\/em> method instructs the web server to return the requests it receives 1:1. This enables us to determine whether a proxy server is interposed and whether it has modified the request. This is no loss in our simple setup, but this information is better kept confidential on a corporate network. So, for the sake of security we are turning TraceEnable<\/em> off by default.<\/p>\n Broadly speaking, Timeout<\/em> indicates the maximum time in seconds that may be used to process a request. In reality it is a bit more complicated, but we don\u2019t need to worry about the details at the moment. The default value of 60 seconds is very high. We\u2019ll lower it to 10 seconds.<\/p>\n MaxRequestWorkers<\/em> is the maximum number of threads working in parallel to reply to requests. The default value is once again a bit high. Let\u2019s set it to 100. If this value is reached in production, then we have a lot of traffic.<\/p>\n By default, the Apache server listens to any available URL on the internet. However, for our tests we will have it initially listen to only the IPv4 local host<\/em> URL and on default HTTP port 80. It\u2019s possible to have multiple Listen<\/em> directives one after the other, but having only one is sufficient for our purposes at the moment.<\/p>\n Let\u2019s now load five modules:<\/p>\n We already compiled all of the modules supplied by Apache in Tutorial 1. We will now be adding the most important ones to our configuration. mpm_event_module<\/em> and unixd_module<\/em> are needed to operate the server. When compiling in the first tutorial we chose the event<\/em> process model, which we will now be enabling by loading the module. Of interest: In Apache 2.4 such a fundamental setting as the process model of the server can be set in the configuration. We need the unixd<\/em> module to run the server (as described above) under the user name we defined.<\/p>\n log_config_module<\/em> enables us to freely define the access log, which we will be making use of shortly. And finally, there are the two authn_core_module<\/em> and authz_core_module<\/em> modules. The first part of the name indicates authentication (authn<\/em>) and authorization (authz<\/em>). Core then means that these two modules are the basis for these functions.<\/p>\n In terms of access security, we often hear about AAA<\/em>, short for authentication<\/em>, authorization<\/em> and access control<\/em>. Authentication means checking the identity of the user. Authorization means you define the access permissions for a user that has been authenticated. Finally, access control means the decision as to whether access is granted to an authenticated user with the access permissions defined for him. We lay the foundation for this mechanism by loading these two modules. There are a lot of other modules with the authn<\/em> and authz<\/em> prefixes which require these modules. For the moment we actually only need the authorization module, but by loading the authentication module we are preparing for extensions later on.<\/p>\n We use ErrorLogFormat<\/em> to change the format of the error log file. We will be extending the customary log format a bit by precisely defining the time stamp. We use LogFormat<\/em> to define a format for the access log file. We give it the name combined<\/em>. This common format includes the client IP address, time stamp, methods, path, HTTP version, HTTP status code, response length, referer and the name of the browser (User-Agent). For the timestamp we are selecting a structure that is quite complicated. The reason for this is the desire to use the same format for timestamps as in the error log and access logs. While easy identification is available in the error log, we have to painstakingly put together the timestamp for the access log format.<\/p>\n By using debug<\/em> we are setting the LogLevel<\/em> for the error log file to the highest level. This is too chatty for production, but it makes perfect sense in a lab-like setting. Apache is not very chatty in general so the volume of data is usually easy enough to handle.<\/p>\n We assign the error log file by adding the path logs\/error.log<\/em> to ErrorLog<\/em>. This path is relative to the ServerRoot<\/em> directory.<\/p>\n We now use LogFormat combined<\/em> for our access log file called logs\/access.log<\/em>.<\/p>\n The web server delivers files. It searches for them on a disk partition or generates them with help from an installed application. We are still using a simple case here and tell the server to look for the files in DocumentRoot<\/em>. \/apache\/htdocs<\/em> is an absolute path below \/apache<\/code> on the file system. Its default configuration is located in \/apache\/conf\/httpd.conf<\/code>. It is very extensive and contains many comments and commented out configuration lines. This makes it rather difficult to understand but at least everything is still in a single file. For packaged versions of Apache, on many Linux distributions, the default configuration is not only very complicated, it is also fragmented into a handful of separate files that are spread across multiple directories. This can make it hard to get a good overview of what is actually going on. To simplify things, we will be replacing this extensive configuration file with the following, greatly simplified configuration.<\/p>\n<\/a>ServerName<\/span> localhost<\/span>\n<\/a>ServerAdmin<\/span> root@localhost<\/span>\n<\/a>ServerRoot<\/span> \/apache<\/span>\n<\/a>User<\/span> www-data<\/span>\n<\/a>Group<\/span> www-data<\/span>\n<\/a>PidFile<\/span> logs\/httpd.pid<\/span>\n<\/a><\/span>\n<\/a>ServerTokens<\/span> Prod<\/span>\n<\/a>UseCanonicalName<\/span> On<\/span>\n<\/a>TraceEnable<\/span> Off<\/span>\n<\/a><\/span>\n<\/a>Timeout<\/span> 10<\/span>\n<\/a>MaxRequestWorkers<\/span> 100<\/span>\n<\/a><\/span>\n<\/a>Listen<\/span> 127.0.0.1:80<\/span>\n<\/a><\/span>\n<\/a>LoadModule<\/span> mpm_event_module modules\/mod_mpm_event.so<\/span>\n<\/a>LoadModule<\/span> unixd_module modules\/mod_unixd.so<\/span>\n<\/a><\/span>\n<\/a>LoadModule<\/span> log_config_module modules\/mod_log_config.so<\/span>\n<\/a><\/span>\n<\/a>LoadModule<\/span> authn_core_module modules\/mod_authn_core.so<\/span>\n<\/a>LoadModule<\/span> authz_core_module modules\/mod_authz_core.so<\/span>\n<\/a><\/span>\n<\/a>ErrorLogFormat<\/span> "[%{cu}t] [%-m:%-l] %-a %-L %M"<\/span><\/span>\n<\/a>LogFormat<\/span> "%h %l %u [%{%Y-%m-%d %H:%M:%S}t.%{usec_frac}t] <\/span>\\"<\/span>%r<\/span>\\"<\/span> %>s %b \\<\/span><\/span>\n<\/a>\\"<\/span>%{Referer}i<\/span>\\"<\/span> <\/span>\\"<\/span>%{User-Agent}i<\/span>\\"<\/span>"<\/span> combined<\/span>\n<\/a><\/span>\n<\/a>LogLevel<\/span> debug<\/span>\n<\/a>ErrorLog<\/span> logs\/error.log<\/span>\n<\/a>CustomLog<\/span> logs\/access.log combined<\/span>\n<\/a><\/span>\n<\/a>DocumentRoot<\/span> \/apache\/htdocs<\/span>\n<\/a><\/span>\n<\/a><<\/span>Directory<\/span> \/><\/span><\/span>\n<\/a><\/span>\n<\/a> Require<\/span> all denied<\/span>\n<\/a><\/span>\n<\/a> Options<\/span> SymLinksIfOwnerMatch<\/span>\n<\/a><\/span>\n<\/a><<\/span>\/Directory<\/span>><\/span><\/span>\n<\/a><\/span>\n<\/a><<\/span>VirtualHost<\/span> 127.0.0.1:80><\/span><\/span>\n<\/a> <\/span>\n<\/a> <<\/span>Directory<\/span> \/apache\/htdocs><\/span><\/span>\n<\/a><\/span>\n<\/a> Require<\/span> all granted<\/span>\n<\/a><\/span>\n<\/a> Options<\/span> None<\/span>\n<\/a><\/span>\n<\/a> <<\/span>\/Directory<\/span>><\/span><\/span>\n<\/a><\/span>\n<\/a><<\/span>\/VirtualHost<\/span>><\/span><\/span><\/code><\/pre><\/div>\nStep 2: Understanding the configuration<\/h3>\n
\n
[%{cu}t]<\/code> will then produce entries such as [2015-09-24 06:34:29.199635]<\/code>. This means the date written backwards, then the time with a precision of microseconds. Writing the date backwards makes it more easily sortable in the log file; the microseconds provide precise information as to the time of the entry and enable conclusions to be made about how long processing takes in the different modules. This is also the purpose of the next configuration part, [%-m:%-l]<\/code>, that specifies the module doing the logging and the log level<\/em>, i.e.\u00a0the severity of the error. After this come the IP address of the client (%-a<\/code>), a unique identifier for the request (%-L<\/code>) (a unique ID which can be used in later tutorials in correlation to requests) and the actual message, which we reference using %M<\/code>.<\/p>\n