In the prior edition of this article, we covered several general practices to avoid when deploying a new Linux system. The focus there was primarily in hardening the system from an outside perspective. While hardening against external attack is certainly crucial, one should never stop there. For this reason, I intend to go over some noteworthy things to avoid which can adversely effect the internal security of a Linux host.

1. Don't run any daemons or services which don't need to be running. Avoiding such behavior will go a long way in preventing internally-launched attacks on your Linux host. For instance, if you're using sendmail for nothing more than mailing logs to yourself, it doesn't need to be run as a daemon. This also includes the X server, since a graphical environment is rarely useful on a production server.
2. Ironically, don't store passwords in /etc/passwd. The old, outmoded method for storing passwords on a UNIX-like system is hashed in /etc/passwd.  The password itself isn't readable by human eyes, since it is encrypted. But since /etc/passwd must be world-readable, it is extremely vulnerable to brute-force decryption and can put a whole system at high risk. To overcome this limitation, the concept of a shadow password file was conceived. The basic idea behind the shadow password file is that the normal user account info is still stored in the old /etc/passwd file, but the password itself is left out. Instead, it is stored encrypted in a separate file which is not readable by any user but root. On most Linux and modern UNIX systems, this is the default behavior. However, this is still worth taking note of, as many distros still give you the opportunity to enable or disable the shadow file. Unless you are using something like NIS which needs the passwords to be in /etc/password, always enable shadow passwords.
3. Don't allow unprivileged users to have free reign over your resources. Without limitations, users can overwhelm the system making it unusable for others, or even bring it down entirely. With this in mind, it's wise to limit user's resource allocation to a reasonable value. This can be done with the /etc/security/limits.conf file. In a future article I will go into further depth on limits.conf, but it's a bit out-of-scope for this topic. However, I will say that it's always a good practice to use limits.conf to prevent core dumps altogether on production systems. Storage space availability is also a concern, since a malicious user could potentially create a large enough file to cause a local denial of service attack. To prevent such behavior, you should limit the amount of space each user and/or group is allowed by making use of the quotas facility coupled with a policy in /etc/mtab on your Linux host. To cover quotas in any depth here would make this article far too long, so look for a future article on this topic.
4. Don't let just anybody try to login as root. On *BSD and most other UNIX systems, a concept called wheel limits who can and cannot 'su'; only members of the wheel group are even allowed to try. The same concept exists on Linux, though it is disabled by default (for mainly political reasons). Thankfully, it can be re-enabled quite easily. First, add any users whom you would like to be able to 'su' to the group called wheel. Make sure root is also added to the wheel group! Afterwards, all that's left to do is add or uncomment one line in /etc/pam.d/su . On a Red Hat or derivitive system,  the line will look like so:

   ---

   auth  required  /lib/security/$ISA/pam_wheel.so  use_uid

   ---

   On a Debian or derived platform (like Ubuntu), it will appear as follows:

   ---

   auth  required  pam_wheel.so  group=wheel

   ---

   From that point onwards, only those belonging in the wheel group will be able to 'su'. There is much, much more in pam which can be used to harden a Linux host internally, but that's out of the scope of this article.
5. Don't give more file access than is necessary. In fact, the general rule of thumb on this matter should be "give the least amount of access necessary to accomplish one's duties". Your own user account should be no exception. This is especially true of tools which use the SUID bit, since they run at the system level and not on the normal user level. Even applications like "ping", which requires SUID for raw socket access, can be a potential security threat. I recommend creating special-purpose groups for the usage of these SUID applications, then delegate the ability to use them to only those who need to use them regularly. For example, suppose you had a system where some network engineers regularly needed to use the 'ping' tool, but no other users needed access to said file. You could create a group called ping, the members of which will be allowed to use the ping utility. Afterwards, you'd change the group ownership of the ping command to be the ping group, and set the permissions like follows:

   ---

   -rwsr-x---  1 root ping 33272 May  3  2006 /bin/ping

   ---

      ... Additionally, users don't usually need to be able to list the contents of many directories, let alone wander them unhindered. For this reason, some care should be taken to tighten down the default permissions on some key directories. To give you an example, here is a simple hardening script which might help you get started: http://anti-trend.homelinux.org/pub/resources/tighten-file-perms.sh There are also other widely used internal hardening methods, such as Bastille.
6. Don't fly blind. As Pausanias would have written had he been a sysadmin, "know thy server..." You should have key logs mailed to an account external to the system in question on a regular basis. Every distro of any consequence will have a facility to automate this, such as the logrotate script or another application or script which is similar in functionality. Make use of it, and at least skim these logs daily. There are also a myriad of other ways to monitor the system for changes, which I will leave largely as an exercise for the reader. However, I would recommend taking a glance at AIDE (designed to replace Tripwire) and chkrootkit (intended to search for signs of a rootkit, but will also detect system changes such as new accounts and changes in key binaries).

⇐ Part 1