[Core 164] IPS Ruleset update in progress with no end. upgrade from 163 to 164

[ip-mfg]

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?

[alain (Alain Stucki)]

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.

[roberto (Roberto Peña)]

Hi.

This issue has been reported:

Possible problem with Suricata. Test core 164

Hello. In the mornings, around 08:00, I try to access the page “Intrussion Prevention” and this always appears. It won’t let me access: [imagen] The only way I know how to access it is by restarting the IPFire. My machine profile is: fireinfo.ipfire.org - Profile 509c7b9c50f8d6a5df7049b70e051019ab787fc9 Is it happening to someone else? Bye.

And has been reported in bugzilla:

https://bugzilla.ipfire.org/show_bug.cgi?id=12785

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.

Regards.

[ip-mfg]

@alain

I’ve had exactly the same problem. What I did was:

Thank you Alain Stucki for the procedure.
Problem solved concerning the automatic update.

[ip-mfg]

@roberto

This issue has been reported:

Thank you roberto for the hint with the bug report already performed.
The reboot was the clue.

[roberto (Roberto Peña)]

Hello @ip-mfg.

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.

Greetings.

[alain (Alain Stucki)]

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.

[rejjysail (Rejjy_S)]

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.

[ip-mfg]

I did it already and it worked.

[cbrown (Charles Brown)]

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[24378]: <ERROR> Downloading ruleset for provider: subscripted.
Mar 17 01:25:12 ipfire oinkmaster[24378]: <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?

Edit:
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/
total 95256
-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
.

[cbrown (Charles Brown)]

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.

[cbrown (Charles Brown)]

Opened bug: 12805 to address the erroneous ERROR indication for this informational syslog entry

[velifire]

@roberto

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.

There is no need to reboot… you can instead

1. get a console prompt via ssh
2. delete the lock file under /tmp
3. 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

logged here
https://bugzilla.ipfire.org/show_bug.cgi?id=12804

[trish]

If it’s of any value, after upgrading to core 164

when I looked in /TMP, there was NO
“/tmp/ids_page_locked” file

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”
and rebooted.

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