Protect Web Page Directories With Passwords,Multiple Ip Virtual Host

Step 1: Configure Virtual Hosting on Multiple IPs

You can configure Apache to serve the correct content when accessing www.mysite.com or www.another-site.com from the outside, and also when accessing the specific IP address 192.168.1.100 from the inside. Fortunately Apache allows you to specify multiple IP addresses in the statements to help you overcome this problem.

Here is an example:

NameVirtualHost 192.168.1.100
NameVirtualHost 97.158.253.26


DocumentRoot /www/server1
ServerName www.my-site.com
ServerAlias bigboy, www.my-site-192-168-1-100.com


Step 2: Configure DNS "Views"

You now need to fix the DNS problem that NAT creates. Users on the Internet need to access IP address 97.158.253.26 when visiting www.my-site.com and users on your home network need to access IP address 192.168.1.100 when visiting the same site.

You can configure your DNS server to use views which makes your DNS server give different results depending on the source IP address of the Web surfer's PC doing the query. Chapter 18, "Configuring DNS", explains how to do this in detail.

Note: If you have to rely on someone else to do the DNS change, then you can edit your PC's hosts file as a quick and dirty temporary solution to the problem. Remember that this will fix the problem on your PC alone.
How To Protect Web Page Directories With Passwords

You can password protect content in both the main and subdirectories of your DocumentRoot fairly easily. I know people who allow normal access to their regular Web pages, but require passwords for directories or pages that show MRTG or Webalizer data. This example shows how to password protect the /home/www directory.

1) Use Apache's htpasswd password utility to create username/password combinations independent of your system login password for Web page access. You have to specify the location of the password file, and if it doesn't yet exist, you have to include a -c, or create, switch on the command line. I recommend placing the file in your /etc/httpd/conf directory, away from the DocumentRoot tree where Web users could possibly view it. Here is an example for a first user named peter and a second named paul:

[root@bigboy tmp]# htpasswd -c /etc/httpd/conf/.htpasswd peter
New password:
Re-type new password:
Adding password for user peter
[root@bigboy tmp]#

[root@bigboy tmp]# htpasswd /etc/httpd/conf/.htpasswd paul
New password:
Re-type new password:
Adding password for user paul
[root@bigboy tmp]#

2) Make the .htpasswd file readable by all users.

[root@bigboy tmp]# chmod 644 /etc/httpd/conf/.htpasswd

3) Create a .htaccess file in the directory to which you want password control with these entries.

AuthUserFile /etc/httpd/conf/.htpasswd
AuthGroupFile /dev/null
AuthName EnterPassword
AuthType Basic
require user peter

Remember this password protects the directory and all its subdirectories. The AuthUserFile tells Apache to use the .htpasswd file. The require user statement tells Apache that only user peter in the .htpasswd file should have access. If you want all .htpasswd users to have access, replace this line with require valid-user. AuthType Basic instructs Apache to accept basic unencrypted passwords from the remote users' Web browser.

4) Set the correct file protections on your new .htaccess file in the directory /home/www.

[root@bigboy tmp]# chmod 644 /home/www/.htaccess

5) Make sure your /etc/httpd/conf/http.conf file has an AllowOverride statement in a directive for any directory in the tree above /home/www. In this example below, all directories below /var/www/ require password authorization.


AllowOverride AuthConfig


6) Make sure that you have a directive that defines access to /home/www or another directory higher up in the tree.


ServerName 97.158.253.26
DocumentRoot /home/www


7) Restart Apache.

Try accessing the web site and you'll be prompted for a password.
The conf.d Directory

Files in the /etc/httpd/conf.d (Redhat / Fedora) or the /etc/apache*/conf.d (Debian / Ubuntu) directory are read and automatically appended to the configuration in the httpd.conf file every time Apache is restarted. In complicated configurations, in which a Web server has to host many Web sites, you can create one configuration file per Web site each with its own set of and containers. This can make Web site management much simpler. To do this correctly:

1. Backup your httpd.conf file, in case you make a mistake.
2. Create the files located in this directory that contain the Apache required and containers and directives.
3. If each site has a dedicated IP address, then place the NameVirtualHost statements in the corresponding conf.d directory file. If it is shared, it'll need to remain in the main httpd.conf file.
4. Remove the corresponding directives from the httpd.conf file.
5. Restart Apache, and test.

The files located in the conf.d directory don't have to have any special names, and you don't have to refer to them in the httpd.conf file.
Troubleshooting Apache

Troubleshooting a basic Apache configuration is fairly straightforward; you'll find errors in the /var/log/httpd/error_log file during normal operation or displayed on the screen when Apache starts up. Most of the errors you'll encounter will probably be related to incompatible syntax in the statement caused by typing errors.
Testing Basic HTTP Connectivity

The very first step is to determine whether your web server is accessible on TCP port 80 (HTTP).

Lack of connectivity could be caused by a firewall with incorrect permit, NAT, or port forwarding rules to your Web server. Other sources of failure include Apache not being started at all, the server being down, or network-related failures.

If you can connect on port 80 but no pages are being served, then the problem is usually due to a bad Web application, not the Web server software itself.

