As Linux continues its ascent in enterprise computing, major vendor support for business-critical applications is evolving to keep pace. Among the challenges enterprises and vendors face is the need for advanced security and accountability for root account users, application administration accounts, and nonprivileged users as well.

In this article I'll look at securing access to these business-critical applications from a layered security perspective.

Two Minutes of History

The Linux development project has benefited from thousands of contributor hours in every area of the operating system and supporting programs. In this way, Linux enjoys a "best of breed" development architecture (the most effective implementation of an application or program withstands significant scrutiny and is incorporated in a release). This scrutiny allows Linux to provide significant benefit to the enterprise in security areas as well.

From pluggable authentication modules (PAM) and IPTABLES to interactive hardening utilities, Linux now features some of the best programming available in the Unix/Linux product space. But no matter what version of Linux you download, compile, or purchase, the "out of the box" software should be significantly hardened for enterprise use.

Two Minutes of Philosophy

Any enterprise security effort should begin with thoughtful analysis and planning. Incorporating Linux into the enterprise plan should be no exception. Determining the who, what, when, where, and why for asset access on Linux systems is a key step. For example, there may be no need to enable secure HTTPS servers without a Web requirement, or no need to limit CPU cycles per user for a Linux SSH jump-box. Experienced Linux administrators can harden a system in a few hours, but if the activity happens without paying attention to the assets deployed, or consideration for the user community or enterprise requirements, the result may be a very secure system that is very difficult to do business with. The key is to begin with the end in mind.

Security from the Outside In

Securing Linux systems for enterprise use may depend on the applications deployed on the system(s). Figure 1 shows how Linux security may look when viewed as a layered model.

Protecting physical access is a well-described combination of processes, including:

• Shredding printouts from work areas before discarding
• Protecting the server room with keyed access
• Protecting servers in the room with racks with keyed doors
• Password protecting the GRUB or LILO boot mode when possible
• Setting timeouts for console logins in server rooms
• Prohibiting nonconsole root logins
• Adding password-protected screen locks on desktop systems
• Adding smart cards or PKI access to exposed systems

You may have 20 additional items in your enterprise security plan, or discard some of these because they are impractical in your enterprise. Match the security with the value of the assets and fit both within the business framework.

Network and Perimeter Security

The majority of information damage or loss in the enterprise happens via internal access - within the infrastructure intrusion detection systems, gateways, routers, and firewalls - using credentialed accounts. When enterprise-critical applications and/or information reside on Linux systems, there are some additional safeguards:

• Disable insecure or unnecessary network services/daemons. These may include telnet and ftp for Linux systems using SSH, or sendmail for systems with no e-mail requirements. For tighter restrictions on programs starting and stopping on Linux systems, the inet or xinet super daemons can be stopped, and their subservices enabled in a more controlled and auditable way.
• Restrict access using TCP wrappers and IPTABLES where possible. In a nutshell, TCP wrappers can allow or disallow access to a host's TCP services (the xinet super-daemon and all subservices, for example). IPTABLES provide packet filtering based on rules within the Linux kernel. If a packet is allowed into a network or segment, IPTABLES can also determine what the Linux system should do with the packet.

Although this may appear to be a lot of overhead, today's processors and the Linux operating system make quick work of well-designed rule sets, allowing only the right information to reach the right systems. Figure 2 illustrates utilizing IPTABLES and TCP wrappers.

These network layer components are actually Linux system configurations. You may see the corresponding "firewall" and "SecureInetd" tab in the hardening script Bastille, a popular Linux collection of programs for securing some Linux and HP-UX systems. Bastille and other similar utilities provide navigable front ends to the hardening of the Linux systems. Using these configurations in addition to the network infrastructure equipment will make the network space in and around Linux systems more secure.

Securing an Application's Access

The application's access control is a tightrope on any system - multiple administration accounts, user accounts, and multiple applications using separate credentialing systems are the tip of the iceberg. When IT/IS does not receive notification for transfers, terminations, or hires, various databases may retain defunct entries, or new employees may wait for inclusion in these business-criti-cal data sets. Coordinating and streamlining these HR/IS joint functions will improve data integrity and security in the enterprise.

When possible, do the following:

• Use common data warehouses to store account and application access information when appropriate. Although this seems like putting all your eggs in one basket, the ability to credential from one source for a variety of applications provides significant benefits for many users again and again in the enterprise. Using encryption during connection requests, queries, and storage of the warehouse can provide additional security.
• Set a processes-per-user limit on the Linux systems, so that a single breached account cannot create a denial of service or system crash as easily. Generic or group-use accounts are a security risk and should be eliminated or closely scrutinized.
• Disable applications not in service on the Linux system. The print scheduler and utilities and sendmail daemon are two examples. Match the business use for the system with the assets and resources available to increase enterprise security.
• Disallow access to programs not normally used by job functions; for example, data entry staff need not run the GCC compiler on a Linux system. Staff designing case-report forms need not access the SQLPLUS program. Limiting access to staff who have the business requirements for access to the asset improves enterprise security. Using the who, what, where, when, and why benchmark tool for asset access will help describe commands and applications required by account (or job type). (An example visualization tool is shown in Figure 3.)

Grouping users by job function on the vertical axis, with systems (by type) and commands/access methods on the horizontal axis of a spreadsheet, is only one way to visualize the activity that can be regulated on Linux systems, via file permissions, application access ACLs, or other means.

Securing the Linux Operating System

Addressing Linux operating system security requirements encompasses everything mentioned above, but in addition you'll want to perform some safeguarding for the operating system as well. There are hundreds of possibilities, so match your requirement with the appropriate security restrictions. Consider the following:

• Disable core dumps on nondevelopment systems. Since core dumps can provide access information to attackers, eliminate their creation where systems are not creating them.
• Limit programs or commands that can run with elevated privilege. Typical examples of these are setuid or setgroupid programs. Your normal audit procedures should include a search for all setuid or setgid binaries. The appearance of a new one or the changing checksum for the size of an existing one are both yellow flags.
• Secure the LILO/GRUB boot proms so that a system cannot be power-cycled and booted from an alternate source.
• Add a password to single user boot logins.
• Set per-user process memory limits so users cannot consume the entire memory that is available with accidental processes.
• Restrict NFS mount requests to only privileged hosts; mount with a "no-suid" option, so that users cannot create set user-ID programs on network drives.

Access Control at the Linux User Account Level

At a minimum, these steps should regularly be performed as part of the internal system auditing, or whenever new Linux accounts are created:

• Employ shadow passwords with aging and high encryption.
• Search password and credential data structures for infrequently used or orphaned accounts.
• Verify no accounts exist with empty or null passwords.
• Verify no UID = 0 accounts other than root exist.
• Verify no unnecessary "+" tokens appear in password or group files.
• User home directories should be mode 750 (or more restrictive).
• Set/check default user-mask (umask) for new/all accounts.
• Remove generic or pseudo accounts.

The Sum of the Parts

Securing Linux systems for deployment is a subjective process. Your enterprise will be more secure by matching the level of security for each Linux system with the corresponding value of assets accessed by the system. Identifying the uses for the system also identifies the reason for the required security, and helps determine the measure and type of security to levy. The goal of secure systems is to provide safe systems for business processing without inhibiting the normal business processes.

Linux is paying back its more mature operating system relatives (Unix systems) with rapid advances in many areas. Bringing the Linux resources into production securely makes cost-effective sense in many cases in today's enterprise computing landscape.

• Figure 1
• Figure 2
• Figure 3