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

SSH Server Configuration in pfSense

SSH

Enabling SSH access in pfSense 2.0.

For today’s article, I decided to cover something I probably should have covered earlier on: how to enable Secure Shell (SSH) login in pfSense 2.0. You may never have occasion to access your pfSense box remotely outside of the web GUI, but enabling the SSH server is still a good idea just in case you do.

Secure Shell (SSH) is a cryptographic network protocol for secure data communication, remote command-line login, remote command execution, and other secure network services between two networked computers that connects via a secure channel over an insecure network, a sever and a client. Typically SSH is used for access to shell accounts on Unixoid operating systems, but it can also be used in a similar fashion for accounts on Windows. It was designed as a replacement for Telnet and other insecure remote shell protocols such as the BSD rsh and rexec protocols, which send information – including passwords – in plain text, thus rendering them vulnerable to interception and disclosure. The encryption used by SSH is intended to provide confidentiality and integrity of data over an unsecured network.


Configuring the SSH Server

To enable the Secure Shell (SSH) service in pfSense, navigate to System -> Advanced, and scroll down to the section labeled “Secure Shell“. Check the “Enable Secure Shell” check box to enable SSH. You will be prompted for a username and password when you connect. You can use the same credentials that you use to connect to the web GUI. But if you check “Disable password login for Secure Shell“, you can use your RSA keys instead. At “SSH port“, leave the edit box blank to use the default port, or type in a different port to use a different one. If you are not going to allow SSH access to your pfSense box from the Internet, you can probably leave the default unchanged; otherwise, it is probably a good idea to choose a port a hacker is unlikely to guess, and even then, it is advisable to do any remote (i.e., from outside the network) administration through a VPN. Finally, press the “Save” button to save the changes and the pfSense SSH service will be started.

Using RSA Keys for SSH Login

SSH

PuTTYGen in action under Windows.

Using RSA keys is one way to secure client/server connections between the client and the SSH server. In order to utilize RSA keys, you must first generate a public-private key pair using a tool such as ssh-keygen on a Linux-based system or a Mac, or a tool such as PuTTYGen on a Windows-based system. To use ssh-keygen, simply open a terminal, run ssh-keygen, and save the key (you can also specify a pass code). To use PuTTYGen, open it and press the “Generate” button to generate a public/private key pair. You can enter a passphrase in the appropriate edit box, and press “Save private key” to save the private key. You can copy and paste the public key from the text box at the top of the application’s dialog box.

SSH

Pasting a public key in the pfSense User Manager.

Once you have a public/private key pair, you need to make sure that “Disable password login for Secure Shell” is checked in the Secure Shell settings at System -> Advanced. Then navigate to System -> User Manager, and click on the “e” next to the admin listing in the table to edit settings for the admin account. Scroll down to “Authorized keys” and check the “Click to paste an authorized key” check box. Now you can paste the public key into the text box. Press the “Save” button to save the changes.

Now, when you connect to pfSense using an SSH client, you will not be prompted for a password. Instead, your client must have the private key of the public/private key pair generated earlier in order to be authenticated.


External Links:

How to Enable SSH Access at doc.pfsense.org

The SSH lockout table at doc.pfsense.org

Forum posting on safely adding SSH users to pfSense at serverfault.com

© 2013 David Zientara. All rights reserved. Privacy Policy