pfSense 2.1.2 Release Up For Testing

nlogUnless you’ve been living in a broom closet, you probably know about the OpenSSL bug that makes users using sites whose web servers use the OpenSSL library potentially vulnerable to eavesdropping. The pfSense development team is on the case, and they have already posted a fix for the OpenSSL bug. Needless to day, I guess I am going to have to update the links on the downloads page again, since this will likely become the pfSense 2.1.2 release. You can read about it at the pfSense mailing list.

Nlog: A Utility for Analyzing Nmap Logs

nlogIn a previous article, we covered the Nmap utility. You can save Nmap logs in a number of formats, including plain text or machine-readable, and import them into another program. However, if these options aren’t enough for you, Nlog can help you make sense of your Nmap output. Running it on very large networks can be a lifesaver, because perusing hundreds of pages of Nmap output looking for nefarious activity can be tedious.

The Nlog program helps you organize and analyze your Nmap output. It presents them in a customizable web interface using CGI scripts. Nlog makes it easy to sort your Nmap data in a single searchable database. On larger networks, this kind of capability is vital to making Nmap useful. H.D. Moore put together these programs and made them available. You can find more information about Nlog at You can download Nlog at

Nlog is also extensible. You can add other scripts to provide more information and run additional tests on the open ports it finds. The author provides several of these add-ons and instructions on how to create your own. Nlog requires Perl and works on log files generated by Nmap 2.0 and higher.

Installing Nlog

Follow these steps to install and prepare Nlog:

  1. Download the files from the Nlog web site.
  2. Unpack the Nlog files using the tar-zxvf command. It will unzip and neatly organize all the files for Nlog in a directory called nlog-1.6.0 (or other numbers, depending on the version number).
  3. You can use the installer script provided to automatically install and prepare the program. Note that you need to edit the program before you run it. Go to the Nlog directory and, using a text editor program such as vi or emacs, open the file and enter the variables where indicated for you system. Edit the following parameters with the correct values for your installation.

    Put the path to your CGI directory. The above represents the correct values on a default Mandrake installation. Make sure you enter the correct ones for your system. For other Linux systems, find the path to this directory by using the locate command. This useful command will find any files with the text you insert after it.

  4. Save the file, then run it by typing:

    The installation script automatically copies the CGI files to your CGI directory and the main HTML file to your HTML directory. It also changes the permissions on those files so they can be executed by your web browser.

  5. For the final step, go into the /html directory and edit the nlog.html file. In the POST statement, change the reference to the cgi files to your cgi files, which should be the same one used above (/var/www/cgi/). Save the file and you are ready to go.

Running Nlog

Nlog can be used as follows:

  1. The first thing you must do is create a Nlog database file to view. You do this by converting an existing Nmap log file. Make sure you save your Nmap logs with the machine-readable option (-m on the command line) to be able to use them in Nlog. You can then use a script provided with Nlog to convert the Nmap log into the database format that Nlog uses. To convert a Nmap machine readable log, run the script using this command: logfile 

    Replace logfile with your log file name and location.

  2. To combine multiple log files into a single database, use the following commands:
    cat * > /PATH/temp.db
    cat * > /PATH/temp.db | sort -u > /PATH/final.db
  3. Replace /PATH with the path to your Nmap files and final.db with the name you want to use for the combined Nmap database. This sorts the files into alphabetical order and eliminates any duplicates.
  4. Start your web browser and go to the web directory (/var/www/ from the previous section).
  5. Select the Nmap database file you want to view and click Search.
  6. You can now open your Nmap database and sort it based on the following criteria:
    • Hosts by IP address
    • Ports by number
    • Protocols by name
    • State (open, closed, filtered)
    • OS match

    You can also use any combination of these criteria. For example, you could search for any web servers (http protocol) on Windows systems with a state of open.

In the next article, we will look at Nlog add-ons and creating Nlog extensions.

External Links:

Download Nlog at

2003 archive of (the former official site of H.D. Moore, creator of Nlog)

whois and dig Commands

whoisThe whois Command

The whois command is useful when trying to track down a contact for someone causing trouble on your network. This command queries the primary domain name servers and returns all the information that Internic (or whoever their name registrar is) has. Internic used to be the quasi-government agency that was responsible for keeping track of all the domain names on the Internet. Internic became a commercial company called Network Solutions, and was then acquired by VeriSign. Now that name registration has been opened up for competition, there are literally dozens of official name registrars. However, you can still usually find out who owns a domain by using the whois command.

