Paranoid Penguin - How to Worry about Linux Security
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?
Mick Bauer (firstname.lastname@example.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”.
|Understanding OpenStack's Success||Feb 21, 2017|
|Natalie Rusk's Scratch Coding Cards (No Starch Press)||Feb 17, 2017|
|Own Your DNS Data||Feb 16, 2017|
|IGEL Universal Desktop Converter||Feb 15, 2017|
|Simple Server Hardening||Feb 14, 2017|
|Server Technology's HDOT Alt-Phase Switched POPS PDU||Feb 13, 2017|
- Understanding OpenStack's Success
- Own Your DNS Data
- Simple Server Hardening
- Understanding Firewalld in Multi-Zone Configurations
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- Returning Values from Bash Functions
- From vs. to + for Microsoft and Linux
- Tech Tip: Really Simple HTTP Server with Python
- Bash Shell Script: Building a Better March Madness Bracket
- Natalie Rusk's Scratch Coding Cards (No Starch Press)