Paranoid Penguin - How to Worry about Linux Security

Worrying is good when you worry about the right things and act accordingly.
How to Channel the Ph33r

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.

Conclusion

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?

Mick Bauer (darth.elmo@wiremonkeys.org) is Network Security Architect for one of the US's largest banks. He is the author of the O'Reilly book Linux Server Security, 2nd edition (formerly called Building Secure Servers With Linux), an occasional presenter at information security conferences and composer of the “Network Engineering Polka”.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Expense of snort?

jed_reynolds's picture

I've always considered Snort a hard-to-justify expense to clients. I'm surprised to see you recommend it WRT to your article's example.

http://bitratchet.prweblogs.com/2006/08/14/security-something-about-snor...

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix