[Aide] Non-hash and "growing log" Integrity Checking

[gentuxx]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard van den Berg wrote:
> gentuxx wrote:
>> I tried subscribing to this (dev) list, but didn't realize it was
>> moderated for non-members. 
> 
> Yeah, that's a result of the list being flooded with spam otherwise. You
> could simply subscribe, ask your question, and unsubscibe.. it's a
> simple process.

No worries.  It's a normal practice.  I wasn't surprised by it.  Just
meant that there was "administrative time" added to when I could expect
a reply.

> 
>> Naturally, as events are added to the Windows Event log, the MD5 hash
>> will change (so would SHA1 or any other one-way hash AFAIK).  Aside from
>> the obvious, I have reasons for wanting to verify the integrity of these
>> files.
>>
>> I know that AIDE handles these sorts of things, and I was wondering if
>> any of the development team might be willing/able to talk (from a
>> logical perspective) about how AIDE is able to verify the integrity of a
>> file in these types of situations.
> 
> AIDE doesn't really have anything special built in for this. All that
> AIDE does is check that various attributes of a file did not change. For
> a growing (non-rotating) log file, you could check for:
> 
> permissions
> inode
> number of links
> user
> group
> growing size
> 
> That latest versions of AIDE have a special check that ignores the
> renaming of a file (it will check a file by inode number instead) so
> that rotating log files can be tracked. However, I'm not convinced this
> can be used in a practical way.

Agreed.  Do Windows file systems recognize inode?  Unfortunately, I'm
much more if a *nix geek than a Windows geek, so something like that I
wouldn't know without researching it.

> 
> If you are coding your own app, and find this important enough, you
> could calculate MD5 and SHA1 for the file and record the size of the
> file(n), and next time around recalculate those hashes for only the
> first n bytes of that file. Then store the MD5 and SHA1 for the whole
> file again, and so on. Of course this only makes sense for ever growing
> files. I am not sure if the event log is limited in size (if so, the
> first n bytes will change over time).

I don't maintain this system, I'm merely being charged with protecting
it, so I don't know if the event logs are rotated and archived, or
merely drops events from the beginning as the file reaches its size
limit (assuming one is set).  (Obviously this is something I should
probably find out.)

I'm taking a similar approach, albeit one that is likely to be less
portable.  I've discovered that the module I mentioned in the initial
post (Win32::EventLog) is packaged with the ActivePerl Windows
distribution, which (fortunately) is what's used on this system.  This
allows me to "stringify" the entire event log, hash it, and store that
hash.  I'm developing the actual procedure at the moment, but this
seemed to work (logically) since I am able to track on record ID.
Assuming the file has grown, I stringify the text up to the stored
record ID, hash it, then compare the hashes.  The principle is the same
(and has the same flaws) as the approach you mentioned.

I don't know, yet, if I have the luxury of using things like inode, # of
links, etc. on a Windows file system.  Fortunately I have a Windows Guru
at my disposal, so I'll have to pose that question.  ;-)

It's good to have AIDE demystified a bit, and has definitely confirmed
that I'm heading towards a workable approach.

Thanks!
- --
gentux
echo "hfouvyyAhnbjm/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge'

gentux's gpg fingerprint ==> 5495 0388 67FF 0B89 1239  D840 4CF0 39E2
18D3 4A9E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE+mYhTPA54hjTSp4RAg+MAJ44y2kOslSQ9UagiosIz1/76qfBIACdGrCX
7a9W0VvJZ4q/GYnFzSdcm4Q=
=uT+Y
-----END PGP SIGNATURE-----