pfSense 2.1.5 Released

If you’re on the pfSense mailing list, you probably know this already, but pfSense 2.1.5 has been released. It is primarily a security update (including a fix to OpenSSL), but if you want to see a full list of fixes, you can read about it at this blog posting at blog.pfsense.org.

VPN Tunneling with tinc

VPN tunneling

The Config tab in tinc in pfSense.

tinc is a Virtual Private Network (VPN) daemon that uses VPN tunneling and encryption to create a secure private network between hosts on the Internet. Because the tunnel appears to the IP level network code as a normal network device, there is no need to adapt any existing software. The encrypted tunnels allow VPN sites to share information with each other over the Internet without exposing any information to others. tinc is free software and is licensed under the GNU General Public License (GPL). tinc incorporates the following features:

  • Encryption, authentication and compression
  • Automatic full mesh routing
  • Easy to add nodes to your VPN
  • Ability to bridge ethernet segments to work like a single segment
  • VPN tunneling that runs on many operating systems (Linux, FreeBSD, OpenBSD, NetBSD, MacOS X, Solaris, Windows 2000, Windows XP, Windows Vista and Windows 7/8 supported)

VPN Tunneling with tinc: Installation and Configuration

If you choose to install tinc on any of these platforms, binaries are available on the tinc website, as well as documentation. If you choose to install it under pfSense, installation is as easy as finding the tinc package on the package list after navigating to System -> Packages. Once you have found it, click on the “plus” button to install the package, and on the next screen, press the “Confirm” button to confirm installation. The installation should complete within a few minutes.


Once tinc is installed, there will be a new entry under the “VPN” menu called “tinc”. Before you start to configure tinc for VPN tunneling, it might be a good idea to consider how you want to organize your VPN. For example, what are the nodes running tinc? What IP addresses and subnets do they have? What is the network mask of the entire VPN? Do you need special firewall rules, and do you have do set up masquerading or forwarding rules? Do you want to run tinc in router mode or switch mode? It also helps to have a good general understanding of networks.

VPN tunneling

The Hosts tab in tinc.

If you navigate to VPN -> tinc, there are two tabs: “Config” and “Hosts”. Under the “Config” tab, there are several configuation paramters. The “Name” field allows you to enter a name to identify the tinc daemon, which must be unique for the VPN to which this daemon will connect. The “Local IP” field allows you to enter the IP address of the local tunnel interface (often the same IP as your router’s LAN address). “Local Subnet” allows you to specify the subnet behind the router that should be advertised to the mesh, and “VPN Netmask” defines what traffic is the router to the VPN’s tunnel interface. The “AddressFamily” dropdown allows you to select whether listening and outgoing sockets, are IPv4, IPv6, or whether it depends on the operating system. In the “RSA private key” and “RSA public key” fields, you can specify an RSA private/public key pair. You can also check the “Generate RSA key pair” checkbox to generate a new RSA key pair.

On the “Hosts” tab, you can add new hosts by clicking on the “plus” button. The “Name” field allows you to specify a name, while “Address” is for the IP address and “Subnet” is for the subnet behind the host. The “Connect at startup” check box specifies whether tinc should try to connect to the host when it starts. There is also a field for an RSA public key. There are also several advanced settings in both the “Config” and “Hosts” tab; however, if you configure these basic parameters, you should be ready to use tinc VPN tunneling.


External Links:

The official tinc website

Tinc on Wikipedia (just a stub)

Network Traffic Monitoring with vnStat

Network traffic monitoring

Configuring settings with vnStat under pfSense.

vnStat is a console-based program for network traffic monitoring in Linux and BSD. It keeps a log of hourly, daily, and monthly network traffic for the selected interfaces. It uses the network interface statistics provided by the kernel as an information source. This means two things. [1] vnStat isn’t a packet sniffer. But equally important [2] vnStat does not heavily tax system resources. A Linux kernel of at least 2.2 is required. Here, we are concerned with installing and configuring vnStat under pfSense.

Network Traffic Monitoring with vnStat: Installation and Configuration

To install vnStat under pfSense, navigate to¬†System -> Packages and click on the “Available Packages” tab. Scroll down the list of available packages to vnStat, and press the “plus” button on the right side of the entry. On the next page, press the “Confirm” button to confirm installation, which should not take more than a few minutes.


In order to create a vnStat database for an interface, you need to start an SSH session with your pfSense box or access it directly from the console. Then type “8” at the pfSense menu to start a shell session. At the command line, type the following:

vnstat -u -i eth0

where eth0 is the interface to be monitored.

Network traffic monitoring

