• Skip to main content
  • Skip to footer

NetworkJutsu

Networking & Security Services | San Francisco Bay Area

  • Blog
  • Services
  • Testimonials
  • About
    • About Us
    • Terms of Use
    • Privacy Policy
  • Contact Us

Blog

Adding Two-Factor Authentication to TACACS+

06/02/2017 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Several months ago, I covered how to add two-factor authentication (2FA) to FreeRADIUS using Google Authenticator. Today, I will cover the TACACS+ version of it.

Related: What is multi-factor authentication (MFA)?

I’ve written a blog post on how to build tac_plus server using Ubuntu. The guide was written in 2011, while it’s an old blog post, the instructions are still valid using Ubuntu Server 16.04. Please use that guide on how to build one, then use this guide to add multi-factor authentication (MFA) to TACACS+.

Related: Deploying TACACS+ on a Docker container

Installing Google Authenticator PAM

It is super easy to install Google Authenticator on Ubuntu. Below is the command we need to install Google Authenticator PAM on Ubuntu.

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

Configure tac_plus

As mentioned earlier, the instructions in my old blog post are still valid. We’re going to use only some of them in this post for the purpose of demonstration only.

By default, the /etc/tacacs+/tac_plus.conf file looks like this:

accounting file = /var/log/tac_plus.acct
key = testing123
user = DEFAULT {
       login = PAM
       service = ppp protocol = ip {}
}

Let’s change the key and user information fields to look something like this:

accounting file = /var/log/tac_plus.acct
key = tacacskey1234
user = tacacsuser {
        member = Administrators
}
group = Administrators {
        default service = permit
        login = PAM
        enable = file /etc/passwd
}

Restart TACACS+ daemon

Since we made a change to our tac_plus config file, we need to restart the service for our changes to take effect. Issue the command below.

$ sudo /etc/init.d/tacacs_plus restart
[ ok ] Restarting tacacs_plus (via systemctl): tacacs_plus.service.

An alternative command is shown below.

$ sudo service tacacs+ restart

Generating Google Authenticator Secret Key

This step is covered in my old blog post so head over there and skip to the generating the secret key section. Alternatively, we could use the same secret key(s) from another system with Google Authenticator. However, this is not the recommended practice.

To get the secret key from another system, just copy and paste the ~/.google_authenticator file of each user, like the one below.

tacacsuser@tacplus:~$ more .google_authenticator
UXQLCMOLT2QLSMVE
" RATE_LIMIT 3 30 1436015893
" DISALLOW_REUSE 39787632
" TOTP_AUTH
55312114
13740459
80118802
81859009
79311140

If you copy and paste it to a file, make sure that the permission is set to read only.

tacacsuser@tacplus:~$ ls -l .google_authenticator
-rw-rw-r-- 1 tacacsuser tacacsuser 129 May 29 17:54 .google_authenticator
tacacsuser@tacplus:~$ chmod 400 .google_authenticator
tacacsuser@tacplus:~$ ls -l .google_authenticator
-r-------- 1 tacacsuser tacacsuser 129 May 29 17:54 .google_authenticator

Configuring TACACS+ PAM

Since we instructed tac_plus to use PAM, we now need to create a file called /etc/pam.d/tac_plus, so PAM knows what to do. The file should look like:

$ more /etc/pam.d/tac_plus
auth requisite pam_google_authenticator.so forward_pass
auth required pam_unix.so use_first_pass

IOS configuration

Before we can verify that our tac_plus config is working, let’s configure a CSR1000V router running IOS-XE.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#aaa new-model
R1(config)#aaa authentication login default group tacacs+ enable
R1(config)#aaa authentication enable default group tacacs+ enable
R1(config)#aaa session-id common
R1(config)#tacacs-server host 192.168.250.250
 Warning: The cli will be deprecated soon
 'tacacs-server host 192.168.250.250'
 Please move to 'tacacs server <name>' CLI
R1(config)#tacacs-server directed-request
R1(config)#tacacs-server key tacacskey1234
R1(config)#end
R1#

While the configuration above still works, it is a good idea to move towards the new way of doing things. Here’s the new way of configuring TACACS+:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#aaa new-model
R1(config)#aaa authentication login default group tacacs+ enable
R1(config)#aaa authentication enable default group tacacs+ enable
R1(config)#aaa session-id common
R1(config)#tacacs server tac_plus
R1(config-server-tacacs)# address ipv4 192.168.250.250
R1(config-server-tacacs)# key tacacskey1234
R1(config-server-tacacs)#end
R1#

