Jason,
The changes I’d like to submit would be to,
- Create the connection string values in a db.conf file.
- Pass options in the config parser list to create the rule database if not exists.
- Pass options in the config parser list to update the database from a file or directory. This would keep the most recent revision of the rule.
The schema would mimic the rule class rule.py in suricata-update. This however has way too many fields to be useful, and I’d keep the numbers down to limit useful data. The rule class offers elements of the rule:
enabled, action, proto, source_addr, source_port, direction, dest_addr, dest_port, group, gid, sid, rev, msg, flowbits, metadata, references, classtype, priority, noalert, features, raw.
But I would keep, raw, priority, sid, msg, enabled, gid, classtype, rev, proto, metadata and introduce a content and comment field. I’d also mark all of these fields as varchar in the db to avoid too many problems with value types (even if it’s bad practice)
I’d also start with mysql, then optionally support postgres and MSSQL (in Azure) if the change got accepted.