Hi folks.
After we updated a first IPFire to 168 this morning, we aren’t able to update the IDS/IPS.
It tells us: ** Error messages: Could not download latest updates.: no url**
Any idea?
Regards,
Jan
So the error code that includes no url means that no download url could be gathered for the provider.
Which provider(s) have you got specified and which one gave that error message when you tried to update it.
Maybe you could provide a screenshot of the main WUI IPS page.
After opening the IPS-menu, I’m able to see this for 1-2 sec.:
And then it lookes like that:
Nothing else on the screen.
With the Back and Apply buttons on the bottom right that means that when you opened the IPS page it went straight away to the customise ruleset page.
What happens if you press the Back button. In a normal working system that would take you back to the main page where you could see what providers were selected.
It starts again the short try of downloading and unpacking ruleset for 1-2 seconds.
And then it shows the same Error-Message.
I think that he is trying to figure out What providers you have and perhaps one of them is a known or unknown problem. Possible Bad Link.IDK. Or remove them all and update. Add back one at at time. AND update each time to fine if 1 provider Has a bad link.
I think @janr was saying that when he goes to that page then his IPFire immediately starts to try to download the rules and fails due to no url.
With the settings file at 0 bytes this says that the IPS is not enabled and all monitored interfaces are unchecked. I just confirmed on my vm testbed if I deselect all interfaces and disable IPS on the WUI page then the setting file is 0 bytes
With IPS not set then the system should not be trying to download any rulesets. I need to look further into the file system.
3 Likes
Thanks. This is, what I wanted to say.
Are you bale to give me an example of settings-file for red & green only monitored?
Because it seems, the settings-file is damaged.
The main settings file in /var/ipfire/suricata/settings looks like this
ENABLE_IDS_RED=on
ENABLE_IDS_GREEN=on
ENABLE_IDS=on
I have confirmed on my vm system that if you edit this by removing a line and refresh the page then the wui page is updated in line with the settings file.
However I am not sure that having this in the settings file will help. Even if the settings file is blank you should see the WUI page, just with all checkboxes unchecked and the IPS should be stopped. I thinks there are some other issues.
If you look in the menu item Status - Services does the Intrusion Prevention Line show as Stopped or Running?
EDIT:
What is the content of the /var/ipfire/suricata/providers-settings file?
What permissions and ownerships do you have in the /var/ipfire/suricata directory. This is what I have in my vm testbed system.
-rw-r–r-- 1 nobody nobody 291 Jun 14 13:19 emerging-used-rulesfiles
-rw-r–r-- 1 nobody nobody 66 Jul 1 10:41 etags
-rw-r–r-- 1 nobody nobody 61 Mar 14 17:58 oinkmaster-provider-includes.conf
-rw-r–r-- 1 nobody nobody 71 Jul 1 12:21 providers-settings
-rw-r–r-- 1 root root 5.4K Jun 27 22:09 ruleset-sources
-rw-r–r-- 1 nobody nobody 52 Jul 1 12:24 settings
-rw-r–r-- 1 nobody nobody 38 Jun 14 13:19 sslbl_blacklist-used-rulesfiles
-rw-r–r-- 1 nobody nobody 190 Jul 1 12:24 suricata-dns-servers.yaml
-rw-r–r-- 1 nobody nobody 159 Jul 1 12:24 suricata-homenet.yaml
-rw-r–r-- 1 nobody nobody 102 Jul 1 12:24 suricata-http-ports.yaml
-rw-r–r-- 1 nobody nobody 1.5K Jun 14 13:19 suricata-used-rulesfiles.yaml
Ok, thank you.
As you said: It wasn’t the reason.
Service is running:
Here is the content of provider-settings:
1,emerging,xxxxxxxxxxxxxxxxxxxxxxxx,enabled,enabled,IPS
Here is the permission-list (tried something; therefore the bak-folder).
What do you think about trying to take your suricata-files and copy them into my folder?
The problem with that is that many of those files are autogenerated so I am not sure about copying them. It might create more problems that it is worth.
I saw from your earlier message that the IPS is running even though the settings file was empty. That shouldn’t happen, although when I cleared the settings file on my vm testbed system then all the checkboxes were cleared but the IPS stayed running. This is because the save button was pressed which then recognises that the enable box is unchecked and will stop the IPS.
Try running the following command in the console
suricatactrl stop
This should stop suricata running and should come back with an OK message after some seconds. You can confirm by looking at the status - services menu.
With suricata stopped then see if you can access the IPS WUI page now.
1 Like
But can’t access the page because it seems the ids.cgi isn’t able to download the needed URL-content and doesn’t know, what to show in the GUI.
Let’s just confirm that the ids.cgi didn’t get corrupted during the update.
run
b2sum /srv/web/ipfire/cgi-bin/ids.cgi
I get
e55c1e52493d11bc60a9e439465fd907034c0569cde42bd62dc09be2fb55679dae3d6a81638de5d62c8828aa0e7381e09a2dfb43043ff2ce27cdad0768b837ae /srv/web/ipfire/cgi-bin/ids.cgi
1 Like
Seems to be OK:
e55c1e52493d11bc60a9e439465fd907034c0569cde42bd62dc09be2fb55679dae3d6a81638de5d62c8828aa0e7381e09a2dfb43043ff2ce27cdad0768b837ae /srv/web/ipfire/cgi-bin/ids.cgi
Yes, so no problem with ids.cgi itself.
One log file I forgot to check yet.
Try to access the IPS WUI page and when it comes up with the error message then look at the
/var/log/httpd/error_log
and go to the end of the log and see what messages are in there. It might give more clues on where in the ids.cgi the problem is occurring