Wednesday, August 2, 2017

Some Basic Redhat 7 Password Hardening

Build It Right The First Time

Today we'll look briefly at some strategies and considerations for hardening RHEL7 instances, be they physical or virtual.  A general security strategy focuses on two primary areas - the physical and the technical.  If we deploy systems with good security in the first place, we can avoid 'fire drill' exercises and reactive behavior.  Put another way, an ounce of prevention is worth a pound of cure.

Lock It Up

Most IT professionals will not have much say over many aspects of physical security.  Usually facilities staff handles card locks, access keys, power into the datacenter (though power inside the datacenter is another matter!), doors, windows, and other access controls.  This will be the focus of another article, but for the time being, keep your equipment locked up.  Closets, insecure offices, and cubicles are no place for your critical server infrastructure!

From The Top

Security can be viewed as a bottom-to-top or top-to-bottom process.  Whatever it is for you, the goal is the same - minimize risk to the business, employees, vendors, and customers.  That said, here is a brief overview of areas to consider.

A Dumb Thing To Do?

A month ago, I was installing some RHEL 7 instances as VM's - pretty routine and boring stuff - and noticed there was a way to disable shadow passwords.  I haven't seen a sane Unix or Unix-alike OS, since about 1989, that 1) did not mandate the use of /etc/shadow and 2) did give you the option of circumventing /etc/shadow as an install-time option.  Maybe this has been an industry-wide option for all these years, but it certainly it not an option I would have ever used.  

If you disable shadowing, your one-way password hashes will be stored in /etc/passwd, a world-readable file.  All the extra cozy, fuzzy security you get from SHA-512 hashed passwords is diminished by making those hashes available to any user on the system.   That would be a dumb thing to do, so don't do it.  

Complex is Hard, So Make It Hard

A system administrator should also enforce the use of quality password for user accounts.  My investigation of fresh RHEL7 installs shows that quality checks are not necessarily enabled by default.  So, scurry off and check /etc/pam.d/passwd for the following line, and if missing, add it:

password required pam_pwquality.so retry=3

 Then, in /etc/security/pwquality.conf, have the following at a minimum:

minlen = 8 
minclass = 4
maxsequence =0
maxrepeat =2

This requires a password of at least 8 characters, inclusive of all 4 character classes, with 0 permitted sequences, i.e. '1234' or 'abcd' and a maximum of 2 identical consecutive characters, i.e. 'll' 'mm'.  Normally I would make maxrepeat = 0, but this gives users some leeway to help them remember passwords based on, but not actually, double-consonant words.  I prefer to keep minlen at 10 and maxrepeat at 0, but your constraints may lead to different needs.

Like a Fine Wine

This part is easy - make sure password aging is enabled.  Since I sometimes need to have different ages for different account types, each is handled (via scripts) on a case-by-case basis.  For the simplest aging setup, simply run:

chage -M 90 <user> 

This will force the user to pick a new password every 90 days, which is generally considered 'secure enough' in most enterprises.  Of course it would be even more secure to perform authentication from a central store like RHEL IdM or a flavor of LDAP, but that is a post for another time!

Lock Them Out

Intruders are a persistent bunch, and sometimes they'll resort to brute force password guessing.  To intercept and deal with this behavior, make sure you configure the system to lock out user accounts after a given number of failed authentication attempts.  

Add the following lines to the auth sections of /etc/pam.d/system-auth and /etc/pam.d/password-auth:

auth required pam_faillock.so preauth silent audit deny=3 \ unlock_time=1200

auth [default=die] pam_faillock.so authfail audit deny=3 \ unlock_time=1200

and add

account required pam_faillock.so

to the account section of the above files.  
 
This will give a user 3 tries at their password.  On a fourth try, the account is locked for 20 minutes.  I have found this time is long enough for a legitimate user to call in for assistance, which then provides an opportunity to verify the user's identity and perhaps have a little educational chat with them about system security.  

To see who is locked out, the access method, and when the lockout timer started, simply run:

faillock 

I like to poll this data via cron on busy systems and generate reports to find problem users or to identify targeted users.  Knowing who the bad guy is targeting can help you take additional steps to mitigate threats going forward.   

There are many more things you can do to harden just the password subsystem of RHEL7, but I'll end this here.  This is just an introduction to some tips, strategies, configurations, and techniques you may want to consider using in your own physical or virtual RHEL 7 environment.   



No comments:

Post a Comment