Andrew Roderos

Hardening EdgeRouter Lite – Part 1

12/03/2016 By Andrew Roderos 6 Comments

This blog post is part of a series on EdgeRouter Lite. You may want to check them all out!

Date	Title	Description
03/13/16	My Home Router – EdgeRouter Lite	Quick introduction to EdgeRouter Lite
04/09/16	Ubiquiti’s EdgeOS CLI Introduction	EdgeOS CLI Primer
05/01/16	How to configure EdgeRouter Lite via CLI – Part 1	EdgeOS configuration guide for CLI junkies
05/01/16	How to configure EdgeRouter Lite via CLI – Part 2	EdgeOS configuration guide for CLI junkies
12/04/16	Hardening EdgeRouter Lite – Part 2	EdgeOS with two-factor authentication
12/05/16	Hardening EdgeRouter Lite – Part 3	Management ACL
12/06/16	Hardening EdgeRouter Lite – Part 4	Remote Access VPN with two-factor authentication

Introduction

It has been a while since I talked about my EdgeRouter Lite. Since then, my configuration has changed. I will be discussing some of the configuration changes in this series of blog posts.

As the title implies, I will cover the process of hardening EdgeRouter Lite to address the security concerns one might have with my two-part blog post. This, by no means, is complete or the most secure configuration so feel free to drop me a line with your suggestions.

Note: This post is based on firmware version 1.9.

Web UI

The HTTPS service listens, by default, to all addresses assigned to router’s interfaces. We can improve security by restricting web management traffic to a single address.

set service gui listen-address 192.168.200.1

Alternatively, I could disable the service if I have no use for it.

delete service gui

One of the things I noticed in EdgeOS is that it listens to port 80 and 443. However, users that try to hit the router via HTTP will be redirected to HTTPS. The show service gui command won’t list it but when you issue show configuration commands | match “service gui” then it will show up. This behavior is OK in my opinion since it switches to secure HTTP. Though, there might be some people who will find this unacceptable. If you are one of them, the delete service gui http-port 80 command will disable this. Alternatively, one can just use the firewall to block it. I will cover the firewall configuration in future blog posts.

SSH Service

In my how to configure EdgeRouter Lite part one guide, my SSH service section has two config lines. While it touches a bit about security, I didn’t really touch on securing the service further. By default, the router’s SSH server will listen to any addresses assigned to an interface, just like the Web UI. In this section, we will instruct EdgeOS to only listen to a specific IP address.

set service ssh listen-address 192.168.200.1

Public-Key Authentication

One of the mitigation techniques for SSH brute force attack is by using SSH key authentication method. In order to do this, we will need to generate SSH keys on the client(s), load the public key on EdgeRouter, and disable password authentication.

Generating SSH keys

In this post, the host that I used to generate keys runs on Ubuntu Server 16.04.1. Generating keys on macOS and other Linux distro might be the same command. If you’re a Windows user, please research on how to generate keys using PuTTY Generator.

username@ubuntu01:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa): <just hit enter>
Enter passphrase (empty for no passphrase): <enter passphrase here>
Enter same passphrase again: <enter passphrase here>
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:a-bunch-of-characters-are-displayed-here username@ubuntu01
The key's randomart image is:
+---[RSA 2048]----+
|                 |
|                 |
|     random      |
|   characters    |
|      are        |
|    displayed    |
|      here       |
|                 |
|                 |
+----[SHA256]-----+

Copying SSH key

There are two methods, that I know of, on how to copy the public key that we generated to the EdgeRouter. I will only cover two of them.

Method 1

This method is the easiest out of the two. This method will only work if password authentication is still enabled. If not, then you will have to use the second method.

username@ubuntu01:~$ ssh-copy-id username@ubnt.domain.local
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/username/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
********************************************************************
*************       THIS IS MY UBIQUITI EDGEROUTER     *************
*************           YOU SHALL NOT PASS!!!          *************
********************************************************************
username@ubnt.domain.local's password:
Number of key(s) added: 1
Now try logging into the machine, with:   "ssh 'username@ubnt.domain.local'" and check to make sure that only the key(s) you wanted were added.

The public key is now copied and we are now ready to load the key. Skip the method 2 section and go to the next.

Method 2

This method is a bit more involved than the first one. The second part of this method is applicable to Windows users. It’s just a matter of copying the public key to clipboard and saving it to a file in EdgeRouter. This will be the method you’ll use going forward when you disable password authentication and need to add more public keys. Alternatively, you can enable password authentication temporarily and use the first method to add more public keys. Don’t forget to disable password authentication.

The first step is to view the public key from the host.

username@ubuntu01:~$ more ~/.ssh/id_rsa.pub
ssh-rsa a-bunch-of-characters-are-displayed-here-and-is-very-long username@ubuntu01

The next step is to copy everything. Note: It may show up as multiple lines on your screen. Make sure to paste it as a single line to a file in EdgeRouter.

sudo vi ~/.ssh/authorized_keys
ssh-rsa a-bunch-of-characters-are-displayed-here-and-is-very-long username@ubuntu01

If you are not familiar with VI/VIM editor, then use this.

