Amazon Affiliate Purchases: October 2014

Here are some of the items readers bought through my Amazon affiliate links:

Coolerguys Programmable Thermal Fan Controller with LED Display

EnGenius Technologies Dual Band 2.4/5 GHz Wireless AC1200 Router with Gigabit and USB (ESR1200)

Fan Controller FC5V2 Black, Version 2, Changeable Display Colors, 30W per Channel, Controls up to 4 fans, RPM and TempretureDisplay

Samsung Electronics 840 EVO-Series 1TB 2.5-Inch SATA III Single Unit Version Internal Solid State Drive MZ-7TE1T0BW

The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall

A special thanks to everyone who used my affiliate links to make purchases from Amazon in October (or any other month). Remember, your purchases through’s affiliate links help keep the lights on at pfSense Setup HQ without costing you a dime.

September 2014 Amazon Affiliate Purchases

Here are some of the products readers purchased through my Amazon affiliate links during the month of September 2014:

EnGenius Technologies Long-Range Wireless-N Indoor AP/Bridge (ECB300)

Mikrotik RB951-2N Wireless Router 802.11b/g/n

NZXT Technologies Sentry 3 5.4-Inch Touch Screen Fan Controller Cooling AC-SEN-3-B1

Oriental Furniture Modern Furniture, 6-Feet Helsinki Fabric Japanese Privacy Screen Room Divider, 4 Panel Honey

Disney Infinity Power Disc Complete Series 1 Set of 20

Your purchases through this site’s Amazon affiliate links help keep the lights on at And it doesn’t cost you an extra cent: all commissions come from Amazon’s end of the sale.

Greylisting Advantages and Disadvantages

greylistingIn the previous two articles, we covered installation and configuration of spamd, a useful spam-referral daemon. In this article, we will examine some of the advantages and disadvantages of greylisting.

The Greylisting Process

Before we begin, it might be useful to review some of the basic concepts of spam deferral. The process involves, at its most basic level, dividing hosts into three categories: blacklisted hosts, whitelisted hosts, and greylisted hosts. Blacklisted hosts are hosts that are denied access, while whitelisted hosts are granted access. Greylisted hosts, as the name implies, is a kind of cross between blacklisting and whitelisting: such hosts are temporarily blocked (or, in some cases, temporarily allowed) until an additional step is performed.

When spamd receives e-mail from an unknown host, it records three pieces of data (known as a triplet) for each incoming mail message:

  • The IP address of the host
  • The envelope sender address
  • The envelope recipient address (or just the first of them)

With this data, we follow a basic rule: if we have never seen a triplet before, then we refuse delivery and any others that may come within a certain period of time with a temporary failure.

This data s registered on the mail server’s internal database, along with the time stamp of its first appearance. The e-mail message will be dismissed until the configured period of time is elapsed (in the case of spamd, the default time period is 25 minutes). Temporary errors are defined in the Simple Mail Transfer Protocol (SMTP) as 4xx reply codes. Since SMTP is considered an unreliable transport, the possibility of temporary failures is built into the core spec. Therefore, fully capable SMTP implementations are expected to maintain queues for retrying message transmissions in such cases. During the initial testing of greylisting, it was observed that the vast majority of spam appears to be sent from applications designed specifically for spamming. These applications appear to adopt the “fire-and-forget” methodology, and they attempt to send the spam to one or several hosts for a domain, but never attempt a true retry as a real message transfer agent (MTA) would. Conversely, spamd assumes that if a sender has proven itself able to properly retry delivery, then it is a legitimate sender and not a spammer. Thus, such a host will be whitelisted for a longer period of time, so that future delivery attempts will be unimpeded. As an example, spamd can be configured to require a successful delivery attempt against a registered triplet to be no earlier than 25 minutes after registration and not later than 4 hours after it. Repeated delivery attempts before the 25 minute period will be ignored with the same 4xx reply code. After 4 hours the triplet will be expired, so delivery attempts will register anew. When spamd sees an attempt within the 25 minute – 4 hour window, the connecting host will be whitelisted for a certain period of time (default is 36 days).

In addition to being highly effective at blocking spam (over 95% in initial tests), greylisting also ensures that no legitimate mail is ever blocked. In addition, greylisting has been shown to be extremely effective in blocking e-mail-based viruses, as they also do not tend to retry deliveries. And since these viruses are fairly large, bandwidth and processing savings are considerable as compared to the standard method of accepting delivery and local virus scanning.