Verification

This CSR1000V router is using version 15.4(2)S image. The output may vary depending on what platform and the IOS version.

$ ssh tacacsuser@192.168.250.250
Password & verification code:
R1>en
Password:
R1#

For completeness sake, I will list the passwords entered in the example above. The tacacsuser account is a valid account on the Ubuntu server running TACACS+ daemon. For example, the tacacsuser account has a password of tacacsuserpassword1234. Next, the verification code is the six-digit number displayed on Google Authenticator app. For example, the six-digit number is 567 890. With this example, the user will enter tacacsuserpassword1234567890 in the password & verification prompt.

For entering the privileged EXEC mode, we’ll again use tacacsuser’s password. If we look at the tac_plus config file, the enable = file /etc/passwd is what we defined.

Final Words

I am quite biased towards TACACS+. One of the reasons why is because of the command authorization piece. TACACS+ authentication and authorization are completely separate. That said, we could assign different command authorization level for the user or group.

With RADIUS, it combines authentication and authorization. Once the user authenticates successfully, the access-accept packet sent by RADIUS server to the device contain authorization information as well. If we configure the device similar to the example here, then the user will have full access.

To overcome RADIUS’ drawback, we could configure the device to use a local enable secret. This password is then shared only with the necessary user(s) or group(s). The issue with this approach is that the password is then a shared password. A lot of information security professionals do not like shared passwords because it is insecure.

Having said all that, I think it’s better to use TACACS+, especially with the Cisco-centric environment. While a lot of vendors support TACACS+, there might be some limitations on the authorization piece.

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

How to build tac_plus server
TACACS+ (tac_plus daemon) ACL
How to configure AAA on Cisco router/switches
Enabling AAA on Cisco ASA
Deploying TACACS+ on a Docker container

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.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Filed Under: Linux, Security Tagged With: 2FA, AAA, Cisco, Hardening, IOS, Network Security, tac_plus, TACACS+, Ubuntu

Passed the CISSP exam!

05/23/2017 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Passed #CISSP exam! Long exam but not that hard.

— Andrew Roderos (@andrewroderos) May 22, 2017

Yesterday was a good day, at least for me. I passed the CISSP exam on my first attempt! While it wasn’t that hard (in my opinion) compared to other exams that I have taken, it still felt awesome to pass it on the first attempt.

Quick background

As of this writing, I have been in the IT field for 13 years. The last ten years of my IT career has been in the networking field. I’ve heard from some CISSP folks that people in the networking field have some advantages when preparing and taking the exam. The reason could be because there are some overlapping topics in networking and security. Additionally, information security and networking departments work closely together, so there is some knowledge sharing.

Exam preparation

Technically, I started reading CISSP topics back in January. However, I wasn’t that serious about it and stopped reading. Sometime in February, I took the CISSP boot camp from Global Knowledge. I had hoped that I would learn a lot from it but ended up learning only a few things. Though, nothing that I wouldn’t learn from the book.

If you’ve decided that you’re going to take the boot camp, then I would suggest to take it only from SANS – the MGT414 class. They charge more than other vendors out there, but I have read and heard many good things about their training.

I initially considered taking it from SANS but decided against it. The main thing that discouraged me in taking it from them was the price. While I didn’t have to pay for it, their pricing was significantly more than Global Knowledge. The certification isn’t a requirement for my job, so I figured might as well save some money for the company. Furthermore, the training vendor included a “free” CISSP exam voucher, which was probably the most valuable thing I got from the boot camp.

Anyway, after the boot camp, that’s when I shifted into a different gear. I started reading the CISSP book every day. I also watched training videos. Though, to be honest, I didn’t finish them all.

The latter part of March, I knew that I would be finished reading the CISSP book by mid-April. I wanted to schedule the exam, but I kept procrastinating and lost my spot. I had to push my schedule longer than I wanted to. However, it gave me some time to take practice exams and review some more topics that I don’t quite know.

Study materials

In this section, I’ve listed all of the study materials that I had access to or have used. I clearly stated below if I used it or not. Hopefully, it would help CISSP aspirants for their preparation.

Books

I used Sybex’s CISSP Official Study Guide as my primary resource for my studies. This book is the best seller and has good ratings on Amazon. For good reasons, I feel that the book is sufficient by itself as the only resource in preparing for the exam. I read all 21 chapters of the book even though I have a great understanding of one of the domains.