bash
echo ssh-rsa a-bunch-of-characters-are-displayed-here-and-is-very-long username@ubuntu01 >> ~/.ssh/authorized_keys
exit

Loading SSH key

The next step is to load the public key to the configuration. The command covered here instructs the router to load the public key from the Linux environment to EdgeOS. This ensures that the keys will survive a reboot and/or firmware upgrade since configurations will be saved in /config directory.

loadkey username ~/.ssh/authorized_keys

We’ll delete the authorized_keys file since it is no longer needed.

sudo rm ~/.ssh/authorized_keys

Disable Password Authentication

The last step in enabling public key authentication is to disable password authentication. Right now, users are still able to log into the EdgeRouter using password. To disable this behavior, we’ll need to configure SSH daemon to only allow public key authentication.

set service ssh disable-password-authentication

For this to take effect, we’ll need to commit the changes and save the config to the config.boot file. The command below will cause SSH daemon (sshd) to restart.

commit; save

Verification

Now, we’re ready to test our EdgeRouter configuration.

Host with public key

Here’s my Ubuntu host with public key connecting to EdgeRouter Lite.

username@ubuntu01:~$ ssh username@ubnt.domain.local
********************************************************************
*************       THIS IS MY UBIQUITI EDGEROUTER     *************
*************           YOU SHALL NOT PASS!!!          *************
********************************************************************
Enter passphrase for key '/home/username/.ssh/id_rsa': <enter passphrase>
Linux ubnt 3.10.20-UBNT #1 SMP Fri Jul 29 16:51:50 PDT 2016 mips64
Welcome to EdgeOS
Last login: Fri Nov 25 10:09:27 2016 from 192.168.254.100

Depending on your host’s OS, the behavior may be different. My host likes to ask for the private key passphrase every time I try to connect to EdgeRouter Lite. This requirement of passphrase could serve as an additional layer of security. Though, this depends if the user is using a unique and secure passphrase. To modify this behavior, I had to add the identity to the key manager so I don’t have to keep typing every single time. I will leave it to your discretion if you want to do the same thing.

Installing key manager

Install keychain package as the key manager.

username@ubuntu01:~$ sudo apt-get install keychain -y

Edit the .bashrc file and add the following.

username@ubuntu01:~$ vi .bashrc
keychain id_rsa id_dsa
. ~/.keychain/`uname -n`-sh

If you are not familiar with VI/VIM, follow the commands below.

username@ubuntu01:~$ sed -i '$ a keychain id_rsa id_dsa' .bashrc
username@ubuntu01:~$ sed -i '$ a . ~/.keychain/`uname -n`-sh' .bashrc

For the change to take effect, enter the command below.

username@ubuntu01:~$ . .bashrc
 * keychain 2.8.1 ~ http://www.funtoo.org
 * Found existing ssh-agent: 2888
 * Warning: can't find id_dsa; skipping
 * Adding 1 ssh key(s): /home/username/.ssh/id_rsa
Enter passphrase for /home/username/.ssh/id_rsa: <enter passphrase>
 * ssh-add: Identities added: /home/username/.ssh/id_rsa

Now, my host is no longer asking for passphrase every time I try to connect to my EdgeRouter. Though, this will not survive a reboot. It will prompt me again to enter the passphrase when the host reboots. This is better than entering the passphrase every time, though!

username@ubuntu01:~$ ssh username@ubnt.domain.local
********************************************************************
*************       THIS IS MY UBIQUITI EDGEROUTER     *************
*************           YOU SHALL NOT PASS!!!          *************
********************************************************************
Linux ubnt 3.10.20-UBNT #1 SMP Fri Jul 29 16:51:50 PDT 2016 mips64
Welcome to EdgeOS
Last login: Fri Nov 25 12:35:33 2016 from 192.168.254.100

Host with no public key

Clients that do not have public keys saved in the EdgeRouter will no longer be able to connect.

username@ubuntu02:~$ ssh username@ubnt.domain.local
********************************************************************
*************       THIS IS MY UBIQUITI EDGEROUTER     *************
*************           YOU SHALL NOT PASS!!!          *************
********************************************************************
Permission denied (publickey).

Final Words

This post addresses some of the security concerns with my two-part blog post on how to configure EdgeRouter Lite. While there were few security bits here and there in the series, this post increases security by hardening the management plane. There will be more things we can do to enhance management security but will be covered in the future. The next post will give users an alternative to SSH public-key authentication.

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

References

Ubuntu Community QuickTips
Ubiquiti Community – SSH authorized_keys

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

Adding Two-Factor Authentication to FreeRADIUS

10/21/2016 By Andrew Roderos 16 Comments

In my previous post, I talked about enabling two-factor authentication (2FA) for my public facing Linux host. In today’s post, I will talk about integrating Google Authenticator PAM to FreeRADIUS. As a result, any hosts that are pointed to my RADIUS server will have the 2FA functionality.

Update: Migrated FreeRADIUS with Google Authenticator to a Docker container
Update: FreeRADIUS 3.0 with Two-Factor Authentication (2FA)

Installing FreeRADIUS and Google Authenticator PAM

