|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
Apache Security
Apache lets you restrict access to your site based on IP addresses or hostnames.
This is done through allow and deny directives in httpd.conf.
Suppose you don't want anyone who does not have a DNS entry in your company DNS
to access the directory /private You would add these lines to httpd.conf:
<Location /private>
SetHandler private
Order deny, allow
Deny from all
Allow from mycompany.com
</Location>
In this example we deny everyone, unless the request originates from a host belonging
to the domain mycompany.com. Generally
restrictions can be specified in six ways:
- all affects everyone.
- A full or partial IP address, such as 192.168.1.101 or 192.168.1.
- A full or partial host or domain name, such as susefan.com.
- A network/netmask pair such as 192.168.1.0/255.255.1.0.
- A network address in the classless interdomain routing (CIDR) form, such
as 192.168.1.0/24.
- An environment variable, such as env=allowed_hosts.
Apache Basic Authentication is the most common authentication method used: when
someone attempts to access a protected page, Apache asks for a username and a password.
It then verifies the username and password and if successful, Apache serves the
request. Basic Authentication is implemented with the mod_auth module;
make sure this module is installed. The main deficiency is that the Basic Authentication
does not encrypt the password when you type it in and thus you need to select a
separate password so that the interception of the Web password does not lead
to compromise of your other accounts. Basic Authentication requires creation
of a plain-text list of usernames and passwords using htpasswd2, a script
included with the Apache2 package. You should store these passwords away from
your main Apache installation directory, for example /etc/httpd/passwd
Apache Digest Authentication is more secure as it is using SSL/TSL.
to create a new hidden password file, with the first user use:
./htpasswd -c /etc/httpd/.htpasswd joeuser
You'll be prompted twice for this user's password. To add new users to this file,
use the same command without the -c switch (that creates a new file), for
example:
./htpasswd /etc/httpd/.htpasswd webuser
You also need to configure Apache to refer to .htpasswd when serving
a protected page iether in httpd.conf or by
creating a special dot file (.htaccess) in each protected directory:
- In httpd.conf, you would create a new section labeled <Directory
/pub>. Either way, the syntax is the same. Use these four directives:
AuthType Basic
AuthName "Members Only"
AuthUserFile /etc/httpd/.htpasswd
Require user joeuser
Here the AuthType is Basic because we're using Basic Authentication
(the option would be set to Digest if mod_auth-digest was used). The AuthName
can be anything and identifies the "realm" or category of that page. In this
case, all pages with the AuthName Members Only would have the same
password. Thus, when the browser went to another page marked Members Only, it
could deliver the same password without forcing the user to retype it in an
endless series of pop-up dialog boxes. The AuthUserFile points to the
.htpasswd file containing the usernames and passwords. The Require
directive specifies the user(s) allowed to access the page.
- The .htaccess file should be located in the directory you want
to protect
Often it is better to use weaker protection based on username only . In this
case you can create a group of users with the same level of access, create a group
file named .htgroup in any text editor with the Group Name and a list of
users. Save it in the same directory as .htpasswd. The entry in .htgroup
file should look like this:
The concept of the two files are similar to Linux's /etc/passwd and
/etc/group files; .htpasswd stores each username and password
hash, and .htgroup aggregates usernames into logical groups. Each group
member needs to have a password listed in .htpasswd before access is allowed.
Now edit your .htaccess file so that your group has access.
AuthType Basic
AuthName "Members Only"
AuthUserFile /etc/httpd/.htpasswd
AuthGroupFile /etc/httpd/.htgroups
Require group Members
Everyone in the Members group would now have access to all pages with the "Members
Only" realm.
Note: You can create as many groups as you want in
your .htgroups file. Each entry is a single line listing all its members
together, separated only by a space.
A good start is to avoid displaying the software
versions you are using.
Let me explain. When somebody request a page to a
HTTP server, this one respond with headers such as
Content-Type, Content-Length...
as well as Server.
People don't usually see those headers, but if
someone wants to hack your box, they might be looking
for it. Why? Because known exploits usually work on
specific software version.
Lets look at default HTTP headers on my ubuntu dapper
box:
~$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Tue, 25 Jul 2006 10:47:13 GMT
Server: Apache/2.0.55 (Ubuntu) PHP/5.1.4-1.dotdeb.2
Last-Modified: Mon, 20 Mar 2006 09:51:25 GMT
ETag: "3057-1f8-1a0f4140"
Accept-Ranges: bytes
Content-Length: 504
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Connection closed by foreign host.
As you can see from this excerpt, my box is running
Apache 2.0.55 on
an Ubuntu box and
php-5.1.4 is
used. This is perfect, if I want to hack that box, I
simply have to look for known exploit for apache 2.0.55
or php 5.1.4 or even ubuntu.
The idea is to avoid telling too much, so we are
going to make apache be less verbose.
2. Apache
Configuration File:
In Apache, the
ServerTokens directive allow the system
administrator to set different type of Server
HTTP response header:
- ServerTokens
Prod[uctOnly] : this is the most restrictive,
in our example, apache will respond:
Server: Apache
- ServerTokens
Major
response -> Server: Apache/2
- ServerTokens
Minor
response -> Server: Apache/2.0
- ServerTokens Min[imal]
response -> Server: Apache/2.0.55
- ServerTokens Os
response -> Server: Apache/2.0.55 (Ubuntu)
- ServerTokens
Full
response -> Server: Apache/2.0.55 (Ubuntu)
PHP/5.1.4-1.dotdeb.2 mymod1/X.Y mymod2/W.Z
By default, ServerTokens is set to
Full, on my
dapper box at least. To change that value, edit
/etc/apache2/apache2.conf and look for the line
containing ServerTokens.
Nota: On my
ubuntu dapper box, ServerTokens was not set and was
therefore taking the default value (Full), in that case,
simply add this directive to apache2.conf.
I would recommend setting ServerTokens to Prod by
adding this to apache2.conf:
ServerTokens Prod
Reload apache:
$sudo /etc/init.d/apache2 reload
and check for the new headers. Here are the headers
sent back by my local server after setting ServerTokens
to Prod:
$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Tue, 25 Jul 2006 11:33:09 GMT
Server: Apache
Last-Modified: Mon, 20 Mar 2006 09:51:25 GMT
ETag: "3057-1f8-1a0f4140"
Accept-Ranges: bytes
Content-Length: 504
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Connection closed by foreign host.
As you can see, apache does not tell anymore which
version and modules are running
3. PHP:
Another way to hide which PHP version you are running
can be achieved through php.ini.
Php as a directive of its own in order not to be too
verbose, this is the variable called
expose_php.
Turning this one to Off
will avoid php telling that it is running. In the
following output, I had ServerTokens set to Full and
expose_php to Off:
"Mod_security
1.7 has been
released.
Mod_security is an open source intrusion detection and prevention
engine for web applications. It operates embedded into the web server, acting as
a powerful umbrella - shielding applications from attacks. The latest release
adds output scanning to Apache 2.x; the ability to analyze cookies;
functionality to change the identity of the web server; several new actions for
rule grouping; new null-byte attack anti-evasion code."
- CIS_Apache_Benchmark_v1.6.pdf - the Benchmark document contains detailed
instructions for implementing the steps necessary for CIS Level-1 and Level-2
security.>
- cis_score_tool_apache_v2.0.8.sh.gz - a Host-based Scoring
Tool scores the security of a system against the Benchmark and creates a variance
report.
Apache can be hacked. As companies have
improved perimeter security, hackers have increasingly focused on attacking
Apache Web servers and Web applications.
Firewalls and SSL won't protect you: you must systematically harden your Web
application environment.
Preventing Web Attacks with
Apache brings together all
the information you'll need to do that: step-by-step guidance, hands-on examples,
and tested configuration files.
Building on his groundbreaking SANS presentations on
Apache security, Ryan C. Barnett reveals
why your Web servers represent such a compelling target, how significant exploits
are performed, and how they can be defended against. Exploits discussed include:
buffer overflows, denial of service, attacks on vulnerable scripts and programs,
credential sniffing and spoofing, client parameter manipulation, brute force
attacks, web defacements, and more.
Barnett introduces the Center for Internet Security
Apache Benchmarks, a set of best-practice
Apache security configuration actions and
settings he helped to create. He addresses issues related to IT processes and
your underlying OS; Apache downloading,
installation, and configuration; application hardening; monitoring, and more.
He also presents a chapter-length case study using actual Web attack logs and
data captured "in the wild."
For every sysadmin, Web professional,
and security specialist responsible for Apache
or Web application security.
With this book, you will learn to
-
Address the OS-related flaws most likely to compromise Web server security
-
Perform security-related tasks needed to safely download, configure,
and install Apache
-
Lock down your Apache httpd.conf
file and install essential Apache security
modules
-
Test security with the CIS Apache
Benchmark Scoring Tool
-
Use the WASC Web Security Threat Classification to identify and mitigate
application threats
-
Test Apache mitigation settings
against the Buggy Bank Web application
-
Analyze an Open Web Proxy Honeypot to gather crucial intelligence about
attackers
-
Master advanced techniques for detecting and preventing intrusions
This How to Guide instructs Solaris system administrators
and security professionals in the process of securing common Web servers. By
the end of the guide, an example configuration will be created that allows Web
content to be maintained securely by content owners, while the Web server
itself will run with a minimized set of privileges in its own secured Container.
Administrators are guided step-by-step through the process and at the end of
the guide should be able to:
- Create a basic Solaris Container for hosting applications
- Configure the Apache2 Web server to run in a Solaris
Container
- Use User and Process Rights Management to reduce application
privileges
- Use the Solaris Service Manager to reduce security risk
of a Container
- Share data securely between two Containers
This guide is not exhaustive and will not cover all optional
features of these technologies. However, the reference section provided at the
end of the document provides pointers to where administrators can learn more.
Some hints and tips on security issues in setting up a web server. Some of the
suggestions will be general, others specific to Apache.
The Apache HTTP Server has a good record for security and a developer community
highly concerned about security issues. But it is inevitable that some ...
The O'Reilly Network has teamed with Red Hat Apache Week, the leading commercial
Apache site to offer comprehensive Apache information and resources.
Apache Security is the complete guide to securing your apache web server.
(LinuxPlanet)
With Web security becoming a paramount concern in the face of several DoS attacks
in prior weeks, securing your Apache/Linux installation should be the ...
Apache Security is a comprehensive Apache Security resource, written by Ivan
Ristic for O'Reilly. One chapter (Apache Installation and Configuration) is
...
Tutorials and Sample Chapters
Apache:
The Definitive Guide Chapter 11:
Security (PDF Format)
Apache: The
Definitive Guide, 2nd Edition: Chapter 13 Security
Here we will look at how secure communication is built into Apache. ... You
now have a secure version of Apache, httpsd; a site to use it on, site.ssl;
...
www.oreilly.com/catalog/apache2/chapter/ch13.html
- 113k - oreilly.com
-- Online Catalog: Apache Security, First Edition
This all-purpose guide for locking down Apache arms readers with all the
information they need to securely deploy applications.
Apache Security
Apache Security from AZ. Lincoln Stein. Open Source Conference, Version 3. For
copies of this tutorial:. http://stein.cshl.org/~lstein ...
THE COMMON SENSE GUIDE TO APACHE SECURITY. As I clearly state in my Site
Security Page, you are the biggest threat to your own site! ...
Copyright © 1996-2008 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with. We do not warrant the correctness
of the information provided or its fitness for any purpose.
Last modified:
March 15, 2008