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
<jim@apache.org>".
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
<jim@apache.org>".
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
<rse@engelschall.com>".
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
<rse@engelschall.com>".
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 []:webmaster@xianshield.xianco.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: <blank>
An optional company name []: <blank>
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 <server name>.cer), the 2nd file is the certificate
chain. To make things easier, rename the
CA certificate file to remove spaces and change the suffix to .crt (the default
certificate chain name for Apache is “ca.crt”)
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”
<Location "/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
</Location>
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 <IfDefine
SSL> Listen 80 Listen 443 </IfDefine> |
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 <hostname>-webmaster@xianco.com |
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. |
|
<Directory
/> Order Deny, Allow deny from all </Directory> |
Deny access to the root
file system. |
|
<Directory
/opt/apache/htdocs"> <LimitExcept GET POST> deny from all </LimitExcept> Options -FollowSymLinks
-Includes -Indexes -MultiViews AllowOverride None Order allow,deny Allow from all </Directory> |
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'
<hostname>-webmaster@xianco.com < /tmp/error_log
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