Paranoid Penguin

Although most of us manage to muddle through without major breaches occurring terribly frequently, running a networked Linux system is nevertheless a worrisome undertaking. Well, in my opinion, worrying is good! Worrying, if it's the constructive kind that holds complacency at bay, keeps us on our toes. The trick is to worry about the right things and to act on our worries.

Uh-oh, you may be thinking, Mick's setting aside his pocket-protector this month in favor of the soapbox. Guilty as charged. I'm convinced that my technical articles will be much more useful to you if you periodically think about the larger context into which security technologies fit. So this month in the Paranoid Penguin, it's time to discuss what to worry about in Linux security and what to do about it.

When you're thinking about defense, it's good to work your way outward, but because the bad guys are usually looking at you from the opposite direction, it's instructive to consider their viewpoint now and then. Therefore, I begin by talking about who we need to worry about attacking our systems. Next, I discuss their tools (attack-vectors) and finish by examining common system vulnerabilities and ways we can mitigate them.

So who are these attackers? They follow a spectrum from the unskilled, often reckless punks, to careful, highly skilled professionals. I don't even pretend to know the full spectrum myself—these aren't the circles I move in—but I can describe some common types:

Everyone needs to worry about identity thieves, resource thieves and vandals, because these attackers tend to be highly indiscriminate in choosing their targets. The old security clich� “I don't have anything anyone would want to steal”, may hold up when discussing corporate spies, but falls completely flat here. In fact, resource thieves in particular prefer low-profile, innocuous-looking targets, because avoiding attention is such an important part of their operations. With all three of these groups (identity thieves, resource thieves and vandals), the attacker simply couldn't care less what you use your computer for.

Note that identity thieves generally don't care about your computer at all. They care about your identity, and to get at it, they're more likely to try to hack you—for example, by tricking you into entering your Internet banking credentials at an impostor Web site—than to hack your actual computer. (Although, it's only a matter of time before someone writes a worm that looks for identity information stored on its victims' hard drives. More on malicious code later.)

Also, not all attackers are remote. Corporate spies and identity thieves, in particular, who are frequently “insiders” at the organizations they attack, often have or seek local/console access to the systems they attack. (It's a lot easier to get at the data on a hard drive you've just stolen than to hack your way through firewalls, intrusion detection systems, application access controls and so on.) Resource thieves and vandals, however, are usually remote attackers.

So, how do these various attackers achieve their nefarious goals? What, in other words, are their weapons?

When I first became a network engineer in the mid-1990s, the attack paradigm we usually worried about was a human being sitting at a computer, interacting more or less directly with her “victim” systems in real time. In other words, Matthew Broderick's character in the movie WarGames was the sort of attacker we assumed (rightly or wrongly) to be most common.

Today, however, it's safe to say that the vast majority of probes and attacks conducted against networked systems are carried out by automated software processes—that is, by viruses, trojans and worms. People are still behind these types of attacks; make no mistake about it—someone has to write, adapt and deploy all that malicious code—but most actual attacks happen by proxy nowadays.

For example, one of the fastest-growing tools of the resource-theft trades (spamming, porn-peddling, DDoS and so on) is the botnet. A bot is a computer that has been infected with a worm or virus that surreptitiously contacts the person who released it; a botnet is an entire network of bots awaiting instruction.

Botnets are part of a strange, complicated and shady economy. Botnet operators who distribute spam under the pay of spammers are commonly paid per distribution node. Most of the merchants who pay them intentionally turn a blind eye to the fact that these nodes are probably not legitimate e-mail servers, but illegally hijacked systems (that is, bots). When spam-botnet operators are caught, the actual source of both their income and their spam invariably claims they had no idea their spam was being distributed by illegally compromised systems.

Resource thieves aren't the only ones who use botnets. DDoSers use them to conduct highly distributed network bombardments that are difficult both to trace and stop. Identity thieves often carry out phishing attacks, in which spam e-mail purporting to be from a bank or e-commerce site is used to lure people into entering their logon credentials at an impostor Web site. Phishers, even more than garden-variety pharmaceutical and porn spammers, have a strong motivation to hide their tracks, so botnets are especially useful for phishing-spam distribution.

The fully interactive system attacker is still very much with us; not all attackers cast as wide a net as spammers or phishers. Corporate spies, vandals and stalkers are all likely to make use of one-on-one attacks in which attackers focus their attention on one system, and conduct their attacks more or less in real time. Some of these attackers, especially in the corporate-espionage space, are highly skilled and creative experts who are able to crack even carefully secured systems, often by writing customized attack software.

Conventional wisdom, however, is that many if not most Web site defacers and other vandal types are script kiddies—less-skilled attackers who rely on tools they download from the Internet or obtain from friends. Such attackers are much more easily thwarted than the pros, because they tend to be not nearly as adaptable. If the attack scripts they run against a given system fail, they're far more likely to give up and seek a softer target than they are to fine-tune their scripts or write a new script altogether. And, a given script may work only against one version of one application running on one particular architecture (for example, Apache 2.0.1 on Intel x86 platforms).