While there are several RADIUS software out there, FreeRADIUS is one of the most popular RADIUS software of choice in Linux. Since it has PAM library, this is also perfect for integrating it with Google Authenticator PAM. If you want to know more about FreeRADIUS, you might want to check this book out. I have not read it so read through the reviews to see if that will work for your needs.

Installing FreeRADIUS and Google Authenticator on Ubuntu 16.04 is very easy. All we need is to issue one line command. I added NTP package here since my Google Authenticator configuration is TOTP based. If one went through the Ubuntu installation properly, there might not be a need for this so long as the system is syncing to the time correctly.

$ sudo apt-get install freeradius libpam-google-authenticator -y

Configuring FreeRADIUS

After the package installation, the next step is to set up FreeRADIUS by editing configuration files. There are four config files we need to edit to complete this setup. By no means, one needs to follow the order.

First config file

The first config file that we need to edit is the /etc/freeradius/radiusd.conf file. There are two ways in configuring this and it seems that the most popular option is the one with FreeRADIUS running as root. For some people, this is not acceptable so I included instructions below where we’ll leave it as the default configuration.

Option 1 – Run as root

According to my limited research, the need to change the user and group to root is because of how both FreeRADIUS and Google Authenticator PAM works. My observation seems to indicate that FreeRADIUS will also need to access the secret key (.google_authenticator) in each user’s home directory – I could be totally wrong with this. My Linux boxes have encrypted home directories so only the owner and root can access these. That said, letting FreeRADIUS run as root will have access to the necessary files.

$ sudo vi /etc/freeradius/radiusd.conf

We’ll now need to find the lines user = and group =. The default configuration is set to freerad. Change both of them to root.

user = root
group = root

Option 2 – Use default configuration

As mentioned, we can just leave the file as default. I will explain more about this once we get to the section where we need to edit the /etc/pam.d/radiusd file.

Second config file

The the next config file that we need to edit is the /etc/freeradius/users file. This file will instruct FreeRADIUS to use PAM libraries to authenticate users as the default.

$ sudo vi /etc/freeradius/users

Add the lines found below. ~~I usually like to add lines at the end of the file.~~ Add the line after all the commented text of the file, just before the DEFAULT Framed Protocol == PPP line. This will ensure that this line will take precedence. I found out the hard way when I was troubleshooting an issue with L2TP over IPsec authentication.

# Instruct FreeRADIUS to use PAM to authenticate users
DEFAULT Auth-Type := PAM

Third config file

The second to the last config file on our list to be edited is the /etc/freeradius/sites-enabled/default file. This file tells FreeRADIUS to enable PAM authentication. We just need to edit one line here.

$ sudo vi /etc/freeradius/sites-enabled/default

Once the file is open, look for the following lines:

        #  Pluggable Authentication Modules.
#        pam

We now need to uncomment the pam line to enable it. It should look like this now:

        #  Pluggable Authentication Modules.
        pam

Fourth config file

Finally, the last FreeRADIUS config file that we need to change is the /etc/freeradius/clients.conf. This is where we can set up our secret key that is used by the clients to connect to the RADIUS server. Please change the default secret key to random alphanumeric characters. Use a key generator to generate the secret to make things life a little easier. For demo purposes, I will be using the default secret. To change the secret, look for secret = testing123 line.

$ sudo vi /etc/freeradius/clients.conf
<-- Output omitted for brevity -->
secret          = my_super_awesome_strong_secret
client rtr {
	ipaddr = 192.168.200.1
	secret = my_super_awesome_strong_secret 
}

As usual in Linux, when a configuration file has been changed, then the service needs to be restarted for the changes to take effect. To restart FreeRADIUS daemon, issue the sudo service freeradius restart command.

Configuring FreeRADIUS PAM

Since we instructed FreeRADIUS to use PAM to authenticate users, we need to configure the /etc/pam.d/radiusd file and instruct it to integrate Google Authenticator PAM. By default, the file will look something like this:

<-- Output omitted for brevity -->
@include common-auth
@include common-account
@include common-password
@include common-session

Option 1

If you picked the first option in the FreeRADIUS configuration section, then you need to comment those four lines above and add two lines. The file should look like this:

#@include common-auth
#@include common-account
#@include common-password
#@include common-session
auth requisite pam_google_authenticator.so forward_pass
auth required pam_unix.so use_first_pass

Option 2

If you left the /etc/freeradius/radiusd.conf file alone, then it becomes a little bit more complicated setup. Also, you will notice that my instructions are what I will consider a workaround to AppArmor (I am guessing this is the real issue). You will see why later in the next section, after the generating Google Authenticator secret key. Anyway, the /etc/pam.d/radiusd file should look like this:

#@include common-auth
#@include common-account
#@include common-password
#@include common-session
auth requisite pam_google_authenticator.so forward_pass secret=/etc/freeradius/${USER}/.google_authenticator user=freerad
auth required pam_unix.so use_first_pass

Google Authenticator Secret Key

I’ve already covered the generation of the secret key in my previous post, so look for the generating Google Authenticator secret key section. Once you are done generating secret keys, come back to this page. If you picked the first option throughout this tutorial, then skip this section and go to the verification section.

If you picked the second option, then we’ll need to do additional steps to make this work. Again, you do not have to follow the order in which they are listed here.

