Professional Documents
Culture Documents
TechRepublic SolutionSeries
Table of Contents
Apache: The engine Introduction ..................................................................................................3
that powers the Web
What's new in Apache 2.2.4? ......................................................................4
Executive Editor Setting up a simple Web site with Apache 2.2.4 ......................................8
Jason Hiner Make the move from IIS to Apache 2.2.x ..............................................13
Section Editor
John Sheesley
Troubleshoot Apache with these tips ......................................................18
Contributing Editors Ten tips for securing Apache ....................................................................24
Scott Lowe, Jack Wallen, Setting up Apache as a Web server under Linux via GUI....................31
and Vincent Danen
Creating virtual hosts with Apache..........................................................35
Assistant Editor | Graphic Artist
Christina Cathcart
Copyright ©1995-2007
by CNET Networks, Inc. All rights
reserved. TechRepublic and its logo
are trademarks of CNET Networks,
Inc. All other product names or
services identified throughout this
book are trademarks or registered
trademarks of their respective
companies. Reproduction of this
publication in any form without prior
written permission is forbidden.
Disclaimer
The information contained herein has
been obtained from sources believed
to be reliable. CNET Networks, Inc.
disclaims all warranties as to the
accuracy, completeness, or adequacy
of such information. CNET Networks,
Inc. shall have no liability for errors,
omissions, or inadequacies in the
information contained herein or for
the interpretations thereof. The reader
assumes sole responsibility for the
selection of these materials to achieve
its intended results. The opinions
expressed herein are subject to
change without notice.
TechRepublic
1630 Lyndon Farm Court
Louisville, KY 40223
Tel.: 1.800.217.4339
Online Customer Support:
http://www.techrepublic.com/cshelp
Published by TechRepublic
August 2007
This TechRepublic PDF is best viewed in
Facing page layout in Adobe Acrobat Reader.
Introduction
W
hen people think of the term “Open Source Software”, usually the first
thing that comes to mind is the Linux operating system. Linux has been the
poster child for the open source movement for some time, but it's certainly
not the only member of the family.
Beyond Linux, the most famous and widely used piece of open source software is
the Apache Web server. Once by far the most dominant Web server software on the
Internet, Apache still powers about half of the Web sites you'll run into.
One of Apache's key benefits is that it runs on a multitude of operating systems.
You can obtain a version of Apache for such network operating systems as:
X Windows
X Linux
X Mac OS X
X OS/2
X NetWare
X Unix
Apache's chief rival for market share is Microsoft's IIS. Microsoft's Internet
Information Services has shipped with every version of Windows since it was created
as part of an Option Pack for Windows NT back in the late 90's.
Even though no one “owns” Apache, and the open source nature of it means that
anyone can get and modify the original source code, Apache still has a reputation of
being more secure than IIS.
Sometimes you'll hear Apache's name used in concert with other open source soft-
ware, such as Linux, MySQL, and PHP. Together, these products are referred to by the
acronym LAMP. The easiest way to think of them is a software suite which are often
used together to create rich full-featured Web sites.
One of the major drawbacks to Apache is that it's not always as easy to use as IIS.
Whereas Microsoft has gone to great lengths to ensuring that setting up and using IIS
is largely a point-and-click affair, Apache makes use of 80's-era configuration files. This
gives you more flexibility, but makes managing the Apache configurations more chal-
lenging.
In the sections that follow in this guide, we'll show you some of the essentials of
working with Apache 2.2.4. You'll see how to install Apache, how the configuration
files work, and even how to do some advanced things like setting up virtual hosts.
R
eleased in early 2007, Apache 2.2.4 is the latest version of Apache released in the
2.2 branch. Apache 2.2 is a major update from Apache 2.0 and provides a number
of new features and enhancements over previous versions of the server. Apache
2.2.4 is available for most operating systems, including Windows, OS X, UNIX and Linux.
Filtering improvements
Apache's filtering module, which provides you with the ability to make changes to
the way that Apache handles certain tasks related to the traversal of data to and from
the server, has also undergone a transformation in Apache 2.2. Called Smart Filtering,
it does away with dependencies and ordering problems that were inherent in the inflex-
ible filtering model offered by older versions of Apache.
Instead, the new filtering system provides dynamic configuration capabilities by
enabling filters to be conditionally inserted into the filter chain. This conditional pro-
cessing allows Apache to process different content types through different filters, even
when Apache can't tell what kind of content is being handled. Previously, filters were
added in a static, serial way, and each filter had to make a determination whether or not
to run and all filters had to be evaluated. Under the new model, the filters can be
dynamically configured based on the outcome of a filter handler.
Authentication
The Apache 2.2 developers have reworked much of the server's authentication func-
tionality, resulting in a number of changes to modules and configuration directives. In
short, Apache 2.2 separates the authentication and authorization functions of Apache
and provides an easier means by which to develop new authentication back-ends.
The module named mod_auth has been broken up into four new modules:
X mod_auth_basic : Allows the user of HTTP Basic Authentication.
X mod_authn_file : Provides the ability to authenticate users through the user of plain-
text password files.
X mod_authz_user : Allows a user to be granted access to or denied access to particular
sections of the Web site. If the user is listed in a "require user" directive, access is
granted.
X mod_authz_groupfile : Provides similar services to those offered by mod_authz_user,
but works on group membership instead.
The LDAP authentication module, mod_auth_ldap had been renamed to
mod_authnz_ldap.
Note that each module's name includes "auth", "authz", "authn", or "authnz" some-
where. Each of these means something:
X auth : Anything that has to do with HTTP authentication.
X authn : A back-end authentication system. These kinds of modules help to verify that
someone is who they claim to be. In most cases, this consists of the user providing
a username and password, but could also be accomplished through the user of a
smartcard, or some other means.
X authz : An authorization module. Authorization takes place after a user has been
identified by an authentication system and determines whether or not that user is
permitted access to a resource.
X authnz : A module that uses both authentication and authorization.
If you're upgrading from 1.3, or 2.0 to 2.2, and you're using authentication/authori-
zation, make sure to read upgrade docs before you take the plunge, as the httpd.conf
directives related to these services have changed significantly.
seen in Figure A.
X New command line parameter: The -l (that's an "el") parameter has always been
able to list modules compiled into the server, but does not include dynamically
loaded modules included using the LoadModule directive in httpd.conf. You can see
this in Figure B.
X Mod_imap has been renamed mod_imagemap : These kinds of changes actually
improve the usability of the product by reducing what could be significant confusion.
X SSL support is no longer included by using apachectl startssl: Instead, add the
necessary SSL directives to http.conf and just use apachectl start. Note that an example
configuration files, conf/extra/httpd-ssl.conf, has been included to help you in this.
X The default setting for the UseCanonicalName directive is now off: A self-referring
directive will now be constructed using the hostname and port supplied by the client. If
you would rather have a self-referring directive that is built using the value in httpd.conf's
ServerName directive, include a line in http.conf that reads "UseCanonicalName On".
Summary
Even though Apache 2.2 isn't the massive upgrade that 1.3 to 2.0 was, there are a
number of modifications and improvements that make this latest release worth consid-
ering, particularly if you want to use Apache's proxy or caching features. Apache 2.2.4
builds on the overall 2.2 release and rolls up all of the bugs fixes and minor enhance-
ments that have been introduced to the product since the 2005 release of Apache 2.2.
Figure A Figure B
The -M parameter lists all loaded static and shared The -l parameter shows you the modules compiled
modules. into Apache.
W
ith the release of the 2.2 branch of the Apache Web server, the Apache
group has improved upon an already outstanding service. If you're in the
market for a new Web server, or are interested in putting Apache 2.2.4 -- the
latest version as of this writing -- through its paces, it very easy to create a simple
Apache site on either Windows or Linux.
Linux
The installation of Apache 2.2.4 on Linux can be handled in almost unlimited different
ways, some dependent on your preferred Linux distribution. For example, if you're a Red
Hat or Fedora fan, RPM is your best choice. If you're using some other distribution, you
may be able to use RPM, or your distribution may have its own package format.
If you're installing your Linux server from scratch, you can usually choose Apache as
an installation option. If you have this option, take it, unless you need something
unusual in your installation.
If you're using an existing server and don't want to reinstall the OS, or if you want
to have the most granular control over how your Apache installation is configured,
your best bet is to build Apache from source code. If you're somewhat new to Linux
and the sound of this makes you nervous, it's actually a whole lot easier than it sounds.
Better yet, this option works on any Linux distribution out there. It even works for
Windows if you have an appropriate compiler installed.
For the example installation in this section, I'm going to build Apache 2.2.4 from
source and install it on a Fedora 7 installation. You won't see anything fancy in this
build -- just the basics will be included -- but your Linux server will be serving Web
pages in just minutes.
Note: Although I could have just chosen the "Web server" option when I installed
Fedora, that would have defeated the purpose of this article.
Before you can compile Apache, you need the source, which is available for down-
load from the Apache Web site. As of this writing, the latest version of Apache
available is 2.2.4. I've saved the file, named httpd-2.2.4.tar.gz to a folder named
/usr/src/apache-2.2.4 on my server. I like to save installations in this location so I have
them for the future.
The next few commands are entered from a command line. I've put them, in order,
in Table A.
Table A
cd /usr/src/apache-2.2.4 Change to the directory to which you saved the
Apache source download.
tar -zxvf httpd-2.2.4.tar.gz Extract the contents of the downloaded file into a
subdirectory named httpd-2.2.4.
When you're done with the steps in Table A, browse to your new server. You should
get a "It works!" message, as shown in Figure A.
Before you do too much, you should configure Apache to automatically start when
your system boots. The steps to make this happen depend on which Linux distribution
you're using. Please refer to your system docs for more information. Until you get that
set straight, use the "start" command in the last part of Table A.
Table B (page 39) lists the various modules available for your control during the ./configure por-
Figure A
Figure B
Managing Apache
In this article, I won't be going too deeply into managing an Apache configuration
file, but will provide you with some general tips. First off, Apache, under both Linux
and Windows, is managed through the manipulation of the file named httpd.conf. These
files are located here:
X 64-bit Windows: C:\Program Files (x86)\Apache Software Foundation\Apache2.2\conf
X 32-bit Windows: C:\Program Files\Apache Software Foundation\Apache2.2\conf
X Linux: /usr/local/apache/conf/httpd.conf
Httpd.conf is a long text file full of directives that tell Apache what to do. For exam-
ple, on both servers, the httpd.conf file has a line that reads "Listen 80." This directive
tells Apache to listen on port 80 for incoming requests. Going through the various
directives is beyond the scope of this article (I will go over the possible options in a
future article). However, after you make changes to the file, you need to restart the
Apache service. To do this:
X In Windows: Click Start | Control Panel | Administrative Tools | Services. Locate
the Apache2 service and click the Restart button.
X In Linux: execute the command:
/usr/local/apache/bin/apachectl restart
Summary
For a simple site, this is all you really need to know to get up and running. Once you
get used to it, Apache is very easy to work with and provides an outstanding platform
for robust Web development and page serving. As you get into more advanced tech-
niques, such as scripting languages and database access, you'll come to appreciate
Apache's flexibility.
E
ver since Netcraft has started tracking statistics regarding Web server usage, IIS
has never beat Apache when it comes to the number of sites using the two
servers. In general, the gap between IIS and Apache has been anything but
small. Until fairly recently, early 2002 saw Apache's worst day with only a 30% gap
between the two products. Today (in mid-2007), however, Apache's share (52.65%) is
very slowly eroding in favor of IIS (32.8%), which is bundled with the ubiquitous
Windows OS. Of course, these statistics take into consideration all of the free and
cheap hosting services that use Apache and don't consider internal use of IIS in many
companies, so the "real" values are likely more similar than they appear.
Even so, 20 percent is still a fairly significant gap! There are a number of reasons that
your company might consider making the jump from an IIS solution to Apache. I'll quick-
ly explain some of these reasons and then go over some of the ramifications of such a
decision and provide some advice for mitigating problems related to this kind of a move.
The focus of this article is on moving from IIS to Apache. As such, I'm not going
to spend a lot of time balancing the argument. While I personally consider both IIS
and Apache to be worthy products, in this article, I'm not arguing for either option, but
letting you know some things you may run into as a part of a transition.
Why change?
IIS is a good Web server, and it's getting better with each new version. Moreover, with
each new release, Microsoft improves the security of IIS, making the case for change a
little less compelling. And, for some organizations -- particularly those that have a heavy
reliance on other Microsoft tools -- a change would simply not make any sense.
Given these facts, why make a jump from a perfectly good Web server to Apache?
For those of you that do not have tools -- such as Exchange Outlook Web Access,
SharePoint or SQL Server Reporting Service -- that are tightly tied to IIS, are there
compelling arguments for making the leap?
The answer: If you have a need to operate in a heterogeneous environment, and
have a need to choose a single Web server to use across all platforms, you simply can't
beat Apache. The lines have blurred with regard to other issues that used to set Apache
apart from IIS, including the security and manageability of the servers.
Another answer: If you need to implement a significant Web service and want to be
able to do so with a minimal license cost, consider Apache on Linux for your solution.
The direct licensing cost for this solution is exactly zero dollars, unless you choose to
make use of a commercial Linux distribution.
For argument's sake, I'm going to assume your organization has made the decision
to at least consider moving from IIS to Apache and you want to know what to expect
should you decide to begin an actual migration.
ASP.NET is the language of choice since both are very well-supported and included
with IIS. Unfortunately, both are native to Windows, and Microsoft has not moved
them outside this playground. However, there are numbers of ways that you can still
make the move to the open source Apache/Linux combination (or Apache/Windows,
for that matter).
Change to another language
If you only use ASP casually on your site, you can opt to migrate your ASP code to
another language, such as PHP. With smaller sites, this is probably best handled manu-
ally, but for larger sites, the prospect of converting code could be a major undertaking.
However, there are some tools available that can help you with a conversion. For exam-
ple, asp2php is a free tool that can help you make this leap. While this free tool is
only provided to help you make the move (it doesn't do it all, by any means), it can help
you avoid some of the tedious task of recoding hundreds of pages of code.
Also, consider the use of a Java-based framework for a site if you decide to take the
plunge and migrate to another language. Apache's Tomcat provides you with a free,
open source servlet container to help make this change.
If you do decide to make the jump to a new language, remember that it's not the
syntax that was difficult to write in the first place, but the logic. Since you already have
the logic completely documented in your ASP code, migrating to another language isn't
generally as difficult as starting anew.
Keep ASP and still run Apache
One great thing about open source and an open market is that for just about any
need, you can find a reasonable solution. In the case of continuing to run ASP code
after moving to Apache, there are many solutions available for you to peruse.
The most well-known solution, Chilisoft ASP, is now a product from Sun called Sun
Java System Active Server Pages 4.0 and provides ASP support for certain versions of
Solaris, Red Hat Enterprise Linux, HP-UX, AIX, and Windows (without IIS, of
course). Sun Java System ASP 4.0 supports Apache 1.3 and 2.0 (see below for informa-
tion about Apache 2.2). Sun's solution also provides ADO support, as well as a full line
of ODBC database drivers for use with the product. Among the ODBC database driv-
ers included are drivers that allows Sun's product with work with both SQL Server and
Microsoft Access databases. As with anything, a conversion process using this software
is probably not going to be 100 percent perfect, and you may need to make some
minor code changes to make everything work exactly as you expect; there are some
instances -- if you use Visual Basic objects, for example -- in which this solution won't
work at all.
Alas, the data sheet for Sun Java System Active Server Pages does not include
Apache 2.2 as a supported Web server. Further, Sun Java System Active Server Pages
has not been updated in quite some time; and, in a forum, it was indicated that there is
no time frame for a future release. This could mean that either Sun just hasn't gotten
around to planning an update, or that they bought Chilisoft's product and are no
longer updating it.
Another option is to use Apache's mod_perl module and a perl-based solution called
Apache::ASP. This is not as clean of a solution as others, so do a lot of research
before you decide on this free solution.
If you decide to scrap your IIS --> Apache project, one major reason will likely be
dealing with ASP or .NET Framework applications that run great under IIS.
Go modular
There's a module for PHP, a module for Perl, a module for MySQL, a module for
this and a module for that. Simply put, Apache is nothing if not incredibly modular.
The Apache approach is this: Install only what you need and nothing else. This serious-
ly reduces the attack surface of the Web server and also improves performance. Yes,
you can disable certain IIS services, particularly under IIS 6.0, but a default IIS 6.0
installation is still less efficient -- and more prone to attack -- than a default Apache
installation.
What do you need to learn here? First off, everything in Apache is handled through
some kind of module. Want database access, scripting, or proxy services? Get a mod-
ule. This is definitely a good way to handle this kind of service, but Windows adminis-
trators may not be used to the flexibility offered by a system like Apache. There are
hundreds of modules available that help you make Apache do new and interesting
things.
For example, with IIS, you're somewhat limited with your authentication methods.
With Apache, as of this writing, there were 74 modules listed on the Apache Module
Registry that are all designed to extend Apache's authentication methods to other sys-
tems, including PostgreSQL databases, IMAP servers, LDAP directories, NT servers,
Oracle databases, and a whole lot more.
In total, the Apache Module Registry has well over 400 modules, all designed to help
Apache help you meet your goals.
This brings up the issue of how you handle direct connections to things like
Microsoft SQL Server, which is commonly used with IIS. An open source implementa-
tion called FreeTDS provides your Linux or IIS-less Windows Server with the capability
to continue to communication directly with SQL (or Sybase) servers.
Or, while you migrate from IIS, you could also consider migrating to a lower cost
database such as MySQL or PostgreSQL.
Note: IIS 7.0 is also supposed to "go modular," a la Apache.
As for other modules, such as IIS-specific ISAPI modules, you will need to migrate
these to something that works outside of IIS, such as NSAPI. Apache does include the
mod_isapi module, which provides basic ISAPI extensions, but not support for ISAPI
filters.
Summary
As you would expect, any conversion like this can't be broken down into two or
three steps and called good, except for the simplest of sites. Decide if it's worth taking
the plunge, and then plan your strategy very well. With Apache's wealth of support
resources, you will probably be able to conquer any problem that comes your way.
A
s a community supported project, the open source Apache Web server is well-
proven, but can still offer an administrator headaches from time to time when
things don't go quite as planned.
In this article, I will provide you with ten tips to help you solve the most common
Apache dilemmas.
Table A
Level Description Example
Emerg Emergencies - system is unusable. "Child cannot open lock file. Exiting"
Alert Action must be taken immediately. "getpwuid: couldn't determine user name from uid"
Warn Warning conditions. "child process 1234 did not exit, sending another SIGHUP"
Notice Normal but significant condition. "httpd: caught SIGBUS, attempting to dump core in ..."
If you can't figure out why your Apache server is having a problem, try adjusting the
log level to a higher threshold to capture more information. After you change the level,
stop and restart your server.
There are actually two log files in Apache: error_log, which I described in this section,
and access_log. The error_log file, as you might expect, is the log of most interest for
troubleshooting purposes. However, also make use of the access_log when looking for
problems. This file lists all of the items pulled down by clients along with the HTTP
error or success code.
Part of knowing where to look involves knowing what's actually running on your
server, too. Used in conjunction with the httpd command, use the -l and -M parameters
to see what is loaded in your Apache configuration. The -l (el) parameter lists modules
compiled into the server, but does not include dynamically loaded modules included
using the LoadModule directive in httpd.conf. The -M parameter does show you more
information and lists all loaded static and shared modules.
Apache security prowess to make potentially insecure changes to your Web site.
Finally, use of .htaccess can exact a performance penalty on your web site due to the
need of the web server to look for an .htaccess file in the current directory and in every
superior directory all the way to the document root of the Web server.
Unless you have a really good reason, avoid the use of .htaccess files. Instead, in the
httpd.conf file, make liberal use of "Directory" sections to set per-directory options.
On the other hand, if you are using .htaccess files and they don't seem to be activated,
look to the httpd.conf file and make sure the directive "AllowOverride" is not set to
"None". You can limit what options are allowed in an .htaccess file by further manipulat-
ing the AllowOverride directive's type. Table B, based on the Apache documentation,
provides you with a list of possible AllowOverride options. Only use the options you
need.
Table B
Type Description
All Allow use of all directives listed in this table. This is generally considered to be a major
security risk since it allows users to override httpd.conf settings such as disallowing the
following of symbolic links along with other things.
FileInfo Allow use of the directives controlling document types (DefaultType, ErrorDocument,
ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, and mod_mime
Add* and Remove* directives, etc.).
Indexes Allow use of the directives controlling directory indexing (AddDescription, AddIcon,
AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing,
HeaderName, IndexIgnore, IndexOptions, ReadmeName, etc.).
Limit Allow use of the directives controlling host access (Allow, Deny and Order).
Options Allow use of the directives controlling specific directory features (Options and XBitHack).
AllowOverride types
The default Apache installation omits the "Index.php" file, rendering many PHP-
based sites useless.
Further, your httpd.conf file needs to tell Apache about the .php extension through
the use of the AddType directive. If you're using PHP, you should have a line in your
configuration that reads:
AddType application/x-httpd-php .php
If this still isn't working, make sure your module is compatible with the version of
Apache you're running. The PHP developers, for example, recommend that, for
Apache 2 and later, you use at least PHP 4.3.0.
The short answer: Make sure you've strictly followed the instructions for setting up
Apache with additional modules. I've highlighted some of PHP's requirements in this
tip, but every module has its own nuances.
ing on port 80, Apache will not be able to listen to requests (or, Apache will work fine,
but the other application will be broken). In these cases, make sure Apache is the only
service listening on port 80.
A combination of the fuser and ps commands handily accomplishes this goal.
Use the command fuser -n tcp 80 to get a list of processes that are listening on port
80. Then, use the ps command to see which processes are used by the httpd daemon. ps
-ef | grep httpd accomplishes this part. You'll see results similar to those in Figure A.
Now, match up the list of ports provided by the fuser command and those provided
by the ps command. If there are more ports listed by fuser than are accounted for by ps,
use the ps command to find out exactly which other services are listening on port 80.
Use configtest
So you've made some modifications to your httpd.conf file and now Apache isn't
working properly, but you don't have a handy backup of the original file to find out
what's wrong?
Well, the good folks that created Apache have provided you with a way to scan your
httpd.conf file and make sure it's free from obvious errors. This error-checking tool is
provided as a part of the apachectl program. To use it, execute apachectl -configtest from
the command line. The apachectl program is located in the bin directory of your Apache
installation.
If no errors are found, the utility will execute like this example:
[root@localhost bin]# ./apachectl configtest
Syntax OK
To show how this tool works, I've intentionally create an httpd.conf file with an
error or two.
[root@localhost bin]# ./apachectl configtest
Syntax error on line 22 of /usr/local/apache/conf/httpd.conf:
Invalid command 'sserversignature', perhaps misspelled or
defined by a module not included in the server configuration
Figure A
In this case, I have misspelled a directive, which should read "ServerSignature", not
"SServerSignature". Even if you correct the error, run the tool again as more errors
may be found. As a highlight to this, I actually had another error in my httpd.conf file.
[root@localhost bin]# ./apachectl configtest
Syntax error on line 108 of /usr/local/apache/conf/httpd.conf:
DocumentRoot must be a directory
In this case, the directory name in the DocumentRoot directive also had a spelling
error which would have resulted in Apache being unable to serve any content since the
directory does not exist.
The apachectl program has a number of options. You've probably used "start" and
"stop", but there are many more that may be useful, depending on what you're trying
to do. Some of the options you can use with apachectl include:
X configtest : Checks for errors in httpd.conf.
X fullstatus : (Requires mod_status) Provides you with a configuration report at the loca-
tion specified in the module's httpd.conf configuration.
X Graceful: Restarts Apache, maintaining current connections.
X Restart: Restarts Apache, killing all connections.
X Start: Starts the Apache server.
X Status: (Requires mod_status) Same as fullstatus, except omits details of current
requests.
X Stop: Stops Apache.
Summary
Will these ten tips help you solve all of your problems? Probably not, but these tips
were designed to help point you in the right direction to solve problems.
O
ne of the reasons Apache powers over half of the world's domains is its
track record when it comes to being a safe and secure Web operating envi-
ronment. The Apache group has done a great job at keeping its product safe
and, at the times when the product has been found to have a defect related to security,
the Apache group gets a patch out as quickly as possible.
However, even with Apache's focus on producing a secure product, the Web server
can still be vulnerable to any number of attacks if you fail to take some security pre-
cautions as you build your server.
In this article, I will provide you with 10 tips that will help you keep your Apache
Web server protected from predators. Bear in mind that you need to carefully evaluate
each of these tips to make sure that they are right for your organization.
sion number and information related to your operating system. With this information,
a potential hacker can go after specific exploits that may affect your system, particularly
if you haven't been able to stay current with all patches. Now, instead of a hacker's
exploit attempt being handled by trial and error, he knows exactly what you're running
and he can tailor his attack.
To help keep your server from broadcasting sensitive information, make sure the
"ServerSignature" directive in httpd.conf is set to "off". As a note, a default Apache
installation sets this directive to off by default, but many administrators enable it.
Figures A and B show you the result of changing this directive.
Likewise, it's a good idea to disable directory browsing. When directory browsing is
enabled, users that browse to a directory that does not contain a default document are
Figure A
This is a sample 404 page when you have ServerSignature set to 'on'.
Figure B
This is the same page, but the ServerSignature directive is set to 'off'.
instead provided with a complete list of the contents of that directory. While you
shouldn't store sensitive materials in plain text on a Web server unless you have to, you
shouldn't allow people to see more than they need.
Directory browsing is enabled by default. To disable this feature, edit the httpd.conf
file; and, for each "Directory" directive, remove the "Indexes" reference.
For example, on my lab Apache 2.2.4 server, this is the default Directory directive:
<Directory "/usr/local/apache/htdocs">
Options Indexes FollowSymLinks
AllowOverrride None
Order allow,deny
Allow from all
</Directory>
You can also leave the Indexes directive and precede it with a dash to disable the
directive (i.e., "-Indexes").
Figures C and D show you the results of this change.
Figure C
Run mod_security
Mod_security, an Apache module written by Ivan Ristic, provides Apache with a
front-end firewall through which all incoming requests are filtered before being sent on
to other Web server modules. Among other features, mod_security includes:
X As indicated above, powerful request filtering that also works for HTTPS traffic.
X Anti-evasion techniques, such as the removal of null bytes (%00), multiple slashes,
etc., from URLs.
X Identity obfuscation. The identity of the Web server can be changed to thwart hackers.
X Full audit logging for future analysis if necessary.
Among the reasons that mod_security was developed was to protect servers prone to
SQ injection attacks from being compromised and databases lost. Under a SQL injec-
tion attack, SQL code is passed to a database process via a URL. If proper precautions
aren't taken, an Internet miscreant could send a command such as "DROP DATA-
BASE" through a URL string and render a Web site useless in a matter of seconds.
Mod_security does much more than what I've outlined here. Follow the link above
to visit the mod_security Web site for a more thorough overview of this module.
Generally, administrators that decide to take this step create a user and group on
their Apache server named "Apache", and the Apache service runs under this account.
Files related to the web site are then made readable by this account.
To make this change, open the httpd.conf file and change the contents of the User
and Group directives to "Apache", or the account name you have selected.
You will likely need to also make changes to the file permissions and ownership of
the files in your Apache directory as well.
If some users need the ability to follow symbolic links, consider the use of the
SymLinksIfOwnerMatch directive instead.
<Directory />
Options None
AllowOverride None
Order Deny,Allow
Deny from all
</Directory>
Table A
Directive Apache 2.2/2.3 default Advice/Description
TimeOut 300 seconds Should be lowered on sites that are subject to
DoS attacks. Setting this to as low as a few sec-
onds may be appropriate, but could pose prob-
lems for some CGI scripts.
LimitRequestBody 0 bytes (unlimited) Restricts the total size of the HTTP request
body sent from the client. If DoS attacks are
occurring as a result of large requests, limit
request size.
LimitRequestFieldSize 8190 bytes Limits the size of the HTTP request header
allowed from the client.
LimitRequestLine 8190 bytes This directive sets the number of bytes that will
be allowed on the HTTP request-line.
L
inux is increasingly becoming a popular alternative to Microsoft Windows for net-
work administrators wanting to provide services for their organization. Learning a
new OS like Linux can present some challenges to a long-time Windows adminis-
trator, however. This is the beginning of a series of articles aimed at the IT administrator
new to Linux wanting to set up various servers. This first article will describe the steps to
setting up an Apache server as a Web server for your organization.
Configuring Apache
To configure an Apache server in SuSe Linux, you’ll use the YaST tool. To do so, go
to the Control Center. Select Administrator Settings from the Common Tasks section
to open the YaST Admin Tool. Next, select Network Services to reveal a listing of the
various Network Services that can be configured from within YaST. Now you can start
administering Apache. Press the HTTP Server button to open up the Apache
Configuration tool, as shown in Figure A.
From the main configuration window, you’ll notice a number of options. One of
those options is the Firewall Details. By default, the http daemon is enabled, and the port
(80) are open in the firewall. From this screen, you can’t do much with editing the fire-
Figure A
You are now ready to begin your quest to set up the Apache server.
wall; you can only enable or disable the http port. If you press the Firewall Details button,
a new window appears, which allows you to select the interface assigned to the firewall.
From the main window, there are four tabs. The default tab is the Listen Ports and
Addresses tab. From this tab, you can handle the action above, add additional ports for
Apache to listen to, and view access and error logs.
One of the first issues I ran into was YaST not reading the access and/or error logs for
Apache. By opening up a console and issuing the command less /var/log/apache2/access_log, I
was able to read the log file. In order to successfully be able to read the Apache log files, go
back to the YaST Control Center and select Miscellaneous | View System Log. The View
System Log window will open (as shown in Figure B), defaulting to /var/log/messages. If you
click on the drop-down, you will not see the Apache logs listed. What you will need to do is
type out /var/log/apache2/access_log, and the log will appear as it is in Figure B.
Server modules
As we all know, Apache would be fairly useless without modules. Today’s Web site
denizens have grown used to the increasingly robust content available. With that in mind,
let’s take a look at the Server Modules tab within YaST’s Apache2 configuration window.
Figure C shows the main window for the Server Module configuration. There are two
configurations within this window: toggle a modules status (enable/disable), or add a
module. Obviously, everyone’s HTTP needs are going to vary, so you’ll have to go
through the module listing to decide what you need. If the module isn’t listed, press the
Figure B
After you have typed out the log you want to view, it will appear in the drop-down the next time you need it.
Add Module button for a new window, allowing you to select from a good number of
modules, ranging from auth_alias to version. When you add a new module, it will be
appended to the bottom of the module listing, and its status will be enabled.
Once you add a module or change the status of a module, you will need to reload
Apache2 so the server will be made aware of the new module. To reload the service,
simply press the Finish button at the bottom right of the YaST window. Once the
service is reloaded, the YaST window will disappear.
Apache hosts
The next tab is the Apache Main Host tab. From this window, the servers Apache
information is listed (and can be edited). Like all of the YaST GUI tools, this tool edits
the httpd.conf file directly. But from this window, that will be made quite obvious. As you
can see in Figure D, the listing in the GUI window already should look familiar to those
of you who have taken a crack at editing an Apache conf file. The good news for those
of you who haven’t — this makes it very easy.
Most of the defaults should work for you. Of course, there are special needs where
you might have to edit one of the various entries. One entry you’ll definitely have to
edit is the Server Administrator e-mail entry. To do this, highlight the entry and press
the Edit button, enter the administrators e-mail, and press OK.
There is one really cool feature here called Server Resolution. What this enables you
to do is set up virtual hosting based on either IP Address or HTTP headers. Let’s set
Figure C
You can change the listing of the modules by selecting one of the headings: Name, Status, or Description.
Figure D
As the instructions say, if you opt to use Server Resolution, the default server will not be served.
O
ne of Apache's most underused features is its ability to host virtual sites.
Being able to host more than one site allows for one machine to host all of
your Web needs. Here's how you make it work.
This will use whatever IP address to which you assign your server to point to all the
hosts configured in the httpd.conf virtual hosts configuration. (The NameVirtualHost *
configuration only works with Apache 1.3.13 and greater.) You can also configure a
specific IP address for the server in place of the asterisk (*).
The following example will require you to have the document root located in
/var/www/ (as it is in Apache2) and the new Web mail will be installed in
/var/www/Web mail. If your locations vary, change the example accordingly before
adding them to httpd.conf.
To get it up and running quickly, add these lines below NameVirtualHost *:
<VirtualHost *>
ServerName www.yourcompany.com
DocumentRoot /www/yourcompany
</VirtualHost>
<VirtualHost *>
ServerName Web mail.yourcompany.com
DocumentRoot /www/Web mail
</VirtualHost>
So, if you want your Web mail site to record messages to Web mail-access_log and Web
mail-error_log, then your VirtualHost section for the Web mail site will look like this:
<VirtualHost *:80>
ServerName Web mail.yourdomain.com
DocumentRoot /www/Web mail
ErrorLog /var/log/httpd/Web mail-error_log common
CustomLog /var/log/httpd/Web mail-access_log common
</VirtualHost>
X Error Pages
You can set Apache to serve a custom page when a visitor gets a 404 (not found)
or 500 (internal server error) or any other error code, for that matter. For
instance, you can redirect any visitor who receives a 404 error to the main index file,
or to a 404 file you created. To accomplish this, add the following directives to the
virtual host block, just like in the above example:
The error page could be anything. But remember, the location starts with the direc-
tory set in DocumentRoot in httpd.conf. For instance, if your DocumentRoot is
/var/www/html and the error page is in /var/www/html/messages/404.htm, then you'll
have to append /messages/404.htm to the ErrorDocument directive.
X Server Aliases
If you want to use your virtual host for more than one domain name, you can use
the ServerAlias directive inside the virtual host block in order to link the two domains
together. In the httpd.conf file, enter:
Take this a step further by using the wildcard to point all requests to
yourcompany.com:
ServerAlias yourcompany.com *
One caveat: You cannot simply make up host names and put them in the ServerAlias
or ServerName directives. All host names must be correctly mapped in your DNS server
configuration so those names will properly map to the right server.
The above configuration means that any request for any URL beginning with
/domain will be served from the virtual host www.domain.yourcompany.com. These
pages can be accessed as http://www.domain.yourcompany.com/domain/ for all
clients. Of course any client sending the proper Host: header will also be able to access
www.domain.yourcompany.com.We have also added the RewriteEngine directive to
ensure that clients who send the proper Host:header information will be able to use
both iterations of the URL.
Enabled mod_alias --disable-alias Disable the mapping of requests to different parts of the filesystem, which is provided by
mod_alias.
Enabled mod_asis --disable-asis Disable support for as-is filetypes, which is provided by mod_asis.
Disabled mod_auth_anon --enable-auth-anon Enable anonymous user access provided by mod_auth_anon.
Enabled mod_auth_basic --disable-auth-basic Allows the use of HTTP Basic Authentication to restrict access.
Disabled mod_auth_dbm --enable-auth-dbm mod_auth_dbm provides for HTTP Basic Authentication, where the usernames and pass-
words are stored in DBM type database files. Use this option to enable the module.
Disabled mod_auth_digest --enable-auth-digest Enable RFC2617 Digest authentication provided by mod_auth_digest. This module uses
plain text files to store the credentials.
Disabled mod_authn_alias --enable-authn-alias Provides the ability to create extended authentication providers based on actual providers
Disabled mod_authn_dbd --enable-authn-dbd User authentication using an SQL database.
Enabled mod_authn_default --disable-authn-default Authentication fallback module.
Enabled mod_authn_file --disable-authn-file User authentication using text files.
Disabled mod_authnz_ldap --enable-authnz-ldap Enable LDAP based authentication provided by mod_authnz_ldap.
Disabled mod_authz_dbm --enable-authz-dbm Group authorization using DBM files.
Enabled mod_autoindex --disable-autoindex Disable the directory listing functionality provided by mod_autoindex.
Disabled mod_cache --enable-cache Enable dynamic file caching provided by mod_cache. This experimental module may be
interesting for servers with high load or caching proxy servers. At least one storage manage-
ment module (e.g. mod_disk_cache or mod_mem_cache) is also necessary.
Disabled mod_cern_meta --enable-cern-meta Enable the CERN-type meta files support provided by mod_cern_meta.
Enabled mod_cgi --disable-cgi mod_cgi, which provides support for CGI scripts, is enabled by default when using a non-
threaded MPM. Use this option to disable CGI support.
Enabled mod_cgid --disable-cgid When using the threaded MPMs worker support for CGI scripts is provided by mod_cgid by
default. To disable CGI support use this option.
Disabled mod_charset_lite --enable-charset-lite Enable character set translation provided by mod_charset_lite. This module will be installed
by default only on EBCDIC systems. On other systems, you have to enable it.
Disabled mod_dav --enable-dav Enable the WebDAV protocol handling provided by mod_dav. Support for filesystem
resources is provided by the separate module mod_dav_fs. This module is also automati-
cally enabled with --enable-dav.
Disabled mod_dav_fs --enable-dav-fs Enable DAV support for filesystem resources, which is provided by mod_dav_fs. This mod-
ule is a provider for the mod_dav module, so you should also use --enable-dav.
Disabled mod_dav_lock --enable-dav-lock Enable mod_dav_lock which provides generic DAV locking support for backend modules.
This module needs at least mod_dav to function, so you should also use --enable-dav.
Disabled mod_dbd --enable-dbd Manages SQL database connections.
Disabled mod_deflate --enable-deflate Enable deflate transfer encoding provided by mod_deflate.
Enabled mod_dir --disable-dir Disable directory request handling provided by mod_dir.
Disabled mod_disk_cache --enable-disk-cache Enable disk caching provided by mod_disk_cache.
Disabled mod_suexec --enable-suexec Allows CGI scripts to run as a specified user and Group.
Disabled mod_unique_id --enable-unique-id Enable the generation of per-request unique ids, which is provided by mod_unique_id.
Enabled mod_userdir --disable-userdir Disable the mapping of requests to user-specific directories, which is provided by mod_user-
dir.
Disabled mod_usertrack --enable-usertrack Enable user-session tracking provided by mod_usertrack.
Disabled mod_vhost_alias --enable-vhost-alias Enable mass virtual hosting provided by mod_vhost_alias.