The vandals who broke into our machines were kind enough to format all of our disks, completely obliterating every byte of data on them. In addition to lost data, this meant that we had no record of the source of the attack; the miscreants wiped away all records of their whereabouts along with everything else that was on the disks. After the attack, Fred and I started thinking about what would be required to keep a record of all logins to our machines in a secure way -- that is, so that it would be impossible for an attacker to erase or tamper with the logs, even if root access on the machine was compromised.
The solution we developed was a set of two companion programs, rkloffl and kloffld. rkloffl sends UDP datagrams containing information about a login (login name, time, and originating site); kloffld is a daemon that receives the datagrams sent by rkloffl and writes them to a file. Every time someone logged into one of the machines that we were monitoring, rkloffl was called from csh.login and sent the login information to a more-or-less secure logging host that we set up. The log host didn't have any type of remote access daemon (no telnet, no rsh, no ftp); it could only be accessed from the console and didn't run any daemons except for kloffld. The host was an old junk PC cobbled together from extra parts laying around the lab -- a 386SX with 3MB of RAM and a 40MB disk (running Linux, of course).
Now, if you're really serious about building a secure logging server, you can do what I always meant to do but never got around to doing: physically cut the transmit pin on the AUI cable connecting the logging host to the network. This will prevent the log host from ever sending any data, which certainly will ensure that no one will ever be able to break into the machine over the network. The UDP log messages will still get through because they don't require acknowledgments. (Just make sure that you hard-code the Ethernet address of the log host into all the machines that are running rkloffl, because the log host won't be able to respond to ARP requests.)
Of course, even that method isn't that secure; after all, someone can still send fabricated login information to the logging host in order to misdirect an investigation, or design a denial-of-service attack by sending enough logging information to kloffld to fill the disk. Solutions to these problems were beyond the scope of our interest when we wrote the software.
Back to my software page
Back to my home page
Jeremy Elson