We first need to create a directory equal to the user account that we’re working on. In this scenario, we’ll use user account named test.

$ sudo mkdir /etc/freeradius/test

Then, we need to change the owner of the directory that we just created.

$ sudo chown freerad:freerad /etc/freeradius/test

The second to the last step is to copy the secret key to the directory that we just created.

$ sudo cp .google_authenticator /etc/freeradius/test/.google_authenticator

Finally, we need to change the owner of the file.

$ sudo chown freerad:freerad /etc/freeradius/test/.google_authenticator

If I ever learn more about AppArmor, then I will update this blog post because I think this is the real issue why it’s failing. I did try creating an AppArmor profile, but testing shows that I was still failing. When I looked at the /var/log/auth.log file, I saw an error message that looked like this:

Oct 10 21:24:53 radius radiusd(pam_google_authenticator)[18433]: Failed to update secret file "/etc/freeradius/test/.google_authenticator"

Verification

We now need to test to make sure that we can successfully authenticate. FreeRADIUS software package includes a simple tool that we can use to directly query the daemon with requests. The command format is radtest test <password+google authenticator token> localhost 18120 <RADIUS secret key>. The password and Google Authenticator token should not have space in between. Below shows the syntax that I used to test my configuration and the test result.

$ radtest test testing1234803732 localhost 18120 testing123
Sending Access-Request of id 79 to 127.0.0.1 port 1812
	User-Name = "test"
	User-Password = "testing1234803732"
	NAS-IP-Address = 127.0.1.1
	NAS-Port = 18120
	Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=79, length=20

Final Words

I’d like to speculate that a lot of people would pick the first option since the second option involves a lot more steps. Also, this isn’t a scalable solution so I think it will turn off quite a number of people. Imagine doing the steps above for multiple accounts. It’s going to be a lot of administrative work. For my purpose, this is a perfectly acceptable solution because I only have one account in my RADIUS server. It is probably an overkill to be creating a FreeRADIUS server instance for home use, but some may argue that nothing is overkill in security. The more secure you are, the better.

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

You might also like to read

FreeRADIUS 3.0 with Two-Factor Authentication
Securing SSH with Google Authenticator
Migrated FreeRADIUS with Google Authenticator to a Docker container
Adding Two-Factor Authentication to TACACS+

References

Integrating Google Authenticator PAM module with FreeRADIUS Server
Freeradius and Google Authenticator
GitHub Google Authenticator

Disclosure

Securing SSH with Google Authenticator

10/10/2016 By Andrew Roderos 2 Comments

In my old blog post, I talked about how to mitigate from persistent SSH brute force attack. While there are several options in mitigating SSH brute force attack, I opted to use the Fail2Ban option at the time. Today, I’ve decided to add another security layer to the host since this is a public facing server. This addition of security layer is based on defense in depth, which is an information assurance concept. As the title says, I will be using Google Authenticator to generate a time-based one-time password (TOTP) for two-step verification.

It seems like two-factor authentication (2FA) is becoming a norm these days. More and more security professionals are pushing organizations to use 2FA for every sensitive systems and application. Understandably so, because the consensus is that password is no longer enough to protect accounts in this day and age. As a result, I’ve also decided to start implementing 2FA in my home devices.

Installing Google Authenticator PAM

Ubuntu has been my distro of choice for several years now, so all of my Linux-related tutorials have been on that. I will keep that going, mostly because I do not have time to learn another distro, like CentOS.

Installing Google Authenticator on Ubuntu 16.04 is a piece of cake. All you need is one command.

$ sudo apt-get install libpam-google-authenticator -y

Configuring SSH PAM

The Google Authenticator 2FA is accomplished by integrating into Linux’s Pluggable Authentication Modules (PAM) library. PAM is a way for programs to use an underlying authentication mechanism. With that said, we’ll need to configure PAM configuration to pass it to Google Authenticator. To do this, we need to edit the PAM configuration file for SSH.

$ sudo vi /etc/pam.d/sshd

At the bottom of the file, I added the following lines below. The first line is optional, but it’s always best to add comment lines in my opinion.

# Enable MFA using Google Authenticator PAM
auth required pam_google_authenticator.so nullok

If you want to understand the syntax, please check this site. Though, the article did not include what nullok argument means. The argument simply means that if a user hasn’t created secret key yet, then they’re still allowed to log in. My recommendation is to enable 2FA for all users so make sure to have all the users generate the secret key. Once all secret keys are generated, take out the nullok argument.

Configuring OpenSSH Daemon

The next step is to actually configure SSH to check for backend system (e.g. PAM) to use the challenge-response authentication method. To do this, we need to edit the OpenSSH configuration file.

$ sudo vi /etc/ssh/sshd_config

Once the file is open, look for the line with ChallengeResponseAuthentication no and change it to yes. Save the file and exit.

ChallengeResponseAuthentication yes

In Linux, changes to Linux configuration files require a service restart to take effect, for the most part. With that said, we need to restart SSH daemon (sshd). To restart SSH service, issue sudo service ssh restart command. Once sshd is back up, test to make sure that user can still log in without two-step verification.

Generating Google Authenticator Secret Key