This command is useful for attacks coming both from within companies or within ISP networks. Either way, you can track down the person responsible for that network and report your problems to them. They won’t always be helpful, but at least you can try. The syntax is:


The variable is the domain name on which you are looking for information.

As an example, here’s the whois information for

Domain Name: LINUX.COM
Registry Domain ID:
Registrar WHOIS Server:
Registrar URL:
Updated Date: 2013-05-08 13:51:05
Creation Date: 1994-06-02 04:00:00
Registrar Registration Expiration Date: 2016-06-01 04:00:00
Registrar:, LLC
Registrar IANA ID: 886
Registrar Abuse Contact Email:
Registrar Abuse Contact Phone: +1.6027165396
Reseller: +1.8004015250
Domain Status: clientTransferProhibited
Domain Status: clientUpdateProhibited
Registry Registrant ID:
Registrant Name: Jim Zemlin
Registrant Organization: The Linux Foundation
Registrant Street: 660 York Street Suite 102
Registrant City: San Francisco
Registrant State/Province: CA
Registrant Postal Code: 94110
Registrant Country: US
Registrant Phone: +1.4157239709
Registrant Phone Ext:
Registrant Fax: +1.4157239709
Registrant Fax Ext:
Registrant Email:
Registry Admin ID:
Admin Name: Jim Zemlin
Admin Organization: The Linux Foundation
Admin Street: 660 York Street Suite 102
Admin City: San Francisco
Admin State/Province: CA
Admin Postal Code: 94110
Admin Country: US
Admin Phone: +1.4157239709
Admin Phone Ext:
Admin Fax: +1.4157239709
Admin Fax Ext:
Admin Email:
Registry Tech ID:
Tech Name: Jim Zemlin
Tech Organization: The Linux Foundation
Tech Street: 660 York Street Suite 102
Tech City: San Francisco
Tech State/Province: CA
Tech Postal Code: 94110
Tech Country: US
Tech Phone: +1.4157239709
Tech Phone Ext:
Tech Fax: +1.4157239709
Tech Fax Ext:
Tech Email:
DNSSEC: Unsigned
URL of the ICANN WHOIS Data Problem Reporting System:
>>> Last update of WHOIS database: 2013-05-08 13:51:05 <<<

Registration Service Provider:,
This company may be contacted for domain login/passwords,
DNS/Nameserver changes, and general domain support questions.

As you can see, you can contact the technical person in charge of that domain directly. If that doesn’t work, you can always try the administrative person. The whois command usually displays an e-mail address, a mailing address, and sometimes phone numbers. It tells when the domain was created and if they’ve made recent changes to their whois listing. It also shows the domain name servers responsible for that domain name. Querying these numbers with the dig command can generate even more information about the remote network’s configuration.

Unfortunately, whois is not built into the Windows platforms, but there are plenty of web-based whois engines, including the one located on Network Solutions web site.

It should be noted that if you administer domains of your own, you should make sure your whois listing is both up-to-date and as generic as possible. Putting real e-mail addresses and names in the contact information fields gives information that an outsider can use either for social engineering or password-cracking attacks. Also, people might leave the company, making your record outdated. It is better to use generic e-mail addresses, such as or You can forward these e-mails to the people responsible, and it doesn’t give out valuable information on your technical organization structure.

The dig Command

The dig command queries a name server for certain information about a domain. Dig is an updated version of the nslookup command, which had be depricated (but has since been revived). You can see it to determine the machine names used on a network, what the IP addresses tied to those machines are, which one is their mail server, and other useful tidbits of information. The general syntax is:

dig @server domain type

where server is the DNS server you want to query, domain is the domain you are asking about, and type is the kind of information you want on it. You will generally want to query the authoritative DNS for that domain: that is, te one listed in their whois record as being the final authority on that domain. Sometimes the company runs this server; other times its ISP runs the server.

Results of the dig command can yield valuable information, such as the host name of their mail server, their DNS server, and other important machines on their network. If you run a DNS server, you should be able to configure it to respond only to these kinds from authorized machines.

dig Record Types

