pfSense Installation: A Scrounger’s Guide (Part Two)

pfSense installation

The computer I used as my new pfSense box.

In the last article, I discussed my project to turn an old computer into a pfSense firewall and set some guidelines for the project. In this article, I get to configuration of the pfSense box and pfSense installation.

pfSense Installation: Selecting the Hardware

As you recall from part one of this series, the base system requirements for a pfSense installation are:

  • Pentium II or better
  • 256 MB RAM
  • 1 GB of disk space for a standard installation; 512 MB of disk space for embedded systems

I immediately realized the system I used for m0n0wall would not make the grade (too slow and not enough memory). However, I had another old system that might work. I had a Pentium III (733 MHz) with 256 MB RAM. The motherboard for this system died a few months ago; I found a replacement on eBay (for $15), but the system has been running slow ever since. It seemed like an ideal candidate for conversion to a pfSense firewall.

Since I did not want to erase the contents of the original hard drive, I had to find another one to install into the system. I went through a box of old hard drives and found a Western Digital Caviar 22000. With 2 GB of disk space, it had more than enough space for pfSense. I swapped out the original hard drive with the Western Digital.

The next consideration was what network cards to install on the system. You need at least two NICs: one for the WAN and one for the LAN. Installing a third NIC allows you to have an OPT1 interface for a DMZ. Fortunately, there was already one Intel Pro 100 NIC in the computer, and I had a spare two. The Intel Pro 100s are PCI cards, and there are three PCI slots on this motherboard, so I used up all the available PCI slots, but that shouldn’t be a problem. If you need to buy NICs, the folks at recommend purchasing Intel cards (or systems with built-in Intel NICs) up to 1 Gbps. It would behoove you to by Intel PRO 1000s, at least for the LAN and OPT1 interfaces (on the WAN side, using a 100 Mbps NIc will not create a bottleneck for most residential broadband customers). A quick eBay search revealed than PRO 1000s are available for less than $10 (for both PCI and PCI-X interfaces). My Neoware thin client has a 1 Gbps 2-port NIC for the LAN and OPT1 interfaces, and a 100 Mbps NIC for the WAN interface. An upgrade to Intel PRO 1000s on this system is definitely something I will consider in the near future.

pfSense installation

The Compaq Deskpro motherboard recognizes the Samsung drive, so we can proceed.

With the hard drive and NICs installed, I was ready to move the computer over to the test bench and begin pfSense installation. After running setup to make sure the BIOS recognized the Western Digital drive, I put the pfSense CD in and booted the system. When prompted whether to boot pfSense from the CD or run the installer, I hit “I” and invoked the installer. This is where I had my first real setback: although the motherboard’s BIOS recognized the Caviar, pfSense did not, and I therefore could not install pfSense onto it. Fortunately, I had a Samsung sW0434A (total capacity: 4.3 GB) I could install (again courtesy of the box of old hard drives), so I powered down the system and replaced the Western Digital with the Samsung.

pfSense Installation: Options

Once the hard drive had been replaced, I was able to boot pfSense from the CD and begin pfSense installation. When the installer starts, you have a chance to change the video font, change the screenmap, change the keymap, or accept the settings. Since I had no reason to change the defaults, I chose “Accept These Settings“.

On the next screen, you have a choice between quick/easy install and custom install (there are also options to rescue config.xml and reboot). In most cases you can opt for the quick/easy install, but if you do not want to reformat the hard drive, or if you want to partition the hard drive onto which pfSense is installed, or specify a different hard drive geometry than what was detected by pfSense, you want to opt for the custom install. I just wanted to reformat the hard drive and install pfSense onto it, so I opted for “Quick/Easy Install“.

Next, the pfSense installer will give you a choice between installing the standard pfSense kernel, or the embedded kernel (which has no vGA console or keybaord available). I selected “Standard Kernel” and continued. After a few minutes, pfSense was installed, and I was prompted to reboot the system. With pfSense installation complete, I rebooted the system and was ready to run pfSense on this computer for the first time.

When pfSense runs for the first time, it will ask you to assign interfaces. I assigned fxp0 for the WAN and fxp1 for the LAN. [I opted to set up OPT1 from the web configurator, later on]. I also assigned the IP address for the LAN interface.

