BEAST Attack Mitigation in pfSense

BEAST attack

Enabling BEAST attack protection in pfSense 2.1.3.

On September 23, 2011 researchers Thai Duong and Juliano Rizzo demonstrated a proof of concept called Browser Exploit Against SSL/TLS (BEAST). A BEAST attack involves intercepting and decrypting HTTPS cookies. Whenever you log into an HTTPS page, after your authentication, you can see your autenticated page, and if you look carefully at the page’s URL, you can see the session ID. A session ID is a random number or combination of numbers and string that maintains the state of the page, it is assigned by the website server to the client browser. The session ID can be found in either the cookie or the URL of the web browser. Usually, session IDs will be encrypted to prevent hijacking of the session.

A successful BEAST attack entails first sending a malicious JavaScript to run on the victim’s machine. This can be achieved by several means: Cross Site Request Forgery (CSRF), social engineering, a download, or a web page containing JavaScript. This malicious script runs on the victim’s machine and can capture the entire header info and the encrypted cookie that is assigned from the web server running Transport Layer Security (TLS) 1.0 and can then send the information to the website.

Next, the attacker utilizes a vulnerability in SSL/TLS. In TLS 1.0, if there are two identical plaintext messages, then after encryption, the cipher text is the same. Thus, by comparing the encrypted session details and the unencrypted data sent by the script, the attacker can find the initialization vector. Once the attacker gets this information, it can decrypt future cookies sent from the web server.

Using this blueprint, Duong and Rizzo built the BEAST tool, which is capable of decrypting HTTPS cookies and hijacking browsing sessions in order to steal credentials. Major browser makers, except for Apple, addressed the issue on the client side by implementing a technique known as the 1/(1-n) split. The technique stops attackers from being able to predict the initialization vector blocks that are used to mask plaintext data before it is encrypted.

Enabling BEAST Attack Protection in pfSense

Fortunately, pfSense provides some measure of protection against BEAST attacks on your web configurator sessions. If you navigate to System -> Advanced, and click on the “Admin Access” tab, under “webConfigurator“, there is a “BEAST Attack Protection” check box. It is left unchecked by default because it does not work with Hifn cryptographic accelerators, and if it is used when such accelerators are being utilized, the web GUI will not work. If you are not using such cryptographic accelerators, however, you should be able to enable this option without having any issues.

External Links:

Not So Fast on BEAST Attack Mitigations at

BEAST vs. CRIME Attack at

Web-Based SSH with Anyterm

web-based SSH

Anyterm settings page under pfSense 2.1.3.

Sometimes, you may want to access Secure Shell (SSH) servers but the access point you are using blocks port 22 or whatever port your SSH server is using. Fortunately, there is a solution: web-based SSH makes it possible to access SSH servers through standard web browsers. Respective clients are based on JavaScript/Ajax or JavaScript/WebSockets and can be used to access SSH servers from behind a firewall or proxy.

Anyterm is one such web-based SSH program. It is written in C++ for the server side and JavaScript for the client side, and uses server-side terminal emulation. It also utilizes long polling for client/server communication. The server-side implementation is a stand-alone daemon which is typically used with a reverse proxy, such as Apache’s mod_proxy. Anyterm is licensed under the terms of the GPL.

Anyterm consists of some JavaScript on a web page, an XmlHttpRequest channel on standard ports back to the server, an HTTP proxy and the Anyterm daemon. The daemon uses a pseudo-terminal to communicate with a shell or other application, and includes terminal emulation. Key presses are picked up by the JavaScript, which sends them to the daemon. Changes to the emulated screen are sent from the daemon to the JavaScript which updates its display. SSL can be used to secure the connection, and is recommended.

Web-Based SSH with Anyterm: Installation and Configuration

To install Anyterm in pfSense, navigate to System -> Packages; Anyterm should be at the top or near the top of the list. Press the “plus” button to the right of the listing for Anyterm; on the next screen, click the “Confirm” button to confirm installation. It will take a few minutes for installation to complete, after which there will be a new menu item on the Diagnostics menu (Anyterm).

When you navigate to Diagnostics -> Anyterm, there are two tabs. The first tab, “Settings“, has four options. The first two fields are “Username” and “Password“, in which you can specify the username and password for accessing Anyterm. The third field is “Port“, where you can enter the port that Anyterm will use (default is 8080). The last field is “STunnel Port” where you can enter the STunnel port if you have an STunnel forward. Press the “Save” button at the bottom of the page to save the settings.

