On March the 10th I upgraded ipfire from 163 to 164.
Everything worked fine. IPS was active with the rule sets from the 7th.
A week later the automatic update started and this is the feedback from ipfire
The ipfire has access to the internet:
RED (192.168.178.22) > Standard networks RED with Service Group (80, 443)
The IPS ruleset is " Emerging Threats Community Ruleset".
Proxy is active on BLUE and GREEN.
Normal behavior if I use the browser an start a session in the internet.
Presently the IPS is working but the rule sets are not updating.
What is to do?
I’ve had exactly the same problem. What I did was:
- turn off URL Filter
- turn off Web-Proxy
- restart IPFire
- after restart immediately remove ruleset from IPS and turn off IPS completely
- activate Web-Proxy
- activate URL filter
- wait for next Core Update
Not sure if URL-filter and Web-Proxy could have been left activated.
This issue has been reported:
And has been reported in bugzilla:
And one workarround is:
At the moment to get things work again properly you only can perform a reboot of the system to get rid of this lock or you manually have to remove the “/tmp/ids_page_locked” file by hand.
Thank you Alain Stucki for the procedure.
Problem solved concerning the automatic update.
Thank you roberto for the hint with the bug report already performed.
The reboot was the clue.
I don’t think restarting is the solution, since tomorrow you will have the same problem again (it happens to me).
We’ll have to wait for them to fix it.
After the reboot you can turn IPS off and deactivate auto update of the rulesets. Hopefully this way the message doesn’t reappear the next day.
What I found with the problem the of the IPS constantly freshing update was to disable the
“Drop packets from and to hostile networks (listed at Spamhaus DROP, etc.)” , found in the Firewall options page, which is enabled.
I reported bug 12791 regarding no defaults showing up for 3 new options. The bug has since been set as resolved, but makes this option enabled when it should be infact set to off because, from what I understand, the background stuff to make it work isn’t ready.
When I turned this option off, and rebooted, the IPS stuff page now refreshed correctly.
Edit: It worked fine for a while, but later tried a forced update and the IPS update icon kept rolling, and rolling, and rollin. So guess this wasn’t really a fix.
I did it already and it worked.
I have applied the c165 patches and things seem to be working but getting these errors reported on nightly update:
Mar 17 01:25:00 ipfire oinkmaster: <ERROR> Downloading ruleset for provider: subscripted.
Mar 17 01:25:12 ipfire oinkmaster: <ERROR> Downloading ruleset for provider: emerging.
Could anyone say whether this is a real error indicating the download really failed or is this a spurious error that should/could be ignored?
The timestamp on gzip files at /var/tmp tend to indicate they were written at time of nightly update. Do they get regenerated even if the download fails?
[root@ipfire tmp]# ls -l /var/tmp/
-rw------- 1 nobody nobody 3199897 Mar 17 01:25 idsrules-emerging.tar.gz
-rw------- 1 nobody nobody 94338775 Mar 17 01:25 idsrules-subscripted.tar.gz
Okay, I’m guessing the
<ERROR> is in fact, benign – as it seems most things written to syslog from
ids-functions.pl are classified as error.
Opened bug: 12805 to address the erroneous ERROR indication for this informational syslog entry
There is no need to reboot… you can instead
- get a console prompt via ssh
- delete the lock file under /tmp
- run /etc/init.d/suricata restart
This is how every morning I manage to recover the IPS screen
Unfortunately I have an other issue atm with IPS refreshing overnight causing rulesets to disappear in addition to the tmp lock file not clearing
If it’s of any value, after upgrading to core 164
when I looked in /TMP, there was NO
I have the never ending “Ruleset update in progress. Please wait …”
I rebooted twice but no change.
Only when I turned off “Drop packets from and to hostile networks”
The IPS page still says "…Please wait…
but now I see events in the IPS logs
when I look in TMP
I see “/tmp/ids_page_locked” file
I deleted it and now I have no more “Please wait” in IPS