Apache 1.3 Hardening Guide
Technical Reference: Apache 1.3 Secure Server Install
Overview
This document is a guide to installing and hardening an Apache 1.3 web server to common security standards. It will guide you through practical measures to harden your Apache server, by way of example.
Because a web server is often placed at the edge of the network, it is one of the most vulnerable services to attack. Therefore, it’s vital that you follow this guide to ensure that:
1) The opportunity to compromise the web server is limited
2) Should the web server be compromised, the damage potential to the rest of the network, data, and systems is limited.
This document assumes that you will use the more common Apache configuration, placing everything into the httpd.conf file, and leaving srm.conf and access.conf empty.
1. Prepare the host operating system
1.1 Install and secure the host operating system.
Follow the hardening guidelines for your host at The Center for Internet Security. Hardening the host operating ensures that, should someone compromise the security of your web server, the amount of damage that they could inflict will be minimized.
1.2 Create the directories to hold the Apache files
It’s important to separate the binaries (/bin), docs (/htdocs), and logs (/logs) into separate partitions on the system. You can choose whatever root you want, but this example will use /opt/apache as the root directory for the Apache web server.
1.3 Create the host groups for administering and running the server.
Create a distinct group for all the users who will have permission to change the configuration, start, and stop the web server. For example, if you want to call the group “webadmin”, create it like this:
# groupadd webadmin
Create a distinct group for the web server user – no one will actually log into this group, but it will only be used to hold the userid which will run the web server. For example, if you want to call that group “webserv”, create it like this:
# groupadd webserv
Take note that you should not create a “web developer” group on this host. Since this is a hardened production host you must not provide web developers login accounts on this system. Instead, developers should deploy documents and code to the server using your code/content deployment system, such as Kintana’s Apps*Integrity.
1.4 Create an unprivileged host user id to run the server.
Never run the web server as root; if the web server is ever compromised, the attacker will have complete control over the system. Instead, the best way to reduce your exposure to attack when running a web server is to create a unique unprivileged userid for the server application. The userid nobody is often used for this purpose, but a userid and group that are unique to the web server is a more secure solution.
By default the web server uses privileged ports (port 80 and 443) and, when configured for secure operation, must have root privileges to open its log files and start the dæmon. (Therefore, the web server daemon will have to be started as “root”, unless you configure it to use a port higher than 1024.) Once the server's startup tasks are complete, all active instances can run as the unprivileged user.
Use the following command line entries as patterns for creating a group and user for the web server. Here’s an example if you were to use “webserv” as the user:
# useradd -d /opt/apache/htdocs -g webserv -c "Web Server" webserv
1.5 Lock down the web server account
It’s important that no one can successfully execute a password guessing attack against this account, so in this step, we’ll restrict this account so that no one can log into it.
1.5.1 Issue this command to lock the password for the web server account:
# passwd –l webserv
Password changed.
1.5.2 To be sure the account is locked, issue the command:
# grep webserv /etc/shadow
…a :!: at the beginning of the line indicates that the password is locked.
1.5.3 Issue this command to remove the shell for this account:
# usermod –s /bin/false webserv
1.5.4 To be sure the account is locked, issue the command:
# grep webserv /etc/passwd
…/bin/false at the end of the line indicates that the shell is set to a non-existent shell.
1.5.5 Test the web server account to be sure you can’t login. Issue this command to try to log in:
> login webserv
2. Download and verify Apache modules
By default, web servers return information about the product and version they are running in the Server variable of the HTTP header. This information can be very useful to hackers, enabling them to target attacks to that specific server. To prevent that information from being returned from the web server, this step shows you how to modify that header and build your own copy of the web server.
Because web servers often host sensitive information, or allow users to log in with plain-text passwords, it’s important to encrypt the HTTP traffic. Therefore, this section will show you how to configure mod_ssl on your web server.
Note: Don’t build the web server on your production, hardened host. Build it on a staging or development server (with identical O/S), and then copy it to your production host.
These steps will guide you through downloading Apache source code, validating it, compiling it, and installing it. We don’t recommend use of pre-compiled or DSO versions. DSO versions may allow a hacker to introduce new “features” without having to recompile the code.
If you intend to add other module to your Apache web server installation, repeat the validation steps below for each module you add.
2.1 Download the latest version of Apache 1.3
Ensure that you retrieve the latest copy, so that you have cumulative bug fixes and security patches. You can download it from the Apache site.
From here, download four files:
1) The Apache source code itself, called something similar to apache_1.3.xx.tar.gz
2) The PGP keys for the Apache signers probably called something like KEYS.txt
3) The PGP key for this source distribution, called something similar to apache_1.3.XX.tar.gz.asc
4) The MD5 checksum for this source distribution, called something similar to apache_1.3.XX.tar.gz.md5
2.2 Verify PGP signature for the Apache source
To ensure that you have an authentic version from the Apache Group, and that it’s not been tampered with (remember, there are many mirrors from which you can download the Apache source), you should check the PGP signature. If you don’t have PGP installed on this server, you can validate these files on another machine.
a) If you don’t already have them in your PGP keyring, import the public keys from the Apache Group into your keyring:
~> pgp –ka KEYS.txt
b) Check the PGP signature:
~> pgp apache_1.3.27.tar.gz.asc
…if the signature is correct, you should get something similar to this:
-- CUT --
File ‘apache_1.3.27.tar.gz.asc’ has signature, but with no text.
Text is assumed to be in file ‘apache_1.3.27.tar.gz’.
Good signature from user “Jim Jagieleski <>".
Signature made 2002/06/18 18:26 GMT
WARNING: Because this public key is not certified with a Trusted signature, it is not known with high confidence that this public key actually belongs to “Jim Jagielski <>".
The fact that it says, “Good Signature from…” is what we’re looking for here. The WARNING statement indicates that we’ve not verified this signature with a 3rd party, which is ok here.
2.3 Verify the MD5 checksum for the Apache source.
MD5 is a way to validate the integrity of the file itself, much more reliable than checksum and similar methods. Normally, mismatches in the MD5 checksum from the Apache source are the result of download errors or file corruption. If you don’t have MD5 on your system, you can download it from here.
Compare the results of these two commands – visually inspect them to ensure they match (if they don’t, download it again):
~> pwd
/usr/local/build
~> cat apache_1.3.27.tar.gz.md5
MD5 (apache_1.3.27.tar.gz) =
52e9b875597a208fca9d393e710087b6
~> md5 apache_1.3.27.tar.gz
MD5 (apache_1.3.27.tar.gz) =
52e9b875597a208fca9d393e710087b6
2.4 Extract the zipped Apache source file.
Finally, you need to unzip and untar the source file.
~> /pwd
/usr/local/build
~> gunzip apache_1.3.27.tar.gz
~> tar –xvf apache_1.3.27.tar
3. Download and configure mod_ssl and certificates
This section will walk you through configuring mod_ssl for encrypting your HTTP traffic. It will help you build a validated certificate and install it on your web server.
3.1 Implement OpenSSL
It’s necessary to have the source code for OpenSSL for mod_ssl to configure and compile properly. In this step you will download OpenSSL and install it.
3.1.1 Download the latest version of OpenSSL from http://www.openssl.org. In this example, we download openssl-0.9.6g.tar.gz.
3.1.2 Unpack, configure, and make the OpenSSL package.
~> pwd
/usr/local/build
~> gunzip openssl-0.9.6g.tar.gz
~> tar –xvf openssl-0.9.6g.tar
~> cd openssl-0.9.6g
~> pwd
/usr/local/build/openssl-0.9.6g
~> ./config
~> make
3.2 Download and verify the latest version of mod_ssl
The version of mod_ssl that you download and install must be explicitly compatible with the version of Apache that you’re installing. For example, if you download and install Apache 1.3.27, you must download and install mod_ssl-2.8.11-1.3.27. You can download it from the modssl site.
From here, download four files:
1) The modssl source code itself, called something similar to mod_ssl-2.x.x-1.3.xx.tar.gz
2) The PGP keys for the modssl signers probably called something like pgprse.asc
3) The PGP key for this source distribution, called something similar to mod_ssl-2.8.11-1.3.27.tar.gz.asc
3.3 Verify PGP signature for the mod_ssl source
To ensure that you have an authentic version from the Ralf S. Engelschall (mod_ssl author), and that it’s not been tampered with (remember, there are many mirrors from which you can download the source), you should check the PGP signature. If you don’t have PGP installed on this server, you can validate these files on other servers or platforms.
3.3.1 Import keys into your PGP key ring.
If you don’t already have them in your PGP keyring, import the public key from Ralf S. Engelschall into your keyring:
~> pwd
/usr/local/build
~> pgp –ka pgprse.asc
3.3.2 Check the PGP signature:
~> pwd
/usr/local/build
~> pgp mod_ssl-2.8.11-1.3.27.tar.gz.asc
…if the signature is correct, you should see something like this:
-- CUT --
File ‘mod_ssl-2.8.11-1.3.27.tar.gz.asc’ has signature, but with no text.
Text is assumed to be in file ‘mod_ssl-2.8.11-1.3.27.tar.gz’.
Good signature from user “Ralf S. Engelschall <>".
Signature made 2002/10/04 13:53 GMT
WARNING: Because this public key is not certified with a Trusted signature, it is not known with high confidence that this public key actually belongs to “Ralf S. Engelschall <>".
The fact that it says, “Good Signature from…” is what we’re looking for here. The WARNING statement indicates that we’ve not verified this signature with a 3rd party, which is ok here.
3.4 Extract the zipped mod_ssl source file.
Do this in the apache source directory.
~> /pwd
/usr/local/build/apache_1.3.27
~> gunzip mod_ssl-2.8.11-1.3.27.tar.gz
~> tar -xvf mod_ssl-2.8.11-1.3.27.tar
3.5 Create a key and certificate request for your web server
Using OpenSSL, the following command will create a 1024-bit private key named, “private.key” and generate a certificate signing request (CSR). You need to have the CSR signed by a Certificate Authority (CA) who can validate your identity. When prompted to input information, note the answers in bold print below. (Answer the prompts with the information relevant for your server, of course).
Note: If you provide a challenge password, you will be unable to start the web server unattended. We don’t recommend providing a challenge password, just leave it blank.
~> pwd
/usr/local/build
~> openssl req -nodes -newkey rsa:1024 -keyout /usr/local/build/private.key -out /usr/local/build/xianshield.csr
Using configuration from /usr/share/ssl/openssl.cnf
Generating a 1024 bit RSA private key
................++++++
.......++++++
writing new private key to 'private.key'
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:NC
Locality Name (eg, city) []:RTP
Organization Name (eg, company):Xian Systems, Inc.
Organizational Unit Name (eg, section) []:InfoSec
Common Name (eg, YOUR name) []:xianshield.xianco.com
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Most importantly, make sure your “Common Name” above matches the DNS name of your server. The locale information is less important, but we think it’s best to use the locality of the server itself.
3.6. Submit CSR for validation/signing by a CA.
Next, you need to submit your CSR for signing by a CA. This will eliminate the “warning dialog” that a browser will pop up when a user accesses your site. This is because the user’s browser has a set of trusted CAs that will prevent you from being notified if the web server’s site certificate is signed by a CA you’ve trusted in your browser already (such as Verisign or DST). In this example, we will submit the request to our company’s CA for signing. (You can use another CA if you want).
Send your request for a certificate to the CA. Include your name, your web server (Apache, in this case) your OS, and of course, the .csr (certificate signing request).
3.7 Rename your certificates
You will receive 2 files from the PKI team. The first file will be your server certificate (and will probably be named
mv “XianCo CA (01-03).cer” ca.crt
3.8 Copy signed certificates to your server.
Once you receive your certificates from the certificate signing team, you will need to place them back into your build directory on your server.
scp xianshield.cer xianshield:/usr/local/build/.
scp ca.crt xianshield:/usr/local/build/.
3.9 Configure mod_ssl with your cert
Configure mod_ssl so that it knows where to find your certificate and key. You need to run this using sudo so that Apache will know that it can use ports < 1024.
~> pwd
/usr/local/build/apache_1.3.27/mod_ssl-2.8.11-1.3.27
~> sudo ./configure --prefix=/opt/apache \
--with-apache=/usr/local/build/apache_1.3.27 \
--with-ssl=/usr/local/build/openssl-0.9.6g \
--with-crt=/usr/local/build/xianshield.cer \
--with-key=/usr/local/build/private.key
+ Apache location: /usr/local/build/apache_1.3.27 (Version 1.3.27)
+ OpenSSL location: /usr/local/build/openssl-0.9.6g
+ Auxiliary patch tool: ./etc/patch/patch (local)
…
4. Configure and build the Apache Server
In order to customize Apache to the extent necessary, we need to download the source for the latest version of Apache. Once that’s complete, we will configure it,
4.1 Alter the Apache version
We want to remove/modify the default HTTP response header parameter for the “Server:” token to hide the identify of our web server software. To do this, we must open a header file (httpd.h) prior to compiling the server. To do this, edit the httpd.h file located in ${ApacheSrcDir}/src/include
~> pwd
/usr/local/build/apache_1.3.27/src/include
~> vi httpd.h
…
#define SERVER_BASEVENDOR "Apache Group" ß Change this…
#define SERVER_BASEPRODUCT "Apache" ß and this
#define SERVER_BASEVERSION “1.3.27” ß DON’T change this
These are the lines you want to change; change these to remove references to Apache. Be careful not to change the SERVER_BASEVERSION line because add-in modules (such as mod_ssl), may not properly compile if you change it. Don’t worry about the SERVER_BASEPRODUCT value, as we’ll hide that through the use of the ServerTokens directive in the httpd.conf file. As an example, the CCO web server modifies these to return CCO/1.0 for the Server name. You might modify it to say something like this:
#define SERVER_BASEVENDOR "Network Services"
#define SERVER_BASEPRODUCT "Networks, Inc."
4.2 Configure Apache software to disable modules
There are a few standard modules that should be disabled when you set up the Apache web server. We recommend that you disable the following modules:
info: gives out too much information about your web server to potential attackers.
status: gives out server stats via web pages
autoindex: provides directory listings when no index.html file is present
imap: provides server-side mapping of index files
include: provides server-side includes (.shtml files)
userdir: translates URLs to user-specific directories
To disable these, run a command similar to this one (yours may include a list of “enable” statements to enable the modules that you want).
~> pwd
/usr/local/build/apache_1.3.27
~> sudo ./configure –-prefix=/opt/apache \
--enable-module=ssl \
--enable-module=so \
--disable-module=info \
--disable-module=status \
--disable-module=autoindex \
--disable-module=imap \
--disable-module=include \
--disable-module=userdir
Configuring for Apache, Version 1.3.27
+ using installation path layout: Apache (config.layout)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
…
4.3 Compile the Apache server
Now that the software is validated and configured, it’s time to compile it. Since you won’t have a compiler on your production host, we’ll compile and install it on a separate server, then tar/compress it and scp it to your production host. You’ll need to run make using “sudo” so that Apache knows it can use ports < 1000.
~> pwd
/usr/local/build/apache_1.3.27
~> sudo make
===> src
make[1]: Entering directory `/usr/local/build/apache_1.3.27'
make[2]: Entering directory `/usr/local/build/apache_1.3.27/src'
===> src/regex
sh ./mkh -p regcomp.c >regcomp.ih
…
4.4 Install the Apache server
By convention, shared third-party applications are installed in the /opt directory. The root directory for a web server, commonly referred to as the Server Root directory, would thus be a subdirectory in /opt (e.g., /opt/httpd).
If you have followed our instructions for securing the host, you will have to unpack the distribution and compile it on a separate host. When you unpack the distribution file, you should see the following directories:
cgi-bin
conf
htdocs
icons
logs
src
support
To make your server more secure, use a separate disk partition for your web content. Create a unique mount point for this directory -- htdocs is a good name to use, but make it somewhere outside the ServerRoot directory. You'll need to update /etc/vfstab to mount this partition as part of your server's startup process.
Do not use the htdocs directory included in the distribution as your DocumentRoot. This directory contains user documentation that you don't want to make available to the public as it contains information a potential attacker could use to penetrate your system. (The attacker can deduce what kind of web server you’re running, and hone his attack accordingly.) Move these documentation files into your support directory so the webmasters for your site can refer to them as needed.
The src directory (shown in red above), should not be installed on your server. The contents of this directory are only needed when you are compiling the dæmon executable.
You’ll need to install the Apache server using “sudo” privileges or as root.
~> pwd
/usr/local/build/apache_1.3.27
~> sudo make install
make [1]: Entering directory ‘/admin/apache_1.3.27’
===> [mktree: Creating Apache installation tree]
./src/helpers/mkdir.sh /usr/local/apache/bin
./src/helpers/mkdir.sh /usr/local/apache/libexec
./src/helpers/mkdir.sh /usr/local/apache/man/man1
./src/helpers/mkdir.sh /usr/local/apache/man/man8
./src/helpers/mkdir.sh /usr/local/conf
..
+--------------------------------------------------------+
| You now have successfully built and installed the |
| Apache 1.3 HTTP server. To verify that Apache actually |
| works correctly you now should first check the |
| (initially created or preserved) configuration files |
| |
| /opt/apache/conf/httpd.conf
| |
| and then you should be able to immediately fire up |
| Apache the first time by running: |
| |
| /opt/apache/bin/apachectl start
| |
| Or when you want to run it with SSL enabled use: |
| |
| /opt/apache/bin/apachectl startssl
| |
| Thanks for using Apache. The Apache Group |
| http://www.apache.org/ |
+--------------------------------------------------------+
5. Add authentication against LDAP entitlement store.
It’s important that you don’t set up your own userid/password store, since it propagates passwords into insecure locations. Instead, you should modify your configuration to defer authentication to a central store, such as a centrally maintained LDAP. To authenticate against an LDAP store, you need to compile Apache with mod_ldap. In order to use mod_ldap, you’ll need LDAP libraries installed on your system. You can use OpenLDAP or Netscape Directory SDK for the LDAP client libraries.
There is more than one version of mod_ldap available, but we recommend using the one that retains the same Apache directives as Apache 2.0. This module requires DSO support, if you prefer to compile statically, you’ll have to figure that out on your own.
5.1 Download mod_auth_ldap from http://www.rudedog.org/auth_ldap
5.2 Un-tar and install auth_ldap
~> pwd
/usr/local/build
~> tar -xvf auth_ldap-1.6.0.tar
You’ll need to use Apache’s module installation tool (apxs) to install this shared module.
~> pwd
/usr/local/build/auth_ldap-1.6.0
~> sudo ./configure --with-apxs=/opt/apache/bin/apxs
creating cache ./config.cache
checking for apxs... /opt/apache/bin/apxs
checking whether apxs works... yes
checking for ber_init in -llber... no
checking for ldap_init in -lldap... no
checking how to run the C preprocessor... cc -E
checking for ANSI C header files... yes
checking for working const... yes
checking for vprintf... yes
checking for strdup... yes
checking for strerror... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
~> sudo make
~> sudo make install
5.3 (After installation) Add the AuthLDAPURL directive to directories
This step really can’t be run until you’ve installed the web server, but it belongs in this section. Once you’ve got your web server installed, just add the LDAP authentication directives to any directory (or httpd.conf file) where you want password protection with CEC credentials. Here’s an example of protecting a directory named “Internal”
AuthName CEC
AuthType Basic
AuthLDAPURL ldap://ldap.xianco.com:389/ou=employees,ou=people,o=xianco.com?uid?sub?(objectclass=xiancoPerson)
require valid-user
6. Complete certificates setup
Now that the server is installed, we need to copy the CA cert chain to Apache’s configuration file and get rid of any extra junk in there. Apache creates default “Snake Oil” certificates in your cert directory, you should get rid of those too.
6.1 Clean out the certificate directory
Get rid of default information from the certificate directory, including linked files and the extra “Snake Oil” certificates.
~> pwd
/opt/apache/conf/ssl.crt
~> sudo make clean
~> sudo rm snakeoil*
6.1 Copy the certificate chain to the configuration directory
~> sudo cp /usr/local/build/ca.crt /opt/apache/conf/ssl.crt/
7. Configure the Apache server
Configure the file permissions and runtime settings of the Apache server. It’s important that you place your htdocs, cgi-bin, and logs directories on separately mounted filesystems.
7.1 Configure httpd.conf settings
Set the following in your httpd.conf file. You can also download an example httpd.conf with these settings here.
Directive and setting |
Description/rationale |
|
ServerType standalone |
More secure than starting it with inetd |
|
ServerSignature Off |
Prevents server from giving version info on error pages. |
|
ServerTokens Prod |
Prevents server from giving version info in HTTP headers |
|
Port 80 Listen 80 Listen 443
|
Default ports. It uses the “IfDefine” directive to listen on both ports when you start the server in SSL mode. |
|
User webserv (or whatever you created in step 2 above) |
Ensure that the child processes run as unprivileged user |
|
Group webserv (or whatever you created in step 2 above) |
Ensure that the child processes run as unprivileged group |
|
FancyIndexing off |
Prevent server from displaying an icon to reveal the file type |
|
ErrorDocument 404 errors/404.html ErrorDocument 500 errors/500.html etc. |
To further obfuscate the web server and version, this will redirect to a page that you should create, rather than using the default Apache pages. |
|
ServerAdmin |
Use a mailing alias – never use a real id here (avoid social engineering). |
|
UserDir disabled root |
Ensures that, should user directories be enabled, it will not allow access to root’s files. |
|
Order Deny, Allow deny from all
|
Deny access to the root file system. |
|
deny from all
Options -FollowSymLinks -Includes -Indexes -MultiViews AllowOverride None Order allow,deny Allow from all
|
LimitExcept prevents TRACE from allowing attackers to find a path through cache or proxy servers.
The “-“ before any directive disables that option.
FollowSymLinks allows a user to navigate outside the doc tree, and Indexes will reveal the contents of any directory in your doc tree.
Includes allows .shtml pages, which use server-side includes (potentially allowing access to the host). If you really need SSI, use IncludesNoExec instead.
AllowOverride None will prevent developers from overriding these specifications in other parts of the doc tree. |
|
ScriptAlias /cgi-bin/ "/opt/apache/cgi-bin/" |
Make sure you don’t mingle HTML files in your cgi-bin directory, or vice-versa. |
|
SSLCertificateChainFile /opt/apache/conf/ssl.crt/ca.crt |
(Find this line and uncomment it). This points to the Certificate Authority file for your chained certificate. |
You should familiarize yourself with the following parameters. Unless you are running a high-volume web site, you can safely leave the settings at their default values. If you are running a high-volume web site, you’ll want to adjust these directives upward to better withstand denial-of-service attacks.
StartServers
MinSpareServers
MaxSpareServers
Timeout
Keepalive
MaxKeepAliveRequests
KeepAliveTimeout
MaxClients
MaxRequestsPerChild
7.2 Remove default Apache files
It’s important to remove default files such as .html files and CGI scripts (yes, even the Apache manual). This will help obfuscate the server you’re running, targetted attacks against your web server. You’ll probably want to build a simple index.html page to place in the htdocs directory, just so you know the web server is working when you start it.
~> sudo rm –fr /opt/apache/htdocs/*
~> sudo rm –fr /opt/apache/cgi-bin/*
~> sudo rm –fr /opt/apache/icons/*
To test that your web server is running, you can now place this file in your htdocs directory – it’s just a simple index.html file. Make sure you set the permissions to world-readable.
7.3 Set directory and file permissions for the server
To protect the directories on your server, it’s important that you protect the directories themselves.
bin is where the executable portion of the Apache web server is. It should be readable/executable only by members of the webadmin group, but only writable by root.
~> sudo chown –R root:webadmin /opt/apache/bin
~> sudo chmod –R 770 /opt/apache/bin
conf is where your web server configuration files are and needs to be read/writable only by the webadmin group.
~> sudo chown –R root:webadmin /opt/apache/conf/*
~> sudo chmod –R 770 /opt/apache/conf/*
logs is where your access and error logs will go. It should be readable only by the webadmin group.
~> sudo chown –R root:webadmin /opt/apache/logs
~> sudo chmod –R 755 /opt/apache/logs
htdocs is where your HTML files are and needs to be world readable, but writable only by root (you should copy content in from a staging server).
~> sudo chown –R root /opt/apache/htdocs
~> sudo chmod –R 775 /opt/apache/htdocs
cgi-bin is where your executable scripts are and needs to be world read/executable, but writable only by root (you should copy content in from a staging server).
~> sudo chown –R root /opt/apache/cgi-bin
~> sudo chmod –R 775 /opt/apache/cgi-bin
8. Make final configuration and start server
Lastly, we need to modify the startup configuration for Apache and restart the server.
8.1 Modify Apache startup script so that it will notify you when it’s restarted.
As a failsafe measure, you should notify your webmaster alias any time this server is restarted. That way, you’ll be notified of any unauthorized attempts.
Open /opt/apache/bin/apachectl and add something like this to the file:
tail /opt/apache/logs/error_log > /tmp/error_log
/bin/mail -s 'Apache web server has restarted'
rm /tmp/error_log
8.2 Test your configuration by starting the server
sudo /opt/apache/bin/apachectl startssl
8.3 Keep your web server patched
Check web sites for Apache and all modules regularly and apply important patches.
Apache web server: http://nagoya.apache.org/dist/httpd/patches/
mod_ssl server: http://www.modssl.org/source
OpenSSL: http://www.openssl.org/source