You probably want to set up port forwarding for the Anyterm port so you can use Anyterm from other networks. Navigate to Firewall -> NAT, and press the “plus” button on the bottom right to add a new entry. For “Destination port range”, enter the Anyterm port, and for “Redirect target IP“, type the IP of your pfSense system. For “Redirect target port“, enter the Anyterm port again. At “Description”, add a brief description, and leave “Filter rule association” at the default of “Add associated filter rule“. Press the “Save” button to save the entry. Press “Apply changes” on the next page to apply the changes.

web-based SSH

Anyterm in action, used to access the pfSense shell.

You should be able to use Anyterm to gain shell access to pfSense now and thus take full advantage of its web-based SSH capabilities, but you probably want to install STunnel as well so you have an SSL encryption tunnel between you and pfSense. STunnel can be installed from System -> Packages, and installation should only take a minute. Once you install stunnel, it will be an option on the “Services” menu.

Under “STunnel”, there are two tabs: “Tunnels” and “Certificates“. “Listen on IP” and “Listen on port” specifies the listening socket IP address and port. “Certificate” specifies the certificate to use for the listening socket. “Redirects to IP” and “Redirects to Port” specifies the target IP address and port. The “Outgoing source IP” is the IP address to bind to when connecting to the target.

Certificates are managed by requiring the user to provide an RSA key and certificates/chains in PEM format. The Certificates tab will list the configured certificates along with status information, indicating whether the certificate is valid, will expire soon, or is already expired. A check is also performed to make sure the key and certificate matches. Once you finish setting up stunnel, remember to go back to the Anyterm “Settings” tab to enter the STunnel forward port.

By now, you should be able to use web-based SSH to access the shell of your pfSense system from outside your local network by entering your WAN IP address and the Anyterm port. If you installed STunnel, you will have an SSL encryption tunnel, so your web-based SSH session should be relatively secure.

External Links:

The official Anyterm web site

Apache Server Hardening: Part Three

Apache server hardeningIn the previous article, we discussed configuring the underlying OS and download and verifying Apache. After downloading and verifying the Apache source code, you’ll need to do some research to understand what options you want to compile into your web server. There are many modules, such as mod_access and mod_ssl, that can be added into your server to provide additional functionality and security. A full list of Apache Foundation-provided modules can be found at the Apache web site. When choosing modules, be sure you select only what you need. Compiling extra, unnecessary modules will only result in a less secure, slower web server.

You should use caution in enabling and disabling services at compile time. Before you do so, determine the dependencies of your web server code. Failure to understand what services you require to operate could result in loss of critical functionality. It might be prudent to test your configuration in a lab environment before disabling services on a production server.

Once you’ve decided which modules and configurations to use, you should accomplish one final task before building your software. Obscure the Apache version information located in the ap_release.h file located in the $[ApacheSrcDir]/include directory. To do so, use vi, gedit, or the editor of your choice and alter the following lines to change the Software Vendor (Apache Software Foundation) information:

#define AP_SERVER_BASEVENDOR “Apache Software Foundation”

In general, you’ll need to perform three steps to compile and install your Apache Web server, as follows:

  1. From the $[ApacheSrcDir] directory, run ./configure.
  2. after configuring source, run ./make to compile the software.
  3. After compiling the software, run ./make install to install the Apache web server.

During the first step, you’ll decide what is added to the Apache server at compile time.

Add/Remove Module name Purpose
Remove Status Provides potentially dangerous information via server statistics web page
Remove Info Provides potentially dangerous configuration information
Remove Include Provudes server-side include (SSI) functionality
Remove userdir Permits users to create personal homepages in ~user home directories
Add mod_ssl Provide cryptography using the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols
Add mod_log_forensic Increases granularity of logging to forensic levels
Add mod_unique_id Required for mod_log_forensic module

mod_security, a third-party Apache module available from, provides application firewall intrusion protection and prevention. To enable mod_security, you must download and compile the software into the Apache web server. Adding mod_security increases the secure operation of your Apache web server and adds functionality including, but not limited to, the following:

  • HTTP protocol awareness
  • Anti-evasion technique prevention such as URL encoding validation and URL decoding
  • Enhanced audit logging
  • Bult-in chroot functionality
  • Buffer overflow protection
  • HTTPS filtering

We will enable mod_security in our example because it adds so many security features to our system. Once you have downloaded mod_security source from the download page of the mod_security website, perform the following steps as root:

cd $[modsecuritySrcDir]/apache2

mkdir -r $[ApacheSrcDir]/modules/security

cp mod_security.c config.m4 \ $[ApacheSrcDir]/modules/security

cd $[ApacheSrcDir]


