My guide to fascist syslogging (or how I caught the internet worm)
Craig Leres
leres at ace.ee.lbl.gov
Tue Nov 29 17:49:47 AEST 1988
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
More information about the Comp.unix.wizards
mailing list