MailScanner Installation and Configuration: Part One


MailScanner configuration under pfSense 2.1.3.

MailScanner is an e-mail security and anti-spam package for e-mail gateway systems. It is not designed to be run on Microsoft Windows desktop PCs. Instead, it is designed to be run on mail servers operated by companies and ISPs so that all their users and customers can be protected from one place. This avoids the need for any software to be installed on individual desktop PCs at all. The software works with any Unix-based system and is compatible with a wide range of mail transports, and comes with support for any combination of 25 different virus scanner packages, including the free ClamAV scanner.

MailScanner is implemented in around 50,000 lines of Perl. It links with other software packages in order to perform its functions:

  • E-mail server (e.g. sendmail)
  • Anti-virus software (e.g. ClamAV)
  • Anti-spam software (SpamAssassin)

MailScanner Installation

To install MailScanner under pfSense, navigate to System -> Packages, and scroll down to “Mailscanner” in the package list. Press the “plus” button to the right of the listing, and on the next page, press the “Confirm” button to confirm installation. It will take a few minutes for the Package Installer to extract and install MailScanner.

Once MailScanner is installed, there will be a new entry on the “Services” menu called “MailScanner”. If you navigate to it, you will be able to modify several settings. There are 9 tabs: “General”, “Attachments”, “Antivirus”, “Content”, “AntiSpam”, “Alerts”, “Reporting”, “XMLRPc Sync”, and “Help”. Under the “General” tab, the first heading is “System Settings”. The “Enable Mailscanner” check box will enable the mailscanner daemon if checked. “Max Children” allows you to choose how many MailScanner processes you want to run at a time (the default is 50. “Processing Incoming email” allows you to either scan messages or reject messages.

In the “Logging” secion, “Syslog Facility” allows you to specify what type of program is logging the message. The default is “mail”, and that is probably what you want to leave it at, but there may be circumstances when you may want to specifiy a different Syslog facility. See the Syslog entry on Wikipedia for a list of facility levels, or read RFC 1164 for more information. The “Logging” list box allows you to choose which messages to log.

“Advanced Settings” has some additional options. “Advanced features” allows you to select several options. By default, only “Deliver in Background” is selected. “Deliver Method” allows MailScanner to attempt immediate delivery of messages, or just place them in the outgoing queue for the MTA to deliver when it wants. “Minimum Code Status” lets you set the minimum acceptable code status; if MailScanner comes across a code that is not at least as stable as what it set here, it will stop running.

In the next article, we will continue our look at MailScanner’s settings.

External Links:

The official MailScanner web site
MailScanner at Wikipedia

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

Snort Security Optimization

snort securityIn the previous two articles (part one part two), I discussed the installation of snort. In this article, I will mention some ways to improve snort security.

Improving Snort Security

One of the snort security issues is preventing unauthorized access to a privileged account. There are several ways of preventing this. First, when running snort in daemon (-D) mode, the user (-u) and group (-g) switches should be used. This will allow snort to run as a given user and group after it is initialized. Typically, most system administrators prefer to add the snort user and group to their systems, and that the snort user should be unable to login or initiate shell privileges.

Second, the source code for snort/DAQ binaries, logging directories, shared/static libraries, and configuration files should all be owned by the snort user with appropriate permissions. Finally, all binaries which are produced by the compiling and installation process of snort and DAQ should be verified using a hash function and the output stored on removable media. A cron job could be used to run this process on a regular basis with results e-mailed to a system administrator. Another alternative would be the use of a utility called tripwire for auditing installed software on a computer. All of these measures are excellent ways of increasing snort security.

Mirroring or Copying Network Traffic to Snort

In addition, your small office/home office (SOHO) router can be used to mirror or copy network traffic to a snort sensor running on a standalone system or to a virtual machine running in VirtualBox, VMWare, or Xen. This method of improving snort security can be easily done provided you have a router that is running DD-WRT, OpenWRT, or Tomato as the firmware. If you are running Tomato, you may have to add the following to your startup script:

modprobe ipt ROUTE

Users of OpenWRT must use the Tee option for IPtable (provided by module iptables-mod-tee). The module “iptabels-mod-tee” must be loaded before the following command will work:

iptables -t mangle-A PREROUTING -j TEE -gateway x.x.x.x

Where x.x.x.x is an IP address you wish to mirror traffic to (usually a system running snort). It should be noted that in more recent versions of OpenWRT (10.03.1 and never), iptables-mod-tee does not seem to be enabled by default, and using it will require a rebuild/re-enabling of modules for OpenWRT.

Now, using DD-WRT or Tomato’s GUI (or SSHing into the router), issue the following commands:

iptables -A PREROUTING -t mangle -j ROUTE -gw x.x.x.x -tee

iptables -A POSTROUTING -t mangle -j ROUTE -gw x.x.x.x -tee

In each case, x.x.x.x is the address of the machine running snort. To stop mirroring traffic, type

iptables -F -t mangle

If you have snort running in test mode (-T option), try starting snort with /etc/rc.d/snort start (you should get a running message if snort is running properly). If there is a problem, check the output in /var/log/messages. Also, you can check the status of snort by issuing this command:

./snort status

External Links:

How to make some home routers mirror traffic to Snort at




Packet Filter: The Engine of pfSense

Packet FilterpfSense is, as most users know, a specialized version of FreeBSD. It can be configured an upgraded through a web-based interface and often runs on embedded systems; it requires no knowledge of the underlying FreeBSD system. Those curious enough to find out, however, will be interested to know that pfSense is based on OpenBSD’s powerful pf (Packet Filter) software, which was released in late 2001 and has since been ported to many other operating systems including FreeBSD, NetBSD, DragonFly BSD, Debian GNU/Free BSD, and Mac OS X 10.7 “Lion” and later.

OpenBSD and the other BSD variants are direct descendants of BSD Unix. BSD, sometimes called Berkeley Unix, is a Unix operating system derivative developed and distributed by the Computer Systems Research Group (CSRG) of the University of California, Berkeley, from 1977 to 1995. The final release from Berkely was 1995’s 4.4BSD-Lite Release 2, after which the CSRG was dissolved and development of BSD at Berkeley ceased. In the meantime, as CSRG was winding down, small groups of enthusiasts around the world began working on further development of the code. Several different variants of BSD Unix came into existence. The OpenBSD group became known as the most security-oriented of the BSDs. For its packet filtering needs, it used a program called IPFilter, written by Darren Reed.

The packet filter’s main function is to filter network packets by matching the properties of individual packets and the network connections build from those packets agains the filtering criteria defined in its configuration files. The packet filter is responsible for deciding what to do with those packets, which could mean passing them through or rejecting them, or triggering events that other parts of the operating system or external applications are set up to handle.

The IPFilter subsystem performed this function within OpenBSD, but in May 2001, IPFilter was removed from the OpenBSD source tree due to licensing issues. The OpenBSD version of IPFilter contained several changes and customizations that, as it turned out, were not allowed under the licensing agreement. For a few weeks, the development version of OpenBSD did not include any firewalling software.

Enter Packet Filter

However, Daniel Hartmeier had already begun work on his own packet filtering software, called PF, and after a few months of development, it was ready to be added to OpenBSD. PF was added as a default part of the OpenBSD 3.0 base system in December 2001. Migrating from IPFilter to PF sense did not pose major problems, as their configuration languages were similar. Moreover, PF has done well in performance tests, performing equally well or better under stress on OpenBSD 3.1 than either IPFilter on OpenBSD 3.1 (or iptables on Linux). PF’s overhead is relatively low, and is capable of running effectively on rather modest hardware.

Future installments of this series of articles will go into greater depth on how to configure and run PF. For now, it should be mentioned that in order to run PF, you need to install and run a BSD system such as OpenBSD, FreeBSD, NetBSD, or DragonFly BSD. OpenBSD is the BSD variant of choice for many, as this is where PF was first introduced and where essentially all PF development happens. Moreover, the newest and most-up-to-date PF code is always to be found on OpenBSD. If you are planning to run PF on FreeBSD, NetBSD, DragonFly BSD, or another system, you should check your system’s release notes and other documentation about which version of PF is included.

External Links:

PF documentation in the OpenBSD FAQ

pfSense Virtual IP Addresses: Part One

pfSense Virtual IP Addresses

Virtual IP address configuration page in pfSense.

A virtual IP address (VIP or VIPA) is an IP address that is not assigned to a specific single server or network interface card (NIC). Rather, it is assigned to multiple applications on a single server, multiple domain names, or multiple servers. Normally, a server IP address depends on the MAC address of the attached NIC, and only one logical IP may be assigned per card. However, VIP addressing enables hosting for several different applications and virtual appliances on a server with only one logical IP address. VIPs have several variations and implementations, including Common Address Redundancy Protocol (CARP) and Proxy Address Resolution Protocol (Proxy ARP).

pfSense Virtual IP Addresses: Proxy ARP

pfSense allows four types of virtual IP addresses: Proxy ARP, CARP, Other, and IP Alias. In this article, I will cover how to configure pfSense virtual IP addresses using Proxy ARP and CARP.

The different types of virtual IP addresses have slightly varied properties. With proxy ARP, the properties are:

  • Can only be forwarded by the firewall (cannot be used by the firewall)
  • Uses Layer 2 (the data link layer) traffic
  • Can be in a different subnet than the interface
  • Cannot respond to pings
pfSense Virtual IP Addresses

Once the Virtual IP has been entered and saved, it is added to the list.

To configure a Proxy ARP virtual IP address, browse to Firewall -> Virtual IPs and Click the “plus” button to add a new virtual IP address. At type, there are four radio buttons; select the radio button for “Proxy ARP” (it should be the default selection). For “Interface”, select “WAN”. At “IP Address(es)“, select “Single address” for “Type” (this should be the default). At “Address“, specify an IP address. At “Description“, enter a description if desired. Then press “Save” to save the changes and “Apply changes” to apply changes if necessary.

Now, the newly-created VIP should be listed at the “Virtual IPs” tab at Firewall -> Virtual IPs.

pfSense Virtual IP Addresses: CARP

You can also configure a virtual IP with CARP in pfSense 2.0. The properties for a CARP VIP include:

  • Can be used or forwarded by the firewall
  • Uses Layer 2 (data link layer) traffic
  • Should be used in firewall fail-over or load-balancing scenarios
  • Must be in the same subnet as the interface
  • Will respond to pings if configured properly

To set up a CARP virtual IP address, browse to Firewall -> Virtual IPs and click the “plus” button to add a new virtual IP address. At “Type“, select the “CARP” radio button, and at “Interface“, select “WAN” (it should be the default). At “IP address(es)“, specify an IP address. At “Virtual IP Password“, specify a password. At “VHID Group“, choose a group. At “Advertising Frequency“, select a frequency (0 for master). At “Description“, add a description if desired. Then press “Save” to save the changes and “Apply changes” to apply the changes if necessary.

In part two of this series, I will cover setting up virtual IP addresses with IP Alias and Other types.

Once again, the “Virtual IPs” tab under Firewall -> Virtual IPs should display the newly-created VIP within the list of pfSense virtual IP addresses. In part two, I will cover IP aliases (new to pfSense 2.0) and other VIPs.

External Links:

What are Virtual IP Addresses? at

pfSense VPN: Part Three (PPTP)

pfSense VPN

VPN PPTP configuration page in the pfSense GUI.

In the previous two articles on pfSense VPN, I covered how to configure a VPN tunnel using IPsec and also the L2TP and OpenVPN protocols. In this article, I will cover how to set up a VPN tunnel using PPTP.

pfSense VPN: PPTP

First, browse to VPN -> PPTP. You should be at the “Configuration” tab. You will see the following warning message:

PPTP is no longer considered a secure VPN technology because it relies upon MS-CHAPv2 which has been compromised. If you continue to use PPTP be aware that intercepted traffic can be decrypted by a third party, so it should be considered unencrypted. We advise migrating to another VPN type such as OpenVPN or IPsec.

Click on the “Enable PPTP server” radio button. At “No. PPTP users“, select the number of PPTP users. At “Server address“, etner an unused IP address. PfSense’s PPTP service will listen on this address. In the next box, Enter the start of the “Remote address range” for clients that connect (it must be large enough for the number of users specified at “No. PPTP users“). Check the “Require 128-bit encryption” checkbox just above the “Save” button. Click on “Save” to save the configuration.

pfSense VPN

Users tab in the VPN PPTP setup in pfSense.

Now select the “Users” tab and hit the “plus” button to add a user. Specify a “Username” and “Password” and an “IP address” if you want the user to be assigned a specific IP address. Click on “Save” to save changes, and then click on “Apply changes” if necessary.

Now it is necessary to set up a firewall rule to allow PPTP VPN traffic. Browse to Firewall -> Rules. Select the “PPTP VPN” tab. At “Destination“, set it to “LAN subnet“. Set the “Destination port range” to “any“, and at “Description“, enter a description if desired. Then press “Save” to save the changes and press “Apply changes” if necessary.

Now, your pfSense router will be configured to use VPN with PPTP. Moreover, PPTP is natively supported by Windows, Linux and MacOS, so you should be able to easily connect to your VPN tunnel from any of those platforms.

External Links:



Port Forwarding with NAT in pfSense

Firewall Configuration: NAT port forwarding

Firewall -> NAT configuration page in the pfSense web GUI.

In computer networking, Network Address Translation (NAT) is the process of modifying IP address information in IPv4 headers while in transit across a traffic routing device. In most cases, it involves translating from the WAN IP address to the 192.168.x.x addresses of your local network. In this article, I will describe how to set up NAT port forwarding.

NAT and firewall rules are distinct and separate. NAT rules forward traffic, while firewall rules block or allow traffic. In the next article, I will cover firewall rules, but for now keep in mind that just because a NAT rule is forwarding traffic does not mean the firewall rules will allow it.

NAT Port Forwarding

NAT port forwarding rules can differ in complexity, but in this example, let’s assume we set up an Apache server at on the local network, and we want to direct all HTTP traffic (port 80) to that address. First, browse to Firewall -> NAT. The options are “Port Forward“, “1:1” and “Outbound“. Select the “Port Forward” tab. Click the “plus” button in order to create a new NAT port forward rule. “Disable the rule” and “No RDR” can be left unchanged. For “Interface” you can choose WAN and LAN; we are concerned about incoming requests from the Internet, so you can keep it as WAN.

For “Protocol”, there are five choices: TCP, UDP, TCP/UDP, GRE, and ESP. TCP stands for Transmission Control Protocol, and is the transport level protocol of the Internet protocol suite. This is usually what we want to use. Next is UDP, or User Datagram Protocol, another transport level protocol which is also part of the Internet protocol suite. It is suitable for purposes where error checking and correction are either not necessary or are performed in the application. GRE stands for Generic Routing Encapsulation, a tunneling protocol that can encapsulate a wide variety of network layer protocols inside virtual point-to-point links. It can be used, among other things, in conjunction with PPTP to create VPNs. ESP stands for Encapsulating Security Payload, a member of the IPsec protocol suite which provides authenticity, integrity and confidentiality protection of packets. In this port forwarding scenario, you can leave the protocol unchanged (TCP).

Firewall Configuration: NAT

Adding a NAT port forwarding rule.

For “Source“, you can specify the allowed client source. Typically you can leave it as “any”, but there are several choices: “Single host or alias“, “Network“, “PPTP clients“, “PPPoE clients“, “L2TP clients“, “WAN subnet“, “WAN address“, “LAN subnet“, and “LAN address“. In this case, you can leave the default (any) unchanged.

For “Source port range“, we want to redirect HTTP traffic (port 80), so choose HTTP for the from and to drop-down boxes. “Destination” offers the same choices as “Source” and can be left unchanged. “Destination port range” should be changed to HTTP for the from and to drop-down boxes. For “Redirect target IP“, specify the web server the traffic to be forwarded to (in our case, For “Redirect target Port“, choose HTTP. Next is “No XMLRPC Sync“; enable this option to prevent this rule from being applied to any redundant firewalls using CARP. This option can be left unchecked now. “NAT Reflection” can be enabled or disabled, usually it is disabled. “Filter Rule association” will automatically create a firewall rule and associate it to this NAT rule. Check this box to avoid having to create a separate firewall rule. Add a description if you wish, and press “Save” to save the changes. The port forwarding rule set up should now be in effect.

NAT Port Redirection

In this case, we passed traffic from port 80 on the source to port 80 on the destination, which is the classic port forwarding scenario. But there’s no reason you can’t redirect traffic to a different port. There are two reasons you might want to do this:

[1] Security: A good way to thwart hackers is to put services on non-standard ports. For example, everyone knows the standard port for FTP is 21, but an outsider is unlikely to find your FTP server if you place it on port 69, or better yet, an even higher port number (e.g. 51782). The same can be said of SSH. Users will have to know the port in order to access it.

[2] Single Public IP Address, more than one computer with the same services: Smaller networks with only a single public IP address may be stuck if the want to expose a lot of public services. For example, imagine that we want to have two separate FTP servers, but on two separate computers. With port redirection, we create two different NAT rules: the first rule will redirect port 51782 to port 21 on FTPServer1, and the second will redirect port 51783 to port 21 on FTPServer2. We can then remote into two separate FTP servers on two different computers using the same IP address.

External Links:

Port Forwarding Troubleshooting at

© 2013 David Zientara. All rights reserved. Privacy Policy