leres@ace.ee.lbl.gov (Craig Leres) (11/29/88)
When the internet worm hit Lawrence Berkeley Laboratory, I found out about it Pretty Damn Fast. One important factor was that I happened to be physically present. Another was that I had recently installed what I call fascist syslogging code in many of my Unix systems. The result was that only a few of our machines became infected and none crashed from "worm overloading." Since lots of people have been pestering me, I've decided to explain how my fascist syslogging works. The basic idea is to add code to various programs and daemons to syslog a certain class of activities and then to configure syslogd to display this information to the group of local wizards in real-time. Let's look at the syslog configuration first since the functionality of your syslog system dictates what kind of syslog() messages you will want to add. The goal is to have all messages having to do with system security go to people who handle security problems. For example, on a 4.3 BSD system you can have syslogd send messages in the LOG_AUTH facility to a list of users: auth.info root,leres,doug,bob Adding this line to /etc/syslog.conf causes most security or authorization messages to be sent to root, leres, doug and bob as they occur. Unfortunately, the 4.2 syslog system (as is used in SunOS 3.X) is pretty limited and it has no concept of "facility" which makes it more difficult to avoid bothering people with trivia. One possible solution is to use the LOG_SALERT level. exclusively for your security syslog() messages. Crude, but effective. Now on to the code-slinging. First, a few general notes: Make sure that the program calls openlog() with the correct facility (for example LOG_AUTH). In some cases (for example, /bin/login) I found it helpful to write a helper routine that formats the remote and/or local username, hostname, etc. Before you start hacking, decide which levels to use for which types of events. For example, you should save LOG_DEBUG for messages that you normally wouldn't want displayed on your terminal. LOG_INFO might be used for successful authorization activities and LOG_ERR for unsuccessful authorization attempts. Following is a list programs and daemons with a description of what you might want to syslog(): /bin/login: On many systems, /bin/login is run when you attempt to login on a local async port or over the network via telnetd or rlogind. Add a syslog() anywhere a user fails to login normally. Possibilities include: - logins are disabled - no such user - password is incorrect - Timed out Log the local tty port or remote hostname. If the remote login name is known and is different than the local login name, log it too. As mentioned earlier, you might want to also syslog() successful logins. /etc/rshd: In addition to the things mentioned for /bin/login, you'll want to log the failure to look up the remote host by its internet address. (And a totally fascist system will syslog() the actual command being run via rsh.) /etc/ftpd: Log the obvious things mentioned above. Also, if you support anonymous ftp, you might log everything that guests do with the level LOG_DEBUG. /etc/fingerd: As with anonymous ftp, use the level LOG_DEBUG so you'll have a record of remote sites who finger you. Also, don't forget to log the target of the finger request, if there is one. /usr/lib/sendmail: Although you don't want sendmail to do its copious logging to the LOG_AUTH facility, it's a good idea to add a syslog() that displays the remote hostname as soon as it is known. If you're really sneaky, you might log attempts to WIZ or DEBUG your mailer... Obviously, I could have posted the context diffs of my mods changes. There are several reasons why I didn't: My code is based on a severely hacked SunOS 3.5 source (which is some percentage 4.3 BSD) and won't port easily. I think it's a bad idea for everyone to run exactly the same security hacks. (Look at the number of sites the worm got into.) I don't want people to know exactly what is logged on my systems. So please don't ask for context diffs; I promise to ignore you if you do. Craig