Now mod_security appears like other Apache modules. When we compile Apache, we will enable it using the command -enable-security. There are many options to consider in configuring the Apache source code for compilation. To view a list of options, issue the command ./configure –help from the $[ApacheSrcDir] directory.

After successfully configuring the source code, proceed with running make and make install. You will see a message indicating successful completion of building and installing Apache. Now that we have successfully installed the Apache web server software, we will proceed to the next step: configuring theĀ httpd.conf file for secure operation. We will cover that in the next article.

External Links:

The official Apache website

The official ModSecurity website

VPN Access Strategies

VPN accessA virtual private network (VPN) is exactly what it sounds like: the network connection you create is virtual, because you can use it over an otherwise public network. Basically, you take two endpoints for the VPN tunnel, and all traffic between these two endpoints will be encrypted so that the data being transmitted is private and unreadable to the system in between. Different VPN solutions use different protocols and encryption algorithms to accomplish this level of privacy. VPNs tend to be protocol independent, at least to some degree, in that the VPN configuration is not on a per-port basis. Rather, once you have established the VPN tunnel, all applicable traffic will be routed across the tunnel, effectively extending the boundaries of your internal network to include the remote host. In this article, we will examine some of the issues involved in implementing VPN access.

VPN Access: Network Design

One of your first considerations when planning to provide for VPN access is the network design. Because the VPN tunnel needs two endpoints, one will be the remote workstation. The other will be a specially configured device for that purpose. This is generally called a VPN concentrator, because it acts as a common endpoint for multiple VPN tunnels. [As noted previously in this blog, Soekris makes affordable VPN cards that offload the CPU of the the computing intensive tasks of encryption and compression.] The remote system will effectively be using the concentrator as a gateway into the internal network; as such the placement of the concentrator is important: in a highly secured environment, the concentrator is placed in a DMZ sandwiched between two firewalls, one firewall facing the Internet, and the other facing internally. While this type of arrangement is the most secure, it takes more hardware to implement.

Another way to place the VPN concentrator inside a DMZ is to use an additional interface on the firewall as the DMZ in a “one-legged” configuration. This saves you having to implement an additional firewall, but still provides some isolation between the concentrator and the rest of the internal network. If an attacker compromised a remote host who was VPNed into the concentrator or compromised the concentrator itself, they would still have a firewall between them and the internal network. The least preferable option is to place the concentrator inside the internal network. With this type of design, if the concentrator is compromised, the attacker would have full access to the internal network, with no firewalls to inhibit their activities. With any of these designs, you will have to permit the required ports through the firewall and forward them to your VPN concentrator in order to ensure VPN access.

VPN Access: Protocols

Another consideration in providing VPN access is the type of VPN protocol you want to use. IPsec is still the most widely deployed VPN technology for good reason. One is interoperability. As a widely used and tested standard, IPsec will work with virtually any modern firewall and operating system. The disadvantage of IPsec is that it can sometimes be difficult to configure properly, and there is zero margin for error on the configuration. Both ends have to se the same parameters for encryptions, hashing, and so forth, or the tunnel cannot be established. SSL is an increasingly popular choice for VPNs, largely because of its simplicity to implement.

Once you have chosen a design and VPN technology, you need to consider the administrative ramifications of offering remote access. Some level of training will be required. At the very least, they may require training to use the VPN software. It is a good idea to educate your users on good security habits as well. A determination will also need to be made as to whether remote users are allowed to use their own personal computers and/or laptops, or if they must use a company-provided computer for remote access. The former option carries with it many risks. When a remote user connects their personal computer to the corporate network, they may have spyware, a virus, or any number or potentially damaging conditions present on their system. Due to the fact that you probably do not have any administrative access to their systems, you may have no way to secure the personal systems even if you wanted. This is why most companies require that only corporate resources be allowed to connect to the company network.

VPN Access: Hardware

One last consideration for VPN access is hardware selection. Normal workplace desktop applications place very little strain on even a remotely modern processor. The same is not true when it comes to VPN connections. A single VPN connection requires little overhead and rarely impacts the remote user’s system unless it is especially underpowered. For the VPN concentrator, however, it will handle the encryption and decryption of multiple connections, in addition to managing the volume of network data that will be accessed through it. For this reason, if you anticipate more than just a couple of VPN connections to be used simultaneously, you will want to test and evaluate your hardware needs.

Internal Links:

pfSense VPN: Part One

pfSense VPN: Part Two

pfSense VPN: Part Three (PPTP)

External Links:

An Overview of VPN Concentrators at YouTube (from CompTIA’s Network+ certification training)

How the VPN Concentrator Works at

© 2013 David Zientara. All rights reserved. Privacy Policy