UPDATE: The one I used was the 7th edition which was applicable to the CISSP 2015 exam objectives. The Sybex’s CISSP Official Study Guide 8th edition is meant for the CISSP 2018 exam objectives.

Another book that I used was the Eleventh Hour CISSP. This book has only 21 reviews, but the rating is high. I read this book from cover to cover. It is good for a refresher before the exam, but I still think that the previous book was enough. I’d say, just go back to the topics that you’re weak on and you should be good to go.

Since I took a boot camp, I have access to Official (ISC)2 CISSP training handbook, flash cards, and Guide to the CISSP CBK book. I didn’t use any of them, but it’s good to have for reference.

Videos

I have or had access to boot camp recordings and Cybrary. Out of the two, I’ve used only the Cybrary.

Cybrary’s instructor is Kelly Handerhan. I haven’t come across her name in the years I’ve been in IT field. That’s not a shot to the instructor since I mostly know people in networking. The videos are good, so I recommend to go through them. I think for the level being tested on CISSP, their videos are a great learning tool.

Honestly, I stopped watching their videos because they were making me fall asleep. Again, not a shot to the instructor. I just couldn’t finish the videos without falling asleep. Your mileage may vary.

Practice tests

I have or had access to Transcender practice exams (included with the boot camp), Sybex’s CISSP Official Study Guide practice tests and Sybex’s CISSP Official Practice Tests. Out of the three, I’ve used only two of them.

The Sybex’s CISSP Official Study Guide have four full practice tests accessible via online. Each full practice tests contains 250 questions. I’ve only tried two out of the four practice tests.

When I took the first full practice test, I scored around 77 – 78%. It is a low score but still a passing mark. At the time, I felt so confident that I will pass the CISSP exam if I took it that day. Boy, I was wrong. Because the following day or so, I took the second full practice test and I failed. I scored between 65 – 66%. To my defense, I was quickly picking the answers and weren’t paying too much attention. My average time taking the practice exams was between 70 – 95 minutes (can’t remember). Not very long at all.

The Sybex’s CISSP Official Practice Tests have 100 questions per domain plus two full practice tests. The best way to use this resource is to access the online portal. To me, it is hard to use it as physical book or ebook. The online portal was more convenient than using the book.

I didn’t try the domain tests. I felt that it would go into too much detail compared to the CISSP exam. Having said that, I went straight ahead and took one of the full practice exams. Again, I failed. I scored 69.20%. Since it was a practice exam, I also rushed taking the exam and didn’t pay full attention.

Days before the exam

I booked the exam probably six weeks ahead of time. At the time, I was not sure if I was going to be ready or not. Though, I knew I had plenty of time. I just had to make sure I used my time efficiently. Though, I would say that the last two weeks before the exam, I relaxed and started watching some Marvel shows on Netflix. The relaxation that I did was the main reason why I was panicking few days before the exam.

24 – 48 hours before the exam, I had a mixture of relaxation and also some exam cramming. I focused reading my weak topics because if I were to get those questions, I would totally fail. I guess my cramming for the exam worked because I passed it.

Day of the exam

I slept late the night before and woke up at 5:30 in the morning. Having enough rest is important when taking any exam so make sure you do. Even though I didn’t have enough sleep, I felt fine.

Since I woke up early, I had plenty of time to prepare and get to the Pearson Vue testing center. I made sure I ate breakfast before I left, prepared my snacks, meal, and water to bring to the testing center. Since the test won’t stop the timer when you take a break, it is important that you bring food. Do not attempt to skip your snack or meal. I think it is important to have food in your body.

Arrival

When I arrived at the testing center, I was 40 – 45 minutes early. I talked to some of the test takers that day and found out they weren’t taking any exam related to IT or IS. Makes sense since Pearson Vue handles non-IT related exams as well.

The testing center’s employees started to arrive and eventually let us in 30 minutes before our scheduled time. During all of this, I was still having some second thoughts if I was going to pass. I was saying to myself that it’s okay if I pass or not. At least I attempted it, and failure is part of any journey.

When it was my time to check in, the person almost turned me away because of the two forms of identification rule. I did have my government-issued ID and credit cards, but they weren’t signed. The person eventually decided to let me through. It would’ve been bad if I was denied to take the exam. I would’ve wasted the “free” exam voucher.

