Skip to main content

Attackers always follow three basic steps: infiltrate, escalate and exfiltrate. We have done a lot of documentation on how to add two-factor authentication to various remote access solutions. How can we setup a network that makes escalation of privilege extremely difficult by using two-factor authentication instead of static passwords? With WiKID's Active Directory protocol you can now use 2FA for Administrators' accounts. Combine that with PAM-RADIUS for sudo, and you can.

The most common methods attackers use to escalate their attacks involve weak, stolen or default credentials.  In the pass-the-hash attack, they do not even need to decrypt the administrator credentials.  Clearly better protection for privileged accounts is required.  In addition to being great security, it seems likely that two-factor authentication for administrator accounts will be part of PCI-DSS 3.2.

We are going to setup a network that has both Linux servers (Ubuntu and RHEL/Centos) and Windows servers to show that this setup works across both.   All of our users will be in Active Directory and managed there.  In order to include authorization in AD, we will be using the Windows RADIUS plugin NPS.   For the sake of brevity, you can see how to setup NPS 2012 here and 2008 here.

Configure sudo on Centos/RHEL for two-factor authentication

Administrative control on linux relies on sudo, so we will be adding two-factor to it using PAM.

We will start on RHEL/Centos 7.   Install the pre-requisites:

$ sudo yum -y install make gcc pam pam-devel

Get the latest PAM RADIUS code (1.4 as of this writing):

$ wget ftp://ftp.freeradius.org/pub/radius/pam_radius-x.x.x.tar.gz

Build the library:

$ tar -xzvf pam-radius-x.x.x.tar.gz
$ cd pam-radius-x.x.x
$ sudo ./configure
$ sudo make

Copy the library to the proper location:

$ cp pam_radius_auth.so /lib/security/

Or for 64bit:

$ cp pam_radius_auth.so /lib64/security/

Create the configuration directory and copy the configuration file under the name 'server':

$ sudo mkdir /etc/raddb
$ cp pam_radius_auth.conf /etc/raddb/server

Edit /etc/raddb/server and add your radius server, in this instance the NPS server at IP address 10.100.0.114:

# server[:port] shared_secret      timeout (s)
127.0.0.1       secret             1
10.100.0.114    secret       3
#
# having localhost in your radius configuration is a Good Thing.

