Tried it out. But it shows me “last modification 13:10”. But at the Monet it’s 13:30 o’clock.
And inside the file for 12:19 o’clock it tells me: “[Fri Jul 01 12:19:12.798985 2022] [cgid:error] [pid 26656:tid 133519010993728] [client 178.13.224.130:39630] End of script output before headers: ids.cgi, referer: EXTERNAL-URL-OF-THE-WEBGUI-I-AM-USING”
I just realised that I didn’t look closely enough at the output from your provider-settings file. That long string starting with badb4e is not in my provider-settings file. that section is blank.
Mine looks like
1,emerging,,enabled,enabled,IPS
2,sslbl_blacklist,,enabled,enabled,IPS
I have two entries because I am already using the multiple providers option on my system.
I would edit that file, maybe making a backup copy just in case, to look like
1,emerging,,enabled,enabled,IPS
and then try accessing the ids.cgi page again.
Tried it and restarted the service (after added settings-entries some minutes ago).
But the GUI shows the same …
As ids-functions.pl says for return codes: “no url” - If no download URL could be gathered for the provider
In line 355 it grabs the “dl_url” for the provider with my $url = $IDS::Ruleset::Providers{$provider}{'dl_url'};
And in line 368 it seems to end with # Abort and return "no url", if no url could be determined for the provider.
So I think the reason for the problem is between these lines, right?
That is a reasonable conclusion but I can’t figure out what, although the ruleset-sources file is a potential issue.
Let’s first just confirm that ruleset-sources and the ids-functions.pl are as they should be by running a b2sum on them. Here is what I get.
b2sum /var/ipfire/suricata/ruleset-sources
5090fc5e817a2e99e2b3a4776877d3254d5b3329fe6c5e698e0f376dd9069d499caaa787043eefbf9506fee742d04829a640596802d12e6f1d21e32b56eb2a29
b2sum /var/ipfire/ids-functions.pl
6cea6314b3b41a2cb5b93d0f38e2c65d0109120aa479872beb08b32a16c1cdc7506c413e4cd1301ddeab0903696efe00aeebb51203f5219cefd71965c996fb79
I have confirmed these numbers both in my IPFire vm system and from the build files that I have.
1 Like
Check: functions.pl
6cea6314b3b41a2cb5b93d0f38e2c65d0109120aa479872beb08b32a16c1cdc7506c413e4cd1301ddeab0903696efe00aeebb51203f5219cefd71965c996fb79 /var/ipfire/ids-functions.pl
Neg: ruleset-sources
30dbad5663b36dedb7e2bb6f72fb449e81531c19e4926e5b2b7570ef315b5c0dad997a778109e087de2c5c4606e299c7dd979538fa5665c1a305d00b2d3fd6d8 /var/ipfire/suricata/ruleset-sources
Took the ruleset-sources again from “ipfire-2.27.2gb-ext4.x86_64-full-core168.img” (2.img) and put it on the IPfire.
But the checksum-result is the same …
Sorry about the ruleset-sources problem, I was checking on my vm system and it is running CU169 Testing. I checked the value from the git repository for CU168 and I get the same as you.
Can you confirm that you were using Emerging Threats Community and not Emerging Threats Pro.
The download url for the emerging threats community ruleset from the ruleset-sources file is
https://rules.emergingthreats.net/open/suricata-5.0/emerging.rules.tar.gz
I entered this into my browser and it opened the archive for me showing all the rules available from that provider.
If you look in the ruleset-sources file the emerging threats community info starts at line 50
Line 50 ff.:
# Emerging threads community rules.
emerging => {
summary => "Emergingthreats.net Community Rules",
website => "https://emergingthreats.net/",
tr_string => "emerging rules",
requires_subscription => "False",
dl_url => "https://rules.emergingthreats.net/open/suricata-5.0/emerging.rules.tar.gz",
dl_type => "archive",
},
And inside provider-settings is set:
1,emerging,,enabled,enabled,IPS
When the no url error message occurs on the screen then there should also be an entry in the messages log.
Try accessing the IPS WUI page again and after getting the error message look in
/var/log/messages
looking for
<ERROR> Could not determine a download URL for
and this should be followed by the name of the provider.
Can you check what is in the log for the provider. I want to confirm that the problem is occurring when trying to download the emerging provider ruleset and not that it is getting confused with another provider.
1 Like
Sorry, nothing with URL in this context available in /var/log/messages.
But for diagnostic purposes I added the URL instead of the array-data in line 355-357 inside ids-functions.pl:
# Grab the download url for the provider.
#my $url = $IDS::Ruleset::Providers{$provider}{'dl_url'};
my $url = "https://rules.emergingthreats.net/open/suricata-5.0/emerging.rules.tar.gz";
It seems, the ids-function.pl goes one step forward. But for the next steps all the other information from providers-settings are missing.
Is it possible for diagnostic-steps, to output debug-information about accessing poviders-setting from ids-functions.pl over the WUI?
Will start a fresh install over the weekend …
Possible that the update from 159 to 168 was the reason …
In the ids.cgi file there are the following lines that can be uncommented for debugging purposes. Never tried them myself so don’t know what they will provide but it might be worth a try.
25 # enable only the following on debugging purpose
26 #use warnings;
27 #use CGI::Carp 'fatalsToBrowser';
1 Like
The move from 159 to 168 might have had an effect. The move from CU167 to CU168 was a major change for the IPS as it moved to multiple providers and the ability to update each individually or not and the update moved from a choice of daily or weekly to a fixed daily check if the update was needed.
Good luck over the weekend.
These warnings show possible problems in the Perl script.
Usually these are interpreted the right way. Perl is nearly a DWIM ( Do What I Mean ) language. 
1 Like
Found the reason: language-files were not updated from the old ones.
On my diagnostic-way I stumbled over “ruleset-sources” line 12 “The translation string which is used by the WUI and part of the language files.” And checked them with the result: old ones. Copied the new ones manually and the magic happened: WUI works fine.
3 Likes