The last step to make SSH 2FA work is to generate a secret key for the two-step verification. In this example, I created a test user account for demo purposes.

Use the Google Authenticator app on your mobile device and add the QR code.

Account with Google Authenticator secret key

In this example, SSH daemon is asking the user to enter Google Authenticator OTP.

$ ssh test@radius
Password: testing1234
Verification code: 664449
<-- Output omitted for brevity -->
test@radius:~$

Account with no Google Authenticator secret key

Here the admin account does not have the Google Authenticator secret key yet. If one forgets to add the nullok argument, then the system will not allow user accounts without the secret key.

$ ssh admin@radius
Password:
<-- Output omitted for brevity -->
admin@radius:~$

Optional Configuration

It is probably a good idea to enable 2FA to the local login (console) too. So this way, anyone who has access to the physical machine will be subjected to two-step verification. To do this, we need to edit the login configuration file.

$ sudo vi /etc/pam.d/login

Once the file is open, add the lines below at the end of the file. Save the file and exit out.

# Enable MFA using Google Authenticator PAM
auth required pam_google_authenticator.so nullok

From now on, all user accounts with Google Authenticator secret key will need to enter a verification code.

Thoughts

Balancing security and convenience is one of the biggest dilemmas that information security professionals face. In a nutshell, making it convenient for users to access their account means it is less secure. In a perfect world (no bad guys) people would probably pick one password across all of their accounts. Since we’re not living in a perfect world, this leaves the accounts to be very insecure. If one account is compromised, then all of the other accounts could potentially be accessed by the bad guys.

The use of complex passwords and password managers are good first steps toward securing accounts. However, in today’s world, some of the information security professionals view password alone as an antiquated technique in securing accounts. As a result, a lot of online services have had multi-factor authentication feature. However, companies that provide these online services do not force accounts to use it. As a result, accounts are still at risk by relying on passwords alone.

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US

You might also like to read

Adding Two-Factor Authentication to FreeRADIUS

Reference

How to Secure SSH with Google Authenticator’s Two-Factor Authentication

Disclosure

My Semi-Managed Switch – TL-SG2008

07/10/2016 By Andrew Roderos 2 Comments

I bought three of the TL-SG2008 the same day I bought my EdgeRouter Lite. I’ve always wanted some form of managed switch at home to satisfy my wants and to segregate my lab environment.

In my old setup, I had three unmanaged switches and all-in-one router (with switch and access point built-in). While they worked fine, I wanted some SMB features – LACP, IEEE 802.1Q, etc. That said, I needed to buy some form of managed switches.

I checked for used Cisco Catalyst 3560CG on eBay but they are still expensive. I also checked for used prices of Cisco SMB products and they are also expensive for my needs. By then, I realized that I should look at other vendors.

The search begins

I checked Netgear and Linksys product pages because they are popular manufacturers in SOHO and SMB space. I found potential products but I wanted more options. That said, I also checked other manufacturers like D-Link, ZyXEL, and TP-LINK. After few days, I narrowed the potential products into two: TL-SG108E and TL-SG2008.

I like the TL-SG108E because of the price and meet my requirements. However, I did not like the fact that I can only configure the switch with a Windows machine because of the application that they provide. The CLI access, SNMP, etc. are the features I like to have so I went with the TL-SG2008.

Amazon review

When I was looking at TL-SG2008, there is a 1-star review in Amazon that caught my eye. The person who wrote the negative review is calling himself/herself as Mandrake. The review stated that the product includes security vulnerabilities and claimed that the company will not issue firmware to address them. The company, however, released a firmware that claims that they improved the security level. To me, this signals that the company patched the security vulnerabilities found in this report. This assumption is later confirmed by one of the commenters in Mandrake’s review.

While the company seems to have addressed the security vulnerabilities, reading the notes further reveals that they are still using weak security protocols. For example, the recent firmware includes SSLv3 and TLSv1 that addressed the security vulnerabilities of SSLv2. For general users, this might indicate that they’ve improved security but far from truth. Sure, removing SSLv2 does improve security level. However, replacing it with old or deprecated protocol does not.

SSLv3 is not sufficiently secure according to RFC 7568. With the release of POODLE type of attack, one should definitely disable this protocol. However, disabling SSLv3 means that we have to use TLSv1. This protocol, however, is no longer acceptable in new implementations per PCI DSS v3.2 document. The document also states that entities should start working towards migrating to new TLS version. Hopefully, TP-LINK will release new firmware that will remove SSLv3 completely and add TLSv1.2.

Vulnerability Reports

Knowing that the firmware is using outdated security protocols, I decided to run Kali Linux – just used it last month. Kali has a lot of security tools pre-installed that hopefully I can play with in the future. For now, I used it to install and run Nessus Home and OpenVAS to check for security vulnerabilities.

I did two scans for each of the vulnerability scanners: one default configuration for both HTTPS and SSH settings and then I made changes. Note: The switch comes with HTTP and Telnet as the default protocols for management. Users will have to configure the switch to use the secure protocols. Using non-secure protocols by default for management is bad practice. Did they really improve security level?

First vulnerability scan

The first vulnerability scan is my baseline. At this time, I enabled HTTPS and SSH then disabled HTTP and Telnet for management. I left the other settings alone in the HTTPS and SSH configuration section.

