These days I believe many inexperienced system administrators don't focus as much as they should on the fundamentals—such as user account management.
Many system administrators are distracted by the urge to patch their systems to address vulnerabilities they aren't susceptible to or to configure their systems with nifty tricks they found on a “tips-and-tricks” or “how-to” website.
This urge, I believe, is rooted in their belief they are a warrior combating the forces of evil in this cyber war.
When a young, inexperienced administrator reports they've “plugged” a major hole in their defenses to their boss, the administrator feels like an important asset.
If they quote details from the vulnerability report including the CVSS base score, impact subscore, and exploitability subscore their boss must think they are a genius.
In Peter Bright's article: “Anonymous speaks: the inside story of the HBGary hack”, he states:
The Anonymous hack was not exceptional: the hackers used standard, widely known techniques to break into systems, find as much information as possible, and use that information to compromise further systems. They didn't have to, for example, use any non-public vulnerabilities or perform any carefully targeted social engineering.
I would never discourage organizations from patching their systems—when it is necessary. Often times, organizations waste time patching unused services which should be removed from the system altogether.
Organizations may patch software to address a vulnerability in a feature which isn't even being used.
Several years ago, I had a young, enthusiastic, inexperienced system administrator working for me. He loved reading these vulnerability reports and he found the inner workings of the system fascinating. His curiosity and his affinity for the hacker subculture was a distraction from his daily responsibilities.
I remember him passionately arguing on two occasions that we must patch our systems immediately. The first was a flaw in OpenSSL's SSL/TLS handshaking code when using Kerberos ciphersuites and the second, a vulnerability in the Apache module which provides Web-based Distributed Authoring and Versioning (WebDAV).
He calmed down after I explained to him that none of our applications use Kerberos ciphersuites and the Apache module isn't statically linked to the daemon nor is it loaded as a dynamic shared object.
I urged him to slow down and think about what he was doing. I did not, however, want to discourage him from learning new things but I needed him to focus on the fundamentals.
Account management is a discipline often overlooked because it is mundane and boring. Neglected, unused accounts are a front door for attackers and often used to escalate privileges or worse, extend the attacker's reach into your enterprise.
I am not a fan of the “Top X Tips to Y” articles but many people prefer this abridged list format due to their busy schedules. Nonetheless, here are some key aspects of account management which I feel are overlooked:
- Types of accounts: Are they system or application accounts? What authentication realm do they belong? Are they internal to an application, database, centralized authentication, or simply local accounts managed by the operating system?
- Account ownership: Who owns the account? If it is an application account responsible for providing a service, who is the primary point of contact? Can anyone directly login to the account?
- When was the last time the account was accessed? Is it obsolete? If it is a user account, when was the last time it was accessed. In my opinion, when in doubt about a user account—lock it. If it is important enough and they need it, they will contact you.
- Password policy: Have a good password policy, implement account aging mechanisms, and change ALL default passwords. In Linux, try to avoid setting a user account's password as root without forcing the user to change it at their next login.
- A common mistake made by system administrators is to login as root, issue the command to change a user account's password but allow the user to enter a new password. When you set a password on an account as root, on most Linux systems the password complexity rules are bypassed allowing the user to choose a weak password.
I only covered the basics. It is critical that system administrators not neglect these not-so-glamorous activities. This is part of a system administrator's daily grind. Don't be afraid to question why someone has a user account on your system—you're responsible.
Cross posted from Security Blanket Technical Blog.