[ossec-list] Re: Integrity Checks and Diffs?

["Marty E. Hillman" <mehillman@xxxxxxxxxxxx>]

Just looking at it from a hacker perspective.  If I am going to break
into a network to change information in a file (for example a log file
to cover my tracks), I am going to have the forethought to monitor all
network traffic in the process of my hacking.  If a packet shows up
containing the data that I just changed (as it would in an unencrypted
smtp session packet), I am going to cause that packet to drop at all
cost.  Failing that, I will do whatever other damage is necessary
including wiping the system to shift the finger-pointing away from me
knowing that my behavior was just discovered.

So, to defend against the hypothetical unethical hacker above, I would
most likely take the time in my own system to do the diff manually
against a backup.  Being responsible for networks other than my own, I
see the argument about not being able to work in ideal environments.  In
those instances, I would configure the ssh tunneling of port 25 from the
OSSEC server to the mail server as described in my previous email.  This
is assuming that 1) it would work to encrypt the information, 2) it is
cost effective, 3) it is easy to maintain and repair.

Only if I could securely transmit such information would I send it in
the clear.  As Stephen King's Jude Andrews stated, "Perfect paranoia is
perfect awareness."

-----Original Message-----
From: ossec-list@xxxxxxxxxxxxxxxx [mailto:ossec-list@xxxxxxxxxxxxxxxx]
On Behalf Of Forrest Aldrich
Sent: Thursday, September 07, 2006 3:35 PM
To: ossec-list@xxxxxxxxxxxxxxxx
Subject: [ossec-list] Re: Integrity Checks and Diffs?


Then it can be an optional feature.

For it to be really useful, especially in your scenario, the copies 
would need to be maintained locally.

*shrug*

You could also detect changes from SVN and use that to augment, but yet 
one more loop in the chain.


_F


Erick Kinnee wrote:
>
> That is administratively expensive.
>
> In my environment there is no "change control" per se for some people.

> Many customers that have their own boxes; in some cases and we have no

> control over what they do, although I do want to know if those boxes 
> are exploited in some fashion. Some of those boxes aren't even backed 
> up as the customer doesn't want it or elected not to pay for it. Most 
> of our customers your idea would work for, but getting the tape loaded

> and pulling the data to a stagin area for comparison as I said is 
> administratively expensive.
>
>
> On Sep 7, 2006, at 3:02 PM, Marty E. Hillman wrote:
>
>>
>> Forgive my ignorance, but in the interest of data security and not
>> transmitting the information cleartext, wouldn't the alert be enough
to
>> cause the administrator to do a diff of the file against a known good
>> backup?  Might take a little more time than actually sending you the
>> changed information, but would maintain security.
>>
>> I suppose an alternative would be to use a dual-NICed computer and
send
>> the alert over the second network (assuming that they were not
sharing
>> common infrastructure hardware and that that link was not hacked as
>> well).
>>
>>
>> -----Original Message-----
>> From: ossec-list@xxxxxxxxxxxxxxxx
[mailto:ossec-list@xxxxxxxxxxxxxxxx]
>> On Behalf Of Forrest Aldrich
>> Sent: Thursday, September 07, 2006 2:39 PM
>> To: ossec-list@xxxxxxxxxxxxxxxx
>> Subject: [ossec-list] Re: Integrity Checks and Diffs?
>>
>>
>> Very true.
>>
>> In that case, send it over/via OSSEC in an encrypted package?  I
>> dunno...
>>
>> But the basic principle is useful - knowing "what" was changed, not
just
>> that it was changed.
>>
>>
>>
>> David Vasil wrote:
>>> Forrest Aldrich wrote:
>>>
>>>> Maybe for text-only files, provide an option to include a
contextual
>>>> diff output, which shows the changes of the monitored file, with
that
>> of
>>>> the known version --- this would require keeping that old version
>>>> archived somewhere, though.  Hmm...     may be useful in some
>>>> situations, knowing not only that the file was changed, but WHAT
was
>>>> changed.
>>>>
>>>
>>> That could come back and bite you in some situations where the file
>> that
>>> was changed contained sensitive information (which upon alert would
be
>>> sent to you through clear-text email).
>>>
>>>
>>
>> This electronic mail (including any attachments) may contain 
>> information that
>> is privileged, confidential, and/or otherwise protected from 
>> disclosure to
>> anyone other than its intended recipient(s). Any dissemination or use

>> of this
>> electronic email or its contents (including any attachments) by 
>> persons other
>> than the intended recipient(s) is strictly prohibited. If you have 
>> received
>> this message in error, please notify us immediately by reply email so

>> that we
>> may correct our internal records. Please then delete the original 
>> message
>> (including any attachments) in its entirety. Thank you.
>>
>>
>