IPsec VPN Configuration in pfSense: Part One

IPsec VPN

Phase 1 IPsec configuration in pfSense 2.2.4.

In the previous article, we covered how to set up a PPTP VPN connection in pfSense, and how to connect to it in Mint Linux. Since PPTP relies on MS-CHAPv2, which has been compromised, we probably want to use another method if security is paramount. In this article, we will cover setting up an IPsec tunnel with pfSense and connecting to it with Mint Linux.

IPsec VPN Configuration: Phase 1

First we need to set up the IPsec tunnel in pfSense. Navigate to VPN -> IPsec and click on the plus button on on the lower right to add a new tunnel. Under General information, there is an entry for Interface, where we select the interface for the local endpoint of the tunnel. Since our end user will be connecting remotely, the local endpoint should be WAN. The next entry is Remote Gateway, where we enter the IP address or host name of the remote gateway. Enter a brief description and scroll down to the Phase 1 proposal (Authentication) section. At Pre-Shared Key, you need to enter a key (PSK), which will essentially be the tunnel’s password. Whether you alter the Phase 1 proposal (Algorithms) settings or not, take note of the settings, as we will need them for future reference. Press the save button at the bottom to save the Phase 1 configuration. On the next page, press the Apply changes button to commit changes.

IPsec VPN

Phase 2 IPsec configuration.

IPsec VPN Configuration: Phase 2

Now there should be a new entry in the IPsec table for the new Phase 1 configuration. Click on the big plus button underneath the entry you just created to initiate Phase 2 configuration. This section should expand, revealing an empty table for Phase 2 settings. Click on the (smaller) plus button to the right of the table to bring up the Phase 2 settings page. For Mode, you can select whichever method you prefer, but note that whoever connects will have to use the same method. For Local Network, enter the network or address to which you want to give the VPN user access (probably LAN net). For Remote Network, enter the address of the remote end of the VPN tunnel. Enter a brief description. In the Phase 2 proposal section (SA/Key Exchange), set the protocol and encryption options, again taking note of them for future reference (AES-256 is the commonly used standard). When you are done, press the Save button at the bottom of the page. Press the Apply changes button on the next page to commit changes. Finally, check the Enable IPsec check box on the main IPsec page and press the Save button.


Now that Phase 1 and Phase 2 configuration are complete, all that remains is to create a firewall rule for IPsec traffic. Navigate to Firewall -> Rules. There should be a new tab for IPsec; click on it. There may already be a rule there allowing traffic to pass to whatever network or address you specified in the Phase 2 configuration. If not, then create one now by pressing the one of the plus buttons on this page. Most of the default settings can be kept, but set Destination to the network or address specified in Local Network in the Phase 2 configuration. For Destination port range, specify any. Add a brief description, and press the Save button. On the next page, press the Apply changes button to commit these changes.

In part two of this article, we will cover connecting to the VPN tunnel from the remote node.

External Links:

IPsec on Wikipedia

pfSense IPsec configuration information from the official pfSense site

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

Man-in-the-Middle Attacks

man-in-the-middle attackMan-in-the-middle attacks are perhaps one of the more complex and sophisticated forms of security breaching approaches. As the name implies, such an attack involves the surreptitious placement of a software agent between the client and server ends of a communication. In this scenario, neither end of the communication is aware that the malicious agent is in the line of communication. For the most part, the man in the middle simply relays the data transmissions between client and server as though nothing is happening. What is generally happening in parallel with this process is that the agent is also recording the data as it is passed through. A man-in-the-middle attack can succeed only when the attacker can impersonate each endpoint to the satisfaction of the other. Such an attack results in a third party gaining access to a variety of different types of data, from login and password credentials to proprietary and confidential information. In addition, it is possible for the man-in-the-middle agent to modify data, causing unsold problems for the victim.

Man-in-the-middle attacks have increased considerably since the introduction of wireless networking. As a result, there is no need for the hacker to connect to a wire. Instead, the data can simply be intercepted from anywhere within range of the wireless signal.


Preventing Man-in-the-Middle Attacks

In order to prevent MITM attacks, some form of endpoint authentication is helpful. Just using public key encryption is not enough to prevent such an attack. As an example, suppose A and B are trying to communicate, and C is trying to intercept said communications. If B sends A his public key and C intercepts it, he can replace B’s public key with his own and send it to A. If A then encrypts a message with C’s public key (believing it to be B’s public key), then when it is sent, C can intercept and read it, decrypting it with his private key. He can also re-encrypt the message using C’s public key and send it to C.

