search

secureworks / dalton

Suricata and Snort IDS rule and pcap testing system
Apache License 2.0
449 stars 91 forks source link

Allow same version of IDS with different build options #109

Closed zoomequipd closed 5 years ago

zoomequipd commented 5 years ago

I would like to have multiple configurations of the same engine and verison..

For Example. I'd like to have both Suricata 4.1.4 without Rust and Suricata 4.1.4 with Rust.

At first thought, this would be as simple as adding another sensor, dockerfile. But in practice because of the way the SENSOR_TECHNOLOGY string is auto determined, it's more complex.

My first thought was to create an ENV variable in the Dockerfile which contained the SENSOR_TECHNOLOGY string. During build time (of the docker image), with the exception of the engine type and version are known, with the exception of the support for "current". This can probably be addressed in dalton-agent.py by checking for the env variable first and default to the current "auto" method is not.

I am interested in hearing the best way to approach this. I'm more than willing to attempt a PR with some direction.

zoomequipd commented 5 years ago

here is an attempt based on a setting a specific SENSOR_TECHNOLOGY via specific Dockerfiles https://github.com/zoomequipd/dalton/commit/a3135eac4e302c81a2c22ec8cca29357d1d406d5

seems to work in my limited testing so far.

whartond commented 5 years ago

Comments at https://github.com/zoomequipd/dalton/commit/a3135eac4e302c81a2c22ec8cca29357d1d406d5#commitcomment-33397212

zoomequipd commented 5 years ago

If I clean up that branch a bit and update README to demonstrate this use case, you ok with me submitting a PR on it?

whartond commented 5 years ago

PRs are welcome although if we are going to update the main repo, I think there may be a slightly easier/better way to support Rust and non-Rust Suricata 4 agents, now that I think about it. Let me me mess around with it and get back with you.

whartond commented 5 years ago

Take a look at this branch at see what you think -- https://github.com/counterthreatunit/dalton/tree/agent-suricata-rust. I haven't updated docker-compose.yaml yet so you'll have to add a specification for a rust agent in there; see README for example. You can also specify a "current" Rust agent if you want too.

zoomequipd commented 5 years ago

It looks like a much more complete implementation that fits my current needs. I worry about it being too specific. For instance, lets say I want one with hyperscan next, or for snort one with OpenAppID and one without, or suricata with a different version of libhtp, etc.

whartond commented 5 years ago

I agree, it is specific (to Rust support), but it kind of needed to be done anyway in anticipation of Suricata 5.0 coming out in less than two months, in which Rust support will no longer be optional.

For your use cases, my suggestion would be to build the agents however you want, either as Docker agents or not; see https://github.com/secureworks/dalton#adding-sensors. Then, if necessary, tweak the dalton-agent.conf file(s), and add engine conf files. I don't think a PR is necessary as such sundry customizations are probably best kept on on the forks of people who have specific use for them, and not part of the canonical repo.

I did make it certain that if the SENSOR_TECHNOLOGY matches the filename of a corresponding conf file (minus the file extension), the the matching conf file will be used:

https://github.com/secureworks/dalton/blob/82571dfa9ffd60cf9ceaf86a13693c4287bf06e3/app/dalton.py#L410-L411