This temporary rejection can be issued at different stages of the SMTP dialogue, so that the spam deferral daemon can store more or less data about the incoming message. In addition to whitelisting good senders, a greylisting daemon can provide for exceptions. Greylisting can usually be overridden by a fully validated TLS connection with a matching certificate. In addition, because large senders often have a pool of machines that can send and resend e-mail, IP addresses that have the most-significant 24 bits the same are treated as equivalent. In some cases, SPF records are used to determine the sending pool.

Greylisting Disadvantages

Now that we have presented an overview of greylisting and its advantages, it is time to examine some of the disadvantages of this method.

The biggest disadvantage of greylisting is that for unrecognized servers, it destroys the near-instantaneous nature of e-mail most users have come to expect. Mail from unrecognized servers is typically delayed by 15 minutes, and could be delayed for days. A customer of a greylisted ISP cannot always rely on getting e-mail in a predetermined period of time. This disadvantage is mitigated somewhat by the fact that prompt mail delivery is restored once a server has been recognized and is generally maintained automatically so long as users continue to exchange messages. This disadvantage is apparent when a server accessing a greylising mailserver attempts to reset his credentials to a website that uses e-mail confirmation of password resets. In some cases, the delivery delay imposed by the greylister can exceed the expiry time of the password reset token delivered in the e-mail. In such cases, manual intervention may be required to whitelist the host so the e-mail with the reset token can be used before it expires.

Another problem is that some SMTP senders may interpret the temporary rejection as a permanent failure. Old clients conforming only to the obsolete SMTP specification and ignoring its recommendations may give up on delivery after the first failed attempt, as RFC 821 (the old specification) states that clients “should” retry messages rather than using the word “must”. The problem can affect SMTP clients in unexpected ways. Most MTAs will queue and retry messages, but some do not. A possible solution is to configure the application to use a local SMTP server as an outbound queue, instead of attempting direct delivery. The server operator who employs greylisting can whitelist a client which is known to fail on temporary errors.

Some MTAs, upon encountering the temporary failure message from a greylisting server on the first attempt, will send a warning message back to the original sender of the message. The warning message is not a bounce message, but it is often formatted similarly to one and reads like one. This practice often causes the sender to believe the message has not been delivered, although the message will be delivered successfully, albeit at a later time.

Another problem is that the retry might come from a different IP address than the original attempt. When the source of an e-mail is a server farm or goes out through a relay, it is likely that a server other than the original one will make the next attempt. Moreover, their IPs can belong to completely unrelated address blocks (due to network fault tolerance), thereby defying the simple technique of identifying the most significant part of the address. Since the IP addresses will be different, the recipient’s server will fail to recognize that a series of attempts are related, and refuse each of them in turn. This problem can be partially solved by proactively identifying such server farms and making exceptions for hem. Likewise, exceptions have to be configured for multi-homed hosts and hosts using DHCP.

External Links:

The Next Step in the Spam Control War: Greylisting by Evan Harris on

August 2014 Amazon Affiliate Purchases

Here’s some of the products that people have purchased through my Amazon affiliate links:

Allstar ALL90040 Red Anodized 1/4″ Mounting Hole In-Line Oil Temperature 10AN Male 1/2 NPT Female Tee Fitting

Asus Black 12X BD-ROM 16X DVD-ROM 48X CD-ROM SATA Internal Blu-Ray Drive (BC-12B1ST)

Lamptron CW611 Water Cooling Controller 6CH X 36W LCD Six2510-3pin

Sunbeamtech PL-RS-6 Rheosmart 6 Fan Controller

San Francisco Bay Coffee, Breakfast Blend, 80 OneCup Single Serve Cups

DNSSEC Mastery: Securing the Domain Name System with BIND

A special thank you to everyone who purchased something through my Amazon affiliate links. Your purchases from Amazon through my affiliate links help pay the bills here at pfSense Setup HQ.

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

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 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

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

TCP/IP Hijacking

