the reason was to make the db compatible with snort/base.
But I get your point and I will submit a generic ossec2rdbms


On 8/11/07, Josh Drummond <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Just setup the ossec2mysql perl daemon that ships in the contrib
> directory and seems to work correctly.  I don't use Snort or
> BASE.  I'd like to try using it to generate SQL-based reports, easy
> querying, and long-term archiving.  It looks like it puts the entire
> alert content into a single column "data_payload" in the "data" table
> however, rather than breaking out the various decoded fields into
> their own columns (i.e. time/date, hostname, program_name, user,
> srcip, dstip, url, action, status, log, etc etc as well) although
> rule_id can be derived by joining with the "event" and "signature"
> tables.  It seems to me the big win of using a RDBMS to store the
> information is so that one can model the attributes in separate
> columns for advanced querying.  Is there a reason it doesn't do this,
> or is this just a feature not yet implemented waiting for some good
> soul to do it :) ?
>
> Thanks,
> ~Josh
>
>

Reply via email to