HTTPS

In HTTPS configuration section, there are two sections one could play with and these are: cryptographic protocols and cipher suite. For the cryptographic protocol section, we must use at least one protocol.

TL-SG2008(config)#ip http secure-protocol
 ssl3                 - Protocol levels (versions): SSLv3
 tls1                 - Protocol levels (versions): TLS1.0

For the cipher suite section, there are four ciphers that we can choose from. In order for HTTPS to work, we must enable at least one cipher. I actually tried disabling the all of them except 3DES-EDE-CBC-SHA but I lost connectivity using Chrome.

TL-SG2008(config)#ip http secure-ciphersuite
 3des-ede-cbc-sha     - Encryption type ssl_rsa_with_3des_ede_cbc_sha
                         ciphersuite
 rc4-128-md5          - Encryption type ssl_rsa_with_rc4_128_md5
                         ciphersuite
 rc4-128-sha          - Encryption type ssl_rsa_with_rc4_128_sha
                         ciphersuite
 des-cbc-sha          - Encryption type ssl_rsa_with_des_cbc_sha
                         ciphersuite

SSH

In the SSH configuration section, there are three sections one could play with and these are: version, encryption, and finally the data integrity. The output below shows the settings available for us to configure.

For the first configuration section, we must use at least one.

TL-SG2008(config)#ip ssh version
 v1                   - Protocol version v1
 v2                   - Protocol version v2

For the second section, we have six encryption algorithms to choose from. We must use at least one.

Lastly, we have two data integrity algorithm available to choose from: HMAC-SHA1 or HMAC-MD5. We must use at least one.

TL-SG2008(config)#ip ssh algorithm
 <algorithm>          - Enable SSH algorithm, AES128-CBC | AES192-CBC |
                         AES256-CBC | Blowfish-CBC | Cast128-CBC |
                         3DES-CBC | HMAC-SHA1 | HMAC-MD5

Results

Both Nessus and OpenVAS report summary shows seven medium severity vulnerabilities. If one does not read the report, one might conclude that both of the scanners reported the same thing. However, reading the report shows their similarities and differences.

Here is the Nessus summary report

Here is the OpenVAS summary report

I have uploaded both the reports. Click here for Nessus report and here for OpenVAS report. Feel free to view the documents if you want to follow along.

In the Nessus report, two of the vulnerabilities point to self-signed certificate used by SSL/TLS. Self-signed certificates pose a security risk because of man-in-the-middle attacks. However, I think this is fine in a home environment so I do not consider it being that bad. Though, security professionals may disagree with this thinking.

As mentioned earlier, SSLv3 is vulnerable to POODLE type of attack. Both Nessus and OpenVAS reports this vulnerability as well. As a reminder, SSLv3 does not provide sufficient security in this day and age.

I do not want to enumerate everything in this post, but I want to mention one more thing that is in the OpenVAS report. The vulnerability does not only affect TP-LINK but multiple manufacturers as well. The security vulnerability that I am talking about is the one that says “Known SSH Host Key”. You can find more information here. Unfortunately, there is no way around this because of TP-LINK did not include a way for users to generate new keys. Being able to generate new keys is a common practice in configuring networking devices.

Last vulnerability scan

In this last vulnerability scan, I disabled some settings so I can lessen the security vulnerabilities of my switches. With the current firmware, I will never able to reach zero security vulnerability.

HTTPS

In the HTTPS configuration section, I disabled SSLv3 and two RC4-based ciphers. Though, the two left are also weak ciphers in today’s standards. Today, TLS implementations are using stronger ciphers like AES in GCM mode, AES in CTR mode, or ChaCha20.

ip http secure-protocol tls1
ip http secure-ciphersuite des-cbc-sha 3des-ede-cbc-sha

SSH

In the SSH configuration section, I disabled the following lines. Any device with SSH should no longer use SSHv1. The manufacturer should have not included this version if they want to improve security level.

no ip ssh version v1

For the encryption algorithm, I disabled three of them. Though, all of the encryption algorithms available to us are weak anyway so it may not buy us anything. Encryption algorithm using Cipher Block Chaining (CBC) mode is weak. As a result, we will see that OpenVAS and Nessus will report that we are still using weak SSH ciphers.

no ip ssh algorithm Blowfish-CBC
no ip ssh algorithm Cast128-CBC
no ip ssh algorithm 3DES-CBC

For the data integrity algorithm, I disabled MD5 because it is vulnerable to collision attack as described in this paper. Though, SHA1 is also vulnerable to an attack as described in this paper.

no ip ssh algorithm HMAC-MD5

Results

As you can see below, I was able to reduce the number of medium severity vulnerabilities by disabling some settings. Interestingly enough, the OpenVAS increased to three low vulnerabilities. Again, I uploaded both of the reports. Click here if you want to see Nessus report and here for OpenVAS.

Here is the Nessus summary report

Here is the OpenVAS summary report

Things I like

There are few things I like about this switch that other smart switches don’t have

CLI access is big for me
SNMP/RMON is pretty cool to have for monitoring purposes
LACP support
802.1X support (though, quite limited)

