I did’nt find any way to activate the Intrusion Prevention System (IPS) on IPFire 2.27. Here is a picture:
If I try to choose a ruleset - nothing happened. Who could help?
Have you tried to add a provider first?
Eventually select one of the Community Rulesets and download the rules.
After that restart the IDS.
Silvio
2 Likes
A quick look into the source of the page showed, that you really can start IPS only with a provider selected.
The additional entries shown in the wiki are displayed with a selected ruleset only.
Yes, I tried to add a provider. After klicking “add” I see an empty white screen. But nothing happens.
Are there any messages in /var/log/httpd/error_log or /var/log/messages ?
I just tried to reproduce your situation.
- stopped IPS
- removed the IPS provider
- no start button etc.
- added my IPS provider
- start is possible and functioning
Only difference: I had a ruleset already. But a manual update went through also.
I had exactly the same problem as the OP, when I try and add an IPS Provider, after clicking the “add” button, I get a white screen.
Following @bbitsch 's suggestion, I checked in /var/log/hjttpd/error_log and found the following:
[Fri Jun 10 11:12:22.644834 2022] [core:notice] [pid 16552:tid 129761122461568] AH00094: Command line: '/usr/sbin/httpd'
Unable to write to file /var/ipfire/suricata/providers-settings at /var/ipfire/general-functions.pl line 902.
Unable to write to file /var/ipfire/suricata/providers-settings at /var/ipfire/general-functions.pl line 902.
I had tried twice, with two different providers which probably explains the repeated error messages.
TIA
Googling the error message took me to this thread:
https://community.ipfire.org/t/ipfire-167-no-ruleset/7839 which had a slightly different problem, but the cause seems to have been the same.
It appears the wrong owner/group have been set for the file /var/ipfire/suricata/providers-settings. On my system they were root:root when they should have been nobody:nobody
Running the following command from the SSH console logged in to my firewall fixed the problem for me:
chown nobody:nobody /var/ipfire/suricata/providers-settings
4 Likes
@robh thankyou this “can’t enable IPS” fix also worked for me on ipfire 2.27 core 170
1 Like
@robh Cheers. This is still an issue on 2.29 Core 185. Fresh install after old hardware finally gave up.
Hi @jimpye
Welcome to the IPFire community.
I just tried a fresh install of Core Update 185 and i ended up with an ownership of nobody:nobody for that file. That is what I have always ended up with on my fresh installs., which I do periodically as part of my Testing evaluations etc.
Here is the exact sequence of steps I carried out.
After doing a fresh install of CU185 here is the listing of files in
/var/ipfire/suricata
So straight after a fresh install the providers-settings file has not yet been created.
The suricata WUI page looked like this
I then pressed the Add provider button and got
I then pressed the Add button and got back to the main page showing
So a provider is now selected but no rules will have been selected from the ruleset.
The /var/ipfire/suricata/ directory now contains
and the providers-settings fiule has been created with ownership of nobody:nobody.
So then I pressed the Customize ruleset button on the main screen and got
I then selected the single rule from this provider and pressed the Apply button and got back to the main page.
I then selected the Enable Intrusion Prevention System and the Enabled on RED check-boxes and then pressed the Save button and got
So suricata has successfully started.
The /var/ipfire/suricata/ directory now contains
and the providers-settings file still has ownership nobody:nobody.
Can you show the sequence of steps that you carry out on a fresh install that result in the root:root ownership occurring.
There might be a bug in the code that if you do certain steps in a certain order then the ownership of root:root gets applied but we need to be able to duplicate that sequence of steps so we can see where in the code the issue is and what needs to be changed to prevent the wrong ownership being applied and at the moment I can not replicate the effect you are experiencing.
1 Like
Thank you for your reply. I might have been a bit misleading saying my installation was a fresh install.
As I mentioned I had a hardware failure which meant I did not have an internet connection to download the latest IPFire image to reinstall from. So I used the original USB I created for my original install and let the system go through all the updates to bring it up to date.
So what I was seeing in my installation was probably a hang over of the bug from past versions bubbling through.
One thing I did notice was there seemed to be several files in that directory that, going by their names, seemed to also have the wrong ownership and was causing the blank screen issue on other areas in the IPS configuration after I was able to add a provider. eg. opening a ruleset to look at it.
I was able to change ownership for all files and could see that hitting reload, which resent the request, that the operation I was doing would complete and I could see the access date/time on a file would have changed.
Is there a definitive list somewhere of the permissions/ownership of the files needed in that directory. As I think having all files as nobody.nobody is a bit too open for a firewall 
Again thanks for your reply.
In principle that should work as long as you are just doing the upgrade over a few Core Updates. What Core Update was the USB version?
Users have done the upgrade successfully over 10 or 20 Core Updates but others have also had significant problems as there could be issues in some of the updates that are only fixed at later times.
I notice that you only mention about doing the install from an old version and did not mention doing a restore from a backup.
If you did a restore from a backup and this was an old version then you could also have the wrong ownerships in the backup.
The backup file is just a tarball so you can download the backup to another PC and use a GUI archive tool to look at the contents.
Looking at the /var/ipfire/suricata/ directory in the backup you should see ownerships and permissions like the following
If you see some entries, beside the ruleset-sources file with a root:root ownership then you have a corrupted backup.
In that case when you fix the problem with the suricata ownerships you should do a fresh backup and delete all older versions with the wrong ownerships.
No there is not. The code for installing and running suricata takes care of all the ownerships.
However looking at my systems, I believe that everything except the ruleset-sources file should be nobody:nobody. The ruleset-sources file should be root:root.
No the nobody user is a non-login user and only it and root can write to any of the files in the /var/ipfire/suricata/ directory.
I always make sure I have a copy of the last 4 Core Update iso’s on my network and the most recent installed into my USB stick, so I am prepared if I need to use it. Only had to do it twice in the last 4 or 5 years but it proved useful to have available.
I also have a document that lists the MAC addresses of each of the NIC’s on my IPFire hardware, on my network and printed out.
That wouldn’t have helped in your present case as you had to replace the hardware but it does help if you need to do an install.
That way I know which MAC address relates to each colour zone.
1 Like
Again thanks for your reply.
The version I started the upgrades from was 2.27 core 162, I did not count the versions it stepped through, but there were a few of them.
I did restore a backup once it was upgraded, but it was from a version one back, so that might have been a contributing factor.
Will look into that.
This seemed to be the case, so it did have some issues.
Done.
This makes sense as all the other files seem to be configuration files that will change depending on which rules and rulesets are enabled/disabled.
Good call.
It will be a new process before each update now
Great minds… I do have a list but with modern phones using random MAC addressing now its a bit hard to keep track, but as I also run a separate DHCP server I can keep track of the current assigned MAC address to the currently assigned IP address for any forensics
Again many thanks for your assistance.
Jim