Moving the Suricata module from its temporary repo to Filebeats #8089
Conversation
This is the code as of commit #c346ff7 over [there](https://github.com/elastic/filebeat-module-suricata/pull/1)
|
Correction: just after posting this, I realized that somehow the Kibana objects in |
|
@ruflin Awesome, thank you for the pointer! |
| [float] | ||
| === Compatibility | ||
|
|
||
| TODO: document with what versions of the software is this tested |
There was a problem hiding this comment.
Should we fix the TODO in this file before merging? What I worry is that we forget about it before we release it.
There was a problem hiding this comment.
I agree we can't forget this. But testing compatibility will take a little while. I would track this as a task to be completed as part of the initial release. I wouldn't necessarily have the initial PR wait on this.
There was a problem hiding this comment.
What I would add here is just the version you tested yourself with and used for creating this. That is what we normally do for Filebeat / Metricbeat.
There was a problem hiding this comment.
++ on creating a meta issue to track necessary steps for first release. could you create one?
There was a problem hiding this comment.
Since I'm handing off the module to Andrew I've created an ad hoc Google Docs with a bit of background, some links, some issues and some remaining tasks. I'll let him decide how to track the follow-up work.
But I did add a task in this handoff doc, so we do have it somewhere. I tagged you there, you should have received a GDoc comment notif :-)
There was a problem hiding this comment.
Ah right, I will add the current version I used, though. That's straightforward enough :-)
| @@ -0,0 +1,8 @@ | |||
| {"timestamp":"2018-07-05T15:01:09.820360-0400","flow_id":298824096901438,"in_iface":"en0","event_type":"ssh","src_ip":"192.168.86.85","src_port":55406,"dest_ip":"192.30.253.112","dest_port":22,"proto":"TCP","ssh":{"client":{"proto_version":"2.0","software_version":"OpenSSH_7.6"},"server":{"proto_version":"2.0","software_version":"libssh_0.7.0"}}} | |||
There was a problem hiding this comment.
Would be nice to have a test and generated file as we do in other filesets in addition to this. This would also make it more visible how the end events look like.
The problem is I you would have to copy the module to the module directory and then run the test / generate script there.
There was a problem hiding this comment.
Ok I see what you mean with example test.log and test.log-expected.json.
These tests run which part of the processing? Currently only a little bit of work is performed in Beats (read as JSON as is to suricata.eve.*), and the rest of the work is performed in ingest node. I assume the tests don't run an ES ingest node?
There was a problem hiding this comment.
The test run ingest node. Have a look at test_modules.py
|
This is no longer relevant. |
This is currently a WIP and is not ready to be reviewed yet.
I will consider it ready for review when:
at the top level except
ecs.source, to avoid the pre-7.0 name clash).beats/filebeat/_meta/fields.common.yml
for this module, not all of them at once.
ECS fields, instead of creating them based on
suricata.eve.*.If you want to try the module out, look for a few tips (and more caveats)
in the module's readme:
x-pack/filebeat/module/suricata/README.md.It has functional ingestion, minimal enrichment via Ingest Node and
2 starter dashboards (Overall and Alerts).