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.
Check out part two of this tip.