By now, pfSense installation and configuration was complete, and I had a fully functional pfSense box, but I hadn’t connected it to my network. That’s no fun, so in the next article, I will talk about what happened when I used the new system as my firewall.

External Links:

pfSense Hardware at

Intel PRO/1000 GT Desktop Adapter – Overview at

Nessus Configuration: Part One

Nessus Configuration

Advanced settings in the Nessus web GUI.

Nessus Configuration: Proxy and Advanced Settings

The first thing you will see when you access Nessus is the login page. You must first enter the login name and password you created when you set up Nessus. Since Nessus uses a web-based front end, you can access the Nessus server from any computer on the local network that has a web browser, making Nessus configuration much easier. This increases the scalability of Nessus for larger organizations. You can configure scan options and make other changes, all from the web interface.

Once you are logged in, there are several settings you can change. If you click on your username (in this example, “nessusadmin”) on the right side of the page, there is a drop-down menu with several options; select “Settings”. On the left sidebar, there is an option called “Proxy”. If you did not set up a proxy during the setup process and need to do so now (for example, if your organization requires that all web traffic be directed through a corporate proxy), you can input the settings here.

Proxy Setting Options

Option Description
Host The host or IP of the proxy
Port The port of the proxy
Username Optional: if a username is required for proxy usage
Password Optional: If a password is required for proxy usage
User-Agent Optional: If the proxy you are using filters specific HTTP user agents, a custom user-agent string can be supplied
Custom Update Host Optional: This can be used to force Nessus to update plugins from a specific host. For example, if plugins must be updated from a site residing in the U.S., you can specify “”

Different Nessus configuration options can be set by clicking on the “Advanced” link in the Settings menu. Each option can be configured by editing the corresponding field and clicking the “Save” button at the bottom of the screen. In addition, the option can be removed completely by clicking on the “X” button.

By default, the Nessus GUI operates on port 8834. To change this port, edit the xmlrpc_listen_port to the desired port. The Nessus server will process the change within a few minutes.

If additional preferences are required, click on the “New Setting” button, input the name and the value, and press “Save”. Once a preference has been updated and saved, Nessus will process the changes within a couple of minutes.

Nessus Configuration

Adding a new user in Nessus.

Nessus Configuration: Adding/Editing Users

During the initial setup, one administrative user is created. Using the credentials specified during the setup, you can log into the Nessus GUI. Once authenticated, click on the “Users” heading at the top. To create a new user, click “New User” on the upper right. This will open a dialog box asking for required details. Input the username and password, verify the password, and determine if the user should have administrator privileges. If a user account needs to be modified, double-click on the user.

You cannot rename a user. If you want to change the name of a user, delete the user and create a new user with the appropriate login name. To remove a user, select the check box next to the account on the list, select “Options” on the upper right, and then click “Delete User” and confirm.

A non-admin user cannot upload plugins to Nessus, cannot restart it remotely, and cannot override the max_hosts/max_checks setting in the configuration section. If the user is intended to be used by SecurityCenter, it must be an admin user. SecurityCenter maintains its own user list and sets permissions for its users.

In the next article, we will cover more Nessus configuration options.

External Links:

Nessus home page on

Nessus on Wikipedia

Apache Server Hardening: Part Four (httpd.conf)

httpd.confIn the previous article, we looked at compiling and installing Apache and discussed the benefits of mod_security. In this article, we will cover httpd.conf configuration.

httpd.conf File Configuration

The Apache web server stores all its configuration data in the httpd.conf file located in the $[ApacheServerRoot] directory, which is, in our example, /usr/local/apache. The httpd.conf file includes many directives that can be categorized into the following sections:

  • Server Directives
  • User Directives
  • Performance/Denial of Service directives
  • Server Software Obfuscation Directives
  • Access Control Directives
  • Authentication Mechanisms
  • Directory Functionality Directives
  • Logging Directives

Not all directives play a significant role with regard to security. In this article, we will discuss the directives that impact the security of your Apache server. Furthermore, because we disabled a lot of functionality at compile time, some directives that would normally be dangerous do not need to be removed, since they were not added into the compiled Apache binaries. There may also be other configuration files, called Include files, associated with the httpd.conf file. Since we have enabled mod_security, there is a long list of potential configurations to make in an Include filled called modsecurity.conf, which is usually located in the $[ApacheServerRoot]/conf directory.

