Trying to add provider in Intrusion Prevention Services and get blank web page https://192.168.1.1:444/cgi-bin/ids.cgi that doesn’t progress. Tried using Talos (Snort) registered user with my oinkcode and it does the same resulting in a blank page. Turned off pihole and adguard DNS and still have the same problem thinking this was the cause. The IPS daemon is not running as I understand you must add a provider first. No provider works so this seems to be a problem with IPFire. Currently running version 165.
Hi,
first, welcome to the IPFire community. 
Second, based on your description, I believe you suffer from this bug. To confirm that, does switching to a different IPS ruleset provider improve things for you?
Oh, a time traveler. The current stable version of IPFire is Core Update 164. 
Thanks, and best regards,
Peter Müller
I have the same problem on core164, can’t add ANY ruleset provider! I have enabled the recommended new “Drop packets from and to hostile networks.”
After clicking ADD on the provider settings page I just get a blank page “https://10.2.2.2:444/cgi-bin/ids.cgi” and no rule set has been added when I go back to the IDS page.
I am on testing version 165 but this happened on stable 164 as well, I just didn’t bother trying to solve it until today. This happens on all rulesets and is not specific to Talos.
I can’t install any rulesets at all. So, not actually specific for Talos. This is on testing 165 but same problem for c164.
If you look through the community postings, you’ll find many problems with IDS rules.
This bug is under development at the moment, but will be solved in one of the next CUs ( hopefully c165 ).
3 Likes
Thanks, yes, I am seeing this. It isn’t critical to me but I wanted to harden our router more. I am on t165 and it is a problem still so much more work to do.
This problem still exists on my machine with Core Update 171. Any solution in sight?
As far as I was aware that problem was fixed several Core Updates ago.
I just checked and confirmed with my running CU171 system that I have two providers listed in it and I added a third successfully, selected the rules and saved them and it all is shown on my screen.
I was also then able to successfully delete the added provider.
This is what my IPS page looks like.
What does the IPS page look like on your system.
When I click Add provider I get this screen.
Is this the point at which you get a blank screen.
My IPS page:
and I can go to the Add provider page which looks the same as yours but after clicking “Add” I get to the blank page.
I wondered if the problem was when starting with an empty IPS page, so I installed a fresh CU171 into a vm so that my starting status was Stopped and with no providers listed.
I was then able to successfully load two providers, Abuse.ch and Emerging Threats Community and then start IPS.
I suspect that when you had your Testing version of Core Update 164 it never got updated to the full version of Core Update 164 before updating to CU165 and onwards.
There are probably some files or some permissions not in place or incorrectly set.
I think your best bet is to make a backup and save it on another computer and then do a fresh install of CU171, test adding some IPS providers and if that works then doing a restore from the backup and see if everything is still working okay after that.
I never had a testing version installed so that can’t be the reason. Is there a way to get it going without reinstalling?
If it wasn’t due to a partial Testing Release then something must have gone wrong with one of the Core Updates.
There is an alternative to doing a re-install but the likelihood is that it will take longer.
This is described below.
Before doing that you should try to access the page that shows up blank and then go into the console and look in the httpd/error_log
less /var/log/httpd/error_log
This give some info on what the problem is that is causing the blank screen to be shown.
If that doesn’t give any clue then you could always then start to follow the following steps, although my recommendation would still be to do a fresh install and restore.
To check the files ownerships and permissions you will have to check all the files involved with the IPS system to see if their permissions and ownerships are correct.
I am not sure of all the files involved with the IPS but a starting point is the following directory
ls -hal /var/ipfire/suricata/
total 60K
drwxr-xr-x 2 nobody nobody 4.0K Dec 18 14:42 .
drwxr-xr-x 50 root root 4.0K Oct 20 16:53 ..
-rw-r--r-- 1 nobody nobody 64 Dec 18 14:41 emerging-modifications
-rw-r--r-- 1 nobody nobody 257 Dec 18 14:41 emerging-used-rulesfiles
-rw-r--r-- 1 nobody nobody 66 Dec 20 15:36 etags
-rw-r--r-- 1 nobody nobody 0 Dec 15 2020 ignored
-rw-r--r-- 1 nobody nobody 129 May 24 2022 oinkmaster-provider-includes.conf
-rw-r--r-- 1 nobody nobody 71 Dec 18 14:42 providers-settings
-rw-r--r-- 1 root root 5.4K Jul 7 23:09 ruleset-sources
-rw-r--r-- 1 nobody nobody 52 Jul 1 12:23 settings
-rw-r--r-- 1 nobody nobody 38 Dec 18 14:41 sslbl_blacklist-used-rulesfiles
-rw-r--r-- 1 nobody nobody 188 Dec 4 18:48 suricata-dns-servers.yaml
-rw-r--r-- 1 nobody nobody 156 Dec 1 05:00 suricata-homenet.yaml
-rw-r--r-- 1 nobody nobody 102 Jul 1 12:23 suricata-http-ports.yaml
-rw-r--r-- 1 nobody nobody 1.4K Dec 18 14:42 suricata-used-rulesfiles.yaml
You won’t have all these files as some are related to the providers that have been selected.
You should however have settings and ruleset-sources and the ownership and permissions should match the above.
I think you should have providers-settings as well but in your case it should be an empty file.
You should have the four files starting with suricata. They are all auto generated files.
The suricata-used-rulesfiles.yaml should just have the following lines
%YAML 1.1
---
#Autogenerated file. Any custom changes will be overwritten!
- /var/lib/suricata/whitelist.rules
#Default rules for used application layer protocols.
- /usr/share/suricata/rules/app-layer-events.rules
- /usr/share/suricata/rules/decoder-events.rules
- /usr/share/suricata/rules/dhcp-events.rules
- /usr/share/suricata/rules/dns-events.rules
- /usr/share/suricata/rules/files.rules
- /usr/share/suricata/rules/http-events.rules
- /usr/share/suricata/rules/ipsec-events.rules
- /usr/share/suricata/rules/kerberos-events.rules
- /usr/share/suricata/rules/mqtt-events.rules
- /usr/share/suricata/rules/nfs-events.rules
- /usr/share/suricata/rules/ntp-events.rules
- /usr/share/suricata/rules/smb-events.rules
- /usr/share/suricata/rules/smtp-events.rules
- /usr/share/suricata/rules/ssh-events.rules
- /usr/share/suricata/rules/stream-events.rules
- /usr/share/suricata/rules/tls-events.rules
If providers have been selected then there will be sections starting with
#Used Rulesfiles for
followed by the provider name.
You should have the following file available in the shown path.
ls -hal /var/ipfire/ids-functions.pl
-rw-r--r-- 1 root root 55K Jul 7 21:47 /var/ipfire/ids-functions.pl
The permissions, ownership and date should match what you have.
the ruleset-sources files should have the same date as the ids-functions.pl file.
The above is a good starting point to look at and maybe other people can give more input on what to look for.
EDIT:
You can also check that the ids-functions.pl file is correct by checking the b2sum hash for the file. You should get the same number as shown below.
b2sum /var/ipfire/ids-functions.pl
6cea6314b3b41a2cb5b93d0f38e2c65d0109120aa479872beb08b32a16c1cdc7506c413e4cd1301ddeab0903696efe00aeebb51203f5219cefd71965c996fb79 /var/ipfire/ids-functions.pl
There’s some progress, the directory looked like this:
drwxr-xr-x 2 nobody nobody 4.0K Jul 16 09:13 .
drwxr-xr-x 48 root root 4.0K Oct 18 16:55 …
-rw-r–r-- 1 nobody nobody 0 May 18 2019 ignored
-rw-r–r-- 1 nobody nobody 0 May 18 2019 oinkmaster-disabled-sids.conf
-rw-r–r-- 1 nobody nobody 0 May 18 2019 oinkmaster-enabled-sids.conf
-rw-r–r-- 1 nobody nobody 171 Jun 28 2019 oinkmaster-modify-sids.conf
-rw-r–r-- 1 root root 0 Mar 11 2022 oinkmaster-provider-includes.conf
-rw-r–r-- 1 root root 0 Jun 19 2022 providers-settings
-rw-r–r-- 1 root root 5.4K Jul 7 23:09 ruleset-sources
-rw-r–r-- 1 nobody nobody 0 May 18 2019 rules-settings
-rw-r–r-- 1 nobody nobody 27 Mar 11 2022 settings
-rw-r–r-- 1 nobody nobody 98 Apr 23 2020 suricata-http-ports.yaml
-rw-r–r-- 1 root root 0 Mar 11 2022 suricata-used-providers.yaml
-rw-r–r-- 1 nobody nobody 0 May 18 2019 suricata-used-rulefiles.yaml
-rw-r–r-- 1 nobody nobody 0 Jul 16 09:13 suricata-used-rulesfiles.yaml
So I changed the file ownerships and now I don’t have a blank page anymore and suricata starts. However, the suricata-used-rulesfiles.yaml doesn’t change. It stayed empty first after adding a rule provider and then I pasted the content you showed into it, stopped and restarted suricata, added another rule provider etc. still no changes except time stamp. The file ids-functions.pl has the correct checksum.
Directory now looks like this:
drwxr-xr-x 2 nobody nobody 4.0K Dec 21 14:32 .
drwxr-xr-x 48 root root 4.0K Oct 18 16:55 …
-rw-r–r-- 1 nobody nobody 39 Dec 21 14:34 etags
-rw-r–r-- 1 nobody nobody 0 May 18 2019 ignored
-rw-r–r-- 1 nobody nobody 0 May 18 2019 oinkmaster-disabled-sids.conf
-rw-r–r-- 1 nobody nobody 0 May 18 2019 oinkmaster-enabled-sids.conf
-rw-r–r-- 1 nobody nobody 171 Jun 28 2019 oinkmaster-modify-sids.conf
-rw-r–r-- 1 nobody nobody 0 Mar 11 2022 oinkmaster-provider-includes.conf
-rw-r–r-- 1 nobody nobody 39 Dec 21 14:34 providers-settings
-rw-r–r-- 1 root root 5.4K Jul 7 23:09 ruleset-sources
-rw-r–r-- 1 nobody nobody 0 May 18 2019 rules-settings
-rw-r–r-- 1 nobody nobody 32 Dec 21 14:08 settings
-rw-r–r-- 1 nobody nobody 158 Dec 21 14:08 suricata-dns-servers.yaml
-rw-r–r-- 1 nobody nobody 120 Dec 21 14:08 suricata-homenet.yaml
-rw-r–r-- 1 nobody nobody 98 Dec 21 14:08 suricata-http-ports.yaml
-rw-r–r-- 1 nobody nobody 0 May 18 2019 suricata-used-rulefiles.yaml
-rw-r–r-- 1 nobody nobody 922 Dec 21 14:34 suricata-used-rulesfiles.yaml
So it probably doesn’t work correctly. Anything more I can do or is re-install the only option left?
This looks like there was some corruption of ownerships for some reason during a core update.
The challenge will be to figure out all the files that need to be checked and corrected.
You have two files with very similar names. The first one should not be there.
Pasting content into the files won’t work as they are overwritten by suricata.
Your providers-settings file is no longer 0 in the updated list so I would now expect that file to contain the providers you selected in the WUI page.
Your updated directory listing has the file
which should not be there. It is the incorrect name - rulefiles vs rulesfiles
The correct file
is no longer zero so if you check the content of that file then it should show the Default Rules content I showed and hopefully the rules info from the provider(s) you selected.
I deleted the file which shouldn’t be there. As mentioned in my previous message the suricata-used-rulesfiles.yaml file doesn’t get updated or changed so no rules from the selected providers there (tried a couple of times)
Basic check question.
For the providers you have selected did you then select the rulesets that you wanted to use. By default for at least Emerging Threats and Abuse.ch no rulesets are selected. So you have to press the Customize ruleset button after selecting the providers that you want. Then you can check the boxes for the rulesets that you want to use.
Apologies if you have selected the required rulesets for the providers.
2 Likes
This did the trick, sorry for not knowing that. Happy New Year!
1 Like