ViperDB 0.9.2

This version is a few bugfixes as well as some new features

Version 0.9.2: viperdb.conf, viperdb.ignore and viperdb.pl.

CHANGELOG
0.9.2 - Changed entire way parsing of config file was done
- Added capability to check dirs recursively
- Added different LogLevels 1=basic 2=extensive
- Fixed a bug in Cleaup() which was leaving
  ViperDB.tmp files everywhere.
- removed CTIME monitoring and only left MTIME
- Misc other cleanup/bugfixes


ViperDB 0.9.1

This version has some critical race conditions fixes

Version 0.9.1: viperdb.conf, viperdb.ignore and viperdb.pl.

NOTES : When you first run this new version, be sure to first run with the -init option to re-create all new databases as the structure for storing file information is completely rewritten.

CHANGELOG
0.9.1 - Fixed some nasty race conditions
- changed almost all system() calls to perl equivolents
- cleaned up -checkstrict code to handle changing perms,
  owner,group back to original.. now use UID/GID instead
  of the name of the uid/gid
- Simplfied reporting (lumped all perms together and uid/gid together)
- cleaned up a bug with chattr and -init runtype
- added ctime & mtime checking


ViperDB 0.9

This version just has some added features.

Version 0.9: viperdb.conf, viperdb.ignore and viperdb.pl.

CHANGELOG
0.9 - Added ignore functionality which allows the user to specify
   filenames to explicitly ignore and they will not be monitored
- Updated code for better compatability with Solaris
   (LS_OPTIONS were -laAS and solaris needs -lAcr)
- Cleaned up code having to do with splitting perms out into owner,
  group, and all perms.


ViperDB 0.8

This version just has some added features.

Version 0.8: viperdb.conf and viperdb.pl.

CHANGELOG
0.8 - Added email notification system to send summary
  emails when changes have been detected.
- Made database(s) immutable and undeleteable between checks
  so that even if someone manages to bust root, removing/modifying
  the databases between checks is considerably harder.


ViperDB 0.7

ViperDB 0.7 has been released. This new version has numerous bugfixes as well as the addition of many new features including the ability to not only monitor but to "Protect" your files. ViperDB 0.7 has the added ability to change owner/group back to the original values on files that have had their owner/group changed as well change permissions back to original permissions. Another feature of ViperDB 0.7 is that now, if a change detected to a SUID/GUID file, all permissions are taken away from that file until a time at which the admin can review the file.

This is an ongoing project and all comments and suggestions are welcomed at J-Dog@resentment.org

Version 0.7: viperdb.ini and viperdb.pl.

Documentation Coming shortly

PLANNED UPGRADES

  • Adding of a more complex "system status" function which when a change is detected, would grab info that might be helpful in determining what caused the change (ie. processes running, users logged in, last few lines from logfiles, etc)

    CHANGELOG
    0.7 - Changed logging mechanism from logging to an individual file to
      logging to the standard logging facility (calls on 'logger')
    - Added '-checkstrict' functionality which changes permissions back
      to what they were before the change was made to the file.
    - Added exception(s) to '-checkstrict' which removes all permissions
      from the changed file if the file originally was SUID/GUID.
    - Changed way changes were seen by admin, now a change only
      sends an alert to the logs once instead of repeatedly.


    ViperDB 0.6

    ViperDB was created as a smaller & faster option to Tripwire. Tripwire while being a great product leaves something to be desired in the speed department and also, by default tripwire generates a report everytime it runs and directs that report to an email address. This hinders most people from running Tripwire every few minutes to do a system check. ViperDB however is the answer to this problem. ViperDB does not use a fancy all-in-one database to keep records instead, I opted to keep it fast and hence decided to go with a plaintext db which is stored in each "watched" directory. By using this there is no real one attack point for a attacker to focus his attention on. This coupled with the running of ViperDB every 5 minutes (via cron root job) decreases that likelyhood that an attacker will be able to modify your "watched" filesystem .while ViperDB is monitoring your system

    As of now, I am tired of waiting around for the beta testers to get back to me and let me know what they think, so I am kinda doing a general release of the source to all to check out and let me know what you think. If you like it, please tell me.. I am always pleased to hear that I have helped someone out. But more than hearing about how great it is.. I would like to hear about problems that you encountered, etc. I have a few more things I would like to add to this script before version 1.0 (official public release & posting on freshmeat.net ,etc) which are listed below. If you can think of anything to add to this script tha tis not listed below, please email me.

    Just before I tell you about how to setup viperdb and shit, let me just save myself some flamemail. I am in no way stating that my lil perl script is better than Tripwire.. I am simply saying that (in my personal opinion) Tripwire leaves something to be desired and whatever it is I feel that Tripwire lacks, I will try to makeup for by adding into my script. Once again, Tripwire is a GREAT product... and I am not trying to knock them. My script is VERY simple, no complex databases, nothing suppah dupah l33t.. just me dinking around and some people have shown interest in possibly having me develop this further ( no profit of course... ain't OSS great *sigh* =P )

    Currently there are 2 files that you need viperdb.ini and viperdb.pl.

    As of now, there is no real documentation on this. I suck ass at documentation, but basically, you stick viperdb.ini in /usr/local/etc/viperdb.ini (you can change the ini file location in viperdb.pl) and edit the ini file to contain the directories that you would like to "watch" (presently it is REQUIRED that you have the trailing / on the path for the script to work.. so /bin in the ini file wouldn't work but /bin/ would... )and then run the 'viperdb.pl -init' this creates the 'database' and stores it.. then when you want to check any changes just do a 'viperdb.pl -check' and any changes will be recorded to /var/log/ViperDB.Log by default (again, you can change the logfile from within the viperdb.pl script.

    PLANNED UPGRADES

    • Adding of a "protect" function which would "react" to changes made to the filesystem and do whatever it could to maintain the stored filesystem (ie change permissions, owners, and groups back to what they were stored as when -init was run)
    • Adding of a more complex "reporting" system which would create email to a specified address and would report changes, additions, and deletions
    • Adding of a more complex "system status" function which when a change is detected, would grab info that might be helpful in determining what caused the change (ie. processes running, users logged in, last few lines from logfiles, etc)

    LOG/TIMELINE
    0.1 - 0.5 - Wrote CreateDB.pl which generates the DBs
    - Wrote CheckDB.pl which used diff to find changes
    - Re-Coded to use a "distributed database" instead of one    centralized DB.
    - Re-Coded to use a config file (ViperDB.ini)
    - Changed to use Assoc. Arrays to speed up processing
    - Added capability to detect additions & deletions of files to    "watched" directories
    0.6 - Merged CreateDB.pl & CheckDB.pl into one
    - Cleaned out debugging code and commented more
    0.7 - Changed logging mechanism from logging to an individual file to logging to the standard logging facility (calls on 'logger')
    - Added '-checkstrict' functionality which changes permissions back to what they were before the change was made to the file.
    - Added exception(s) to '-checkstrict' which removes all permissions from the changed file if the file originally was SUID/GUID.
    - Changed way changes were seen by admin, now a change only sends an alert to the logs once instead of repeatedly.