OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: yet another idea about /etc/security
From: Igor Roshchin (igorphysics.uiuc.edu)
Date: Fri Feb 04 2000 - 21:14:11 CST

While we are on this subject:

Running an anonymous ftp (wu-ftpd) server (with several different limits
enforced, inlcuding number of users in each class), we are getting
tons of messages about refused ftp connections (as ftp.notice messages).
I want to have those messages logged, but there are two problems:

1. they sometimes obscure other messages in the /var/log/messages
2. Reeding the daily output from /etc/security,
you see those messages (and only from ftpd - this is related
to all other messages too)
over and over, until /var/log/messages is rotated
(for some local reasons on some of the hosts the system policy is
to rotate /var/log/messages weekly).

Possible solutions:

1. For rather long time I was dealing with the first issue by
applying my own patch to the wu-ftpd, which would lower the message
priority from .notice to .info, so I can log them to a separate file,
while keeping the rest of the .notice messages in /var/log/messages.
I even suggested this patch to the wu-ftpd guys at some point,
but it seems to be lost, and I was too busy to remind about it.

Yet another idea would be to implement the following feature into
syslogd: to specify which facility messages at a given .priority
should NOT be written to the specified output,
(say log *.notice but not ftp.notice to /var/log/messages),
but knowing how messy (IMHO) syslogd code is (I wrote some minor patches
for it), and remembering its logic, I would say it would be rather
complicated, although very useful procedure.
It might be just easier to rewrite it almost from the scratch..
specified file.

2. I was trying to come up with a scenario, how to make /etc/security
remembering the messages it already reported, so it can
report only the new ones.

My first thought was to use a mechanism similar to dmesg.today/yesterday,
but in this case such files (security.today and security.yesterday)
might become rather huge, comparable by the size to the size of
/var/log/messages itself - so we end up having tripled its size.
Besides, you need to do rotation of those files upon rotation
of /var/log/messages, or something similar..
So, this does not seem to be acceptable (unless some can add some
elegant solution)

My best solution so far was to have a file (say /var/log/security.dat)
which would have the date of the last date /etc/security ran,
and than would exclude parsing of any messages in /var/log/messages
prior to the stated date, by matching them against that date-time stamp,
thus avoiding duplicated ("multi"-plicated) efforts and output.

Ideas and insights are welcome.

Probably some script-gurus (in-line perl script ? sed ? )
would come up with an elegant solution how to compare date
in "Feb 4 21:34:56" (+%Ef" "%T) format -
regular comparison that exists in any shell
would not work due to the need of comparing month
names, and I am somewhat reluctant to introduce an array of month
names into /etc/security script.

Igor

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message