by Steven J. Owens (unless otherwise attributed)
Note: I wrote up this outline almost 10 years ago (around 2000). I wonder if intro Unix books have improved since then. Also, note that the following outline was written from the perspective of helping somebody understand what's going on under the covers, and mostly with the intent of running internet nodes, e.g. not addressing X windows, desktops, etc.
Last year my cousin had to start learning Unix in a hurry. I've been trying to help him - not that I don't have plenty to learn about unix myself - and ever since, I've been trying to think about what kind of book I'd write, the book I keep looking for but haven't found.
Well, okay, that book is probably not possible, at least not yet, though I may yet attempt to write it. The book I want is a sort of step by step walk through the process of setting up and maintaining a unix system, but at the same time with an emphasis on the questions and reasoning, not on details. I might yet attempt to write something like that, but it'd definitely be a long-term process and involve a lot of interviewing and working with people who know more about it than I do.
But what I have been thinking about is a sort of "orientation" book that gives a beginner enough of an idea of what's going on that they can begin learning for themselves. Unix is the epitome of the concept of simple principles that when applied together give rise to elegant complexity. Well, it's the epitome of what happens when that concept is then left to accrete new tools and gewgaws and gimcracks for forty years.
My idea for the book is to introduce this basic concept and try to give a quick overview of each of the different dimensions in which Unix exists, and how they come together, with pointers to further reference & research.
Below is my outline, followed by a little discussion of the introduction.
Note: And after that is some discussion of a unix security handbook that a friend would like to see somebody write.
The introduction of the book will have to lay out a few meta-concepts.
The first concept is This Is Complicated and there really aren't any shortcuts. While you can give somebody the lay of the land fairly quickly, in practice it just boils down to having to learn lots of little subsystems, specialized languages, file formats, etc. There's no way around that until somebody sits down and tackles unifying all of these.
Personally, I'd love to see something like this; pick a single scripting language and a single structured file format. For example python and XML (though I suspect some perl fanatic is more likely to do it in perl, just to prove it can be done). Redesign/rewrite all of the hundreds of little chunks of a given linux distribution using python everywhere another scripting language is used, using XML everywhere you need a config file.
Note: Now, thanks to the java enterprise software world, we know this won't work :-).
The second concept is abstraction, and layers of abstraction. This is a popular concept in discussions of programming, so there is tons of material out there on the web.
The third concept is orthogonality, i.e. the idea that you have different dimensions of complexity, which are not always aligned in a layer-like fashion, but might be at right angles to each other. So, for example, the complexity of a script is probably orthogonal to the complexity of the config file data format that the script uses.
The fifth concept is shallow complexity. Essentially, some things just are complex. Nothing you try to do is going to change that, they'll always be complex. Often people try to remedy the problem by slapping a GUI on top of the complexity. But you find that you now have just as much complexity, only now it's hidden, obfuscated. Obfuscated complexity is much harder to see, learn, and ultimately understand. At least with shallow complexity, you can focus your efforts on dealing with the complexity itself, instead of fighting the well-intentioned-but-counterproductive obfuscation.
A friend is looking for a good security handbook, to hand to his subordinates to give them a basic orientation in security. There are, of course, several massive tomes out there (O'Reilly's firewall book and the classic Unix Security book, not to mention a host of supporting works like Internet Core Protocols).
Again, what's needed is a sort of handbook, a quick bootcamp. Here's my rough outline of what this would cover:
There is, of course, an introduction. The usual stuff; statement subject, purpose, scope, nomenclature and plan of attack. Also some basic concepts that will have to be covered VERY quickly and succinctly to avoid boring the reader and bogging them down in abstractions and vagueness. The key concepts I'm thinking of here are:
There is no such thing as "secure," only "more secure" and "less secure". Your challenge is finding "secure enough." Achieving "secure enough" is always about balancing the tradeoffs - both for yourself and for your attacker. Balancing them for yourself requires balancing the cost and constraints that good security imposes on you against the cost of being cracked, and the need to get things done. Balancing them for your attacker is balancing the cost of cracking your system against the usefulness of that access.
"Security through obscurity" is an old, and very stupid meme in the computer world. "Security through obscurity DOES NOT WORK" is a slightly less old, but much less stupid, meme.
The most harm that the first meme does is when it is used - all too often - to justify not fixing security problems. An even more insidious, recurring problem - still is, to this day, most notably with certain large operating system vendors in Redmond - is that when people discover a security hole and notify the vendor, the vendor's response is to try to ignore it. If the discoverer tries to force the issue, the vendor tries to suppress the discoverer.
Or, as one friend put it, "Because the discoverer is an evil hacker, who is letting other people hack these vulnerable systems, and so must be made to pay for all that damage, or even made to pay for fixing the bug."
Keeping your own profile low is an element of your own security - but these days, that's a lot less useful. Now crackers are looking for people with DSL and cable modems, so they can hijack their box and use it to launch distributed denial of service (DDOS) attacks.
Since security in a network sense is always about controlling protocols going back and forth, we need to give an overview of what these protocols are.
This might also need some elementary discussion of network basics; packets, sockets, ports, hubs, switches, routers, etc.
We assume the reader is familiar with all of these topics, but they may not be familiar with everything in these topics; the goal is to give them a glossary and enough details that they can follow the text and do their own research for in-depth purposes.
Every firewall guide I've ever read says "Now you need to figure out your firewall policy. A firewall policy is blah blah blah. You can set up a rule like foo. You can set up a rule like bar. You can set up a rule like baz." But they only give you, at most, a cursory example or two of a good policy. This section should go into practical discussions of tradeoffs, approaches, when it's best to use which, etc. Focus here is on examples with lots of background, discussion and examination, to give the reader a good grounding in how to compose their own, as well as a good cookbook to steal from.
This covers higher level ideas; firewalls, NATting firewalls, transparent firewalls, dead drops, etc. It doesn't necessarily give detailed instructions on how to build them all - since that would include a ton of details specific to the hardware and software used, and lots of unix system administration and maybe even programming. But the idea is to give enough of the concept that a skilled admin/coder could figure out the rest (and a not-so-skilled admin/coder could laboriously work it out).
Security doesn't end when you finish setting up the firewall. Security is an ongoing fact of life. This section describes good routine practices, like monitoring network and system activity, regularly analyzing your logs, monitoring bugtraq, skimming CERT advisories (they're usually slower than bugtraq, but you never know), running regular audits, educating users, evaluating new systems and software, planning, etc.
A template schedule would be a good idea, i.e. tasks laid out daily, weekly, monthly, quarterly and yearly.
In a sense this is the simplest and also the hardest section of the book, basically a compendium of detailed, specific information about different firewall products and how to use them, how NOT to use them, gotchas to watch out for, known problems, etc.
If this gets written at all, it'll definitely be a monster job of compiling this stuff. There's no way in hell I could write it, but it might be compiled with sufficient help from folks knowledgable in the field.
Finally, a section on tools; COPS, SATAN, Tripwire, etc. If this is aimed at home users, a general critique of the so-called "firewall" software for home users would be an excellent idea.