IPS daemon stopped after activating rulesets for the fist time

Security Intrusion Prevention
1

I am running IPFire on an RPi 3b+, Core 176. I wanted to explore the IPS and went by it following the wiki page.

  1. I added the two ruleset providers in the wiki
  2. Activated it for both green and red zone (monitor only mode)
  3. Clicked customize rulesets to activate the specific rules within them.
  4. This seemed to work, but then i noticed the IPS daemon had stopped.
  5. I unchecked “Enable Intrusion Prevention System” and also the Red and Green checkboxes
  6. I unactivated and then clicked delete on the EmergingThreat ruleset because i wanted to see if re-adding them would solve it

…and thats where it has been stuck now for a couple hours. The text in the WebUI has been sitting at

  • Remove old rule structures…
  • Adjust rules and add user defined customizations…

and i get occasional spikes in CPU usage. The rest of the system seems to work fine.

Should i just reboot IPFire ? I dont want to brick it. I guess i can still SSH in and look at things if anyone has a tip for me.

2

Could you post some logs from the System logs, Intrusion prevention.
And could you take a screenshot of Status and Services.

I would guess that the 3B+ with 1GB might be the issue. I am running 4 GB and IPS is using 750MB

1 Like
3

Hi, thanks for the reply.

Yeah you are right about the RAM issue. The IPS log showed that Suricata could not start the daemon again because stale suricata.pid. in /var/run. I deleted it and now it runs. The Kernel log showed some errors too.

I am more careful now about how many rulesets I activate hehe. I activated only a few rules from the EmergingThreats rules and it already eats 397 megs of RAM.

Last time, I activated more, if not all, rules and also Abuse.ch.

But I am not really sure about what rulesets I should absolutely run with the limited RAM i have.

Also,I see that my system doesnt have a swap partition set up by default ? Did IPFire stop using swap partition at some point ? (I found some old screen shots of it being activated)

4

So I just noticed this as well, IPS down.

Upon investigation, same error about stale “suricata.pid” so I went in to ssh cli and figured out how to remove it, restarted the service and now it is working again. I paste the starting log for your scrutiny.
08:22:40 suricata: This is Suricata version 6.0.13 RELEASE running in SYSTEM mode
08:22:40 suricata: CPUs/cores online: 8
08:22:40 suricata: HTTP memcap: 268435456
08:22:40 suricata: Enabling fail-open on queue
08:22:40 suricata: NFQ running in REPEAT mode with mark 2147483648/2147483648
08:22:40 suricata: [ERRCODE: SC_ERR_INITIALIZATION(45)] - pid file ‘/var/run/suricata.pid’ exists b ut appears stale. Make sure Suricata is not running and then remove /var/run/sur icata.pid. Aborting!
08:23:00 suricata: This is Suricata version 6.0.13 RELEASE running in SYSTEM mode
08:23:00 suricata: CPUs/cores online: 8
08:23:00 suricata: HTTP memcap: 268435456
08:23:00 suricata: Enabling fail-open on queue
08:23:00 suricata: NFQ running in REPEAT mode with mark 2147483648/2147483648
08:23:00 suricata: [ERRCODE: SC_ERR_INITIALIZATION(45)] - pid file ‘/var/run/suricata.pid’ exists b ut appears stale. Make sure Suricata is not running and then remove /var/run/sur icata.pid. Aborting!
08:35:54 suricata: This is Suricata version 6.0.13 RELEASE running in SYSTEM mode
08:35:54 suricata: CPUs/cores online: 8
08:35:54 suricata: HTTP memcap: 268435456
08:35:54 suricata: Enabling fail-open on queue
08:35:54 suricata: NFQ running in REPEAT mode with mark 2147483648/2147483648
08:35:54 suricata: dropped the caps for main thread
08:35:54 suricata: fast output device (regular) initialized: fast.log
08:35:54 suricata: Packets will start being processed before signatures are active.
08:35:54 suricata: binding this thread 0 to queue ‘0’
08:35:54 suricata: setting queue length to 4096
08:35:54 suricata: setting nfnl bufsize to 6144000
08:35:54 suricata: fail-open mode should be set on queue
08:35:54 suricata: binding this thread 1 to queue ‘1’
08:35:54 suricata: setting queue length to 4096
08:35:54 suricata: setting nfnl bufsize to 6144000
08:35:54 suricata: fail-open mode should be set on queue
08:35:54 suricata: binding this thread 2 to queue ‘2’
08:35:54 suricata: setting queue length to 4096
08:35:54 suricata: setting nfnl bufsize to 6144000
08:35:54 suricata: fail-open mode should be set on queue
08:35:54 suricata: binding this thread 3 to queue ‘3’
08:35:54 suricata: setting queue length to 4096
08:35:54 suricata: setting nfnl bufsize to 6144000
08:35:54 suricata: fail-open mode should be set on queue
08:35:54 suricata: binding this thread 4 to queue ‘4’
08:35:54 suricata: setting queue length to 4096
08:35:54 suricata: setting nfnl bufsize to 6144000
08:35:54 suricata: fail-open mode should be set on queue
08:35:54 suricata: binding this thread 5 to queue ‘5’
08:35:54 suricata: setting queue length to 4096
08:35:54 suricata: setting nfnl bufsize to 6144000
08:35:54 suricata: fail-open mode should be set on queue
08:35:54 suricata: binding this thread 6 to queue ‘6’
08:35:54 suricata: setting queue length to 4096
08:35:54 suricata: setting nfnl bufsize to 6144000
08:35:54 suricata: fail-open mode should be set on queue
08:35:54 suricata: binding this thread 7 to queue ‘7’
08:35:54 suricata: setting queue length to 4096
08:35:54 suricata: setting nfnl bufsize to 6144000
08:35:54 suricata: fail-open mode should be set on queue
08:35:54 suricata: all 8 packet processing threads, 2 management threads initialized, engine starte d.
08:35:54 suricata: rule reload starting
08:35:54 suricata: Including configuration file /var/ipfire/suricata/suricata-homenet.yaml.
08:35:54 suricata: Including configuration file /var/ipfire/suricata/suricata-dns-servers.yaml.
08:35:54 suricata: Including configuration file /var/ipfire/suricata/suricata-http-ports.yaml.
08:35:54 suricata: Including configuration file /var/ipfire/suricata/suricata-used-rulesfiles.yaml.
08:35:54 suricata: [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - Invalid rule-files configuration sectio n: expected a list of filenames.
08:35:54 suricata: No signatures supplied.
08:35:55 suricata: cleaning up signature grouping structure… complete
08:35:55 suricata: rule reload complete
08:35:55 suricata: Signature(s) loaded, Detect thread(s) activated.

Meanwhile I will check why I did not get any mail report on this, thought I had it confed…
wiki seems to be down at the time I am writing this…

Running 176 btw…