Access Control Restrictions: Best Practices on a Linux Server
Working as a freelance Linux consultant, I see a lot of my clients struggle with the problem of access control on a Linux server. Access control restrictions are the basic process of assigning limited user accounts to consultants or employees on your Linux server. It may seem like access control is not a big problem for most people (a common argument that I hear is that my clients trust their consultants or employees), but access control restrictions exist for purposes other than keeping people honest.
Access control restrictions on a Linux server are necessary to prevent intentional or accidental damage to your server (every system administrator can tell a story of how one command ran unexpectedly). In addition, access control restrictions help to protect sensitive information (passwords of others, credit card information, etc) from being accidentally or maliciously used. An example of how someone can accidentally misuse sensitive information is in the case of backups. If a coder is working on your server, and creates a backup of the database for your Wordpress database, he or she might decide to make a backup of the entire database server. In doing so, the coder might transfer that backup to an insecure off-site location (which then is compromised if the data is copied over an insecure file transfer method), or the coder might copy the database backup to a location that all users and applications can access (such as /tmp). This would result in the potential for an outside attacker to now have all of your databases (which might contain information such as credit card numbers).
Another valid example of how access control restrictions are necessary is the example of a software malfunction destroying data. If a software application runs at a higher privilege level than necessary (be it at the file system or database level), this increases the odds of a software malfunction causing problems with your server. Let's face it- no one wants a malfunctioning PHP script to drop or corrupt all of the databases on your server. Whereas all information should be backed up regularly anyways, it is an unnecessary risk.
Once you have determined a need for controlling access to a Linux server, there are many different ways to accomplish this:
* Use sudo for privilege escalation, and assign every coder or consultant their own user accounts. Disable root login via SSH, and add all consultants or coders to the same user group. Finally, change the permissions on the web document root directory to allow all members of the group write access.
* Log all connections via SSH and FTP, to ensure that outside consultants or employees are not logging onto the server when they are not supposed to be working on a project.
* For a database server, create new user accounts for each separate database. This will reduce the damage that an application or malicious user can do to your database server, if a single database application is compromised.
* For temporary accounts or consultant accounts (that are not needed unless assistance is requested), be sure to disable the accounts once access is no longer required.
* For all user accounts, require a password that is not found in any dictionary, and enforce a password length of at least eight characters.
Once you have determined the need for access control restrictions, and have implemented them on your server, you can rest well at night knowing that your server will be safe and sound. Without access control restrictions actively enforced, your Linux server may not be so safe and sound.