Monitoring file changes

aide and tripwire are the standard, but they're not written in an interpreted language

>>56978544
Thanks for the contribution. Took a look at those too, but they also need installing.

What about btrfs and its snapshots?

>>56978516
Are you askign to calculate the md5 hash of the entire contents of a directory on a loop?
Thats a bit much anon. Maybe if its just a few tiny files, but anything larger is gonna use a bit of cpu and disc access times

>>56978825
Doesn't have to be on a loop

just off the top of my head: a program to generate a crc32 hash of all the files in a folder and subfolders, taking note of the last modified date in an index, then stays resident.

when a file is read, the program takes note of the last modified date, and if the date is not the same as the time it took the crc32 hash, it suspends the process reading it and throws up a prompt, giving you a chance terminate the process, or to just allow it (if you know it updated, etc)

this would primarily be most useful with program binaries and libraries, which makes me wonder why there isn't a security program that does this without all the excess fluff to keep the system nice and snappy while being able to verify your executables.

it's not like an exe, bin, or dll file needs to be changed every 30 minutes, right?

/endramblings

>>56978890
>if the date is not the same as the time it took the crc32 hash

I forgot to mention that it rehashes that file and compares the last one; if the same, then it just takes note of the updated date, if changed, it does the suspend and prompt thing.

see, it cuts out most of the rehashing because it doesn't rehash anything unless the created/modified date changes compared to the noted time in the index

>>56978890
I was thinking of using this for web stuff, so it would work pretty similar. Good ideas!

Why not just use version control?

git, hc, svn should all be able to do what you want.

If you really want to set it up you can use zabbix, it does many more things however

>mfw nobody reads third line of OP

OP here, it's possible with bash and gnu coreutils. Probably just reinvented the wheel but whatever.

>>56978516
>>56978825
Please don't use MD5 hashing. Use SHA-2 or something

>>56981726
Why? did they finally crack md5 or is sha-2 just the latest mega encryption meme?

>>56978516
The Linux kernel provides the means to do this, you can harness this with the fcntl library, here's a python example and it would be pretty much the same if you wrote it in C:

import time
import fcntl
import os
import signal

FNAME = "/directory/to/watch"

def handler(signum, frame):
    print "File %s modified" % (FNAME,)

signal.signal(signal.SIGIO, handler)
fd = os.open(FNAME,  os.O_RDONLY)
fcntl.fcntl(fd, fcntl.F_SETSIG, 0)
fcntl.fcntl(fd, fcntl.F_NOTIFY,
            fcntl.DN_MODIFY | fcntl.DN_CREATE | fcntl.DN_MULTISHOT)

while True:
    time.sleep(1)

That or poll for the "modified time" property of files (and directories?), on python that would be

os.stat(filename).st_mtime

>>56982290
Not that I have a wealth of knowledge on the subject but it is possible to produce collisions with MD5 whereas collisions have yet to be found with SHA-2. That means that MD5 is only good as a checksum and doesn't tell you if files have been legitimately tampered with.

>>56978516
Ignore these retards
Use the auditing system built in...

>>56982570
Well seeing as OP is not asking how to check if his files have been tampered with I don't see why using MD5 or even CRC32 for that matter would be bad

>>56982652
You're probably the most retarded one here

>>56978516
If you're looking to do incremental backups rsync and unison are both great

>>56982754
Yeah, you are right. OP didn't specifically talk about file tampering. MD5 would be fine. I guess my point of view is that if you can get knowledge about file errors and tampering, why not? IDK.