Security isn’t just a technology problem鈥攊t’s a people problem. Many basic mistakes are often made by those who should know better: system administrators and other IT staff.
Intermedia’s 2015 Insider Risk Report found that IT professionals are the most likely to engage in “risky” security practices, such as sharing passwords/logins, reusing personal passwords for business applications, or handing personal account credentials to others.
Top 10 Security Mistakes Sysadmins Must Avoid
Given the god-like control sysadmins have, these mistakes are far more dangerous when made by them than by ordinary users. IT professionals are just as susceptible to phishing, malware, and other attacks as regular users, and stolen privileged sysadmin credentials almost always lead to far more severe security incidents. Admin errors cause much greater damage than user errors. Here are ten common security mistakes and their remedies:
1. Using sudo for Everything
When you log in as root, you gain complete control over that metal box in front of you. This is extremely dangerous because if your credentials are stolen, an attacker can do anything they want with your system.
In Windows terms, there’s no need to log in with an Administrator account when not performing admin-level tasks. You can log in with a personal account and then use sudo for specific commands when needed, rather than logging directly into the system as root.
It’s all too easy to slip back into old habits. If just one command requires sudo, the entire script fails鈥攁nd you have to start all over. If you can’t identify which commands need privileges and which don’t, you’ll likely fall back to running everything with sudo.
2. Running Scripts from Unknown Sources
Installing third-party Linux applications is another area where sudo can be abused. All you need to do is copy and paste commands directly into the terminal to launch the installation script鈥攃ommands already set to execute with sudo. Every command in the script will run with privileged permissions.
For example, the following copied directly from a webpage (URL redacted):
sudo -v && wget -nv -O- https://xxx/xxx/linux-installer.py | sudo python -c “import sys; main=lambda:sys.stderr.write(‘Download failed/n’); exec(sys.stdin.read()); main()”
This command grants sudo privileges to something hosted elsewhere on the internet, along with permission to run Python locally. This is strongly discouraged!! Windows sysadmins face a similar potential disaster鈥攅xecuting downloaded PowerShell scripts.
Even if you trust the source, never assume scripts downloaded from the internet are safe. Always carefully inspect the script’s contents first to confirm that executing these commands won’t cause unwanted behavior.
3. Running Privileged Services as root
Applications should never run as root. Create separate service accounts with specific permissions for every application and service running on the machine.
Service accounts typically lack home directories, and if you log in with a service account, file system operations are usually restricted. Even if an attacker compromises a service account, they still need to figure out a local privilege escalation exploit to gain more permissions to execute code.
Every application must access databases using a custom account, not the root or admin’s personal account. Web applications should belong to the appropriate group and user. When assigning domain permissions to Windows applications, never grant administrator-level privileges.
Major Linux distributions use service accounts by default, but it’s easy to make mistakes if admins manually configure third-party packages. Remember to switch permissions after all installation and configuration is complete, ensuring root or the admin’s personal account is no longer the owner of that application.
4. Reusing Passwords
Brace yourself for the next shock! We’ve all heard plenty about the sin of reusing passwords across different websites, systems, and applications. But the harsh truth is, this problem remains a major issue today, and sysadmins are not immune.
Recently, Mozilla reported that an unknown attacker breached a privileged user’s Bugzilla bug-tracking database account and stole information on roughly 33 critical vulnerabilities. The truth was: that “privileged user” reused their Bugzilla password on another website, and that password had already been exposed in a breach on that site.
Far too often, servers are set up with weak admin passwords or the same password as other machines on the network. Brute-force attacks using common passwords and dictionary words succeed because enough people still make this basic mistake. When multiple machines share the same password, the problem compounds.
Sysadmins should not set the same root password on all machines; instead, they should opt for key files. Each server should have a public key file, and the sysadmin’s workstation should hold the private key associated with that public key file. This way, sysadmins can access all machines deployed on the network, while an attacker moving laterally within the network cannot log in without a valid key. Passwords can’t be intercepted either.
5. Sharing Administrator Accounts
Administrator accounts鈥攕uch as those for accessing databases and admin panels鈥攁re often shared across the network. Instead of setting up an environment where admins can request privileges when needed, sharing admin accounts haphazardly is simply asking for trouble.
Ideally, individual accounts should be used: one root account, and then a separate account distributed to each administrator. Admin accounts shouldn’t be assigned the highest level of access from the start鈥攕pecial access can be requested when performing specific tasks. Intermedia’s report found that 32% of IT professionals gave their login and password credentials to other employees.
Not knowing who is actually using an admin account is bad enough. What’s worse: these passwords often aren’t changed after an administrator leaves. Since passwords aren’t rotated regularly, a scenario where a former colleague waltzes back in, causes damage, and slips away without a trace is entirely possible. Intermedia’s survey found that 1 in 5 IT professionals admitted they would access their former company’s information after leaving. Password change policies aren’t just for end users. Rotate passwords regularly, especially admin and service account passwords. And whenever an administrator departs, be sure to reset passwords immediately.
6. Walking Away After Troubleshooting
During troubleshooting, you pull all sorts of tricks and experiments to find and fix the problem. While making these attempts, you’re likely to bypass normal procedures. The problem often arises after you’ve fixed the issue you found and moved on to the next task. Admins are always in a hurry and may forget to restore the environment, leaving things in disarray鈥攇iving potential abuse an opening.
For instance, while trying to figure out why an application is unresponsive, you might open some ports in the firewall. Once the issue is fixed, you need to close those temporarily opened ports before attackers exploit them. Similarly, if you temporarily disabled SELinux because it interfered with troubleshooting, remember to re-enable it once you’re done.
During troubleshooting, document the changes you make so you can revert settings to their original state afterward鈥攅xcept for the modifications you genuinely need to keep.
7. Failing to Track Log Files
Log files are useful, especially during troubleshooting, because they let you see what’s happening at the most granular level. When you no longer need these log files, stop the processes generating them. Trust me, one of the last things you want is a debugging process left running, continuously producing log files that contain information potentially useful to attackers.
As a best practice, always remember to keep track of which logs are created and be mindful of the type of information they contain.
8. Storing Passwords in Text Files
When there are too many passwords to remember, it’s tempting to record them all in a text file. To an attacker snooping around, that’s a godsend鈥攁 skeleton key to various systems. The consequences of this practice are obvious, but nearly everyone has heard at least one or two stories about all important passwords being stored in a text file.
If passwords must be saved in plaintext within a file (such as database credentials for an application), set file permissions to restrict who can view the contents of that file. Additionally, ensure the database account is a service account with only the minimum necessary privileges.
9. Leaving Dormant Accounts
Expired, restricted accounts are just things in the way. Perhaps some software was evaluated and then uninstalled, but the account added as part of the installation process remains on the system. Don’t do that. Attackers can easily exploit such forgotten accounts, especially if they still have default passwords.
For accounts that need to remain on the system but won’t be used in the future, disable them by modifying the password file and replacing the account password with a string. Obviously, when an employee leaves, revoking their accounts immediately is a mandatory step.
10. Neglecting to Patch
A golden rule: install security updates as soon as they’re released (of course, back up the affected systems first). Far too many servers are compromised not because of zero-day exploits, but because years-old patches were never applied.
Even for critical servers, a short period of planned maintenance downtime is far better than hours or even days of downtime after an attacker successfully breaches the system. Patches should be tested immediately upon release and scheduled tasks created for rolling out updates.
Unfortunately, however, you may encounter frustration when trying to patch immediately鈥攗sually because the patch will break a legacy application. In such cases, don’t simply shrug your shoulders and say “too bad.” Escalate the situation promptly to the appropriate stakeholders. Raise the issue. There may be a way to isolate the server to minimize risk or adopt new technology to reduce reliance on the legacy product.
In real life, patching can be as terrifying as a political quagmire. If a manager above your pay grade orders systems not to be updated, make sure everyone understands the risks of not pat