Viewing stats for the LAN interface with vnStat.

Once installation is complete, you can begin network traffic monitoring. There should be an entry under the Status menu called “Vnstat2“. Navigate to Status -> Vnstat2 and click on the “Config” tab for VnStat configuration options. The “MonthRotate” dropdown box allows you to specify the day of month that months are expected to change. This is usually set to 1, but it can be set to alternate values. For example, if you need to track monthly billed traffic where the billing period does not start on the first day of the month, you can change this parameter accordingly. The “Enable php frontend for vnstat” check box allows you to enable the vnstat frontend (no login needed).

On the second tab, “Vnstati“, you can see pie charts, bar graphs and tables detailing usage of the interface selected from the dropdown box. You can only see information, however, with interfaces for which databases were created. By clicking on the “Access vnstat php frontend” tab, you can access the php frontend, if it is installed and enabled (you can download this frontend from sqweek.com. From the “vnstat info” tab, you can see information about selected interfaces (once you select an interface, the information presented can be filtered via the dropdown box at the top – for example, you can choose to see only activity for the last 24 hours). The “vnstat summary” tab allows you to see a summary of all interfaces for which databases were created.


External Links:

Vnstat at doc.pfsense.org

PHP frontend for VnStat at sqweek.com

Unbound DNS: Additional Settings

In the previous article, we introduced Unbound and covered some of the most common settings. In this article, we will cover some additional settings.

Under Services -> Unbound DNS, the “Unbound DNS Settings” tab has a subheading called “Statistics“. Unbound provides various statistics relating to the number of queries that Unbound handles. These statistics are printed to the Unbound log file, which can be found at /var/log/unbound.log. This log file is viewable via Status: Package logs or via the command line using the command “clog“.

There are a few configurable options. The “Enable Statistics” check box allows you to enable the use of statistics. Checking this will cause Unbound to generate statistics which can be used to generate other information. The “Statistics Interval” dropdown box allows you to select the time as to when statistics will be written to the Unbound log file (anywhere from 5 minutes to 2 hours). If “Yes” is selected in the “Enter Cumulative Statistics” dropdown box, the statistics collected will be cumulative and will not be cleared after each report has been logged. The “Extended Statistics” check box will cause Unbound to log the type of queries that have been handled by the resolver. Otherwise, Unbound only logs the total number of queries collected.


Advanced Settings and ACL Lists

The “Unbound DNS Advanced Settings” tab has a number of additional settings that may be useful. The “Hide Identity” check box will cause Unbound (if checked) to refuse id.server and hostname.bin queries. The “Hide Version” checkbox will cause Unbound (if checked) to refuse version.server and version.bind queries. As a result, any attempt to hack Unbound will potentially be thwarted by depriving the hacker of this vital information. The “Log level verbosity” check box allows you to select the logging verbosity. “Level 0” specifies no verbosity (only errors are logged), while each higher level of logging verbosity (up to Level 5) provides additional information. The “Message Cache Size” dropdown box allows you to alter the size of the message cache. The message cache stores DNS rcodes and validation statuses. The RRSet cache will automatically be set to twice this amount (the RRSet cache contains the RR data).

The “Outgoing TCP Buffers” dropdown box allows you to select the number of outgoing TCP buffers to allocate per thread. If the value is set to 0, no TCP queries to authoritative servers are done. The “Incoming TCP Buffers” dropdown box allows you to select the number of incoming TCP buffers to allocate per thread. Once again, if the value is set to 0, then no TCP queries from clients are accepted.

The next tab is “Unbound DNS ACLs“. Here you can define access control lists for Unbound. Click on the “plus” sign on the right side of the page to add a new ACL. The “ACL name” edit box allows you to provide an ACL name. The “Action” dropdown box allows you to choose what to do with DNS requests that match the specified criteria. “Deny” causes Unbound to stop queries from hosts within the specified netblock. “Refuse” will also stop queries from hosts within the specified netblock, but will send a DNS rcode REFUSED error message back to the client. “Allow” will allow queries from hosts within the specified netblock. “Allow Snoop” will allow recursive and nonrecursive access from hosts within the specified netblock.

At “Networks“, you can press the “plus” button and specify a netblock or series of netblocks (along with descriptions) to which the action will be applied. Finally, you can add a description in the “Description” edit box. When you are done setting up the ACL, press the “Save” button to save the changes (or “Cancel” to cancel).

Unbound also provides various command line utilities to manage your DNS cache server. To remove a name from the cache, type:

unbound-control flush [name]

where [name] is a record of any type (including A, AAAA, NS<SOA, CNAME, DNAME, MX, PTR, SRV and NAPTR). If you want to remove a name of a specific type, then type:

unbound-control flush_type [name] [type]

If you want to flush an entire zone, type:

unbound-control flush_zone [name]

This will remove all information at or below the name from the cache. For example, if you specify .com, all entries below .com will be removed.

To determine the name servers that will be queried to lookup a zone, type:

unbound-control lookup [name]


External Links:

Unbound package at doc.pfsense.org

Unbound DNS

Unbound DNS

Configuring Unbound DNS in pfSense.

Unbound DNS is a validating, recursive and caching DNS server software product. The C implementation of Unbound is developed and maintained by NLnet Labs, and is based on ideas and algorithms taken from a Java prototype developed by Verisign labs, Nominet, Kirei, and ep.net. It is distributed free of charge under the BSD license.

Unbound can run as a server, as a daemon in the background, answering DNS queries from the network. Alternatively, it can link to an application as a library, and answer DNS queries for the application. Here, we are concerned with running unbound as a server by installing the Unbound package in pfSense.

Unbound DNS: Installation and Configuration

To install the Unbound package, navigate to System -> Packages, and scroll down to the Unbound entry in the packages listing. On the right side of the listing, press the “plus” button to select the package. On the next page, press the “Confirm” button to confirm installation. Installation should complete within a few minutes. Once it is complete, you should see the following text:

Unbound setup instructions:
Please visit Services: Unbound DNS to configure the Unbound DNS service. Remember you will need to disable Services: DNS Forwarder before starting Unbound. Also note if your DHCP server makes use of pfSense as the DNS server, then you will now need to add the IP address of the respective interface to the DNS servers field, in the DHCP server configuration page.

After installation, there will be a new item on the Services menu called “Unbound DNS”. Navigate to Services -> Unbound DNS to begin configuration. The first tab, “Unbound DNS Settings”, allows you to configure the basic settings. First is the “Enable Unbound” check box, which lets you enable the use of Unbound as your DNS forwarder. Next is “Network Interface”, which allows you to specify the network interface(s) the server will listen on. “Query interfaces” allows you to specify different network interface(s) the server will use to send queries to authoritative servers.


Next is the “Enable DNSSEC” check box. DNSSEC (Domain Name System Security Extensions) is a suite of specifications for securing certain kinds of DNS information. It was designed to protect applications, as well as caching resolvers serving those applications, from using forged or manipulated DNS data. If you wish to use DNSSEC to validate your DNS queries, it is recommended that you disable forwarding (the next setting) and allow Unbound to do all your DNS resolving. You can leave the forwarding mode enabled, though, if you are certain that your upstream DNS servers also provide DNSSEC support. Forwarding mode will allow you to configure the server to make use of other DNS servers configured in System -> General Setup.

Next is the “Private Address support” check box. With this option enabled, RFC1918 address are stripped away from DNS answers. Additionally, the DNSSEC validator may mark the answers bogus. You will want to disable this if you have zones that return addresses that are private. With this option enabled, any domain overrides configured will be exempt from this check. The “Register DHCP static mappings” check box causes DHCP static mappings to be registered in the DNS forwarder, so their names can be resolved.

The next two options are “TXT Comment Support” and “Cache Restoration Support”. If the “TXT Comment Support” is checked, then any descriptions associated with host entgries and DHCP static mappings will create a corresponding TXT record. This allows you to view somments you have added using DNS. To view these comments, one would simply execute the following command: dig @<pfSense_ip> host_entry.txt. “Cache Restoration Support” ensures that the current Unbound cache containing all the DNS records is saved to disk. Thus, if the service or server is restarted, the cache is restored resulting in quicker responses in resolving DNS queries. Note that any old or wrong data will be restored.

Once these options are saved, you will be able to use Unbound in pfSense to do all your DNS resolving. In the next article, we will look at some of the other settings.


External Links:

The official Unbound web site

Unbound package at doc.pfsense.org

Securing Ports and Services

Securing portsA computer system that is not connected to a network is a rarity. While this provides some flexibility in terms of remote services, data and information that are available, it also brings considerable risks. It is probably correct to assume that any computer connected to a network is in danger of being attacked in some way. Secure computer environments, in many cases used by government defense organizations, often have no contact with the outside world, even if they are networked to each other, and as a result, they often have greater success in securing ports and services.

The predominant network communications protocol is TCP/IP. It is the protocol used by the Internet and thus has supplanted most of the formerly popular protocols used for local area networks (LANs). However, TCP/IP was conceived to send and receive data reliably, not to secure it. Securing the data (and securing ports) is the job of applications listening and sending on specific ports.

TCP/IP defines a total of 65,535 ports of which 1023 are considered to be well-known ports. These are, of course, not physical ports into which network cables are connected, but rather virtual ports on each network connection which can be used by applications and services to communicate over a TCP/IP connection. In reality, the number of ports that are used by popular network clients and services comprises an even smaller subset of the well-known group of ports, which makes the task of securing ports somewhat easier.

There are a number of different TCP/IP services which can be provided by an operating system. Such services include HTTP for running a web server, FTP for allowing file transfers, SSH and Telnet for providing remote login access and SMTP for the transport of e-mail messages. Each service in turn is assigned a standard TCP/IP port. For example, port 80 is for HTTP requests; port 21 is for File Transfer Protocol (FTP); port 17 is for the quote of the day.


Securing Ports and Services: How It’s Done

A large part of securing ports and securing servers involves defining roles, and based on the roles, defining which services and ports should be enabled. For example, a server that is to act solely as a web server should only run the HTTP service, and perhaps SSH for remote administration access. All other services should be disabled, and ideally, removed entirely from the operating system. Removing the service will make it harder for an intruder to re-enable the service. Thus, while it is necessary for some ports to be open to Internet traffic, it is also necessary to ensure that only the bare minimum are exposed and that the software on the system is as up to date as possible.

Securing a system involves (a) removing any unnecessary services from the operating system and (b) ensuring that the ports associated with these non-essential services are blocked using a firewall.

Many operating systems are installed with a number of services installed and activated by default. Before installing a new operating system, it is essential that the installation be carefully planned. This involves deciding which services are not required and identifying which services have been installed and enabled by default. It helps if deployment is not rushed; the fewer services and open ports available on a system, the smaller the surface area and opportunities for attackers. In addition, it is essential to turn on automatic updates, both for Windows and Linux, as well as for your antivirus software.

As for the firewall, you will want to have a dedicated firewall between your network and the Internet. Although not absolutely essential, it is good practice to have a personal firewall on each computer. In securing ports, you should make sure your firewall is closed to all traffic other than to the ports you know should be open. Because some malicious software can silently open ports, it is a good idea to check them yourself and close any that you do not need open.


External Links:

TCP/UDP ports on Wikipedia

How to secure your TCP/IP ports at techradar.pro

Software Exploits

software exploitA software exploit is a piece of software or sequence of commands that takes advantage of a bug, glitch or vulnerability in order to cause unintended or unanticipated behavior to occur. Software applications and the operating systems on which the run are vastly complex entities. Regardless of how carefully written and thoroughly tested a piece of software is, it typically will contain bugs or vulnerabilities that can be exploited. Such software exploits frequently include things like gaining control of a computer system, allowing privilege escalation, or a denial-of-service attack.

Types of Software Exploits

Software exploits can be categorized and named according to certain criteria:

  • The type of vulnerability they exploit (software vulnerabilities can arise from either insufficient testing or the lack of an audit trail).
  • Whether they need to be run on the same machine as the program that has the vulnerability (local) or can be run on one machine to attack a program running on another machine (remote).
  • The result of running the exploit.


The most common categorization is by how the exploit contacts the vulnerable software. A remote exploit works over a network and exploits the security vulnerability without any prior access to the vulnerable system, whereas a local exploit requires prior access to the vulnerable system and usually increases the privileges of the person running the exploit past those granted by the system administrator. There are also exploits against client applications. These usually consist of modified servers that send an exploit if accessed with a client application. Such exploits can be considered remote exploits, although they may require some interaction with the user and thus may be used in combination with the social engineering method.

Another classification is by the action against the vulnerable system: unauthorized data access, arbitrary code execution, and denial-of-service are all examples. Many exploits are designed to provide superuser-level access to a computer system. It is also possible to use several exploits first to gain low-level access, then to escalate privileges until one reaches root.

Often, when a software exploit is publicized, the vulnerability is fixed through a patch and the exploit becomes obsolete until newer versions of the software become available. This is the reason why some hackers do not publish their exploits, but keep them private. Such exploits are referred to as zero day exploits. Obtaining access to such exploits is the primary desire of some unskilled hackers.

While it is impossible to completely eliminate the risk of software exploitations, the threat can be greatly reduced by keeping operating systems and applications patched with the latest vendor updates and to develop applications using programming languages such as C# and Java, which provide managed environments that reduce the risk of some exploitations.


External Links:

Software Exploitation, Malicious Code and Social Engineering at Techtopia

© 2013 David Zientara. All rights reserved. Privacy Policy