Things I don’t like

Aside from the security vulnerabilities, there are few things I do not like about this switch.

Lack of password complexity
No RADIUS support for device authentication
Lost configs after upgrading the firmware

Thoughts

I think it is unfair to for the reviewer to rate it as 1-star purely based on security vulnerabilities. Don’t get me wrong though. Security is very important and would probably lose one or two stars but giving it 1 out of 5 seems to be unfair. If one cannot eliminate the security vulnerabilities then mitigation becomes important. In this case, I was able to reduce the number of security vulnerabilities by turning off settings. In addition, I can reduce the number of medium severity vulnerabilities by disabling HTTPS for management. Speaking of management, the switch offers ACL capability so one can configure it to limit computer(s) that can access it.

Is it better to buy another product that does not include these security vulnerabilities? Sure. Will I return the product? Unfortunately, I will not be able to return them because I’ve had them for more than six months now. If I was able to return them, will I? I have to say no. I haven’t had any issues with the switch and I really like a switch that has CLI access. I have not seen one in the same price range that offers this feature. There is a possibility that I am not looking hard enough though. Will I recommend it? Sure, so long as the buyer is aware and understand the vulnerabilities that come with it.

Disclosure

F5 BIG-IP LTM VE Initial Configuration

06/01/2016 By Andrew Roderos 3 Comments

I talked about my F5 BIG-IP LTM VE home lab in this post, but I didn’t do a walkthrough on how to configure it after deployment. In this post, you will learn the initial configuration of the BIG-IP LTM virtual appliance.

The BIG-IP LTM VE version that I am using is the 90-day trial version so the wizard may be a little different than the newer version since this is an older version (11.3). The latest release of version 11 is 11.6, but the latest version at the time of writing is 12. I actually took two classes few weeks ago based on version 12 at F5 Networks’ Headquarters in Seattle, WA. The two classes were the following: Administering BIG-IP and Configuring BIG-IP LTM: Local Traffic Manager.

While the 90-day trial is based on ~~11.3~~ (F5 has decided to give trial users 13.1.x), the Setup Utility wizard is pretty similar so this guide is still relevant even using the older version of LTM VE. I might buy the lab version but for now this will do the job.

Setting the Management IP address

By default, the management interface of the VE has an IP address of 192.168.1.245/24. This is only true if the management interface is not on a network with DHCP server.

As one might say, such an odd number to pick for the default management IP address. Well, if you try to convert 245 to hexadecimal then you will get F5, as shown below. Very geeky in my opinion!

There are three ways to change the management IP address in the virtual appliance: Bash shell, TMSH (TMOS shell), and Web UI. Personally, I like both CLI methods – bash and TMSH. Both CLI methods are covered in this post.

Using Bash Shell

Easiest way of accessing the CLI is by console display – right click the BIG-IP LTM virtual machine and click Open Console in vSphere client. Alternatively, one can use terminal emulator to SSH to the BIG-IP LTM virtual machine using the default management IP address.

Step 1

Step 2

Issue the config command in bash shell.

This will bring up the F5 Management Port Setup utility.

Step 3

Once you get the prompt, like the one above, hit OK. The next prompt will ask you if you want to use the automatic configuration, hit No.

Step 4

Enter desired IP address for the management interface and hit OK.

Step 5

Enter desired subnet mask for the management interface and hit OK.

Step 6

Management’s default gateway can be optional depending on how your setup. Since I have a management network and I want to access from any network, I do want to configure a default gateway so I can access the management IP from any VLAN. Otherwise, skip step 6 and 7.

Once you hit Yes, you will be prompted to enter the default gateway’s IP address and hit OK.

Step 7

Confirm the management IP address changes by hitting Yes. You will now be back to the bash shell. Exit out of the bash shell and go to Activating License section.

Using TMOS Shell (TMSH)

TMOS is a real-time, event-driven operating system designed specifically for application delivery networking. Through TMOS, you can configure all of the basic BIG-IP system routing and switching functions, as well as enhancements such as clusters, user roles, and administrative partitions.

According to the authors of F5 Networks Application Delivery Fundamentals Study Guide, TMOS and full proxy architecture were introduced back in 2004 when F5 Networks released BIG-IP LTM version 9.

Step 1

Same as step 1 in previous section, log in to the CLI using the default user account. Use root as username and default as password.

Step 2

Enter the TMOS shell then issue the syntax found below to assign the IP address to management interface.

[root@localhost:NO LICENSE:Standalone] config # tmsh
root@(localhost)(cfg-sync Standalone)(NO LICENSE)(/Common)(tmos)# create sys management-ip 192.168.99.51/255.255.255.0

To display the management interface’s IP address.

root@(localhost)(cfg-sync Standalone)(NO LICENSE)(/Common)(tmos)# list sys management-ip
sys management-ip 192.168.99.51/24 {
    description configured-statically
}

Step 3

Same as step 6 in previous section, the management’s default gateway is optional depending on the setup.

root@(localhost)(cfg-sync Standalone)(NO LICENSE)(/Common)(tmos)# create sys management-route default gateway 192.168.99.1

To display the management interface’s default gateway.

