My project consists on adding a proprietary Protocol to suricata. After writing and testing the protocol’s parser, I then moved to writting the Rust register to be able to use it directly from suricata. However, I’m facing various understanding difficulties :
Firstly, is the logger.rs and the log.rs define the result log in the return of the suricata command eve.json or fast.log?
The network protocol I’m working on, uses different states, where I must verify them from a state table, and if not well structured make it possible to drop or alert via suricata. Hence, is it a rule or should I write it in the rust code??
Is there anyway to be able to work with suricata using rust code as a dynamic library ? (I’ve thinking of rusticata and if it’s possible to add protocols to it)
Any help would be awesome !
I can detail my difficulties if necessary
Currently the Rust logging code still needs a bit of a C “glue”. I would suggest having a look at the ssh implementation as an example. There is output-json-ssh.c which calls the rust code:
jb_open_object(js, "ssh");
if (!rs_ssh_log_json(txptr, js)) {
goto end;
}
jb_close(js);
The simplest thing would be to create “events”. The detection engine can then either drop or alert on these events. For ssh, events are defined here:
Not the complete implementation at this point, but you can see examples of parsers that rely on an external crate, like the krb5 parser. We are working on plugin support, but that isn’t ready yet. See:
Thank you very much for your remarks, it really helped a lot. I’ve understood the C “glue” code to add, I was wondering however, how can I specify the range of sid (similarly to what is available for other existing protocols defined here : https://redmine.openinfosecfoundation.org/projects/suricata/wiki/AppLayer) for my new protocol.
If you plan to submit your protocol for inclusion we can define a range for the protocol. This list is only for protocol implementations included in the Suricata as we ship it.
If you don’t plan to submit it for inclusion I would suggest choosing a different range to avoid future sid collisions.