TCP/IP hijackingTCP/IP hijacking is a technique that uses spoofed packets to take over a connection between a victim and a host machine. It is similar to a man-in-the-middle attack, except that the rogue agent sends a reset request to the client so that the client loses contact with the server while the rogue system assumes the role of the legitimate client, continuing the session. This technique is especially useful when the victim uses a one-time password to connect to the host machine. A one-time password can, as its name implies, be used to authenticate once and only once; thus, sniffing the authentication is useless for the attacker.

To carry out a TCP/IP hijacking attack, the attacker must be on the same network as the victim. This gives the attacker the ability to sniff the local network segment and, as a result, all the details of open TCP connections can be pulled from the headers. Each TCP packet contains a sequence number in its header. This sequence number is incremented with each packet sent to ensure that packets are received in the correct order. While sniffing packets, the attacker has access to the sequence numbers for a connection between a victim and a host machine. Then the attacker sends a spoofed packet from the victim’s IP address to the host machine, using the sniffed sequence number to provide the proper acknowledgment number. The host machine will receive the spoofed packet with the correct acknowledgment number and will have no reason to believe the packet did not come from the victim’s machine; thus the TCP/IP hijacking attempt will be successful.

Forms of TCP/IP Hijacking

One form of TCP/IP hijacking is to inject an authentic-looking reset (RST) packet. If the source is spoofed and the acknowledgment number is correct, the receiving side will believe that the source actually sent the reset packet, and the connection will be reset. The attacker could perform such an attack using a program that uses the libpcap and libnet libraries. libpcap would sniff the packets, and libnet would inject RST packets. The program does not need to look at every packet, but only established TCP connections to a target IP, so the libcpap function calls would be structured accordingly. It is relatively easy to come up with a filter rule for packets that have a certain destination IP. It is somewhat more difficult to filter for established connections, but since all established connections will have the ACK flag in the TCP header TCP flags, the program can look for that.

Another type of TCP/IP hijacking is continued hijacking. The spoofed packet does not need to be an RST packet; the spoof packet can contain data. When the host receives the spoofed packet, it will increment the sequence number and responds to the victim’s IP. Since the victim’s machine does not know about the spoofed packet, the host machine’s response has an incorrect sequence number, so the victim ignores that response packet. And since the victim’s machine ignored the host machine’s response packet, the victim’s sequence number count is off. Therefore, any packet the victim tries to send to the host machine will have an incorrect sequence number as well, causing the host machine to ignore it. In this instance, both legitimate sides of the connection have incorrect sequence numbers, resulting in a desynchronized state. And since the attacker sent out the first spoofed packet that caused all this chaos, it can keep track of sequence numbers and continue spoofing packets from the victim’s IP address to the host machine. This lets the attacker continue communicating with the host machine while the victim’s connection hangs.

External Links:

TCP Hijacking at TechRepublic

Replay Attacks and Possible Countermeasures

replay attackReplay attacks are a variation on the man-in-the-middle theme. In a replay attack an agent is once again placed within the client/server line of communication. In the case of a replay attack, however, the transaction data is recorded for the express purpose of allowing the data to be modified and replayed to the server at a later time for nefarious purposes.

An example of a replay attack is an instance where one party wants to prove their identity to a another party. If a third party eavesdrops on the conversation, they can intercept the password. Once the exchange is over, the eavesdropper can send the password and impersonate the party to whom the password belongs to gain unauthorized access to the other party.

Defenses Against Replay Attacks

As with other man-in-the-middle attacks, replay attacks can be countered using encryption, timestamps, serial numbers and packet sequences so that the server can detect that the data is being replayed from a previous session. One effective method of avoiding replay attacks which uses encryption is to use session tokens. Let us assume that A is required to send a password to B. If session tokens are used, B will send a one-time token to A, which A will then use to transform the password and send the result to B. On the other side, B performs the same transformation, and if both values match, the login will be successful. If C eavesdrops on A and B and captures the transformed password, C can try to use it to authenticate with B. But B will send a session token, and if C sends the transformed password captured earlier, the transformations will not match, and authentication will fail.

If C knows that B is using session tokens, C might be able to pose as B, presenting some predicted future token, and convince A to use that token in A’s transformation. C can then replay A’s reply at a later time, when the previously predicted token is presented by B, and B will accept the authentication. For that reason, session tokens should be chosen by a pseudo-random process.

One-time passwords are similar to session tokens in that the password expires after it has been used or after a very short period of time. They can be used to authenticate individual transactions in addition to sessions.

