New users guide to securing an Apache Web Server
Last updated 05/06/03 Copyrighted 2003 flw/Dan, Jason Lambert
Why use Apache Web Server 2.x instead of 1.3? See
http://httpd.apache.org/docs-2.0/new_features_2_0.html If you don’t need the
new features then there is no strong reason to use 2.x except any new features
in the future will be in the 2.x version and not the 1.3.27 version.
This guide is intended for new users of Apache Web Server and how to take some
security steps to make it harder (or slow down) for hackers to deface your hard
work. It is also based on RedHat version 7.x for default file location purposes
only. Your file locations and names may vary. We also are assuming you are
logged in as root or logged in with the root privileges. If you’re not sure,
then from the command line type in “whoami” and press enter. The steps below are
not in any priority order and you don’t have to implement all of them but every
step in insuring your web servers security makes it that much harder to break
in.
Step 1. Always use the most current version. If your using 1.3.26 then upgrade
to 1.3.27 and the same for Version 2.44 upgrade to 2.45 which are the current
versions as of this writing. It very easy for people to find out weaknesses in
older version because they are listed at public locations like
http://www.apacheweek.com/features/security-13 or here
http://www.apacheweek.com/features/security-20 . To upgrade, copy all your
web html/cgi etc… files and graphics to a temporary directory which will include
a copy of the current httpd.conf and .htaccess if used. Then follow the
directions for the install and copy back all your web site content and
httpd.conf and .htaccess if used. Reboot your computer. Remember this is only a
simplistic example.
Step 1a. Where do I get the upgrade? You can get the current versions of 1.3.27
and 2.4.x at
http://httpd.apache.org/
Step 2. My opinion only, always used the current version of your Linux
distribution. An example is if you’re using Redhat 7.0 then upgrade to 7.2. I
don’t recommend upgrading from your 7.2 to major release like 8.0 or a 9.0 until
the versions has been on the market long enough for Redhat to come out with a
minor 9.1 release. There are always lots of bugs in the initial versions. To
upgrade from one version of Redhat to another you'll have to choose “upgrade” to
Red Hat Linux 7.2 (instead of performing a full installation). You must choose
“Upgrade”.
Step 3. Change your document root (main page or starting page on your web site
like /home/mywebsite, if it doesn’t exist you have to go to the cmd line and
type mkdir /home/mywebsite) to a non-default location by editing the httpd conf
file. You’ll be looking for “documentroot”. Feel free to use whatever text
editor you prefer (VI, EMACS, etc…). In Redhat 7.0 it is in /var/www/html, in
older versions it may be in /home/httpd/html or /usr/local/Apache/htdocs. If you
still can’t find it, try from the command line at the / directory by using the
following:
“find –name httpd.conf”
You’ll also want to check for obvious errors that Apache Web Server see’s. So
from the command line use “apachectl configtest “ and any syntax errors will be
reported.
Step 4. Verify and if needed correct all your files for viewing only. They
should be set as read only by Apache Web Server.
Step 5. Verify only files or graphics that are used or viewed at your site are
the only files in your web directories. I.e. don’t put password files or your
configuration notes in the same directory as index.html or where your graphics
are.
Step 6. Any temporary files created by content generators like cgi scripts be
located in a single directory where they have “write” access outside your
content area to protect a script from deleting your web content.
Step 7. Create visible and imbedded copyright notices. Imbedded notices should
be toward the top of the web page so it is very visible. You’ll want to edit any
original graphics with the same copyright notice.
Step 8. Disable directory view from displaying your web page as a view only file
manager. This is done from httpd.conf. You can just comment out the “directory
view” by using the # symbol.
Step 9. This is for cgi only so if your not using cgi skip ahead. CGI is a how
to all by itself. So for here I’m only going to list the commonly known issue
you should be aware of and look into.
User input crashes the cgi app.
User input creates system calls that are unsafe.
User sees hidden data.
User input causes denial of service (DOS). A good practice is to limit how much
memory and CPU usage Apache Web Server web gets to use. This is in case you are
under a DOS that you still have some memory and cpu power to start a session
with the server and kill the problem process or user connection.
The commands you would use within httpd.conf to limit a DOS are “<Limit
RLimitCPU > </Limit>” and “RLimitMEM”. RLimitCPU
RLimitCPU
Syntax: RLimitCPU n|max [n|max]
RLimitCPU sets the CPU resource limit for all server processes. It can have one
or two values, and the values are either n or "max," where n is seconds per
process "max" is the maximum resource limit allowed by the operating system.
Whether this directive is given one value or two, the first value is always the
soft resource limit. If there are two values, the second is the hard resource
limit.
RLimitMEM
Syntax: RLimitMEM n|max [n|max]
RLimitMEM sets the memory resource limit for all server processes. It can have
one or two values, and the values are either n or "max," where
n is bytes per process "max" is the maximum resource limits allowed by the
operating system Whether you give this directive one value or two, the first
value is always the soft resource limit. If there are two values, the second is
the hard resource limit. User input gets posted to the web site.
Note: you can reduce the risks involved by the use of a cgi wrappers which runs
the cgi as the user that owns the file rather than as the Apache Web Server
user. Some cgi wrappers will do additional security checks as well.
Step 10. This is really just for fun. Change the authentication error message to
get a unauthorized user thinking if he should really continue or not. Put the
following code inside the htttpd.conf:
ErrorDocument 401 “Your message goes here”.
You can create a special page like “While you were busy trying to get into my
server, I was busy tracking your ip to your ISP. “Just so you are aware, after
three failed attempts to authenticate successfully, my server forwards your
information with the details to your ISP under the ‘violation of the terms of
service agreement’ you opted in for to get your service. Good luck and have a
nice day :>”
The key to the above is they really don’t know if it true or not and will steer
some away. Security is not always locks and keys. Sometimes it’s the fear of the
unknown.
Step 11. Do not use Java Script or ASP to secure your web site. There are many
weaknesses to these methods are not recommended. Use basic authentication
instead that is part of Apache Web Server.
Step 12. If you want to require user authentication for your whole site or just
a section of there are several things that must be done and if one is not right
it will fail. All of the following is from the command line and assumes your
logged in a root or a user with root privileges.
a. Use .htpasswd to create a username and password for each user or one for a
group of people to use.
At the cmd line type: “htpasswd -c /usr/local/etc/httpd/.htpasswd martin”.
The -c argument tells htpasswd to create new .htpasswd file. When you run this
command, you will be prompted to enter a password for martin, and confirm it by
entering it again. Other users can be added to the existing file in the same
way, except that the -c argument is not needed. The same command can also be
used to modify the password of an existing user.
After adding a few users, the /usr/local/etc/.htpasswd file might look like
this:
martin:WrU808BHQai36
jane:iABCQFQs40E8M
accounting:FAdHN3W753sSU
The first field is the username, and the second field is the encrypted or hashed
password.
The .htpasswd file goes into the same directory as the httpd.conf file. Such as
etc/httpd/conf/.htpasswd
b. To get the server to use the usernames and passwords in this file, you need
to configure a realm. This is a section of your site that is to be restricted to
some or all of the users listed in this file. This is typically done on a
per-directory basis, with a directory (and all its subdirectories) being
protected (Apache Web Server 1.2 and later also let you protect individual
files). The directives to create the protected area can be placed in a
httpd.conf file.
To allow a directory to be restricted within another directory you first need to
ensure that the httpd.conf file allows user authentication to be set up in a
.htaccess file. This is controlled by the AuthConfig override. The httpd.conf
file should include AllowOverride AuthConfig to allow the authentication
directives to be used in a .htaccess file.
c. To restrict a directory to any user listed in the users file just created
(.htaccess), you should create a .htaccess file containing:
(The .htaccess file goes into the target dir unless changed in the httpd.conf
file)
Such as /home/httpd/html/.htaccess
authname "mycompany’s secured site"
authtype basic
authuserfile /etc/httpd/conf/.htpasswd
require valid-user
Since all web content in located in /home/mywebsite all configuration and Apache
Web Server application files are located outside of your sites directory and as
only as secure as you Linux machine is. This is a tutorial by itself.
The first directive, AuthName, specifies a realm name for this protection. Once
a user has entered a valid username and password, any other resources within the
same realm name can be accessed with the same username and password. This can be
used to create two areas, which share the same username and password.
The AuthType directive tells the server what protocol is to be used for
authentication. At the moment, Basic is the simplest method available but also
transmits username and passwords in clear text which is its security weakness.
AuthUserFile tells the server the location of the user file created by htpasswd.
A similar directive, AuthGroupFile, can be used to tell the server the location
of a groups file (see below).
These four directives have between them tell the server where to find the
usernames and passwords and what authentication protocol to use. The server now
knows that this resource is restricted to valid users. The final stage is to
tell the server which usernames from the file are valid for particular access
methods. This is done with the require directive. In this example, the argument
valid-user tells the server that any username in the users file can be used. But
it could be configured to allow only certain users in:
“require user martin jane” would only allow users martin and jane access (after
they entered a correct password). If user art (or any other user) tried to
access this directory, even with the correct password, they would be denied.
This is useful to restrict different areas of your server to different people
with the same users file. If a user is allowed to access the different areas,
they only have to remember a single password.
Note that if the realm name differs in the different areas, the user will have
to re-enter their password.
Step 13. Disguise or limit the information Apache “server” header gives out
When a HTTP request is sent to a webserver, the server will respond with any
necessary page content, and also, depending on how the server is configured, it
will provide some information about the type of server software being used. For
example, what I have typed appears in bold:
jason@london:~$ telnet
www.example.com 80
Trying x.x.x.x...
Connected to
www.example.com.
Escape character is '^]'.
GET /filethatdoesnotexist HTTP/1.0
HOST:
www.example.com
HTTP/1.1 404 Not Found
Date: Sun, 04 May 2003 15:22:53 GMT
Server: Apache/1.3.19 (Unix) FrontPage/4.0.4.3 mod_ssl/2.8.2 OpenSSL/0.9.6g Auth
MySQL/2.20
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /filethatdoesnotexist was not found on this server.
<HR>
<ADDRESS>Apache/1.3.19 Server at
www.example.com Port 80</ADDRESS>
</BODY></HTML>
Connection closed by foreign host.
jason@london:~$
If you look closely, you can see the server has passed back some vital
information about itself in the line:
Server: Apache/1.3.19 (Unix) FrontPage/4.0.4.3 mod_ssl/2.8.2 OpenSSL/0.9.6g Auth
MySQL/2.20
We can see that the server is Apache, Version 1.3.19, running on a UNIX system.
We can also see modules that are loaded into the server, for example Frontpage
and mod_ssl. With this information an attacker can begin attacking your system,
with precision.
So… How do you stop this information being divulged?
There are 2 ways, the first, ideal if you are not really comfortable with
editing the Apache source, then you can use “ServerTokens” to control what level
of information is sent to the client with a HTTP response. Beware that some
applications can still give away free information like phpbb , mysql, ssh that
Apache cannot stop. You would need to fine tune these apps or use a firewall for
that.
To use server tokens, you need to edit your httpd.conf file, and, firstly see if
you already have a line/section called ServerTokens. If not, you can add it. A
ServerTokens directive for the server we looked at earlier will probably look
like:
ServerTokens Full
If a server tokens line is not specified, it will Apache will default to “Full”
setting. Depending on what you set “ServerTokens” to, will control how much
information revealed. Some newer versions of Apache come in "Prod" configuration
by default, you need to check and see how your httpd.conf file is setup. Here is
a quick table of the settings you can use, and the response that will be shown
to the client:
ServerTokens Prod
Server sends (e.g.): Server: Apache
ServerTokens Min
Server sends (e.g.): Server: Apache/1.3.0
ServerTokens OS
Server sends (e.g.): Server: Apache/1.3.0 (Unix)
ServerTokens Full
Server sends (e.g.): Server: Apache/1.3.0 (Unix) PHP/3.0 MyMod/1.2
Don’t forget, after changing your httpd.conf file to restart apache for the
settings to take effect.
If you want to go to extremes, then the 2nd method is for you. What we will
attempt to do is to change the Server header to impersonate a Microsoft IIS
server, ie, so instead of server: apache, we now display: “Server:
Microsoft-IIS/5.0”.
To make this change you will need to re-compile your apache server. At this
stage, make a backup of your httpd.conf, and all of your webpages and graphics.
Download the apache source tarball from httpd.apache.org and unpack, then change
to the directory that you unzipped to.
For version 1.3.27, open the file src/include/httpd.h (2.x users, edit
include/ap_release.h), and change these lines:
#define SERVER_BASEPRODUCT “Apache”
#define SERVER_BASEREVISION “1.3.27”
to:
#define SERVER_BASEPRODUCT “Microsoft-IIS”
#define SERVER_BASEREVISION “5.0”
Then proceed to recompile apache, and test.
For further questions on web server security see:
http://www.w3.org/Security/Faq/
http://httpd.apache.org/docs-2.0/mis...rity_tips.html
http://httpd.apache.org/docs/misc/security_tips.html
Saturday, November 15, 2008
Security Guide for people new to Apache Web Server
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment