Now that rust-lang is working, I'm going to start working on optimizing and slimming it down some, If you have any issues, let me know.
1 Like
runtime test did not pan out so good... related log in post above...
What does uci show suricata give?
whatever the default is... after the logread and init.d errors I bailed out... ( logread is pretty essential to testing stuff suppose next time I can find your other post and attempt just a foreground manual run or something )
actually... I did not zero the sdcard before writing... let me try again... this time doing a full zap ( this caused random issues for a previous build user )...
Reason I asked is because I updated init.d and the config, but it may ahve been after you pulled the PR.
You can redo the patch, or, pull the /etc/init.d/suricata and /etc/config/suricata
1 Like
ok... there is no /etc/config/suricata
Yeah, I ujpdated the PR after you pulled it then.
I linked to the two files above. If you want to pull them, that's the only change
1 Like
ok... i'll try again with those and a proper dd erase before flashing to see if that created the logread issues...
1 Like
ok... seems to startup ok now with a config file in place... and logread issue is un-related...
have to hand off to others to test at this point due to time constraints...
thanks for your hard work in this...
Where to put Suricata Rules by DEFAULT?
- Default Location (Built-In-Rules:/usr/share/suricata/rules/, Suricata-Update:/var/libs/suricata/rules)
- Hybrid Location (Built-In-Rules:/usr/share/suricata/rules, Suricata-Update: /etc/suricata/rules)
- Something Else (Post Below)
0 voters
I am looking for Advice on where to put the Built-In Distro rules and the Suricata.rules file created by Suricata-update.
Chime in!
seeing some similarities with nginx... et. al...
gut says;
/etc/suricata/rules.default
/etc/suricata/rules.update
/etc/suricata/rules.${instance}?
By default, /usr/share/suricata/rules/ holds the distro rules, and suricata-update uses /var/lib/suricata/rules/ to hold the suricata.rules file.
Our concern is
- Do we need/want to save the rules files on backup?
- Rules path are completely settable via UCI, but I want default locations to put it so it runs out of the install to some degree..
the thing is... if you are not using keep.d certain sysupgrade -b logic works by comparing /etc...
you lose this ability (not a huge loss but something to be mindfull of) by stashing 'config' under /usr or /lib ... if they are static-per-ipk... then /usr/lib/PKG is the openwrt typical location for bin related includes...
if they are updated/user modified and expected to be migrated alongside backup data... then /etc is the place to be IMHO
if they are bulky / and or highly dynamic... then /tmp comes into play ( think adblock rules )
Gotcha..
The Distro rules I think I can ignore, because they are installed with the ipkg regardless, unless they are edited by the user, and they shouldn't be editing those files anyway, no?
Suricata-update uses /var for processing speed, but since it's dynamic, I don't know if saving it is worthy. It would give a base reference ruleset on an upgrade, but sysupgrade doesn't reinstall the ipkgs, the user will get them when they reinstall Suricata (correct?), and suricata.rules would be recreated when it was ran.
I currently have Package/suricata6/conffiles pointing at /etc/suricata and /etc/config/suricata, which (in theory) should also pull in anything under /etc/suricata/rules that the user stores (.rules files not created by suricata-update or included with suricata, for example)
I was able to run suricata on the ER-10x, but NOT the et/open rules lists due to RAM limits (the ER-10x has 512MB RAM Only, and Suricata with et/open takes 480MB). But smaller lists were fine. I just need to be able to backup without wasting space what needs to be kept vs what can be regenerated after the fact (if that makes sense)
1 Like
exactly... farming out core config params -> /etc/config -> /tmp/abc.conf <-> ln -s -> /etc/abc/rules is one way a fair amount of apps keep writes to a minimum and backup easy... ( and honouring pure non-uci based configuration )
so defining what params are definable in 'etc/config/abc' will be a slice of the factors you have to consider...
I think for the sake of simplicity... 'default' rules staying per ipk@/usr/lib || /usr/share ( whatever the default package defines ) is acceptable in term of 'breaking consistency'... so long as most of the attention is payed to config migration and init.d~tmp~merge processes...
I have not checked apache but that comes to mind as having a similar structure... might be worth a look... samba has a cool split the primary config in half method... dnsmasq is probably the benchmark/most adaptable in terms of putting what you want where you want it... but they all leverage features from daemon specifics... afaik... all the (old)snort rules are in etc... but maybe the new-snort uses /usr? have not messed with the new snort...
1 Like
that's borderline 'i-want-a-brick' territory... in other words... given the few users likely to 'take-up' the initial offerings... and their likely advanced skill levels... I think you are in 'radius' territory...
in other words... do as little as possible in '/etc/config/abc'... and leave it up to the user to take care of their own backup for anything outside of 'etc/config' (same for non-(daemon)standard path structure if you can manage it)
Oh, I meant as far as MEMORY footprint for Suricata with the et/open ruleset, not the ruleset itself (which is 16MB text).. But, yes, I think just letting the user re-run update is the best bet
2 Likes
To anyone who wants to test easiler, I've created a working branch that combines all the rust-lang, suricata6, libhtp, and suricata-update all into a single branch.
1 Like
I'll be pushing a new working branch soon, hopefully. This should fix the arm issues (I hope)
2 Likes