In this section, I included the recommended mod_security configuration. For more information about configuring this file, refer to the mod_security documentation.

Recommended modsecurity.conf file:

# Turn ModSecurity On
SecFilterEngine On

# Reject requests with status 403
SecfilterDefaultAction “deny.log.status.403”

# Some sane defaults
SecFilterScanPOST On
SecFilterCheckURLEncoding On
SecfilterCheckUnicodeEncoding Off

# Accept almost all byte values
SecFilterForceByteRange 1 255

# Server masking is optional
# SecServerSignature “OurServer”

SecUploadDir /tmp
SecUploadKeepFiles Off

# Only record the interesting stuff
SecAuditEngine RelevantOnly
SecAuditLog logs/audit_log

# You normally won’t seed debug logging
SecFilterDebugLevel 0
SecFilterDebug logs/modsec_debug_log

# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply “text/html” as Content-Type
SecFilterSelective REQUEST_METHOD “|^(GET|HEAD)$” chain
SecFilterSelective HTTP_Content-Type \

# Do not accept GET or HEAD requests with bodies
SecFilterSelective REQUEST_METHOD *^(GET|HEAD)$” chain
SecFilterselective HTTP_content-Length “!^$”

# Require Content-Length to be provided with
# every POST request
SecFilterSelective REQUEST_METHOD “^POST$” chain
SecFilterSelective HTTP_Content-Length ‘^$”

# Don’t accept transfer encodings we know we don’t handle
SecFilterSelective HTTP_Transfer-Encoding “!^$”

There are a couple directives you must configure in the httpd.conf file to ensure that the Apache web server runs using the unprivileged user account we established earlier, among other things. Inspect your httpd.conf file to verify that the following statements appear as show in the following. Recall that we decided to run Apache as wwwusr:wwwgrp.

User wwwusr
Group wwwgrp

Also, configure the serverAdmin directive with a valid alias e-mail address such as the following:


This will provide a point of contact for your customers, should they experience problems with your site.

Performance-Tuning Directives in httpd.conf

there are a number of performance-tuning directives in the Apache httpd.conf file. As a security professional, you should interpret those directives as DoS prevention statements, since they control resource allocation for users of the Apache server. The following directives control the performance of an Apache server:

  • Timeout: Configures the time Apache waits to receive GET requests, the time between TCP packets for POST or PUT requests, or the time between TCP ACK statements in responses. The Apache default is 300 seconds (3 mintues), but you might want to consider reducing this timer to 60 seconds to mitigate DoS attacks.
  • KeepAlive: Configures HTTP1.1-compliant persistency for all web requests. By default, this is set to On and should remain as such to streamline web communication.
  • KeepAliveTimeout: Determines the maximum time to wait before closing an inactive, persistent connection. Here we will keep this value att the default of 15 seconds, since raising it can cause performance problems on busy servers and expose you to DoS attacks.
  • StartServers: Designates the number of child processes to start when Apache starts. Setting this value higher than the default of 5 can increase server performance, but use care not to set the value too high, because doing so could saturate system resources.
  • MinSpareServers: This setting, like the MaxSpareServers setting, allows for dynamic adjustment of Apache child processes. MinSpareServers instructs Apache to maintain the specified number of idle processes for new connections. This number should be relatively low except on very busy servers.
  • MaxSpareServers: Maintains Apache idle processes at the specified number. Like MinSpareServers, the value should be low, except for busy sites.
  • MaxClients: As its name implies, this setting determines the maximum number of concurrent requests to the Apache server. We will leave this as the default value of 256.

Once you’ve finished editing this section of your httpd.conf, you should see something similar to the following:
Timeout 60
KeepAlive On
KeepAliveTimeout 15
StartServers 5
MinSpareServers 10
MaxSpareServers 20
MaxClients 256

By default, Apache informs web users of its version number when delivering a 404 (page not found) error. Since it is good practice to limit the information you provide to would-be hackers, we will disable this feature. Recall that we already altered the Apache server signature and that we installed mod_security. Both of these actions should be enough to obfuscate our server because they both alter the default behavior. If you would like to turn off server signatures completely, you can always set the ServerSignature directive to Off and the Server tokens to Prod. this will disable Apache signatures entirely.

