Apache Server Hardening: Part Five

Apache server

Apache User Authentication

Apache also includes several ways in which you can authenticate customers using your web server such as LDAP, SecureID, and basic .htaccess, to name a few examples. To use authentication mechanisms beyond basic .htaccess, you must compile additional functionality when you’re building Apache. Like access control, authentication mechanisms are specified as part of the directive.

The two steps to enabling basic .htaccess user authentication are:

  1. Creating an htpasswd file to store user credentials.
  2. Adding a directive to the httpd.conf file to protect a directory structure.

This is different than adding a login form on a web page and creating your own authentication. Let’s use an example to demonstrate how easy it can be to add authentication. In our example, we will secure a directory called /securedir and permit only customers Homer and Marge access to the files in that directory.


First, let’s create an htpasswd file somewhere not in the web server document root by issuing the following command:

htpasswd -c /usr/local/apache/passwdfile homer
New password: *****
Re-type new password: *****
Adding password for user homer

Next, we’ll add Marge to the list as well. This time we don’t need to use the -c argument, since our htpasswd file already exists:

htpasswd /usr/local/apache/passwdfile marge
New password: *****
Re-type new password: *****
Adding password for user marge

Now that we’ve established our customer accounts, we’ll finish by adding a directive to the httpd.conf file to protect the /securedir directory as follows:

<Directory /usr/local/apache/htdocs/secure>
AuthType Basic
AuthName “Access for authenticated customers only”
AuthUserfile /usr/local/apache/passwdfile
require user marge homer

</Directory>

Now, when anyone attempts to access the /securedir directory, they’ll be prompted for a username and password. Because we specifically require only Marge and Homer, only they will be permitted to use the directory structure, if they authenticate properly.

You can also restrict access based on a domain or IP address. The following directive will do this:

Order deny, allow
Deny from all
Allow from allowable-domain.com
Allow from XXX.XXX.XXX
Deny from evil-domain.com

You can specify the first three (or one or two) octets of an IP address defining the allowable domain.

Although this example involves modifying the httpd.conf file to control directory access, there is another way. You can create an .htaccess and .htpasswd file in the directory to which you want to control access. The .htaccess file should contain the same directive we described above. The .htpasswd file must be created using htpasswd. In the above example, to add access for Homer and Marge, we would first create (or clobber if it already exists) the password file /securedir/.htpasswd:

htpasswd -c .htpasswd homer

Now that we have created .htpasswd, we can add user marge to the existing password file (which contains one user, homer):

htpasswd .htpasswd marge

Within the directive is a subdirective called Options that controls functionality for the directory structures specified in the directive. The available options are listed below:

Option Functionality
All Default setting; includes all options except MultiViews
ExecCGI Permits CGI script execution through mod_cgi
FollowSymLinks Allows Apache to follow OS file system symlinks
Includes Permits SSI through mod_include
IncludesNOExEC Permits SSI but denies exec and exec cgi
Indexes Allows autoindexing using mod_autoindex if no configured index file is present
MultiViews Permits content negotiation using mod_negotiation
SimLinksIfOwnerMatch Allows Apache to follow OS file system symlinks but only if the link and target file have the same owner

Many of the listed options are not relevant to our installation, since we disabled Includes and CGI during compile time. Regardless, a good default directive disabling most options is shown here:

<Directory “/usr/local/apache/htdocs”>
Order, allow, deny
Allow from all
Options -FollowSysLinks -ExecCGI -Includes -Indexes \
-MultiViews
AllowOverride None

</Directory>

At this point, your Apache server should be relatively secure. In the next article, we will discuss some Apache logging directives so that we can better monitor our server.

External Links:

Authentication and Authorization at the official Apache website

Apache Web Login Authentication at yolinux.com

pfSense Backup and Restore

Backing up your pfSense configuration files is a crucial task, both in order to restore the configuration after a system failure and to recover data from an earlier time. Fortunately, pfSense makes the process easy. pfSense backup configuration files are stored in a plain text XML format by default, but it also gives the user an option to encrypt them.

pfSense Backup in a Few Easy Steps

pfSense Backup

Backup configuration options in pfSense 2.0.

