Avoiding security blunders in Linux and IT infrastructures

When it comes to IT infrastructure security, there are things that IT managers just shouldn't do. This two-part tip is written for those who'd like to avoid making those mistakes. It covers four security areas that are either ignored or overlooked in IT infrastructure security, with a focus on securing Linux-based hosts.

In part one, I focus on problems with installations and the hard-perimeter, soft-center security approach. In part two, I look at common gaps in physical security and the problems caused by the "set-it-and-forget-it" mentality.

Installing more than you need

Using the default installation options during the installation of a Linux distribution can lead to the unnecessary installation of applications or services. This can include tools like X Window, Web browsers and email servers that may not be required on a host. These additional packages can provide services, tools and vulnerabilities that an attacker could exploit in order to compromise your host.

One installation methodology is to install the minimum number of packages (most distributions have a "Minimal" installation option), then add later packages to support any required applications.

Another tactic is to use an installation automation application. One example is Kickstart, which is supported on Red Hat and Mandrake, and may be ported to Debian and other distributions. Kickstart can be configured to only install specific packages and can also ensure other installation settings are consistent across all builds.

On existing systems, it is also worth auditing their installed packages and running applications and services. Obviously, it is considerably harder to remove existing packages without careful testing to guarantee other applications will not be affected. Some packages like X Window, Games, Office tools, media players and "entertainment" packages may be obvious targets for removal.

Other commonly installed packages that are not appropriate on many hosts are development tools. Unless you actively develop applications on a host, development tools are akin to providing a ready-made set of tools to an attacker. This is especially true of bastion hosts in your perimeter. Developer tools should be removed from all systems that do not require them.

Lastly, in addition to making your host less vulnerable, the removal of unneeded packages can also mean patching and updating are simplified.

Hard perimeter, soft center

For too long, the assumption in IT security circles was that a strong perimeter -- firewalls, DMZs and features like IDS/IPS -- would provide adequate protection to your organization from attackers. This sometimes results in hosts inside your perimeter being protected to a lesser degree or not being protected at all.

The assumption that a strong perimeter equals protection from attackers is an illusion. Many attacks originate internally; either inadvertently by an internal employee who, for example, opens a virus-infected email, or deliberately by an employee with malicious intent. These attacks generally target internal resources. Therefore, strong perimeter controls can't stop the spread of viruses, worms or the attentions of an employee turned attacker. Additionally, it is often your internal resources that contain the most valuable data -- financial and customer data or engineering data and trade secrets.

This is not to say the perimeter should not be protected. After all, it is the target for a large number of attacks. However, a far more balanced approach to security needs to be taken. The best approach to this is risk assessment. Review the criticality and potential threat for all your assets, internal and external, and deploy controls according to the resulting output.

In the world of Linux, these host-based controls could include:

• deploying an iptables firewall on your hosts
• using host-based intrusion detection including tools like OSSEC and Tripwire
• locking down the network services on your host to only those required
• securing Samba/NFS file shares to ensure only appropriate access is allowed
• increased logging and auditing
• regular reviews of users and groups
• regular patching and updating
• ensuring physical controls are in place (see "Forgetting the Physical" in part two)

Overall, you should harden your internal hosts in a balanced manner in the same way that perimeter or DMZ-based hosts should be hardened against attack.

Castle walls may stop assaults from the outside, but they do nothing to halt attacks from mutinous inhabitants inside the keep. Of course, if the castle walls are not maintained, getting in from the outside gets easier and easier over time.

In this tip, I look at common mistakes made in physical IT infrastructure security and security maintenance. In part one, I covered problems with installations and the hard-perimeter, soft-center security approach. There are other areas to consider, but I find these particular ones to be frequently overlooked or mishandled.

Forgetting the physical

Many tightly-secured systems have major weaknesses in the physical realm. Poorly-secured physical facilities can allow external and internal attackers access to critical systems. Always ensure hosts are stored in a secure, locked environment. It is no good securing your host if an attacker can steal the physical asset itself or some component of the asset, such as its hard disk drives.

Additionally, make sure any console or management station is automatically logged out or locked, if left unattended. The TMOUT environmental variable for the Bash shell is useful for this. If the console needs to be left logged in, then a tool like vlock will assist by allowing you to lock the console in a logged in state.

Another frequently overlooked physical weakness is the potential to restart the host. By physically rebooting the host, an attacker may potentially manipulate the host. For instance, an attacker may log into single mode and change the root password. There are a number of ways to prevent this, either by ading a BIOS level password, or making the LILO and GRUB boot loaders password-protected. There is a risk that, if the host is remote from you when rebooted, it will require manual intervention to input the password(s). The latter risk posed to availability needs to be balanced against the potential mitigation of physical risks.

Appreciate the the power of entropy

Not many security controls are "set-and-forget," and most require regular maintenance and tweaking, since threats against your hosts don't stay static either. New threats appear and old threats can morph and change. If you apply security controls, then neglect the maintenance and review, you can unknowingly leave your hosts vulnerable. Here are some solutions to prevent potential problems.

Apply patches and updates, especially security-related ones, to hosts on a regular basis.

Updates should be scheduled according to the criticality of the vulnerability being addressed. To assist with this, many security companies calculate the criticality/vulnerability ratings of vulnerabilities. See the CVSS rating system. Take this rating and apply your knowledge of your local environment to determine if you are vulnerable and, if so, to what extent. A rating applicable to your environment then determines the priority for the application of any patch or fix.

Don't think that, because a software patch isn't available, you must live with the vulnerability. Seek out workarounds or alternative controls that you can apply, in place of the software patch, until it is available. For example, other systems, like Intrusion Prevention Services (IPS), can also be configured to detect a particular vulnerability and block exploitation of it.

Monitor security information resources regularly.

Make a habit of checking the SANS Web site, vulnerability mailing lists, announcement lists for the products/tools you use and security company Web sites and forums.

As you are reading, compile a list of the vulnerabilities that apply to you on a daily or weekly basis. Then, analyze and rate them according to the threat they pose to your environment, as discussed in part one of this series. Finally, act on them accordingly.

Think about implementing a configuration management tool such as cfengine or Puppet.

Management tools allow you to remotely and consistently configure your hosts, services and applications. They also allow you to ensure that configurations, users and groups, permissions and other settings are correct on your hosts by regularly resetting these to a centrally-defined default. This helps counter the inevitable effect that entropy has on configurations, and could potentially limit the period of any exposure due to a misconfiguration or unauthorised change.

Regular testing is critical to ensuring continued security.

Regular testing can detect new vulnerabilities and identify any vulnerability that has emerged as a result of entropy or change. Testing processes may include: scanning with open source tools like Nessus or commercial equivalents, in-house or out-sourced application and infrastructure penetration testing or code reviews of applications.

I recommend testing after major changes or on a regular basis with the frequency dependent on the criticality of the host.