In summary, the good news is that most attacks are indiscriminate, automated and not very adaptable. Highly focused, human-operated and creative attacks are much less common. The bad news is that the sheer volume and variety of automated attacks (including spam, phishing, malicious code and script-kiddies' tools) makes them a force to be reckoned with. These attacks cost people and organizations everywhere millions of dollars annually in lost productivity and fraudulent transactions. Furthermore, just because skilled/human attackers may not seem like a likely threat in a given scenario doesn't mean you can disregard them altogether.

So, there are attackers, and these attackers have tools. What are the nuts and bolts that these tools manipulate?

Consider this simple formula from threat-modeling parlance: a threat equals an attacker plus some vulnerability. A vulnerability is some characteristic of the attacker's target that presents an opening. What the threat equation tells us is that if a given vulnerability can't be exploited by an attacker (for example, because the system isn't networked and resides in a locked room), it doesn't constitute a risk. Conversely, a system with no vulnerabilities isn't at risk regardless of how many attackers target it.

Obviously enough, there's no such thing as a completely invulnerable system. There are, however, many ways to deal with vulnerabilities that decrease their possibility of being exploited by attackers.

Common types of vulnerabilities include:

The remedies to these tend to be straightforward. Bugs can be patched, default/insecure settings can be changed, extraneous accounts and applications can be removed, security features can be leveraged and users can be educated. “Straightforward” doesn't necessarily mean “easy” (or “quick” or “cheap”), however.

The patch rat race, as I've said many times in this space, is futile—you can't write a patch without first discovering the bug, and what are the odds of the good guys discovering every major bug before the bad guys do? Still, we're stuck with this cycle; patch we must.

The outlook for tightening system and application settings, leveraging application/OS security features, educating users and applying additional security techniques and tools is considerably brighter.

This brings us to the positive, forward-looking part of my little editorial: how to channel all these worries into constructive action. I've already begun talking about security techniques and tools, and I'm not going to go much further with those right now—that's what my technical articles are for. Rather, I'd like to conclude here with my recipe for converting worry into action.

Step one in securing any computer system or network is to define its function. What will it do? What data will it store, process and serve to users? Who are the intended users? How will those users interact with the system? As any fan of Sun Tzu can see, this is none other than the ancient technique of analyzing the terrain you need to defend.

Step two is to identify, in general terms, the types of attackers you need to defend against. Start with all possible, but prioritize the most likely.

Step three is to think of what data or resources these attackers are most likely to attack on your system, and what sorts of vulnerabilities they might try to exploit in conducting those attacks. Once you've considered the most likely attacks, be sure also to consider less likely but still-plausible attacks, particularly those that are easy to mitigate.

Let's walk through this process with an example scenario. Suppose I've just built a Debian-based Web server. In step one, I determine that the server's function will be to host a simple “brochureware” Web page containing information about my accordion shop (hours of operation, address and so on). The Web server will have only a handful of local user accounts. Most access will be by anonymous Web clients. No sensitive data will be housed on it. No other network services (SMTP, DNS, IRC and so on) will be provided by this particular box, although I will need to administer it via Secure Shell (SSH).

In step two, I decide that because there will be no nonpublic data on the server, it will not be a likely target of corporate spies. I've got a small operation, and in fact, I'm friendly with my town's only other accordion dealer. She's highly unlikely to hire a professional system cracker to hack my Web site. My main worry, therefore, will be less-discriminate attackers: resource thieves, malicious code in general and vandals. It's also possible, though, that some more focused type of attacker may attack my system in order to use it to attack other systems, so I won't focus exclusively on automated attack vectors.

In step three, I decide that my system itself is the most likely attack target, and that automated attacks are the likeliest vector, and that software bugs and configuration settings are the likeliest vulnerabilities to be targeted. What I appear to have before me is a very generic system-hardening exercise. I need to apply all current software/system patches (maybe including running apt-get as a cron job), identify and remove extraneous software and user accounts, configure Apache as securely as possible and at least consider using some add-on tools like Tripwire, Snort and syslog-ng to help monitor my system's security status.

I may decide not to bother running Apache in a chroot jail. The whole purpose of this box is to run Apache, so if someone compromises Apache, the system is for all intents and purposes hosed. On the other hand, if the attacker manages to escalate an Apache compromise into a full system (root) compromise, he or she may have a much easier time using my Web server to attack other systems, so maybe a chroot jail (for example, using mod_security) would be worth the extra hassle after all.

The point of this exercise is that I've thought in an organized way about my defense goals, about the attackers that worry me most and about how best to prioritize the time and effort I spend on securing my system. Sure, I may get some or even all of it wrong, but such a mistake is apt to be much less calamitous than applying security controls in a haphazard or reactive manner.

Besides, knowing me, I'm going to worry regardless. Isn't it better to worry in an organized, constructive fashion?