Thus, any private-public key system requires some means of ensuring that a MITM attack does not compromise its integrity. One possible method is public key infrastructures (PKI). The main defense in a mutual authentication. In this case, as well as the application validating the user, the user’s devices validate the application – hence distinguishing rogue applications from genuine applications. Another possibility is a recorded media attestment, which can be either a verbal communication of a shared value for each session, or an audio/visual communication of the public key hash. In addition, stronger mutual authentication, such as secret keys and passwords often helps thwart man-in-the-middle attacks.

Latency examination may be a useful means of detecting man-in-the-middle attacks. For example, if each party performs a long cryptographic hash function calculation that takes 20 seconds normally, and the calculation takes 60 seconds to reach each party, this can indicate a third party.

The integrity of public keys must generally be assured in some manner, but need not be secret. Passwords and shared secret keys have the additional secrecy requirement. Public keys can be verified by a certificate authority whose public key is distributed through a secure channel. Public keys can also be verified by a web of trust that distributes public keys through a secure channel.

Quantum cryptography protocols, which use quantum communication and quantum communication to perform cryptographic tasks, can be used to thwart man-in-the-middle attacks. One method quantum cryptography employs is quantum key distribution (QKD), which establishes a shared key between two parties. If a third party tries to eavesdrop and learn these bits, the messages will be disturbed and the original two parties will notice. The key is then typically used for encrypted communication.


External Links:

Man-in-the-middle attack on Wikipedia

Hash Functions

Hash functionIntroduction to Hash Functions

Hashing is a technique in which an algorithm (also called a hash function) is applied to a portion of data to create a unique digital “fingerprint” that is a fixed-size variable. If anyone changes the data by so much as one binary digit, the hash function will produce a different output (called the hash value or a message digest) and the recipient will know that the data has been changed. Hashing can ensure integrity and provide authentication. The hash function cannot be reverse-engineered: in other words, you cannot use the hash value to discover the original data that was hashed. Thus, hashing algorithms are referred to as one-way hashes. A good hash function will not not return the same result from two different inputs (returning the same result from two different inputs is known as a collision). The collision domain of the function should be large enough to make it extremely unlikely to have a collision. All of the encryption algorithms studied so far, both symmetric and asymmetric, are reversible. However, there is no reversible function for hashing algorithms, so original material cannot be recovered. For this reason, hashing algorithms are commonly referred to as one-way hashing functions. Irreversible encryption techniques, however, are useful for determining data integrity and authentication. It is easy to generate hash values from input data and easy to verify that the data matches the hash, but hard to fake a hash value to hide malicious data. This is the principle behind the Pretty Good Privacy algorithm for data validation.


Sometimes it is not necessary or even desirable to encrypt a complete set of data. Suppose someone wants to transmit a large amount of data, such as a CD image. If the data on the CD is not sensitive, they may not care that it is openly transmitted, but when the transfer is complete, they want to make sure the image you have is identical to the original image. The easiest way to make this comparison is to calculate a hash value on both images and compare results. If there is a discrepancy of even a single bit, the hash value of each will be radically different. Provided they are using a suitable hashing function, no two inputs will result in an identical output, or collision. The hashes created, usually referred to as digital fingerprints, are usually of a small, easily readable fixed size. Sometimes these hashes are referred to as secure checksums, because they perform similar functions as normal checksums, but are inherently more resistant to tampering.

Encrypted passwords are often stored as hashes. When a password is set for a system, it is generally passed through a hashing function and only the encrypted hash is stored. When a person later attempts to authenticate, the password is hashed and that hash is compared to the stored hash. If these are the same, they are authenticated, otherwise access is rejected. In theory, if someone were to obtain a password list for a system, it would be useless, since by definition it is impossible to recover the original information from its hashed value. However, attackers can use dictionary and brute-force attacks by methodically comparing the output hash of a known input string to the stolen hash. If they match, the password has been cracked. Thus, proper password length and selection are crucial.

There are several different types of hashing, including division-remainder, digit rearrangement, folding, and radix transformation. These classifications refer to the mathematical process used to obtain the hash value. Here are two popular hashing algorithms:

  • Message Digest 4/Message Digest 5 (MD4/MD5): The message digest (MD) class of algorithms were developed by Ron Rivest for use with digital signatures. They both have a fixed 128-bit hash length, but the MD4 algorithm is flawed and the MD5 hash has been adopted as its replacement. However, the security of the MD5 hash function has been severely compromised, and a collision attack exists that can find collisions within seconds on a computer with a 2.6 GHz Pentium 4 processor. MD6 was introduced in 2008 and is designed to take advantage of the full potential of future hardware processors with tens and thousands of cores instead of the conventional uni-core systems.
  • Secure Hash Algorithm (SHA): This hashing algorithm was created by the U.S. government (NIST and the National Security Agency [NSA]) and operates similarly to the MD algorithms. The most common is SHA-1, which is typically used in IPsec installations, and has a fixed hash length of 160 bits. SHA-2 has a fixed hash length of up to 512 bits and has a word size of 64 bits, as does SHA-3.


