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

Damn Soda.... You ask the fun ones huh? :)

What's the db engine?

How dynamic do you see the db being?

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

Quote:

---

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.

Quote:

---

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".

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...

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?

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.

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...

Quote:

---

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.