Since this book is about building secure Linux Internet servers from the ground up, you’re probably expecting system-hardening procedures, guidelines for configuring applications securely, and other very specific and low-level information. And indeed, subsequent chapters contain a great deal of this.
But what, really, are we hardening against? The answer to that question is different from system to system and network to network, and in all cases, it changes over time. It’s also more complicated than most people realize. In short, threat analysis is a moving target.
Far from a reason to avoid the question altogether, this means that threat modeling is an absolutely essential first step (a recurring step, actually) in securing a system or a network. Most people acknowledge that a sufficiently skilled and determined attacker[2] can compromise almost any system, even if you’ve carefully considered and planned against likely attack-vectors. It therefore follows that if you don’t plan against even the most plausible and likely threats to a given system’s security, that system will be particularly vulnerable.
This chapter offers some simple methods for threat modeling and risk management, with real-life examples of many common threats and their consequences. The techniques covered should give enough detail about evaluating security risks to lend context, focus, and the proper air of urgency to the tools and techniques the rest of the book covers. At the very least, I hope it will help you to think about network security threats in a logical and organized way.
Simply put, risk is the relationship between your assets, vulnerabilities characteristic of or otherwise applicable to those assets, and attackers who wish to steal those assets or interfere with their intended use. Of these three factors, you have some degree of control over assets and their vulnerabilities. You seldom have control over attackers.
Risk analysis is the identification and evaluation of the most likely permutations of assets, known and anticipated vulnerabilities, and known and anticipated types of attackers. Before we begin analyzing risk, however, we need to discuss the components that comprise it.
Just what are you trying to protect? Obviously you can’t identify and evaluate risk without defining precisely what is at risk.
This book is about Linux security, so it’s safe to assume that one or more Linux systems are at the top of your list. Most likely, those systems handle at least some data that you don’t consider to be public.
But that’s only a start. If somebody compromises one system, what sort of risk does that entail for other systems on the same network? What sort of data is stored on or handled by these other systems, and is any of that data confidential? What are the ramifications of somebody tampering with important data versus their simply stealing it? And how will your reputation be impacted if news gets out that your data was stolen?
Generally, we wish to protect data and computer systems, both individually and network-wide. Note that while computers, networks, and data are the information assets most likely to come under direct attack, their being attacked may also affect other assets. Some examples of these are customer confidence, your reputation, and your protection against liability for losses sustained by your customers (e.g., e-commerce site customers’ credit card numbers) and for losses sustained by the victims of attacks originating from your compromised systems.
The asset of
"nonliability”
(i.e., protection against being held legally or even criminally
liable as the result of security incidents) is especially important
when you’re determining the value of a given
system’s integrity (system
integrity is defined in the next section).
For example, if your recovery plan for restoring a compromised DNS server is simply to reinstall Red Hat with a default configuration plus a few minor tweaks (IP address, hostname, etc.), you may be tempted to think that that machine’s integrity isn’t worth very much. But if you consider the inconvenience, bad publicity, and perhaps even legal action that could result from your system’s being compromised and then used to attack someone else’s systems, it may be worth spending some time and effort on protecting that system’s integrity after all.
In any given case, liability issues may or may not be significant; the point is that you need to think about whether they are and must include such considerations in your threat analysis and threat management scenarios.
Once you’ve determined what you need to protect, you
need to decide what levels and types of protection each asset
requires. I call the types security
goals
;
they fall into several interrelated categories.
Some types of data need to be protected against eavesdropping and other inappropriate disclosures. “End-user” data such as customer account information, trade secrets, and business communications are obviously important; “administrative” data such as logon credentials, system configuration information, and network topology are sometimes less obviously important but must also be considered.
The ramifications of disclosure vary for different types of data. In some cases, data theft may result in financial loss. For example, an engineer who emails details about a new invention to a colleague without using encryption may be risking her ability to be first-to-market with a particular technology should those details fall into a competitor’s possession.
In other cases, data disclosure might result in additional security
exposures. For example, a system administrator who uses
telnet
(an unencrypted
protocol) for remote administration may be risking disclosure of his
logon credentials to unauthorized eavesdroppers who could
subsequently use those credentials to gain illicit access to critical
systems.
Regardless of the need to keep a given piece or body of data secret, you may need to ensure that the data isn’t altered in any way. We most often think of data integrity in the context of secure data transmission, but important data should be protected from tampering even if it doesn’t need to be transmitted (i.e., when it’s stored on a system with no network connectivity).
Consider the ramifications of the files in a Linux
system’s /etc directory being
altered by an unauthorized user: by adding her username to the
wheel entry in /etc/group,
a user could grant herself the right to issue the command
su root -. (She’d still need
the root password, but we’d prefer that she not be
able to get even this far!) This is an example of the need to
preserve the integrity of local data.
Let’s take another example: a software developer who makes games available for free on his public web site may not care who downloads the games, but almost certainly doesn’t want those games being changed without his knowledge or permission. Somebody else could inject virus code into it (for which, of course, the developer would be held accountable).
We see then that data integrity, like data confidentiality, may be desired in any number and variety of contexts.
System integrity refers to whether a computer system is being used as its administrators intend (i.e., being used only by authorized users, with no greater privileges than they’ve been assigned). System integrity can be undermined both by remote users (e.g., connecting over a network) and by local users escalating their own level of privilege on the system.
The state of “compromised system integrity” carries with it two important assumptions:
Data stored on the system or available to it via trust relationships (e.g., NFS shares) may have also been compromised; that is, such data can no longer be considered confidential or untampered with.
System executables themselves may have also been compromised.
The second assumption is particularly scary: if you issue the command
ps auxw
to view all running processes on a
compromised system, are you really seeing
everything, or could the ps binary have been
replaced with one that conveniently omits the
attacker’s processes?
Tip
A collection of such “hacked”
binaries, which usually includes both hacking tools and altered
versions of such common commands as ps,
ls, and who, is called a
rootkit. As advanced or arcane as this may
sound, rootkits are very common.
Industry best practice (not to mention common sense) dictates that a compromised system should undergo "bare-metal recovery”; i.e., its hard drives should be erased, its operating system should be reinstalled from source media, and system data should be restored from backups dated before the date of compromise, if at all. For this reason, system integrity is one of the most important security goals. There is seldom a quick, easy, or cheap way to recover from a system compromise.
The other category of security goals we’ll discuss is availability. “System availability” is short for “the system’s availability to users.” A network or system that does not respond to user requests is said to be “unavailable.”
Obviously, availability is an important goal for all networks and systems. But it may be more important to some than it is to others. An online retailer’s web site used to process customers’ orders, for example, requires a much greater assurance of availability than a “brochure” web site, which provides a store’s location and hours of operation but isn’t actually part of that store’s core business. In the former case, unavailability equals lost income, whereas in the latter case, it amounts mainly to inconvenience.
Availability may be related to other security goals. For example, suppose an attacker knows that a target network is protected by a firewall with two vulnerabilities: it passes all traffic without filtering it for a brief period during startup, and it can be made to reboot if bombarded by a certain type of network packet. If the attacker succeeds in triggering a firewall reboot, he will have created a brief window of opportunity for launching attacks that the firewall would ordinarily block.
This is an example of someone targeting system availability to facilitate other attacks. The reverse can happen, too: one of the most common reasons cyber-vandals compromise systems is to use them as launch-points for " Distributed Denial of Service” (DDoS) attacks, in which large numbers of software agents running on compromised systems are used to overwhelm a single target host.
The good news about attacks on system availability is that once the attack ends, the system or network can usually recover very quickly. Furthermore, except when combined with other attacks, Denial of Service attacks seldom directly affect data confidentiality or data/system integrity.
The bad news is that many types of DoS attacks are all but impossible to prevent due to the difficulty of distinguishing them from very large volumes of “legitimate” traffic. For the most part, deterrence (by trying to identify and punish attackers) and redundancy in one’s system/network design are the only feasible defenses against DoS attacks. But even then, redundancy doesn’t make DoS attacks impossible; it simply increases the number of systems an attacker must attack simultaneously.
Warning
When you design a redundant system or network (never a bad idea), you should assume that attackers will figure out the system/network topology if they really want to. If you assume they won’t and count this assumption as a major part of your security plan, you’ll be guilty of “security through obscurity.” While true secrecy is an important variable in many security equations, mere “obscurity” is seldom very effective on its own.
Who might attack your system, network, or data? Cohen et al,[3] in their scheme for classifying information security threats, provide a list of “actors” (threats), which illustrates the variety of attackers that any networked system faces. These attackers include the mundane (insiders, vandals, maintenance people, and nature), the sensational (drug cartels, paramilitary groups, and extortionists), and all points in between.
As you consider potential attackers, consider two things. First, almost every type of attacker presents some level of threat to every Internet-connected computer. The concepts of distance, remoteness, and obscurity are radically different on the Internet than in the physical world, in terms of how they apply to escaping the notice of random attackers. Having an “uninteresting” or “low-traffic” Internet presence is no protection at all against attacks from strangers.
For example, the level of threat that drug cartels present to a hobbyist’s basement web server is probably minimal, but shouldn’t be dismissed altogether. Suppose a system cracker in the employ of a drug cartel wishes to target FBI systems via intermediary (compromised) hosts to make his attacks harder to trace.
Arguably, this particular scenario is unlikely to be a threat to most
of us. But impossible? Absolutely not. The technique of relaying
attacks across multiple hosts is common and time-tested; so is the
practice of scanning ranges of IP addresses registered to Internet
Service Providers in order to identify vulnerable home and business
users. From that viewpoint, a hobbyist’s web server
is likely to be scanned for vulnerabilities on a regular basis by a
wide variety of potential attackers. In fact, it’s
arguably likely to be scanned more heavily than
“higher-profile” targets. (This is
not an exaggeration, as we’ll see in our discussion
of Intrusion Detection in Chapter 11.)
The second thing to consider in evaluating threats is that it’s impossible to anticipate all possible or even all likely types of attackers. Nor is it possible to anticipate all possible avenues of attack (vulnerabilities). That’s okay: the point in threat analysis is not to predict the future; it’s to think about and analyze threats with greater depth than “someone out there might hack into this system for some reason.”
You can’t anticipate everything, but you can take reasonable steps to maximize your awareness of risks that are obvious, risks that are less obvious but still significant, and risks that are unlikely to be a problem but are easy to protect against. Furthermore, in the process of analyzing these risks, you’ll also identify risks that are unfeasible to protect against regardless of their significance. That’s good, too: you can at least create recovery plans for them.
Many of the threats are fairly obvious and easy to understand. We all know that business competitors wish to make more money and disgruntled ex-employees often want revenge for perceived or real wrongdoings. Other motives aren’t so easy to pin down. Even though it’s seldom addressed directly in threat analysis, there’s some value in discussing the motives of people who commit computer crimes.
Attacks on data confidentiality, data integrity, system integrity, and system availability correspond pretty convincingly to the physical-world crimes of espionage, fraud, breaking and entering, and sabotage, respectively. Those crimes are committed for every imaginable motive. As it happens, computer criminals are driven by pretty much the same motives as “real-life” criminals (albeit in different proportions). For both physical and electronic crime, motives tend to fall into a small number of categories.
One of the most compelling and understandable reasons for computer crime is money. Thieves use the Internet to steal and barter credit card numbers so they can bilk credit card companies (and the merchants who subscribe to their services). Employers pay industrial spies to break into their competitors’ systems and steal proprietary data. And the German hacker whom Cliff Stoll helped track down (as described in Stoll’s book, The Cuckcoo’s Egg) hacked into U.S. military and defense-related systems for the KGB in return for money to support his drug habit.
Financial motives are so easy to understand that many people have trouble contemplating any other motive for computer crime. No security professional goes more than a month at a time without being asked by one of their clients “Why would anybody want to break into my system? The data isn’t worth anything to anyone but me!”
Actually, even these clients usually do have data over which they’d rather not lose control (as they tend to realize when you ask, “Do you mean that this data is public?”) But financial motives do not account for all computer crimes or even for the most elaborate or destructive attacks.
In recent years, Pakistani attackers have targeted Indian web sites (and vice versa) for defacement and Denial of Service attacks, citing resentment against India’s treatment of Pakistan as the reason. A few years ago, Serbs were reported to have attacked NATO’s information systems (again, mainly web sites) in reaction to NATO’s air strikes during the war in Kosovo. Computer crime is very much a part of modern human conflict; it’s unsurprising that this includes military and political conflict.
It should be noted, however, that attacks motivated by the less lofty goals of bragging rights and plain old mischief-making are frequently carried out with a pretense of patriotic, political, or other “altruistic” aims — if impairing the free speech or other lawful computing activities of groups with which one disagrees can be called altruism. For example, supposedly political web site defacements, which also involve self-aggrandizing boasts, greetings to other web site defacers, and insults against rival web site defacers, are far more common than those that contain only political messages.
Low self-esteem, a desire to impress others, revenge against society in general or a particular company or organization, misguided curiosity, romantic misconceptions of the “computer underground” (whatever that means anymore), thrill-seeking, and plain old misanthropy are all common motivators, often in combination. These are examples of personal motives — motives that are intangible and sometimes inexplicable, similar to how the motives of shoplifters who can afford the things they steal are inexplicable.
Personal and psychological reasons tend to be the motives of virus writers, who are often skilled programmers with destructive tendencies. Personal motives also fuel most "script kiddies”: the unskilled, usually teenaged vandals responsible for many if not most external attacks on Internet-connected systems. (As in the world of nonelectronic vandalism and other property crimes, true artistry among system crackers is fairly rare.)
The Honeynet Project, whose mission is “to learn the tools, tactics, and motives of the blackhat community, and share those lessons learned” (http://www.honeynet.org), even has a Team Psychologist: Max Kilger, PhD. I mention Honeynet in the context of psychology’s importance in network threat models, but I highly recommend the Honeynet Team’s web site as a fascinating and useful source of real-world Internet security data.
We’ve discussed some of the most common motives of computer crime, since understanding probable or apparent motives helps predict the course of an attack in progress and in defending against common, well-understood threats. If a given vulnerability is well known and easy to exploit, the only practical assumption is that it will be exploited sooner or later. If you understand the wide range of motives that potential attackers can have, you’ll be less tempted to wrongly dismiss a given vulnerability as “academic.”
Keep motives in mind when deciding whether to spend time applying software patches against vulnerabilities you think unlikely to be targeted on your system. There is seldom a good reason to forego protections (e.g., security patches) that are relatively cheap and simple.
Before we leave the topic of motives, a few words about degrees of motivation. I mentioned in the footnote on the first page of this chapter that most attackers (particularly script kiddies) are easy to keep out, compared to the dreaded “sufficiently motivated attacker.” This isn’t just a function of the attacker’s skill level and goals: to a large extent, it reflects how badly script kiddies and other random vandals want a given attack to succeed, as opposed to how badly a focused, determined attacker wants to get in.
Most attackers use automated tools to scan large ranges of IP addresses for known vulnerabilities. The systems that catch their attention and, therefore, the full focus of their efforts are “easy kills”: the more systems an attacker scans, the less reason they have to focus on any but the most vulnerable hosts identified by the scan. Keeping your system current (with security patches) and otherwise “hardened,” as recommended in Chapter 3, will be sufficient protection against the majority of such attackers.
In contrast, focused attacks by strongly motivated attackers are by definition much harder to defend against. Since all-out attacks require much more time, effort, and skill than do script-driven attacks, the average home user generally needn’t expect to become the target of one. Financial institutions, government agencies, and other “high-profile” targets, however, must plan against both indiscriminate and highly motivated attackers.
Risk isn’t just about assets and attackers: if an asset has no vulnerabilities (which is impossible, in practice, if it resides on a networked system), there’s no risk no matter how many prospective attackers there are.
Note that a vulnerability only represents a potential, and it remains so until someone figures out how to exploit that vulnerability into a successful attack. This is an important distinction, but I’ll admit that in threat analysis, it’s common to lump vulnerabilities and actual attacks together.
In most cases, it’s dangerous not to: disregarding a known vulnerability because you haven’t heard of anyone attacking it yet is a little like ignoring a bomb threat because you can’t hear anything ticking. This is why vendors who dismiss vulnerability reports in their products as “theoretical” are usually ridiculed for it.
The question, then, isn’t whether a vulnerability can be exploited, but whether foreseeable exploits are straightforward enough to be widely adopted. The worst-case scenario for any software vulnerability is that exploit code will be released on the Internet, in the form of a simple script or even a GUI-driven binary program, sooner than the software’s developers can or will release a patch.
If you’d like to see an explicit enumeration of the wide range of vulnerabilities to which your systems may be subject, I again recommend the article I cited earlier by Fred Cohen and his colleagues (http://heat.ca.sandia.gov/papers/cause-and-effect.html). Suffice it to say here that they include physical security (which is important but often overlooked), natural phenomena, politics, cryptographic weaknesses, and, of course, plain old software bugs.
As long as Cohen’s list is, it’s a necessarily incomplete list. And as with attackers, while many of these vulnerabilities are unlikely to be applicable for a given system, few are impossible.
I haven’t reproduced the list here, however, because my point isn’t to address all possible vulnerabilities in every system’s security planning. Rather, of the myriad possible attacks against a given system, you need to identify and address the following:
Vulnerabilities that are clearly applicable to your system and must be mitigated immediately
Vulnerabilities that are likely to apply in the future and must be planned against
Vulnerabilities that seem unlikely to be a problem later but are easy to mitigate
For example, suppose you’ve installed the imaginary Linux distribution Bo-Weevil Linux from CD-ROM. A quick way to identify and mitigate known, applicable vulnerabilities (item #1 from the previous list) is to download and install the latest security patches from the Bo-Weevil web site. Most (real) Linux distributions can do this via automated software tools, some of which are described in Chapter 3.
Suppose further that this host is an SMTP gateway (these are described in detail in Chapter 7). You’ve installed the latest release of Cottonmail 8.9, your preferred (imaginary) Mail Transport Agent (MTA), which has no known security bugs. You’re therefore tempted to skip configuring some of its advanced security features, such as running in a restricted subset of the filesystem (i.e., in a "chroot jail,” explained in Chapter 6).
But you’re aware that MTA applications have historically been popular entry points for attackers, and it’s certainly possible that a buffer overflow or similar vulnerability may be discovered in Cottonmail 8.9 — one that the bad guys discover before the Cottonmail team does. In other words, this falls into category #2 listed earlier: vulnerabilities that don’t currently apply but may later. So you spend an extra hour reading manpages and configuring your MTA to operate in a chroot jail, in case it’s compromised at some point due to an as-yet-unpatched security bug.
Finally, to keep up with emerging threats, you subscribe to the official Bo-Weevil Linux Security Notices email list. One day you receive email from this list describing an Apache vulnerability that can lead to unauthorized root access. Even though you don’t plan on using this host as a web server, Apache is installed, albeit not configured or active: the Bo-Weevil installer included it in the default installation you chose, and you disabled it when you hardened the system.
Therefore, the vulnerability doesn’t apply now and probably won’t in the future. The patch, however, is trivially acquired and applied, thus it falls into category #3 from our list. There’s no reason for you not to fire up your autoupdate tool and apply the patch. Better still, you can uninstall Apache altogether, which mitigates the Apache vulnerability completely.
[2] As an abstraction, the “sufficiently determined attacker” (someone theoretically able to compromise any system on any network, outrun bullets, etc.) has a special place in the imaginations and nightmares of security professionals. On the one hand, in practice such people are rare: just like “physical world” criminals, many if not most people who risk the legal and social consequences of committing electronic crimes are stupid and predictable. The most likely attackers therefore tend to be relatively easy to keep out. On the other hand, if you are targeted by a skilled and highly motivated attacker, especially one with “insider” knowledge or access, your only hope is to have considered the worst and not just the most likely threats.
[3] Cohen, Fred et al. “A Preliminary Classification Scheme for Information Security Threats, Attacks, and Defenses; A Cause and Effect Model; and Some Analysis Based on That Model.” Sandia National Laboratories: September 1998, http://heat.ca.sandia.gov/papers/cause-and-effect.html.
Get Building Secure Servers with Linux now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
