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.