The Apache web server includes mechanisms to control access to server pages and functionality. The statement syntax is part of the directive and is fairly straightforward: you specify a directory structure, whether default access is permitted or denied, and the parameters that enable access to the directory if access is denied by default. There are many options for fine-grained control that you should learn by reading the Directory Directive section of the Apache Core Features document in the current version of the Apache documentation.

Regardless of the access you provide to your customers, you should secure the root file system using access control before placing your server into a production environment. In you httpd.conf file, you should create a statement in the access control directives area as follows:

<Directory />

Order, Deny, Allow
deny from all


This statement will deny access to the root file system should someone intentionally or accidentally create a symlink to /.

In the next article, we will discuss further hardening our Apache server using authentication mechanisms.

External Links:

The official Apache website

sudo: Options and Configuration

sudo configurationIn order to use sudo, the user must have already supplied a username and password. If a user attempts to run the command via sudo and that user is not in the sudoers file (at /etc/sudoers), an e-mail is automatically sent to the administrator, indicating that an unauthorized user is accessing the system.

Once a user logs in to sudo, a ticket is issued that is valid by default for five minutes. A user can update the ticket by issuing the -v falg, which will validate the ticket for another five minutes. To do this, type the following:

sudo -v

If an unauthorized user runs the -v flag, an e-mail will not be sent to the administrator. The -v flag informs the unauthorized user that they are not a valid user. If the user enters a command via sudo anyway, an e-mail will then be sent to the administrator.

sudo logs login attempts, successful and unsuccessful, to the syslog file by default. However, this can be changed during sudo configuration. sudo also has several command line options, such as the following:

  • -V: Version; prints version number and exits
  • -l: List; lists the commands that are allowed and denied by the current user
  • -h: Help; prints usage message and exits
  • -v: Validate; updates the user’s ticket for a configured amount of time (the default is five minutes). If required, the user must re-enter the user password to update the ticket
  • -k: Kill; expires the user’s ticket. Completing this option requires the user to re-enter the user password to update the ticket
  • -K: Sure kill; removes the user’s ticket entirely. User must log in with username and password after running this option
  • -u: User; runs the specific command as the username specified. The user specified can be any user except root. If you want to enter a uid, enter #uid instead of the username

Configuring sudo

To configure sudo, you must edit the /etc/sudoers file. The sudoers file defines which users are allowed to execute what commands. Only the root user is allowed to edit the file, and it must be edited with the visudo command. By default, the visudo command opens the sudoers file in the vi text editor. The vi commands are used to edit and write the file. You can change the default text editor used by visudo using the compile time option. Visudo uses the EDITOR environment variable. The visudo command performs the following tasks when editing the sudoers file:

  • Visudo will not save any changes if a syntax error exists. It will state the line number of the error and prompt you for guidance.
  • If you attempt to run visudo while the sudoers file is being edited, you will receive an error message telling you to try again at a later time.

The sudoers file consists of two different types of entries, user specifications and aliases. The following examples show you to use user specifications, which define which user is allowed to run what commands. Aliases are basically variables.


The sudoers file contains a root entry. The user privilege specification is listed as:

root ALL=(ALL) ALL

This configuration allows the root user to issue all commands. To allow other users to run commands as root, you must enter those users in the sudoers file. You must also list the host on which they are allowed to run the commands. Finally, you must list the specific commands that those users are allowed to run as root. As an example, imagine we have a user called chris and we want to allow him to run some commands as root.

First, we open the sudoers file using the visudo command. The sudoers file will now open in vi. Locate the “User privileges specification” section. After the root entry, enter the following:

chris your-hostname = /sbin/ifconfig, /bin/kill, /bin/ls

[This will allow user chris to run the ifconfig, kill and ls commands as root. NOTE: Depending on your implementation of Linux/Unix, you may have to add your default shell to the list of commands user chris can execute as root; e.g. /bin/bash.] Press ESC, then enter wq at the to write and quit the file. Now, if you have not already, you have to create user chris. To do this, enter:

useradd chris

To create a password of user chris, enter:

passwd chris

Then enter the password when prompted. Now, you should have a user chris on your system that can run ifconfig, kill and ls as root.

External links:

The sudo project page

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 -o c:\backup.xml -v 2.0

will backup the config file of the pfSense router at 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

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

Remote Config pfSense Backup at – 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 (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