Replay attacks can also be thwarted by the use of message authentication codes (MACs), short pieces of information used to authenticate a message and to provide integrity and authenticity assurances on the message. MAC algorithms accept as input a secret key and an arbitrary-length message to be authentication, and outputs a MAC. This value protects both a message’s data integrity and its authenticity by virtue of the fact that the verifiers possessing the secret key to detect any changes to the message content.

Timestamping is another means of preventing a replay attack. Synchronization is achieved using a secure protocol. As an example, B can broadcast the time on their clock along with a message authentication code (MAC). If A wants to send B a message, they can include an estimate of the time on B’s clock in their message (which also sends a MAC). B only accepts messages for which the timestamp is within a reasonable tolerance.

External Links:

Replay attack on Wikipedia

IP Spoofing and Defenses

IP spoofingIP address spoofing is the creation of IP packets with a source IP address with the purpose of concealing the identity of the sender or impersonating another computer system. The basis of spoofing involves masquerading as a trusted system in order to gain unauthorized access to a secure environment. IP spoofing involves modifying data to make it appear to originate from the IP address of a system that is trusted by a server or firewall. Using this approach, a host is able to pass through the IP filtering that would otherwise serve to prevent access.

The objective of IP spoofing in most, but not all cases, is to gain unauthorized access to a server or service. DNS spoofing differs from IP spoofing in that the objective is to send users to a different location than the one to which they thought they were going. For example, assume a user wants to login to Facebook. He enters the URL of Facebook into his browser. The browser contacts a Domain Name Server (DNS) which looks up the IP address which matches the URL. The user is then taken to the site located at that IP address, where he enters his login name and password. DNS spoofing involves the DNS server being compromised such that the Facebook URL is set to point to the IP address of a malicious party where a web site that looks like Facebook has been set up. Now when the user enters the URL in a browser, he is taken to the fake web site where his login name and password are captured and stored. The web site might then report that Facebook is offline for maintenance. The user decides to try again later. In the meantime, the attacker uses the victim’s credentials to log into his Facebook account and gain a foothold in committing identity theft. Even more nefarious would be if the attacker used DNS spoofing to point to a fake bank web site or another site where the attacker may be able to gain access to sensitive data.

IP spoofing is not, however, always carried out with malicious intent. In performance testing of websites, hundreds or even thousands of virtual users may be created, each executing a test script against the web site under test, in order to simulate what will happen when the system goes live and a large number of users log on at once. Commercial testing products can use IP spoofing, allowing each user its own IP address.

IP Spoofing: Defenses

There are several possible defenses against IP spoofing. Packet filtering is one defense against IP spoofing attacks. The gateway to a network usually performs ingress filtering, which is blocking of packets from outside the network with a source address inside the network. This prevents an outside attacker spoofing the address of an internal machine. Ideally, the gateway would also perform egress filtering on outgoing packets, which is blocking of packets from inside the network with a source address that is not inside. This prevents an attacker within the network performing filtering from launching IP spoofing attacks against external machines. In addition, many firewalls (pfSense included) practice bogon filtering, which means that IP packets from the Internet that claim to be from an area of the IP address space reserved, but not yet allocated or delegated by the Internet Assigned Numbers Authority (IANA) or a delegated Regional Internet Registry (RIR), are blocked.
Some upper layer protocols provide their own defense against IP spoofing attacks. For example, Transport Control Protocol (TCP) uses sequence numbers negotiated with the remote machine to ensure that arriving packets are part of an established connection. Since the attacker normally cannot see any reply packets, the sequence number must be guessed in order to hijack the connection.

Implementing encryption and authentication will also reduce spoofing threats. Both of these features are included in Ipv6, which will eliminate current spoofing threats. Additionally, a system administrator should eliminate all host-based authentication measures, which are sometimes common for machines on the same subnet. You should ensure that the proper authentication measures are in place and carries out over a secure, encrypted channel.

IP spoofing is a common problem without a simple solution, since it is inherent in the design of the TCP/IP protocol suite. Understanding how and why spoofing attacks are used, along with a few simple prevention methods, can help protect your network from these nefarious techniques.

External Links:

IP spoofing on Wikipedia

© 2013 David Zientara. All rights reserved. Privacy Policy