Issue #6 April 2005

The security dilemma, part 2: Intrusion prevention

Introduction

In the first part of this series, we focused on what to do, think about, and where to begin your investigation when you find someone has gained unauthorized access to your Linux system. The second part of this series focuses on what to do before your system has been compromised. Rather than focusing on specific technical solutions, this article outlines a secure thought process and offers considerations.

Characterize the system

The first step in protecting your system from attack or intrusion is to classify the system. Classification of the system according to its importance, the risk of lost data, and the time required to recover the system gives you an efficient view of what resources to dedicate to the system and how to better protect it.

The first step in protecting your assets is knowing what those assets are worth and to whom. By defining systems according to their mission and availability requirements, you can more effectively evaluate those systems in terms of security requirements. For the sake of argument and simplicity in this article, let's think of three different groups of servers.

Production Available (PA) systems are systems whose mission and availability define a core business. These systems are often computational in nature. For example, a bank or brokerage firm's trading clusters or transactional systems.

Data Available (DA) systems describe databases, CRM, ERP, and other systems relied upon specifically for the data they manage. While equally important to PA systems in a production data center, they support business more than continue it.

Customer Available (CA) systems provide convenience to our customers while optimizing our business processes and increasing revenue and productivity for consumers. These systems often form front ends for PA systems.

These are, of course, broad notions of systems that are convenient to this article. As you well realize, many systems overlap within these categories. But PA, DA, and CA will help us evaluate the systems in terms of host-based security and how these servers integrate into our security and applications infrastructure.

In the first part of this series, we discussed Risk of Action (rA) for determining what to do when your system has been cracked. It's useful to know that rA can be used to proactively evaluate the need for specific attentions to data security when characterizing a system. For example, PA systems will typically have a positive rA where the risk of intrusion (rI) exceeds the value of data (vD). That isn't to say that the data in PA systems isn't valuable, but the relative values show rA to be positive. In cases of positive rA, you're likely to have less (or lesser) data recovery requirements, but downtime is less acceptable. Therefore, taking more action toward active security is of higher importance on PA systems.

Note:
Once you've pre-calculated your rA, it's easier to formulate host-based security policy. rA also gives you a view into data recovery needs.

DA systems would have nearly the opposite evaluation. While security is still an issue, rA is negative, and data integrity and recovery are the primary concerns. With negative rA, you're better off shutting the system so you are able to react to security issues, and therefore active security is secondary.

CA systems fall somewhere in the middle depending on your security and applications infrastructure. CA systems often represent lower risk but, because of their mission, may have a public IP address on the Internet. Since these will be the boxes that will be scanned by would-be attackers, a balance of active security and readiness toward data recovery is warranted. Generally, as CA systems grow and move through the software architectural lifecycle, they tend to morph in PA systems.

Identifying potential targets

With the advantage of rA already calculated, obvious targets are easily identified. Business critical PA systems are a given, but DA and CA systems cracked and ruined easily cripple a business unit. But it's not quite that simple. To really identify potential targets for attack, you have to think like an attacker.

A generic attack goes through five phases:

  • Inventory and exploring
  • Vulnerability assessment
  • Design and crafting of exploits
  • Execution of the attack
  • Covering tracks

At the beginning of this sequence, the attacker begins a process of checking doorknobs. This is where the attacker identifies targets, and where we can too. Unless an attacker is looking for a particular system (possible, but unlikely) this is a process infused with want of ease and utility but sometimes mitigated by paranoia. As with the five steps, attacks generally follow forensic patterns (refer to part one in this series). Taking an attacker's view, strolling through the doorknobs (systems) in your environment will quickly show you where the first targets lie.

While attackers rarely look for specific systems, they do tend to look for specific types of systems. That is, aside from easily cracked systems, an attacker will seek out powerful systems with far reaching effects. For example, in an attack on web services, an attacker would seek web servers or the source for content to those servers.

Security at work

Now that we've talked about what could happen, what do we do to secure our systems? Put on your intruder thinking cap and make-believe attack your own environment. Following the steps an attacker might is like language immersion. Do as the Romans do and all that.

This is probably where you want to stop thinking from the host level down and go diagram your network. Identify all the machines that are connected to the Internet, including routers, switches, servers, and workstations. Then, evaluate the security precautions in place on those machines and their rA. If you have a main firewall, or cluster of firewalls, this is your first line of defense, so it should be the most secure (physically and network) machine in the data center. This is also the machine with the least number of administrators. It's widely recognized that a computer is only as secure as the administrator is trustworthy, and more administrators per user increases this risk.

As an attacker traverses your environment, they will most likely exploit your systems by component as well as attempting to own an entire box. So, beyond identifying servers as targets, it's useful to consider the components of an attack by their layers. In the words of Douglas Adams, "Think deep." In other words, iptables is not enough. To secure a system, you need to secure the system in layers. Think of system and data security as the attacker does.

With a watch list and rA, you are now equipped to make decisions about the balance of security and usability on your systems. What's secure for this type of server? How do the security requirements of this box fit into your security and applications infrastructure? What measures will allow us to be comfortable with our security and still allow sysadmins, database admins, etc. to do their jobs?

Security is as security does: A team effort

Ultimately, security is about risk management: Measurement and mitigation with policy, processes, and teamwork. Security policy supports the requirements of business while mitigating the risks to a level with which your company is comfortable.

Implementation of a new security policy can accomplished through individual guidelines or bulletins. The documents should be on a single subject such as email, firewalls, or passwords and should provide enough detail to be testable. Keep it small and focused, and assign responsibility to the correct organizational level.

People outside the security team must be involved. Otherwise, they are likely to take shortcuts. Still, security policy need be realistic. If users think that a policy is silly, they are less likely to comply.

Once you feel you have a realistic policy drawn up, work to get the backing of senior officers in your company. This backing makes enforcement possible and helps to make it clear to users that failure to comply will result in real consequences.

After policy, actual security practice is also the responsibility of each person who touches a system. Encourage everyone to be security conscious and to monitor systems proactively.

Conclusion

Ultimately, security is a combination of technology and policy. It's tempting to believe that technology can deliver a totally secure world, but perfect security requires perfection that doesn't exist and never will. Software is imperfect, and so all software has bugs. Even if software could be made perfect, it wouldn't resolve the security dilemma entirely because most attacks involve some manipulation of human beings. If we increase the difficulty of attacking technology, would-be attackers will shift their focus to the person at the console, and in many cases already have. Understanding your role in maintaining security will prevent you from becoming the point of weakness.

Remember, security is relative, proportional, and fluid entity. As system and security administrators, we need to be dynamic and our mantra is one of awareness.

About the author

Matt Frye is a Unix/Linux system administrator living in North Carolina. He is Chairman of the North Carolina System Administrators and is an active member of the Triangle Linux User Group. In his spare time, he enjoys fly fishing and mental Kung Foo.