Blunder No. 3: Running privileged services as root
Applications should never run as root. Create unique service accounts with very specific privileges for each application and service running on the machine.
Service accounts typically lack home directories and are restricted in what they can do on the file system if someone tries to log in using the account. If an attacker compromises a service account, he or she still has to get a local exploit working to get more privileges to execute code.
Each application should use a customized account to access the database instead of root or the administrator’s personal account. Web applications should be owned by the appropriate group and user. When assigning domain privileges to Windows applications, don’t give the application administrator-level access.
Major Linux distributions handle service accounts by default, but if the administrator manually configures third-party packages, it’s easy to make a mistake. Remember to switch permissions after all the installation and configuration is complete to make sure root or the administrator’s personal account is no longer the owner of the application.
Blunder 4: Reusing passwords
Go ahead, roll your eyes. We’ve all heard about the evils of reusing passwords across sites, systems, and applications. But the fact remains that it’s a big problem, and sys admins are not immune.
Recently, Mozilla said an unknown attacker broke into a privileged user’s account for its Bugzilla bug tracking database and stole information about 53 critical vulnerabilities. It turned out the “privileged user” had reused the Bugzilla password on another website, and the password had been exposed in that site’s breach.
Many times, servers are set up with weak administrator passwords or with the same password as other machines on the network. Brute-force attacks using common passwords and dictionary words work because enough people still make this elementary mistake. When multiple machines have the same password, the problem is compounded.
Instead of setting up the same root password on all machines, sys admins should opt to use a key file. Each server should have a public key file and the sys admin’s workstation would have the private key associated with the public key. This way, the sys admin can access all the machines that have been deployed on the network, but an attacker moving laterally through the network will not be able to log in without a valid key. And there is no password to intercept.
Blunder 5: Sharing admin accounts
Administrator accounts -- such as access to the database and administrator portals -- are often shared around the network. Instead of setting up the environment so that administrators request elevated privileges when needed, these admin accounts are shared willy-nilly. That's asking for trouble.