|
BSDCon 2002 Abstract
Log Monitors in BSD UNIX
Brett Glass, Glassware
Abstract
A log monitor is a process, or daemon, which monitors log messages produced
by a computer system and the programs which run on it. A properly designed
log monitor can recognize unusual activity (or inactivity), alert an administrator
to problems, gather statistics about system activity, and/or take automatic
action to contain a threat. It can even "learn," over time, what is normal
and identify message traffic that may betray an abnormal situation.
On BSD UNIX systems, most applications and daemons log events via the
system logging daemon (syslogd). Because Berkeley syslogd
allows log messages to be piped to a program as well as written to one
or more files, implementation of a BSD log monitor often begins with the
creation of a program which accepts formatted log messages via standard
input, parses them, and extracts necessary information. Utilities which
do not log events via syslogd (e.g. the Apache Web server) may require
a separate log monitor process. In all cases, data validation, robust input
handling, and careful parsing of log messages are especially important
considerations in log monitor design, lest the monitor itself compromise
the security of the system it is intended to monitor. Languages which facilitate
string processing and pattern matching, such as Perl and SNOBOL4, are good
choices for the implementation of log monitors for this reason.
Log monitors can work in tandem with firewall software to block traffic
from a would-be intruder, spammer, or "mail bomber." For example, it can
tally the number of outgoing e-mail messages sent by users on an internal
network and detect activity which appears to constitute spamming or mail
bombing. A log monitor can also recognize efforts to exploit security holes,
such as attempted infection by the Code Red worm or attempts to exploit
CGI scripts included with older versions of the Apache Web server. Included
in this paper is source code for a log monitor that identifies and blocks
attacks from Code Red, sadmin/IIS, Nimda, and similar worms. Policy issues
-- including the usefulness of "amnesty" to prevent inadvertent blocking
of innocent third parties -- are discussed. The work described in this
paper --which is still progressing at this writing -- will hopefully culminate
in the release of a general purpose log monitoring facility.
[Note: Because the camera-ready copy of this paper had to be submitted
two months before the BSDCon 2002 conference to allow time for printing,
and USENIX enforces strict limits on size, the version of this paper which
appears online may contain more detail as well as new information from
ongoing work. For the latest version, and/or to follow up the many references
via HTML links, access the master copy at https://www.brettglass.com/logmonitors/paper.html
on the World Wide Web.]
- View the full text of this paper in
HTML and
PDF. Until February 2003, you will need your USENIX membership identification in order to access the full papers.
The Proceedings are published as a collective work, © 2002 by the USENIX Association. All Rights Reserved. Rights to individual papers remain with the author or the author's employer. Permission is granted for the noncommercial reproduction of the complete work for educational or research purposes. USENIX acknowledges all trademarks within this paper.
- If you need the latest Adobe Acrobat Reader, you can download it from Adobe's site.
- To become a USENIX Member, please see our Membership Information.
|
Need help? Use our Contacts page.
