Remote Access Options

remote accessSooner or later, odds are good that you will either want or need the ability to work remotely. Providing remote access must be undertaken very cautiously, because as soon as you allow an employee to connect to the corporate network, you have to some degree extended your network boundary to their workstation. This means your network’s security is now only as good as the security of the remote user’s system or network. In some cases, this borders on no security at all. This is why remote access must only be granted after careful consideration and planning. While the different types of remote access have different levels of security risk, all types of remote access have some common planning and configuration steps.

Remote Access: VPNs

The first step is to determine what type of remote access is appropriate. A virtual private network (VPN) extends a private network across a public network, such as the Internet. It enables a computer to send and receive data across shared or public networks as if it were directly connected to the private network, while benefiting from the functionality, security, and management policies of the private network. This generally provides the greatest level of functionality, but also poses the greatest risk. If the remote system is compromised, an attacker is effectively inside your corporate network. While there are steps you can take to mitigate these risks, they may be time-intensive and effort-intensive. To plan, configure and properly secure a VPN solution is the most involved choice of the various remote access solutions you could provide.

Remote Access: Remote Desktop Software

Another option is to provide remote desktop functionality. This would allow a remote user to see and use the desktop of a system at work. A remote desktop acts as if the user is at work, while a VPN acts as if the user’s computer is at work. This type of solution is slightly easier to implement, because you can typically isolate the traffic that needs to be permitted through the firewall to a single TCP port. Many of the same risks exist, however, in that if an attacker manages to gain access to an internal desktop remotely, it is usually easy for them to move information out of the network or otherwise cause mischief. Another key consideration with this type of solution is that you need to have a computer at home and a computer at work. With the VPN option, youonly need to use one system, so if the user has a laptop, it can be used while they work remotely. There are several options for remote desktop functionality: LogMeIn (which is no longer free), TeamViewer (free for home users), and Symantec’s PcAnywhere, to name but a few.


Remote Access: Remote Shell

The last and least functional option is that of a remote shell. Because most users do not operate extensively (or even at all) in a console environment, this type of remote access is generally most suitable for network administration personnel. While it may be impossible for typical users to operate their systems without a GUI, many network tasks and most firewall administration tasks can be permormed with only terminal access. Because the widely-used Telnet protocol sends all data unencrypted, any sensitive tasks should only be performed using a secured protocol such as secure shell (SSH), or Telnet over a Secure Internet Protocol (IPsec) tunnel.

External Links:

VPN at Wikipedia

netfilter Operation: Part Thirteen (Firewall Builder, continued)

Firewall Builder

Adding inbound and outbound rules for the web server in Firewall Builder.

In the last article, we discussed the process of setting up a firewall object in Firewall Builder and adding a network to it, as well as adding a web server to the network. This seems like a lot of additional effort; however, the real advantage of an object-oriented approach is seen when it comes time to configure the rules. With all of the appropriate objects in place, let’s define the rules to permit the inbound HTTP traffic.

  1. Create a new rule by either navigating to Rules -> Insert New Rule from the menu at the top of the window, or click on the large plus (+) beneath the top menu.
  2. Allow inbound HTTP to WEB1. Click on WEB1 in the object tree and drag it to the destination cell for rule 0.
  3. Now drag the HTTP and HTTPS service from the object pane to the Service cell in rule 0.
  4. Right-click the big red dot in the Action column and select Accept. This allows the inbound Web traffic to access WEB1.
  5. To allow outbound Internet access. create another rule by either navigating to Rules -> Insert New Rule or by clicking on the big plus (+) beneath the menu.
  6. Drag and drop HTTP and HTTPS from the object tree into the Service column of rule one.
  7. Drag the Network object INTERNAL from the object tree to the Source column of the new rule.
  8. Right-click on the Action column for rule 1 and change the action to ACCEPT.
  9. Although our rules seem simple at the moment, let’s apply them to see show things work. First, save your work by navigating to File -> Save or File -> Save As.
  10. Next, right-click the OFFICE01 Firewall and select Compile.
  11. When the “Select Firewalls for compilation” window comes up, OFFICE01 should be checked. When satisfied with your selection, click Next. When the compilation is complete you should see “Success” in the “Progress” column. After verifying that the compilation was successful, click Finish.


Compiling and Uploading the Firewall Rules

Firewall Builder

Compiling the firewall rules.

The next step is to tell Firewall Builder where to find the SSH executables, because this is how Firewall Builder uploads the configuration to the firewalls. You need to have SSH working on both the firewall and the Firewall Builder console, assuming they are on different systems.

  1. Select Edit -> Preferences from the menu.
  2. Select the Installer tab and click the Browse button.
  3. Navigate to the location of your desired SSH utility and click Open. Note that if you are using Windows for the Firewall Builder host, you cannot select PUTTY.EXE; you must use the command-line PuTTY program PLINK.EXE. In Linux, you can leave the default setting (ssh).
  4. After selecting the SSH executable, click OK.
  5. Right-click the OFFICE01 firewall in the object tree, and select Install.
  6. Select the firewalls you wish to install, and click Next.
  7. Enter the username and password for the SSH connection.
  8. All other fields are optional; however, it is recommended that you check “Store a copy of the fwb on the firewall.” When satisfied with your choices, click Ok.

After the upload completes, you will get a status of “Success”. Checking your firewall (iptables -L) shows you the new rules that are listed.

One point that should be made is that you have to be careful when configuring the rules. It is always a good idea to creat the rules to permit administrative access before any others. This is because as soon as you configure the default policies to DROP, your SSH connection will no longer be permitted unless you have it added to the access list. And if you forget to do this, you could find that you no longer have remote access to your firewall after applying the policy. If that happens, you won’t even be able to remotely connect to update the policy and change the ACLs.


External Links:

The official Firewall Builder site

Admin Access Options in pfSense

In this follow-up to a previous article on webConfigurator options, I will look at the other Admin Access options you can configure by navigating to System -> Advanced and clicking on the Admin Access tab.

Admin Access Options: Secure Shell

Admin

SSH and serial port options in advanced settings in pfSense 2.0.

Under the “Secure Shell” heading, the first check box, “Enable Secure Shell”, enables you to login to the admin console via SSH. A terminal emulator such as xterm, Konsole, (or Putty under Windows) can be used to login. The next check box, “Disable password login for Secure Shell (RSA/DSA key only)” allows you to login with a public/private key pair instead of a password. Describing in depth how to do this is beyond the scope of this article (I have provided more detailed instructions in my article on SSH server configuration), but there are three basic steps. First, you need to generate a public/private key pair using a utility such as ssh-keygen or PuTTYGen. Second, you need to check the “Disable password login for Secure Shell” check box and save the settings. Third, you need to navigate to System -> User Manager, edit the settings for the admin account, and paste the newly-generated public key into the text box that appears when the “Click to paste an authorized key” check box is checked and save the settings. Finally, “SSH Port” enables you to change the SSH port (leave it blank for the default of 22). Changing the SSH port is often a good idea, as it makes it less likely that the admin account will be hacked via SSH.


Admin Access Options: Serial Port Access

Under the Serial Terminal heading, check the “Serial Terminal” check box to enable console access via the first serial port with settings of 9600 baud/8 bits/no parity/1 stop bit. This will redirect the console output and messages to the serial port, but you can still access the console menu from the internal video card and keyboard. A null modem serial cable or adapter is required to use the serial cable. Finally, under the Console Options heading, checking the “Password protect the console menu” will cause the console to prompt the user for a password (changes to this option will take place after a reboot) before performing admin functions.


External Links:

How to Enable SSH Access at doc.pfsense.org

Secure Shell at 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