[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ossec-list] Re: ossec2mysql design question
- To: ossec-list@xxxxxxxxxxxxxxxx
- Subject: [ossec-list] Re: ossec2mysql design question
- From: "Meir Michanie" <meirgotroot@xxxxxxxxx>
- Date: Mon, 13 Aug 2007 12:39:54 +0300
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DXdOvQtd9OgIph/Vf4Dq66btZSo6xxcvYl/KL+Y8PzyNT5xXmt+w4XIHimEnbA48yo4ENYHm/6KdkfhahFTd3T+wpCYXP7dEwKXB994Q/Nmn8jQqdsUoj13XhTYZBs/kBfI0EjXcVNrg/M1bo7ec9tv0VF6s75OKaBcb/Gxurzc=
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 <jdrummon@xxxxxxx> 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
>
>
OSSEC home |
Main Index |
Thread Index
OSSEC project: www.ossec.net.
Mailling list information: http://www.ossec.net/en/mailing_lists.html.