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:
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.
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:
Now the Connection Request policy looks like:
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.
Click on Active Directory and Enable it.
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.
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:
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.