Exam experience

As I was going through the questions, I started gaining confidence that I will pass the exam. But then, I started getting questions that I am not sure if I answered correctly. As time went on, I knew I was going to pass the exam. I would’ve been shocked if I didn’t. Don’t get me wrong though I had plenty of flagged questions for review. However, I was sure with my answers on a lot of them. I just wanted to go over again just in case I wasn’t thinking right.

I thought the questions weren’t as hard as the full practice tests I have taken. While I didn’t take a lot of them, I feel that they were similar to the real one. Unfortunately, due to NDA and the fact that I don’t know what I could say, I will stop discussing the exam now.

Breaks

As you know, a CISSP exam taker can take up to six hours to finish it. In this timeframe, exam taker can take breaks at any time. This break could be used to go to men’s or ladies room, eat some snacks or meal. It is up to the exam taker on how he/she would use it.

I took four or five breaks. The first break was around my 77th question. I took a restroom break and also walked around the hallway to relax a bit. My second and third break were pretty much the same. During this time, I had plenty of time left. On my fourth break, I ate my sandwich and walked around a bit. Close the 250th question I had to go to the restroom. Apparently, I drank too much of water.

Review flagged questions

As mentioned, I had plenty of flagged questions. I went through all of them and changed some of the answers. On some of the flagged questions, I just didn’t know how to answer them. I just picked whatever I felt like the best answer. The review took probably between 40 – 50 minutes. By the time I was done, I had between 40 – 45 minutes left on the clock. I didn’t feel like going through the questions again, so I ended the exam.

Exam Results

Apparently, (ISC)2 CISSP exam does not give the results on the screen. I actually closed my eyes when I hit the end exam button and waited few seconds before I opened my eyes. It was for nothing because I had to go to the front desk for the printout. Since I’ve taken quite a bit of Cisco exams, so I assumed that it would be the same thing. I couldn’t be more wrong.

When I saw the congratulations part, I wasn’t shocked about it but I was relieved that it’s finally over. Another difference between the Cisco and (ISC)2 is that the results didn’t say what my score was. Not a big deal but it would’ve been nice to know.

Final words

As mentioned earlier, I believe that the Sybex’s CISSP Official Study Guide book is all one would need to prepare for the exam. Let me reiterate that this is coming from someone with networking and some security experience. Though, I still think that if one spends enough time understanding the book and some memorization, then anyone could pass the exam. So, if one is on a small budget, I’d say only buy that one.

If one wants to learn more about the topics, definitely go through the Cybrary videos. It will help in day to day operations and solidify the concepts that you read from the book.

Some people would like some exam tips. I’d like to give plenty, but I only have one. That is, read the questions carefully and pick the best answer.

Good luck in your CISSP journey and I hope you get the same success as I did!

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

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.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Filed Under: Certifications, Security Tagged With: CISSP, ISC2

Hardening EdgeRouter Lite – Part 4

12/06/2016 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

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

DateTitleDescription
03/13/16My Home Router – EdgeRouter LiteQuick introduction to EdgeRouter Lite
04/09/16Ubiquiti’s EdgeOS CLI IntroductionEdgeOS CLI Primer
05/01/16How to configure EdgeRouter Lite via CLI – Part 1EdgeOS configuration guide for CLI junkies
05/01/16How to configure EdgeRouter Lite via CLI – Part 2EdgeOS configuration guide for CLI junkies
12/03/16Hardening EdgeRouter Lite – Part 1Basic management hardening
12/04/16Hardening EdgeRouter Lite – Part 2EdgeOS with two-factor authentication
12/05/16Hardening EdgeRouter Lite – Part 3Management ACL

Introduction

In my How to configure EdgeRouter Lite via CLI – Part 2 post, there is an L2TP via IPsec section. The commands shown in that blog post works great. However, there are security concerns with that configuration. The remote-access VPN configuration uses pre-shared secret for machine authentication and user authentication with no two-factor authentication (2FA). In this post, I will demonstrate how to harden remote-access VPN connectivity on EdgeRouter Lite.

User Authentication with 2FA

As mentioned in my how-to configure guide, I prefer L2TP over IPsec, so this post will only cover that. The configuration demonstrated here requires a RADIUS server, such as FreeRADIUS. Check my blog post about it if you want to create your own. If you chose the local Google Authenticator route, there might be a way to tie that with user authentication. That is, however, out of the scope of this post.