root@(localhost)(cfg-sync Standalone)(NO LICENSE)(/Common)(tmos)# list sys management-route
sys management-route default {
    gateway 192.168.99.1
    network default
}

Step 4

Save the configuration.

root@(localhost)(cfg-sync Standalone)(NO LICENSE)(/Common)(tmos)# save sys config
Saving running configuration...
  /config/bigip.conf
  /config/bigip_base.conf
  /config/bigip_user.conf

Activating License

Before you can do anything with BIG-IP LTM, you need to activate the license. To activate the license, you need to access the BIG-IP Configuration Utility. To access the BIG-IP Configuration Utility, open your favorite web browser and enter https://BIG-IP mgmt address here in the address bar. You will then be presented with a screen just like below. To log in, use the default username and password, which is admin/admin.

Once logged in, you will be presented with the Welcome screen. To begin the Setup Utility wizard, click Next to continue.

You will now be presented with a screen that shows you to activate the BIG-IP LTM license. Click Activate.

The next screen is where you enter the license key that you received from F5 Networks. Enter the license key and choose the activation method – automatic and manual.

Automatic Method

Automatic method is the fastest and easiest way to activate BIG-IP LTM. However, it requires an interface that has access to the Internet. In this scenario, management interface has access to the Internet. Click Next to continue.

The next screen will ask you to read and accept the EULA. Click Accept to continue.

Once EULA has been accepted, a new screen will appear. This may take less than a minute or so and continue button will appear. Click the Continue button and you will be redirected to the resource provisioning page. Skip to the Resource Provisioning section of this post if you chose this method. If not, go to the next section.

Manual Method

The manual method is for environment where management interface is on a network that is not allowed to access the Internet. It involves more steps than automatic method.

Follow the steps shown in the screen. First step is to copy all text found in the dossier box. Alternatively, download the dossier file.

The second step is to go to the F5’s licensing site by clicking the link found in step 2 section of the screen. Paste the dossier to the box. Alternatively, upload the dossier file. Click Next to continue.

activate f5 product — F5 activation page

The next screen will ask you to read and accept the F5 Networks’ EULA. Click the check box to accept the EULA and click Next.

The next screen is where you can copy the license information for your BIG-IP LTM. Alternatively, you can download the license file.

Once pasted to License section (step 3) of the Setup utility, click Next. You will then be presented with a screen just like below. Wait for less than a minute or so to finish. Once BIG-IP is done configuring the system, click continue button.

Upon clicking the continue button, you will now be redirected to the resource provisioning page.

Resource Provisioning

The license you receive from F5 Networks will determine what software modules you can use. The 90-day trial license will have license for both LTM (Local Traffic Manager) and AVR (Application Visibility and Responsibility). I am only interested in LTM at this time so that’s the only one I am going to provision.

This section also allows you to change the provisioning for the management. For the most part, you can pick the small option especially in a home lab environment. For the LTM, we can technically provision it to dedicated since that is the only thing we’re running but you can leave it at nominal, which is the the default.

resource provisioning — Resource provisioning

Platform

This part of the setup utility wizard allows you to make configuration to the management interface’s IP address details (again), host name, time zone, user account passwords, etc. The SSH Allow section acts as an ACL to allow certain IP addresses and/or ranges. Once you make changes to the account passwords, you will be logged out and need to log back in.

Network Configuration

Once you log back in, you will be in the network section. You have ability to continue the setup utility or finish it. In this post, I will go through the standard network configuration.

Redundancy

You will now be directed to the redundancy portion of the setup utility. This section is about High Availability feature. At this time, I suggest to uncheck both boxes and just configure it in the future when it is needed. This will be covered in future blog post. Once both boxes are unchecked, click Next to continue.

VLANs

Next up is the network configuration for the internal interface. As you know, this interface will be facing your internal servers that will be load balanced by BIG-IP LTM.

In my case, my home lab uses 10.2.0.0/24 as the internal network.

For the port lockdown, you can leave this at the default setting (Allow Default), since it’s only for home lab environment. Adjust accordingly. The Allow Default setting specifies that connections to the self IP address are allowed from the following protocols and services:

For the VLAN interfaces, you will need to know the network mapping during the BIG-IP LTM VE virtual machine deployment. If you used ESXi for deployment, it should be similar to the one below. Once you figured out which interface number it is for your internal, click Next to continue.

The next screen will ask you to configure the external interface. I left the Port Lockdown to the default. Adjust this setting based on your environment. Since this is just a home lab, I left it alone. Click the Finished button once the required settings are entered.

You will now be redirected to the home page. This will always be the page you will see every time you log back into BIG-IP Configuration utility.

Start your Application Delivery Controller training now!

The initial configuration of BIG-IP LTM is quite easy especially when the default settings are accepted. The only part that I struggled with at first was the associating the TMM (Traffic Management Microkernel) interfaces. Other than that, it was really easy to deploy the virtual appliance and do the initial configuration.

With the free 90-day license for BIG-IP LTM, people who are interested in learning F5 will be able to practice using the software. While 90 days is plenty of time, one could extend the trial by requesting a few more license keys for free. As far as I know, there is no limit on how many ones could request. Just do not abuse it.

Are you ready to improve your network security?

Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.

ENGAGE US