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