The EdgeOS has two L2TP modes for user authentication, local and RADIUS. In my how-to guide, it showed the use of the local account which is separate from device management. As previously discussed, username and password are no longer considered secure today. That said, we’re going to add another factor of authentication to the account.

EdgeOS Commands

The first command is to change user authentication mode to RADIUS.

set vpn l2tp remote-access authentication mode radius

The second command is to point the device to the RADIUS server and enter the key you want to use.

set vpn l2tp remote-access authentication radius-server 192.168.250.250 key supersecretkey

The last command is to change the default protocol from MS-CHAPv2 to PAP. Unfortunately, Google Authenticator will only work with PAP, as far as I know.

set vpn l2tp remote-access authentication require pap

Don’t forget to commit and save the configuration. Issue the commit;save command.

FreeRADIUS Configuration

In my FreeRADIUS blog post, there were only a few lines that needed to be changed or added to the config files. Aside from those modifications the files were left in the default state. That’s okay for the most part. However, when we try to access VPN, it takes a bit longer than using the local account. In this section, we’re going to make some optimizations to speed up the process of authentication.

Related: How to implement Duo Security MFA

I am a FreeRADIUS newbie, so I do not know what all of these lines mean, but I commented them out to speed up the process of authentication. I just looked at the debug using sudo freeradius -X command and tried to interpret what it was saying. The lines that included noop, I figured they are not needed for my environment, so I commented them out. Every time I made the change, I tested my VPN to make sure I was able to log in still. If you are currently using or going to use this FreeRADIUS instance for other purposes, then be careful of what you comment out because it may break. Remember, I only use this for remote access VPN and device authentication.

Edit the /etc/freeradius/sites-enabled/default file.

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

Find the following and comment them out.