It is best to test this from both inside your network and from the Internet. Troubleshooting with TELNET is covered in Chapter 4, "Simple Network Troubleshooting".
Browser 403 Forbidden Messages

Browser 403 Forbidden messages are usually caused by file permissions and security context issues. Please refer to the "General Configuration Steps" section for further details.

A sure sign of problems related to security context are "avc: denied" messages in your /var/log/messages log file.

Nov 21 20:41:23 bigboy kernel: audit(1101098483.897:0): avc: denied { getattr } for pid=1377 exe=/usr/sbin/httpd path=/home/www/index.html dev=hda5 ino=12 scontext=root:system_r:httpd_t tcontext=root:object_r:home_root_t tclass=file

Only The Default Apache Page Appears

When only the default Apache page appears, there are two main causes. The first is the lack of an index.html file in your Web site's DocumentRoot directory. The second cause is usually related to an incorrect security context for the Web page's file. Please refer to the "General Configuration Steps" section for further details.
Incompatible httpd.conf Files When Upgrading

Your old configuration files will be incompatible when upgrading from Apache version 1.3 to Apache 2.X. In Redhat / Fedora, the new version 2.X default configuration file is stored in /etc/httpd/conf/httpd.conf.rpmnew. For the simple virtual hosting example above, it would be easiest to:

1. Save the old httpd.conf file with another name, httpd.conf-version-1.x for example. Copy the ServerName, NameVirtualHost, and VirtualHost containers from the old file and place them in the and place them in the new httpd.conf.rpmnew file.
2. Copy the httpd.conf.rpmnew file an name it httpd.conf
3. Restart Apache

With other distributions, the procedure is similar; just place your containers in the new default configuration file and restart Apache.
Server Name Errors

All ServerName directives must list a domain that is resolvable in DNS, or else you'll get an error similar to these when starting httpd.

Starting httpd: httpd: Could not determine the server's fully qualified domain name, using 127.0.0.1 for ServerName

Starting httpd: [Wed Feb 04 21:18:16 2004] [error] (EAI 2)Name or service not known: Failed to resolve server name for 192.16.1.100 (check DNS) -- or specify an explicit ServerName

You can avoid this by adding a default generic ServerName directive at the top of the httpd.conf file that references localhost instead of the default new.host.name:80.

#ServerName new.host.name:80
ServerName localhost

The Apache Status Log Files

The /var/log/httpd/access_log file is updated after every HTTP query and is a good source of general purpose information about your website. There is a fixed formatting style with each entry being separated by spaces or quotation marks. Table 20-3 lists the layout.
Table 20-3 Apache Log File Format
Field Number Description Separator
1 IP Address of the remote web surfer Spaces
2 Time Stamp Square Brackets []
3 HTTP query including the web page served Quotes ""
4 HTTP result code Spaces
5 The amount of data in bytes sent to the remote web browser Spaces
6 The web page that contained the link to the page served. Quotes ""
7 The version of the web browser used to get the page Quotes ""

Upon examining the entry, you can determine that someone at IP address 67.119.25.115 on February 15, looked at the web page /dns-static.htm returning a successful 200 status code. The amount of data sent was 15190 bytes and the surfer got to the site by clicking on the link http://www.linuxhomenetworking.com/sendmail.htm using Microsoft Internet Explorer version 5.5.

67.119.25.115 - - [15/Feb/2003:23:06:51 -0800] "GET /dns-static.htm HTTP/1.1" 200 15190
"http://www.linuxhomenetworking.com/sendmail.htm"
"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; AT&T CSM6.0; YComp 5.0.2.6)"

The HTTP status code can provide some insight into the types of operations surfers are trying to attempt and may help to isolate problems with your pages, not the operation of the Apache. For example 404 errors are generated when someone tries to access a web page that doesn't exist anymore. This could be caused by incorrect URL links in other pages on you site. Table 20-4 has some of the more common examples.
Table 20-4 HTTP Status Codes
HTTP Code Description
200 Successful request
304 Successful request, but the web page requested hasn't been modified since the current version in the remote web browser's cache. This means the web page will not be sent to the remote browser, it will just use its cached version instead. Frequently occurs when a surfer is browsing back and forth on a site.
401 Unauthorized access. Someone entered an incorrect username / password on a password protected page.
403 Forbidden. File permissions or contexts prevents Apache from reading the file. Often occurs when the web page file is owned by user "root" even though it has universal read access.
404 Not found. Page requested doesn't exist.
500 Internal server error. Frequently generated by CGI scripts that fail due to bad syntax. Check your error_log file for further details on the script's error message.
The Apache Error Log Files

The /var/log/httpd/error_log file is a good source for error information. Unlike the /var/log/httpd/access_log file, there is no standardized formatting.

Typical errors that you'll find here are HTTP queries for files that don't exist or forbidden requests for directory listings. The file will also include Apache startup errors which can be very useful.

The /var/log/httpd/error_log file also is the location where CGI script errors are written. Many times CGI scripts fail with a blank screen on your browser; the /var/log/httpd/error_log file most likely lists the cause of the problem.