I am planning to update existing Suricata i.e. v4.1.0 to v6.0.0. additionally in 4.1 i was not using suricata-update instead i had pulledpork. I would request for help on below questions -
I am not quite clear from documentation if upgrade should be sequential i.e. 4.1 > 5.0 > 6.0 or can i directly upgrade 4.1 to 6.0
The readthedocs documentation do not show commands used for upgrade with custom options. please help me with update commands sequence.
i want to switch from existing pulledpork to suricata-update, how should i do that, any guidance please?
@ish may be I am troubling you again, but i doe need to know this thanks in advance
You can just jump to 6.0, just make sure that you look into the new suricata.yaml we provide so that you don’t miss any interesting new features or still use some deprecated options.
What do you mean by custom options?
There is no specific guide I guess, but you can just try suricata-update and point it to your rulesets and compare the outcome with what pulledpork would have shown.
You can upgrade from 4.1 to 6.0 just fine. You don’t need to move to 5.0 first.
If you provided custom options in your 4.1 build, for the most part you’ll want to use the same ones for 6.0. Especially those that change install locations like like --prefix, --sysconfdir, etc. Run suricata --build-info to see these options on your current install.
We don’t have much info on switching from PulledPork. My best advice would be to just start using Suricata-Update and make sure your suricata.yaml is configured to pull from the Suricata-Update file then start migrating your PulledPork configuration over. The files are similar, but not 100% compatible, so you’ll have to test.
Thanks @ish
so when I upgrade 6.0 with custom options, are existing suricata.yaml, classification.config and referance.config files overwritten with new ones,
if yes, how can we stop not doing so
if no, where can we get new copy of such files to compare and add features offered in new versions
A make install will only overwrite the program files, not the config. New suricata.yaml will be in the top-level source directory, and the other configuration files will be in the etc/ directory (of the source).
For the most part, things should still work with the old configuration files, but you may seem some warnings which would be worth cleaning up.
Hi @ish
can you please help where to configure suricata,yaml to pull updates from suricata-update
In new suricata.yaml file I only see -
Configure Suricata to load Suricata-Update managed rules.
default-rule-path: @e_defaultruledir@
rule-files:
suricata.rules
This does not show that update should come from suricata-update or PulledPork. as my existing setup updates suricata.rules bye pulledpork.
i do not want to first remove pulledpork unless suricata-update starts working as expected
After you build Suricata you will have a suricata.yaml which has the paths setup to match your ./configure arguments - it looks like you are looking at suricata.yaml.in. Anyways, the most standard configuration would look like:
This configuration file is unaware of Suricata-Update or PulledPork. It just needs to point to the rule files that the tool you choose to use will output. It will be up to you to run Suricata-Update or PulledPork how you see fit.
If you are running from a Debian or RPM package (or build with something like --localstatedir=/var then the bundled Suricata-Update will write to /var/lib/suricata/rules/suricata.rules and the suricata.yaml will already be configured to read from this file.