(Note that while we want NPS in the loop eventually, you might want to use your WiKID server as the radius server, add this Centos box as a network client on WiKID, restart WiKID and do a quick test.  It's always a good idea to do some small tests along the way, just be sure to remove them.)

Next, we need to tell sudo to use radius.  Edit the file /etc/pam.d/sudo and replace "auth       include      system-auth" with:

auth       required      pam_radius_auth.so

That's it for the Centos/RHEL 7 box.  The same setup work for 5 and 6 too.

Configure sudo on Ubuntu for two-factor authentication

Next up is the Ubuntu 14.04 server.  First, install pam-radius:

$ sudo apt-get install libpam-radius-auth

Configure it with the NPS server as well by editing /etc/pam_radius_auth.conf:

$ sudo vim /etc/pam_radius_auth.conf

So that it is the same as above:

# server[:port] shared_secret      timeout (s)
127.0.0.1       secret             1
10.100.0.114    secret       3
#
# having localhost in your radius configuration is a Good Thing.

Edit your /etc/pam.d/sudo file and add the line ' auth sufficient pam_radius_auth.so' above the comm-auth line:

auth       required   pam_env.so readenv=1 user_readenv=0
auth       required   pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
auth sufficient pam_radius_auth.so
@include common-auth
@include common-account
@include common-session-noninteractive

That's is for the Ubuntu server. 

Configure NPS

Next, we will add these servers as radius clients on NPS, which we have previously configured to use WiKID for two-factor authentication.

Start the Network Policy Server and right click on RADIUS clients and select new:

Add NPS client

Give the client a friendly name and enter its IP address.   Enter the same shared secret you created in /etc/raddb/server and hit OK.

2FA admins in NPS

Select OK and repeat these steps for your Ubuntu server.

Check or create a condition under the Conection Request Policy.  For this test, we want all requests to be routed to WiKID for two-factor authentication, so we will say that any request at any time should be routed to WiKID:

Any time all two-factor!

Now the Connection Request policy looks like:

Connection Request policy final

NPS is a big pain in the butt so be sure to check out our NPS documentaton and our trouble-shooting for radius tips.  But, if NPS is working right, then you have successully configured two-factor authentication for sudo for your linux servers.  Note also that many Linux processes including SSH use PAM for authentication, including some databases like Postgres.

Adding two-factor authentication to Windows Admins

There's no way to use RADIUS for local administrator logins on Windows, so we created a Native AD two-factor authentication protocol for the WiKID server.  WiKID's Active Directory protocol will push one-time passcodes to AD as the new password and after the expiration of the passcode, write a random string as the new password.  This means that the window in which an attacker can use the stolen administrator credentials is significantly reduced. 

Unlike RADIUS, this protocol communicates directly between WiKID and AD.  You set up a WiKID domain just for it.  So, you might have a WiKID domain that uses an externally routable IP (remember WiKID tokens talk to your WiKID server) for VPN access using RADIUS and another that uses an internal IP for AD passwords. 

Enable the protocol

On the WiKID server, on the Configuration tab, click on Enable Protocols.

Enable protocol for native AD 2FA

Click on Active Directory and Enable it.

Native AD 2FA protocol enabled

Create a WiKID domain for Active Directory

 Once it is enabled, click on the Domains tab and then Create a new domain.  You will see some additional options no at the bottom of the Create domain form. 

AD 2FA options on the domain tab

The first box, Use Active Directory, specifies that this domain uses the AD protocol.  If you have a domain that uses RADIUS for a VPN or other solution, you need another domain for AD, similar to the way TACACS+ works in WiKID.   This also means that you need new licenses for AD domain users. 

The second box specifies that this is a password reset domain.  If checked, the server sends the "User must change password at next login" flag to AD.  The user logs in with their passcode and must re-set their password. 

The third box, if checked, specifies the use of passwords designed to meet AD's complexity requirements.  The generated passcodes will be all caps and won't use all the letters, but will be 8 characters long and have a non-alpha numeric character.  We do this to avoid font confusion around characters like l and 1 and 0 and O as they might be displayed on a mobile device.   If you do not choose the enable this, you must remove password complexity requirement in AD.  This might make sense in some scenarios.   In the non-password -reset scenario, the OTP is only good for a limited time and then it is over-written.  You could use an internal IP for the server code and require smartphone tokens, meaning the phones had to be on the local network. 

Obviously the WiKID server needs to communicate with a domain controller.  The last four boxes provide this information. 

Here's what a configured domain looks like:

Active Directory 2FA configured

This one is configured for an internal IP for the server code, it allows all token types and uses complex OTPs to replace static passwords.  We created an administrator called 'wikid admin' in AD with the power to reset users' passwords. 

Note that in this setup, we have two WiKID domains, one for use with RADIUS on linux can one for Active Directory.  The server would need to have two routable IPs for this configuration, but they could be internal, requiring that the administrators be on the local network. 

Using two-factor authentication for remote access is great for reducing infiltration, but hackers might still get in via malware etc.  Using two-factor authentication for administrator accounts will remove or limit a number of extremely common attacks, like pass-the-hash.  Attackers will get tripped up and expose their presence.  This is a great idea for networks of all sizes and it may become a requirement for PCI-compliance soon.  If you have not done so, download the WiKID Strong Authentication server now and test it!

Don't forget to lock down your Cisco and Checkpoint admin access with two-factor authentication too. 

Need reliable two-factor authentication?

 Download a Free Evaluation Today

Keywords:



 

Copyright © WiKID Systems, Inc. 2019 | Two-factor Authentication