To backup the configuration files, first navigate to Diagnostics -> Backup/restore and from there, select the Backup/Restore tab. At “Backup area“, you will see a drop-down box showing all the configuration areas you can back up. Leave it as “ALL” to backup all files. Leave “Do not backup package information” unchecked if you do not want to backup package information. The next check box is “Encrypt the configuration file“; check this if you want to encrypt the backup (you will have to enter the password twice in the edit boxes below if this is selected). Leave “Do not back up RRD checked” unless you want to backup the round robin database (it can be over 4 MB in size). Press the “Download configuration” button and save the file to a safe location. Your pfSense backup is now complete.


Now, the configuration info will be stored in a single XML file. Some passwords, however, will be stored in plain text. If this is a problem, you can always encrypt the file with the “Encrypt this configuration file” option.

Automating Your pfSense Backup

You’re probably wondering if the backup process can be automated. As it happens, there is a package called “AutoConfigBackup” that enables you to automate backups, but it is only available for paying pfSense customers with a Premium support contract. However, Koen Zomers has created his own command line backup automation tool for Windows, which is quite easy to use (remember to use the -v 2.0 option when backing up a pfSense 2.0 configuration file). You can use this in conjunction with the AT command to fully automate the process. For example:

at 20:00 /every:M,T,W,Th,F,S,Su pfSenseBackup.exe -u admin -p password -s 192.168.1.1 -o c:\backup.xml -v 2.0

will backup the config file of the pfSense router at 192.168.1.1 to the C drive at 8:00 PM every day.

If you don’t use Windows or don’t want to use this utility, you can still automatically make a backup. When a change is made in pfSense, a backup of the configuration file is stored in /cf/conf/backup. You could create a script to run as a cron job on the pfSense system to copy this file to a remote system, or you could run a script on the remote system which could download the files.


Restoring from a Backup

You can also restore pfSense’s configuration from a backup. From the same tab under “Restore Configuration“, choose a restore area from the dropdown box, click on the “Choose” button to launch the file dialog box and select a backup configuration file. Press the “Open” button to close out the file dialog box. Click the “Configuration file is encrypted” check box if the file is encrypted (you will have to specify a password), and press the “Restore configuration” button. pfSense will reboot after “Restore configuration” is pressed.

External Links:

Configuration Backup and Restore at doc.pfsense.org

How to automate pfSense backup, where you can download Koen Zomer’s pfSense backup tool.

Remote Config pfSense Backup at doc.pfsense.org – information on how to use the Auto Config Backup package, but you need a paid subscription to use it.

How to Backup and Restore Configurations in pfSense 2.0

pfSense Setup: Part Two

pfSense Setup

The General Setup menu in the pfSense web GUI.

If you followed the setup instructions in pfSense Setup: Part One, pfSense should be running and accessible via the web interface at 192.168.1.1 (or another IP address if you assigned a different one). You should be able to log in using the default username (admin) and password (pfsense).

You will want to change some of the basic settings in General Setup. In the web interface, browse to System | General Setup. At “Hostname”, enter your hostname (the name that will be used to access the machine by name instead of the IP address.

Below this, enter your domain (Domain in the General Settings).

DNS Servers can also be specified. By default, pfSense will act as the primary DNS server. However, other DNS servers may be used, and the place to enter them are in the four boxes for DNS servers.

Check Allow DNS server list to be overridden by DHCP/PPP on WAN. This ensures that DNS requests that cannot be resolved internally are passed on to the WAN and resolved by the external DNS servers provided by your internet service provider.


Next, select the correct time zone; you probably want to leave the default NTP time server as it is.

Next is the theme, which allows you to change the look and feel of the pfSense web GUI. You can probably keep the default theme, pfSense_ng.

pfSense Setup

pfSense’s User Manager, which has been part of the pfSense web GUI since version 2.0.

NOTE: You probably want to change the admin password. You can do this under System -> User Manager. Here you can change the admin password, add new users, and delete users, including the admin.

That’s it for the General Setup within the web GUI. In pfSense Setup: Part Three, I will cover how to configure the WAN and LAN interfaces using the web GUI. Part four will cover configuring optional interfaces.


External Links:

Another useful guide on installing and configuring pfSense (from the iceflatline blog)

Ad Links:


© 2013 David Zientara. All rights reserved. Privacy Policy