This month's offering is the first in a series
of three columns
devoted to securing your Web site. We start with a look
at server-wide security, procede to directory-level issues in July,
and conclude in August with the gory details of password-protected
documents.

Security basics

When you bring your server online and start soliciting visitors, you
instantly increase the chances of your server being penetrated by some
hacker. Why? Because your site is now well-known, promiscuously
offering content to the world. Of the millions of machines on the Net,
a very small percentage are actually Web servers. Since hackers tend
to focus on machines where they may find something useful, any Web
server is a better target than an anonymous machine sitting on
someone's desk somewhere.

This means that you must not only secure your Web server and
documents, you must also secure your machine against all other sorts of
hacks and queries. Fortunately, Unix Insider Online's very own
Peter Galvin has done an excellent job covering the basics of server
security, starting with his
April column and concluding in May. Follow his advice and your machine will be well on its way to
being impervious to most network-based security attacks. In
particular, make sure you install tcp_wrapper and carefully
configure external access to your machine.

The httpd security model

Now you're ready to configure the security features of your Web server.
In order to do that, you need to understand how httpd and its derivatives,
including NCSA's httpd and the
Apache server handle server security.

Each time a user connects to your site, the client passes to the
server the numeric IP address of the client machine. In some cases,
this may be the IP address of a proxy server, requesting the document
on behalf of some other machine. The http protocol also allows
the client to provide the name of the user making the request, but this
rarely happens. As a result, the only bit of data the server has to
validate the request is the IP address of the client machine.

The first thing the server does is reverse this numeric address in an
effort to get the textual domain name of the machine. This is the name
that is human-readable, like www.sun.com. The reversing
process involves contacting a domain name server, presenting it with the
numeric IP address, and getting the domain name in return.

Surprisingly, many machines on the Net are not correctly configured to
have their IP addresses reversed. This is not the fault of the machine,
per se, but of the domain name server responsible for that machine's
domain. Many network administrators get the forward maps (mapping the
name to the IP address) correct but fail to configure the reverse maps
(which perform the opposite mapping). As a result, this attempt to
reverse the IP address may fail. Undaunted, the server forges ahead
anyway.

Once the server has the client's IP address, and possibly its domain
name in hand, it begins applying sets of rules to determine if this
client can access the document in question. This IP-based rule model
is at the heart of Web server security, enhanced only by password
protection (which

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine