Coming up to a year now since I committed properly to running my home machine on Slackware. I want to write down, before I forget, what twelve months of that has actually taught me.
The unromantic part
I spent the first three months in a state of mild, constant irritation. Things did not work the way the documentation said they would. Hardware I had assumed would be supported was not. The kernel I compiled the first time did not boot. The kernel I compiled the second time did boot but had no networking, because I had switched off the wrong thing in make config.
I did not enjoy any of this at the time. In retrospect every one of those failures was the most useful kind of teaching, because every one of them forced me to read something I would not otherwise have read.
The single best feature of Slackware as a teaching tool is that it does not insulate you from the system. There is no friendly wrapper around things being configured. The configuration is the file. The file is small. You have to read it.
What I now know that I did not in January
A partial list, off the top of my head, sitting on the floor of my flat with the back of the machine open and my hand on a screwdriver:
- The boot process from the BIOS through LILO into the kernel into init into rc scripts is now a sequence I can follow without surprises.
- The difference between a kernel module and a kernel-builtin is no longer mysterious.
- I can read most of
/etcand explain what each file is for. - I can write a firewall ruleset that does what I want it to do, and verify with
tcpdumpthat it is doing it. - I can make some sense of a Bugtraq post.
- I can install and run a honeypot and an intrusion detector and read the output of both.
None of this list is impressive on its own. The list as a whole is something I could not have produced in January. The compounding effect of small daily reading was, I think, the actual mechanism here.
What I have learned about security as a discipline
The biggest thing this year has taught me is that computer security is not a subject. It is a property of every other subject in computing. There is no separate field where you learn to do security. You learn to do networking, and along the way you learn how networking goes wrong. You learn to write CGI, and along the way you learn how CGI goes wrong. You learn to read logs, and along the way you start to recognise what the wrong things look like in logs.
This is, I think, why the people I have come to admire most on the mailing lists are not specialists at all. They are systems people who have been doing this long enough to have seen everything go wrong at least once.
What I want to do next year
Three things:
First, get more rigorous about my own machine. I have been running with my own Snort rules for a fortnight. They are catching things. I want to write more rules and to start contributing back to the public ruleset that is forming.
Second, read more code. The intersection of "security" and "actually-fix-the-bug" is in the source. I have been reading enough Perl to be dangerous; I would like to be reading C properly by next December.
Third, write more here. The notebook idea has worked better than I thought it would. The discipline of writing for an imagined reader makes me finish thoughts.
A small note about the year ahead
There is the small matter of the Y2K date rollover coming up at the end of 1999. I do not think it will be the catastrophe some of the press is making it out to be. I do think it is going to be a fascinating exercise in finding out which systems, in which organisations, have actually been maintained — and which have been silently rotting for a decade.
More on that later. For now, end of year, sandwich, kettle, and a quiet evening of make running in the next room.