OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: yet another idea about /etc/security
From: Garance A Drosihn (drosihrpi.edu)
Date: Sat Feb 05 2000 - 17:04:08 CST

At 9:14 PM -0600 2/4/00, Igor Roshchin wrote:
>2. Reeding the daily output from /etc/security, you see
> those messages (and [not] 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:
>
>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.

I'll skip the solution suggested, since I am not comfortable
with some of the issues which it might run up against...

I do notice the same problem, and in my case /var/log/messages
is only rolled once a month so the repetition in security-run
outputs can get rather annoying. I haven't actually WRITTEN
anything to deal with this yet, but I was thinking of something
along the following lines:

   Scan /var/log/messages for <whateverAppropriate>, and save
        the results of that into a temporary file.
   Get a linecount and md5 digest of that temporary file.
        Save *that* info for the next run of /etc/security.
   Copy "new information" (see below) from this run into the
        actual security message.
   For subsequent runs, do the same scan and copy it into a
        temporary file. Count out the first <x> lines of that
        file, where <x> is the number of lines found in the
        PREVIOUS scan. Calculate the MD5 digest for JUST
        those lines. If this MD5 digest matches the previous
        MD5 digest, then you know that those first <x> lines
        are "old" information. The "new information" would
        be everything after those first <x> lines. (you might
        want to include the "last line of old info" as part of
        the "new info" that you include in today's message,
        just for purposes of providing context).
        And of course, if the md5 digest does NOT match, then
        assume everything in the current scan is "new info",
        and copy all of it to the security message.
   Then get the linecount and md5 digest of all the lines in
        the current scan, and save it away for the next run...

My guess is that this would greatly reduce the duplication
in security messages, and it has the nice characteristic
that you won't need to save more than (say) 40 bytes of
information from day-to-day, no matter how large the scan
scan result becomes.

Hmm. Thinking about it some more, the actual security
message might want to start with the line
       [skipping <x-1> lines of duplicate messages]
followed by the last line of "old information", and then all
lines of "new information", just so you're also getting an
indication of how large that scan is getting...

I am not sure if this has any undesirable implications for
security (ie, does it make the security scan "less secure"?),
but I would do some variation of the above if I get annoyed
enough with all of the repetition in security-scan messages.
If ambitious enough, I might even right a program to handle
all of this processing via a filter, attempting to avoid the
need for an extra temporary file. 

---
Garance Alistair Drosehn           =   gadeclipse.acs.rpi.edu
Senior Systems Programmer          or  drosihrpi.edu
Rensselaer Polytechnic Institute

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