External Links:

Cryptographic hash function at Wikipedia

El Gamal and RSA Algorithms

El Gamal

In the previous article, we discussed the Diffie-Hellman algorithm. In this article, we will cover two more asymmetric encryption algorithms, El Gamal and RSA.

El Gamal Algorithm

The El Gamal algorithm is essentially an updated and extended version of the original Diffie-Hellman algorithm based on discrete logarithms. The security of the algorithm is roughly on par with that of the Rivest-Shamir-Adleman (RSA) algorithm. El Gamal has a few drawbacks, mainly its larger output and random input requirement. Encrypted El Gamal ciphertext is much longer than the original plaintext input, so it should not be used in places where bandwidth is a limiting factor, such as over slow wide area network (WAN) links. The El Gamal algorithm also requires a suitable source of randomness to function properly. It is worth noting that the Digital Signature Algorithm (DSA) was based on the El Gamal algorithm. DSA is a complementary protocol to RSA that is widely used in the OpenSSH implementation of the Secure Shell (SSH) protocol.

RSA Algorithm

Shortly after the appearance of the Diffie-Hellman algorithm, Ron Rivest, Adi Shamir and Leonard Adleman proposed another public key encryption system. Their proposal is now known as the RSA algorithm, named for the last initials of the researchers.


The RSA algorithm shares many similarities with the Diffie-Hellman algorithm in that RSA is also based on multiplying and factoring large integers. However, RSA is significantly faster than Diffie-Hellman, leading to a split in the asymmetric cryptography field that refers to Diffie-Hellman and similar algorithms as Public Key Distribution System (PKDS), and RSA and similar algorithm as Public Key Encryption (PKE). PRDS systems are used as session-key exchange mechanisms, while PKE systems are considered fast enough to encrypt small messages. However, PKE systems like RSA are not considered fast enough to encrypt large amounts of data such as entire file systems or high-speed communications lines.

RSA involves a public key and a private key. The public key can be known by everyone and is used for encrypting messages. Messages encrypted with the public key can only be decrypted in a reasonable amount of time using the private key. The keys for the RSA algorithm are generated the following way:

  1. Choose two distinct prime numbers p and q: For security purposes, the integers p and q should be chosen at random and should be of similar bit-length.
  2. Compute n = pq: n is used as the modulus for both the public and private keys; its length is the key length.
  3. Compute φ(n) = φ(p)φ(q) = (p-1)(q-1), where φ is Euler’s totient function.
  4. Choose an integer e such that 1 < e < φ(n) and gcd(e, φ(n)) = 1; i.e. e and φ(n) are coprime.
  5. Determine d and d^-1 ≡ e(mod φ(n)), i.e., d is the multiplicative inverse of e (modulo φ(n)).

