[comp.unix.wizards] My guide to fascist syslogging

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

henry@utzoo.uucp (Henry Spencer) (12/01/88)

In article <1326@helios.ee.lbl.gov> leres@helios.ee.lbl.gov (Craig Leres) writes:
>	/bin/login... Add a syslog() anywhere a user fails to login
>	normally. Possibilities include:
>
>	    - logins are disabled
>	    - no such user	...

But be careful that your logs are secure.  It is a verifiable fact that
people sometimes type passwords instead of login names, due to slow response
or confusion or etc.
-- 
SunOSish, adj:  requiring      |     Henry Spencer at U of Toronto Zoology
32-bit bug numbers.            | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

lvc@cbnews.ATT.COM (Lawrence V. Cipriani) (12/02/88)

In article <1988Nov30.170027.15960@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>But be careful that your logs are secure.  It is a verifiable fact that
>people sometimes type passwords instead of login names, due to slow response
>or confusion or etc.

Good point.  In the login logging I wrote the login name is recorded only if
it is a legal login name, other wise "unknown" is recorded.  This is done for
precisely the reason you gave.

-- 
Larry Cipriani, AT&T Network Systems, Columbus OH,
Path: att!cbnews!lvc    Domain: lvc@cbnews.ATT.COM

jfh@rpp386.Dallas.TX.US (The Beach Bum) (12/05/88)

In article <2428@cbnews.ATT.COM> lvc@cbnews.ATT.COM (Lawrence V. Cipriani) writes:
>In article <1988Nov30.170027.15960@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>But be careful that your logs are secure.  It is a verifiable fact that
>>people sometimes type passwords instead of login names, due to slow response
>>or confusion or etc.
>
>Good point.  In the login logging I wrote the login name is recorded only if
>it is a legal login name, other wise "unknown" is recorded.  This is done for
>precisely the reason you gave.

In a previous life, I added a field to lastlog.h to include the number of
failed login attempts and the tty the attempt was made on, along with the
time of the last failed attempt.  A large number of failures on dialup or
PC lines would help indicate someone was up to no good.
-- 
John F. Haugh II                        +-Cat of the Week:--------------_   /|-
VoiceNet: (214) 250-3311   Data: -6272  |Aren't you absolutely sick and \'o.O'
InterNet: jfh@rpp386.Dallas.TX.US       |tired of looking at these damn =(___)=
UucpNet : <backbone>!killer!rpp386!jfh  +things in everybody's .sig?-------U---