Options Descriptions
AXFR Attempts to get the whole file for the domain or “zone” file. Some servers are now configured not to allow zone file transfers, so you may have to ask for specific records.
A Returns any “A” records. “A” records are individual host names on the network, such as and
MX Returns the registered mail host name for that domain. This is useful if you want to contact an administrator (try or
CNAME Returns any CNAMED hosts, also known as aliases. For example: =
ANY Returns any information it can generate on the domain. Sometimes this works when AXFR doesn’t

External Links:

The whois protocol at Wikipedia

The dig command at Wikipedia

Apache Server Hardening: Part Six

Apache server

Additional Directives

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 symlinks
Includes Permits SSI through mod_include
IncludeNOEXEC 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, here is a good default directive disabling most options:

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


At this point, your Apache server should be relatively secure. Now, we move on to configuring logging options.

There are many reasons to configure logging on you Apache server. Whether helping you see top page hits, hours of typical high volume traffic, or simply understanding who is using your system, logging plays an important part of any installation. More importantly, logging can provide a near-real-time and historic forensic toolkit during or after security events.

to ensure that your logging directives are set up correctly, we will provide an example of the logging options in the Apache web server. Apache has many options with which you should familiarize yourself by reading the Apache mod_log_config documentation page. This will help you understand the best output data to record in logs. Also, recall that we compiled Apache with mod_log_forensic, which provides enhanced granularity and logging before and after each successful page request.

An example logging configuration file is shown here:

ErrorLog /var/log/apache/error.log
LogLevel Info
┬áLogformat “%h %l %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\”\”%{forensic-id}n\” %T %v” full
CustomLog /var/log/apache/access.log combined
ForensicLog /var/log/apache/forensic.log

The example provides a customized logging format that includes detailed output and places all the log files in the /var/log/apache directory.

After you have installed and configured your Apache server, you will need to do some quick cleanup of files that could represent a security threat. In general, you should not leave the source code you used to compile Apache on the file system. It is a good idea to tar the files up and move them to a secure server. Once you’ve done so, remove the source code from the Apache web server.

Removing Directories and Setting Permissions

You’ll also want to remove some of the default directories and files installed by the Apache web server. To do so, execute the following commands on your web server. If you have added content into your document root directory, you will want to avoid the first command:

rm -fr /usr/local/apache/htdocs/*
rm -fr /usr/local/apache/cgi-bin
rm -fr /usr/local/apache/icons

After removing files, let’s ensure that our Apache files have proper ownership and permissions before starting our server.

As we discussed previously, the Apache web server should be run as an unprivileged and unique account. In our example, we used the user wwwusr and the group wwwgrp to run our server. Let’s make sure our permissions are properly set by running the following commands:

chown -R root:wwwgrp /usr/local/apache/bin
chmod -R 550 /usr/local/apache/bin
chown -R root:wwwgrp /usr/local/apache/conf
chmod -R 660 /usr/local/apache/conf
chown -R root:wwwgrp /usr/local/apache/logs
chmod -R 664 /usr/local/apache/logs
chown -R root /usr/local/apache/htdocs
chmod -R 664 /usr/local/apache/htdocs

Monitoring Your Server

Even with the best defenses and secure configurations, breeches in your systems and applications could occur. Therefore, you cannot simply set up a hardened Apache web server and walk away thinking that everything will be just fine. Robust and comprehensive monitoring is perhaps the most important part of securely operating servers and applications on the Internet.

In Apache, there are several things to consider that will help you to identify and react to potential threats. Your primary source of data will be through Apache and OS logs. Even with small web sites, however, sifting through this information can be a challenge. One of the first things to consider is intergrating your Apache logs with other tools to help organize and identify potential incidents within the log file. Many open source and commercial products are available to aid you in securing your site. One such open source tool is called Webalizer, available at the, which features graphical representation of your Apache log file contents.

SNMP polling and graphing constitute another methodology commonly employed for secure monitoring. Often, it is extremely difficult to gauge the severity or magnitude of an even without visualization of data from logs or SNMP counters. One tool you might consider using is a module called mod_apache_snmp, available at Sourceforge. The module can provide real-time monitoring of various metrics including, but not limited to:

  • Load average
  • Server uptime
  • Number of errors
  • Number of bytes and requests served

You might consider other commercial SNMP-based solutions especially for enterprise-scale deployments. These tools help expedite monitoring deployment and usually include enhanced functionaility to automatically alter you when important thresholds, such as web site concurrent connections, are crossed.

External Links:

The official Apache web site

The official Webalize web site

The official Mod-Apache-Snmp web site

pfSense 2.1.1 Released

In case this bit of information didn’t cross your news feed, I should mention that pfSense 2.1.1 has been released. The new release resolves some security issues, and the em/igb/ixgb/ixgbe drivers have been upgraded to add support for i210 and i354 NICs. I will update the download links on the downloads page as soon as possible.

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


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
Allow from XXX.XXX.XXX
Deny from

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 \
AllowOverride None


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

© 2013 David Zientara. All rights reserved. Privacy Policy