The public key consists of the modulus n and the public (or encryption) exponent e. The private key consists of the modulus n and the private (or decryption exponent d, which must be kept secret. p, q and φ(n) must also be kept secret because they can be used to calculate d.


External Links:

ElGamal encryption on Wikipedia

RSA on Wikipedia

Cryptography: An Introduction

CryptographyIn previous blog postings, I have discussed how the open source community has created powerful packet sniffing tools, and how they can be used either to administer your network or to attack it. Because these sniffing tools are open source, and because it is relatively easy to place a Linux host on your company network, you need to consider ways to minimize improper use of packet capturing tools. Encryption solutions, such as Secure Shell (SSH) and Kerberos, are two common solutions to this problem.

Algorithms are the underlying foundation of cryptography. Thus, we will look at the basics of algorithms first, starting with symmetric and asymmetric encryption.

Cryptography Defined

Cryptography predates the computer era; as long as people have been writing down information, there has been a need to keep some information secret, either by hiding its existence or changing its meaning. Encryption, a type of cryptography, refers to the process of scrambling information so that the casual observer cannot read it. An algorithm is a set of instructions for mixing and rearranging an original message (called plaintext), with a message key to create a scrambled message, referred to as ciphertext. Similarly, a cryptographic key is a piece of data used to encrypt plaintext to ciphertext, and ciphertext to plaintext, or both, depending on the type of encryption.


The word crypto has its origins in the Greek word kruptos, which means hidden. The objective of cryptography is to hide information so that only the intended recipients can read it. In crypto terms, the hiding of information is called encryption, and when information becomes readable, it is called decryption. A cipher is used to accomplish the encryption and decryption. The information that is being hidden is called plaintext; once it has been encrypted, it is called ciphertext. The ciphertext is transported to the intended recipient or recipients, where it is decrypted back into plaintext.

Finally, there are two different subclasses of algorithms: block ciphers and stream ciphers. Block ciphers work on blocks or chunks of text in a series. In contrast a stream cipher operates on each individual unit, either letters or bits, of a message.

There are many different encryption algorithms, and in each case, there are tradeoffs between security, speed, and ease of implementation. Here, security indicates the likelihood of an algorithm to stand up to current and future attacks, speed refers to the processing prower and time required to stand up to current and future attacks, speed refers to the processing power and time required to encrypt and decrypt a message, and ease of implementation refers to an algorithm’s predisposition (if any) to hardware or software usage. Each algorithm has different strengths and drawbacks and none of them are ideal in every way. The key algorithms fall into three main categories:

  • Symmetric cryptography
  • Asymmetric cryptography
  • Hashing algorithms

In the next few articles, we will review each of these categories.


External Links:

Cryptography at Wikipedia

Cryptography I – enroll in a free 6-week course in cryptography at coursera.org

pfSense Backup and Restore

Backing up your pfSense configuration files is a crucial task, both in order to restore the configuration after a system failure and to recover data from an earlier time. Fortunately, pfSense makes the process easy. pfSense backup configuration files are stored in a plain text XML format by default, but it also gives the user an option to encrypt them.

pfSense Backup in a Few Easy Steps

pfSense Backup

Backup configuration options in pfSense 2.0.

To backup the configuration files, first navigate to Diagnostics -> Backup/restore and from there, select the Backup/Restore tab. At “Backup area“, you will see a drop-down box showing all the configuration areas you can back up. Leave it as “ALL” to backup all files. Leave “Do not backup package information” unchecked if you do not want to backup package information. The next check box is “Encrypt the configuration file“; check this if you want to encrypt the backup (you will have to enter the password twice in the edit boxes below if this is selected). Leave “Do not back up RRD checked” unless you want to backup the round robin database (it can be over 4 MB in size). Press the “Download configuration” button and save the file to a safe location. Your pfSense backup is now complete.


Now, the configuration info will be stored in a single XML file. Some passwords, however, will be stored in plain text. If this is a problem, you can always encrypt the file with the “Encrypt this configuration file” option.

Automating Your pfSense Backup

You’re probably wondering if the backup process can be automated. As it happens, there is a package called “AutoConfigBackup” that enables you to automate backups, but it is only available for paying pfSense customers with a Premium support contract. However, Koen Zomers has created his own command line backup automation tool for Windows, which is quite easy to use (remember to use the -v 2.0 option when backing up a pfSense 2.0 configuration file). You can use this in conjunction with the AT command to fully automate the process. For example:

at 20:00 /every:M,T,W,Th,F,S,Su pfSenseBackup.exe -u admin -p password -s 192.168.1.1 -o c:\backup.xml -v 2.0

will backup the config file of the pfSense router at 192.168.1.1 to the C drive at 8:00 PM every day.

If you don’t use Windows or don’t want to use this utility, you can still automatically make a backup. When a change is made in pfSense, a backup of the configuration file is stored in /cf/conf/backup. You could create a script to run as a cron job on the pfSense system to copy this file to a remote system, or you could run a script on the remote system which could download the files.


Restoring from a Backup

You can also restore pfSense’s configuration from a backup. From the same tab under “Restore Configuration“, choose a restore area from the dropdown box, click on the “Choose” button to launch the file dialog box and select a backup configuration file. Press the “Open” button to close out the file dialog box. Click the “Configuration file is encrypted” check box if the file is encrypted (you will have to specify a password), and press the “Restore configuration” button. pfSense will reboot after “Restore configuration” is pressed.

External Links:

Configuration Backup and Restore at doc.pfsense.org

How to automate pfSense backup, where you can download Koen Zomer’s pfSense backup tool.

Remote Config pfSense Backup at doc.pfsense.org – information on how to use the Auto Config Backup package, but you need a paid subscription to use it.

How to Backup and Restore Configurations in pfSense 2.0

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:

PPTP VPN at doc.pfsense.org

 

© 2013 David Zientara. All rights reserved. Privacy Policy