authorize {
#      chap
#      mschap
#      suffix
#      eap {
#              ok = return
#      }
#      expiration
#      logintime
#      pap
authenticate {
#      Auth-Type PAP {
#              pap
#      }
#      Auth-Type CHAP {
#              chap
#      }
#      Auth-Type MS-CHAP {
#              mschap
#      }
#      digest
#      eap
preacct {
#      suffix
#      files
accounting {
#      exec
post-auth {
#      exec

Next step is to edit the clients.conf file. From what I can tell, this is kind of like an ACL. If you do not add the router’s source IP address, then FreeRADIUS will ignore the traffic from the router. Once you open the file using VI or your favorite text editor, look for the client localhost { line and add the lines listed below.

$ sudo vi /etc/freeradius/clients.conf
client rtr {
        ipaddr = 192.168.1.1
        secret = secretkey
}
client localhost {

Since we made changes to the files, we need to restart the service for it to take effect.

$ sudo service freeradius restart

Verification

Now, go ahead and test your VPN connectivity to see if it works. If everything works, then you can now delete the local account from the configuration. Remember, the format for the password is password+TOTP.

delete vpn l2tp remote-access authentication local-users username unique-username-here password your-unique-password-here

Troubleshooting

When you are troubleshooting FreeRADIUS, it is very helpful to use the freeradius -X command. This helped me figure out some issues that I’ve encountered when setting this up. This command may be different in other Linux distro, though. Just check the documentation for the right command. From what I can tell, all Debian-based Linux distro uses this command.

Before you can issue the debug command, you need to stop FreeRADIUS service first or you will get an error, as shown below.

$ sudo freeradius -X
<-- Output omitted for brevity -->
Failed binding to authentication address * port 1812: Address already in use
/etc/freeradius/radiusd.conf[273]: Error binding to port for 0.0.0.0 port 1812
$ sudo service freeradius stop
$ sudo freeradius -X
<-- Output omitted for brevity -->
Listening on authentication address * port 1812
Listening on accounting address * port 1813
Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel
Listening on proxy address * port 1814
Ready to process requests.

Once you’re done with troubleshooting, make sure to start the service back up with sudo service freeradius start command.

Final Words

The problem with local authentication is that we need to enter user account details within EdgeOS. That said, anyone who has admin-level access on EdgeOS will be able to view the password of the users. Changing the remote access VPN authentication from local to RADIUS is a more secure option. On top of that, we can add another factor of authentication.

For the most part, this is secure enough. In fact, I’ve seen a lot of organizations that use a similar setup. However, some organizations or people want to implement the securest method possible for their remote access VPN. That said, they need to implement certificate-based machine authentication. Heck, they may even combine both 2FA and certificate-based machine authentication for maximum security.

If I ever get the L2TP over IPsec working using certificates, then I will cover it in my next blog post. I know it’s possible, but my client is stuck in IKE Phase 1. The problem is most likely my certificates.

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

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.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Filed Under: Security, Ubiquiti Tagged With: EdgeRouter, Hardening, Network Security

Hardening EdgeRouter Lite – Part 3

12/05/2016 By Andrew Roderos 1 Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

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

DateTitleDescription
03/13/16My Home Router – EdgeRouter LiteQuick introduction to EdgeRouter Lite
04/09/16Ubiquiti’s EdgeOS CLI IntroductionEdgeOS CLI Primer
05/01/16How to configure EdgeRouter Lite via CLI – Part 1EdgeOS configuration guide for CLI junkies
05/01/16How to configure EdgeRouter Lite via CLI – Part 2EdgeOS configuration guide for CLI junkies
12/03/16Hardening EdgeRouter Lite – Part 1Basic management hardening
12/04/16Hardening EdgeRouter Lite – Part 2EdgeOS with two-factor authentication
12/06/16Hardening EdgeRouter Lite – Part 4Remote Access VPN with two-factor authentication

Introduction

I focused on authentication method in the first two posts of this EdgeRouter Lite series. In today’s post, I will focus on access restriction to the management plane. To accomplish this access restriction, we need to create firewall policies on the router and apply it to LAN and sub-interfaces. This post will show what you need for the firewall policy.

Management ACL

While restricting management services to listen on a single address, it is also a good practice to restrict addresses or networks allowed to reach it. The firewall on EdgeOS allows users the creation of address groups and network groups. The groups allow users include more than one address in the firewall policy. Without further ado, below is an example of a firewall policy that one can apply to EdgeRouter Lite.

Firewall group

We need to gather the source IP addresses or network prefixes that will be allowed to connect to the EdgeRouter Lite. It is good practice that these hosts are one of the most secure computers in the network.  We do not want the bad guys taking control of our router since all traffic traverses through it. For example, my Linux hosts have 2FA enabled for both SSH and console access.

The address-group allows users to add multiple IP addresses.

set firewall group address-group SSH-TRUSTED address 192.168.254.100
set firewall group address-group SSH-TRUSTED address 192.168.254.101

The network-group allows users to add network prefixes.

set firewall group network-group GUI-TRUSTED network 192.168.253.0/24
set firewall group network-group GUI-TRUSTED network 192.168.254.0/24

Firewall policy

Once we’ve created the firewall group, we are now ready to create the firewall rules.

The first three lines are what a lot of people will call this as a catch-all rule. Any traffic not defined in our firewall policy will fall under this rule.

set firewall name LAN-LOCAL default-action drop
set firewall name LAN-LOCAL description 'LAN IPv4 inbound traffic to the router'
set firewall name LAN-LOCAL enable-default-log

The next firewall rule is unnecessary, but I like to add it in the beginning. In my environment, this rule has one of the lowest numbers, so it is safe to move it at the end of the firewall policy if you feel so inclined. Alternatively, do not add this rule since the catch-all rule will drop this traffic.

set firewall name LAN-LOCAL rule 10 action drop
set firewall name LAN-LOCAL rule 10 description 'Drop invalid state'
set firewall name LAN-LOCAL rule 10 log disable
set firewall name LAN-LOCAL rule 10 state invalid enable

I will leave the next rule at your discretion. Some people like to allow ICMP for troubleshooting purposes and some people do not.

set firewall name LAN-LOCAL rule 20 action accept
set firewall name LAN-LOCAL rule 20 description 'Allow ICMP'
set firewall name LAN-LOCAL rule 20 log disable
set firewall name LAN-LOCAL rule 20 protocol icmp

The next rule depends if you run SNMP or not. I run the free PRTG Network Monitor in my environment, so I have to add it.

set firewall name LAN-LOCAL rule 30 action accept
set firewall name LAN-LOCAL rule 30 description 'Allow SNMP'
set firewall name LAN-LOCAL rule 30 destination port 161
set firewall name LAN-LOCAL rule 30 log disable
set firewall name LAN-LOCAL rule 30 protocol udp
set firewall name LAN-LOCAL rule 30 source address 192.168.200.200

These next rules are what we need to restrict source IP addresses or network prefixes that can connect to the EdgeRouter Lite. If you disable GUI access then there is no point in adding firewall rules for both HTTP and HTTPS.

set firewall name LAN-LOCAL rule 40 action accept
set firewall name LAN-LOCAL rule 40 description 'Allow SSH'
set firewall name LAN-LOCAL rule 40 destination port 22
set firewall name LAN-LOCAL rule 40 log disable
set firewall name LAN-LOCAL rule 40 protocol tcp
set firewall name LAN-LOCAL rule 40 source group address-group SSH-TRUSTED
set firewall name LAN-LOCAL rule 50 action accept
set firewall name LAN-LOCAL rule 50 description 'Allow HTTPS'
set firewall name LAN-LOCAL rule 50 destination port 443
set firewall name LAN-LOCAL rule 50 log disable
set firewall name LAN-LOCAL rule 50 protocol tcp
set firewall name LAN-LOCAL rule 50 source group network-group GUI-TRUSTED
set firewall name LAN-LOCAL rule 60 action accept
set firewall name LAN-LOCAL rule 60 description 'Allow HTTP'
set firewall name LAN-LOCAL rule 60 destination port 80
set firewall name LAN-LOCAL rule 60 log disable
set firewall name LAN-LOCAL rule 60 protocol tcp
set firewall name LAN-LOCAL rule 60 source group network-group GUI-TRUSTED

The last rule allows any traffic that is in established or related state. Check this site to understand the states.

set firewall name LAN-LOCAL rule 70 action accept
set firewall name LAN-LOCAL rule 70 description 'Allow Established'
set firewall name LAN-LOCAL rule 70 log disable
set firewall name LAN-LOCAL rule 70 protocol all
set firewall name LAN-LOCAL rule 70 state established enable
set firewall name LAN-LOCAL rule 70 state related enable

Apply the firewall policy

Now, we need to apply the firewall rule to all your LAN interfaces including sub-interfaces.

set interfaces ethernet eth1 firewall local name LAN-LOCAL
set interfaces ethernet eth2 firewall local name LAN-LOCAL
set interfaces ethernet eth1 vif 10 firewall local name LAN-LOCAL
set interfaces ethernet eth1 vif 50 firewall local name LAN-LOCAL
set interfaces ethernet eth1 vif 100 firewall local name LAN-LOCAL
set interfaces ethernet eth1 vif 200 firewall local name LAN-LOCAL

Save config

Now, we need to save the configuration by issuing commit;save command.

Verification

Try connecting to EdgeRouter Lite without logging out from your current SSH or secure HTTP connection. This ensures that you still have access to the router just in case there’s a mistake with the ACL. If you have a Network Management System (NMS), make sure that SNMP is working as well.

Final Words

Any traffic destined to the EdgeRouter Lite must be restricted. While we did it on the WAN side, we also need to secure the LAN side. As much as possible, the allowed list must be limited. Only systems that must have router access should be on the list. Finally, computers on the list should have great security controls to keep it from being compromised.

The next blog post, I am going to talk about securing the remote access VPN. The blog post will address the security concerns on my how to configure EdgeRouter Lite guide.

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

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.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Filed Under: Security, Ubiquiti Tagged With: EdgeRouter, Hardening, Network Security

Hardening EdgeRouter Lite – Part 2

12/04/2016 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

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

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

Introduction

In the first part of this EdgeRouter Lite series, I made changes to improve security of the management plane. In this post, I am going to give an alternative to people who do not like or want to use public-key authentication. This means we stick with the password-based authentication but with an additional factor of authentication.

Authentication

The use of two-factor authentication (2FA) or multi-factor authentication (MFA) has gained popularity in the past several years. This is because password-based authentication is no longer considered secure today. In fact, there are many organizations today that are deploying or have recently deployed 2FA or MFA to their systems.

What makes 2FA or MFA more secure than the usual username and password combination? One common behavior of users is to use the same password across all their accounts. This behavior is a bad thing because it only takes one system to get compromised for malicious users to gain access to other accounts. With 2FA or MFA, even if the user used the same password, the malicious user won’t be able to gain access to other accounts without the other factor of authentication.

The three common factors of authentication are something you know (e.g. password), something you have (e.g. smartphone), and something you are (e.g. biometrics). In this post, we’re going to combine both something you know and something you have factors of authentication that will work with the EdgeRouter family. Though, all the methods discussed here have limitations. Hopefully, Ubiquiti will make changes in their future firmware releases that remove these limitations.

SSH Authentication

If for whatever reason, you chose not to use public key authentication, then we have other methods on how to secure password-based authentication. Though, both of them have limitations so pick one that you feel comfortable with.

Method 1

This method is good for people who are not running RADIUS with 2FA and have no plans for the foreseeable future. One of the disadvantages of this method is that it will only work for SSH authentication. Managing the router via Web UI will need to use the local account without the time-based one-time password (TOTP). This is not a problem with CLI junkies, though.

Another disadvantage is that it will not survive a firmware upgrade. That said, you will have to redo part of the work to get the functionality back. Though, you might be able to restore the packages by creating a script using this method. The ~/.google_authenticator file(s) will need to be backed up as well.

Steps

The first step is to run as root.

sudo su

The second step is optional. This package will prompt you a QR code once you generate Google Authenticator (GA) secret key. Just like the one here. This package makes it convenient for the users since scanning QR code is faster than typing. If you do not want to install the package, you just enter the secret key on your GA app manually.

sudo apt-get install libqrencode3

The third step is to download the Google Authenticator package.

wget http://ftp.us.debian.org/debian/pool/main/g/google-authenticator/libpam-google-authenticator_20160607-2_mips.deb

The fourth step is to install the package.

dpkg -i libpam-google-authenticator_20160607-2_mips.deb

The fifth step is to stop being a root.

exit

The next step is to generate the secret key. Please follow this guide on how to do that. Go directly to the Generating Google Authenticator Secret Key section.

The last step is to edit PAM for SSH. We need to instruct the pam_ssh module to use Google Authenticator PAM when a user logs in. Use the same guide as above and scroll down to Configuring SSH PAM section.

Method 2

The previous section demonstrated the unofficial way of enabling 2FA. I say unofficial because users are required to redo the work after firmware upgrade. While unofficial, it is still an effective way of adding another factor of authentication; thus, increasing security. In this section, I am going to show you on how to set up EdgeRouter family in using RADIUS with 2FA functionality.

The advantage of using this method is that we stay within the EdgeOS environment; thus, no redo of work after the firmware upgrade. Another advantage of this method is that it can be used for Web UI as well.

The disadvantage of this method is that local account may be used. Meaning, users may bypass the 2FA altogether. Hopefully, Ubiquiti has plans to add a command that will disable local account usage when RADIUS is up and running. For now, I suggest in using a secure password and store it in a password manager app and use it only during an emergency, like when RADIUS is down. You might also want to change the local account password periodically.

The EdgeOS requires having an existing local account that matches your RADIUS server. Without the local user account, it will never work. As far as I can tell, this annoying feature has been in EdgeOS for several years now. Ubiquiti developers still have no plans on changing this anytime soon, which is unfortunate.

If you do not have RADIUS server and would like to have one, then visit my blog post where I talked about FreeRADIUS with 2FA. Since I have two FreeRADIUS servers already, it was a no-brainer for me to point the EdgeRouter Lite to it. Without further delay, below are the commands to use to point the router to RADIUS server.

set system login radius-server 192.168.200.100 port 1812
set system login radius-server 192.168.200.100 secret supersecretkeyhere
set system login radius-server 192.168.200.200 port 1812
set system login radius-server 192.168.200.200 secret supersecretkeyhere

Last step is to commit & save the configuration. Issue commit;save command.

Verification

Try to connect to the router using SSH without logging out your current session. This is to make sure that you have access to the router for when something goes wrong. Remember, the password format is password + TOTP.

Final Words

The methods discussed here are not perfect but improves the network security of the network infrastructure. Remember we are dealing with a relatively inexpensive gear with enterprise features, so expect some compromises.

My recommendation is to use the public key authentication method. If you are concerned about machines with public keys getting compromised, then I suggest in using a management ACL. This ACL will restrict IP addresses which are allowed to access the router. The next blog post will talk about on how to create a management ACL.

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

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.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Filed Under: Security, Ubiquiti Tagged With: EdgeRouter, Hardening

  • « Go to Previous Page
  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to page 4
  • Go to page 5
  • Interim pages omitted …
  • Go to page 18
  • Go to Next Page »

Footer

WORK WITH US

Schedule a free consultation now!

LET’S TALK

Copyright © 2011–2023 · NetworkJutsu · All Rights Reserved · Privacy Policy · Terms of Use