Database Integrity Monitoring
Results 1 to 9 of 9

Thread: Database Integrity Monitoring

  1. #1

    Database Integrity Monitoring

    Hey there...

    I know that the point of databases is to have data inserted, updated removed... so it's sort of in a state of flux...

    However, is software available that has sort of a tripwire approach to database integrity? If not, what ways would be simple to detect if a change has been made to a database? For instance...
    PHP Code:
    $result query('SELECT * from TABLE');
    $hash md5($result); 
    ...Then if the hash changes, it's been modified. However, I don't know what element has been modified, nor does this seem very efficient.

    This will be for a web application honeypot, and I'm looking to build a layer to notify me of an attack...

    Thanks in advance

  2. #2
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    Damn Soda.... You ask the fun ones huh?

    What's the db engine?

    How dynamic do you see the db being?
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  3. #3
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    Hi

    Unfortunately, I am not aware of a simple "delta"-mechanism,
    ie. you store one (locked) state of the database (scheme),
    and only changes to this initial state are stored in another
    structure. Certainly, a lot of applications with a middleware
    server are using this technique, but you would like to allow
    for all sql-queries, not just defined ones. Hence, ...



    Since MySql 5.0 supports stored procedures, triggers etc.,
    my idea is implementable on all common database systems.

    You are developing a web application honeypot, therefore
    only one specific database (or scheme) should be available
    to the web application user. In particular, you can deny
    any create/read/update attempts on stored procedures and
    triggers.


    1. Although it is not really efficient (but more efficient than
    comparing two database-versions), you could create a trigger
    for each field in your database (scheme) for any kind of command
    (select, update, delete, ...). This might be limited if the
    honeypot-attacker gets the rights to modify the structure of
    the database (scheme)/tables.

    2. Furthermore, you could send all SQL-queries to a stored
    procedure that creates a "timestamp, id and query"-entry in
    a table in another database (or scheme) and then naively
    executes the query. Having this "history" available, the query
    then could be put in relation to the triggers.


    Of course, you "simply" could dump the database (scheme) to a
    sql-statement file, use step 2 to handle the queries, create
    another dump and compare the two dumps (feasible, but depends
    on the load of your honeypot). For simplicity, store the dumps
    on a CD/DVD.

    In any case I would store a dump of a "clean" state on CD/DVD
    if you want to "reset" your honeypot :-)


    Cheers
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

  4. #4
    Originally posted here by sec_ware
    [B]Hi



    Since MySql 5.0 supports stored procedures, triggers etc.,
    my idea is implementable on all common database systems.

    You are developing a web application honeypot, therefore
    only one specific database (or scheme) should be available
    to the web application user. In particular, you can deny
    any create/read/update attempts on stored procedures and
    triggers.


    1. Although it is not really efficient (but more efficient than
    comparing two database-versions), you could create a trigger
    for each field in your database (scheme) for any kind of command
    (select, update, delete, ...). This might be limited if the
    honeypot-attacker gets the rights to modify the structure of
    the database (scheme)/tables.

    I'm not too familiar with MySQL, but with Oracle, logging for everything is usually on by default. Redo logs, and archiving processes can be monitored via third party tools. I would check with the engine for existing tools first. Additionally, with Oracle, you wouldn't need triggers on each field, rather on each object.


    2. Furthermore, you could send all SQL-queries to a stored
    procedure that creates a "timestamp, id and query"-entry in
    a table in another database (or scheme) and then naively
    executes the query. Having this "history" available, the query
    then could be put in relation to the triggers.


    Of course, you "simply" could dump the database (scheme) to a
    sql-statement file, use step 2 to handle the queries, create
    another dump and compare the two dumps (feasible, but depends
    on the load of your honeypot). For simplicity, store the dumps
    on a CD/DVD.
    I would be wary of that, if an attacker gets access to the "honeypot DB", they might easily get access to the "logging DB".

  5. #5
    It will be MySQL because most of these cheap web app's won't support something like oracle... I expect minimal activity from random spiders, pageloads and such, but something like a worm would probably hit it a little harder, maybe add a user or such. So some of the apps may have tables with "normal" traffic, meaning I'd have to have a configurable IDS that does this...

    There was an article about a bot creating a user called funktalow on thousands of phpBB forums recently... some say it's for a mass hack, I say BS because the bot would also make posts with that user (why draw attn to itself?) I believe it's some spammer developing another tool...

  6. #6
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    I'm having trouble envisioning the scope of this app which makes it hard to come up with suggestions.

    The bigger the database, (number of tables, number of fields etc.), and the purported function of the site/app will make it more complex to pick out valid user input, (assuming you expect any actual users), and "discard" it while still finding the malicious activity and accurately alerting on it.

    Are you expecting valid use of the app, (like a BBS or something), or are you just "popping", (pun intended), a potentially vulnerable db app out there and seeing what activity you attract?
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  7. #7
    There will be no use of the application, (one is likely to be phpBB2, but I'm thinking outside the app right now). Things like posts & users will be obviously static, unless there are some fields modifiable by spiders like "last read" or something where a web crawler could screw it up. So, I need to be able to filter this and that...

    I'm hoping I'll get initial reports from snort when an attack comes through, as most web based exploits are fairly loud... but I still want to cover my bases in case things get crazy.

  8. #8
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    Well... In light of what you said and with my limited experience and ability with MySQL and PHP you should be able to lock the MySQL fields so they cannot be changed and turn off the error check in the PHP source to keep the robots and others from altering the db and the system from erroring out on you or the remote user. That would help with the stability of the db and with no user activity it will leave you with pretty much only activity of interest... You will obviously need to fine tune it...

    I was thinking about Snort because they already have pretty good MySQL rules and with Bleeding Snort and the ability to write your own rules you could, possibly quite quickly, come up with a pretty solid alert system.

    Outside of that you are really trying to control a system that is difficult to control... You like the easy tasks don't you ... Sorry I can't come up with an instant answer... But keep bouncing ideas at me and I'll keep bouncing them back... maybe we could muddle something together...
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  9. #9
    Originally posted here by Tiger Shark
    I was thinking about Snort because they already have pretty good MySQL rules and with Bleeding Snort and the ability to write your own rules you could, possibly quite quickly, come up with a pretty solid alert system.

    Outside of that you are really trying to control a system that is difficult to control... You like the easy tasks don't you ... Sorry I can't come up with an instant answer... But keep bouncing ideas at me and I'll keep bouncing them back... maybe we could muddle something together...
    I'm planning on writing some rules for the known phpBB exploits, as well as using something like osiris or tripwire to do file integrity checks...

    As far as this whole database thing, it might be as simple as a perl script with some test queries... and a couple hashes on important things. The databases won't be that big, they'll be default installs of (like I said before) cheap web apps.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides