Ids.cgi Customize Ruleset freezes

Hello,
I just noticed that “Customize Ruleset” function from Intrusion Prevention System is freezing when I activate more than one Ruleset source.

Is this a known bug that is waiting for a fix?

Here are the sources I activated:

Talos VRT rules with subscription
Emergingthreats.net Community Rules
Abuse.ch SSLBL Blacklist Rules
Snort/VRT GPLv2 Community Rules
Etnetera Aggressive Blacklist Rules

No and I couldn’t reproduce it.

I took my CU187 vm machine running with no problems with Emerging threats and Abuse.ch already added.

I could open the customise window and change things.

I then added Etnetera, Snort Community and Talos VRT Registered and tested out the customise window at each addition step and I could access and change rules at each addition.

I can’t test Talos VRT Subscription as I don’t use that but the registered should be fairly similar.

If the problem is due to the VRT Subscription rules then the problem should occur with only that ruleset selected.

When the screen freezes it might be worth looking at whether there is any info in the /var/log/httpd/error_log file.

2 Likes

The behavior happens only on MS Edge Browser and Windows 10
I powered up my Linux Mate and Firefox from there does not freeze on that page.
Then I went back on Windows 10 and installed Firefox and the browser no longer freezes.

It seems that Edge has an issue with that code while Firefox works fine.
All good.

1 Like

When edge freezes on the IPS page can you show what is in the /var/log/httpd/error_log file related to the ids.cgi page.

It would be good to see if we can figure out what is causing a problem for Edge to see if it is possible to fix for Edge users.

1 Like

I did two tests, after adding the following providers, I clicked Customize ruleset

test1
IPFire 2.29 (x86_64) - Core-Update 189 Development Build: master/84b04cb6

obraz

Windows10 Pro 22H2 19045.4894
Microsoft Edge Version 129.0.2792.52

After clicking Customize ruleset, the page opens without errors.

test2
IPFire 2.29 (x86_64) - Core-Update 186 on Virtualbox

obraz

Windows 10 Pro 22H2 19045.4894
Microsoft Edge Version 129.0.2792.52

After clicking Customize ruleset, the page opens without errors.

Regards

1 Like

Hello,
No lines are appended to /var/log/httpd/error_log while MS Edge freezes on ids.cgi

Then the freezing is not due to a syntactical error in ids.cgi.

Are there any messages in the Windows or MS Edge logs to show what it had a problem with. Maybe MS Edge expects non-standard html commands or something.

I don’t have any Windows systems at all so cannot try and reproduce it to be able to fault find on it.

I do not know where Edge keeps its logs - I had a brief look inside Event Viewer for an entry for Edge but there is none…
All I can provide is this message - it appears after I scroll the (quite big) list of elements to be displayed (to be edited)

I know is not that much, but that is all I have now…

Late edit: while I have typed this post the page unfreeze - now the scroll works ok (I scrolled up to the top and down to the bottom again)

Weird…

Definitely weird.

black-x86-64.go.ro is no where in the IPFire code.

I also did a search for it and found nothing at all. Adding edge to the search just found lots of pages about installing edge and nothing even similar to black-x86-64.go.ro

Oh well, we have tried the best we can.

:crossed_fingers: that it stays working for you.

Maybe this is completely unrelated, but in Firefox the LastPass plugin will often slow the IDS ruleset page to a crawl. I get notifications from Firefox asking if I want to disable LastPass when this occurs. Another browser with Bitwarden does not have this issue. And yes, disabling LastPass does speed up that page in FF. I attributed it to a bug in LP and just work around it when it crops up.

Hello everyone, I have exactly the same problem but I haven’t noticed since which update because it’s not a page I consult often. I’m currently on core 190 and the problem seems to persist when I consult “cgi-bin/ids.cgi”.
I have no errors in the Apache logs.
Is there a solution for this bug ?
Thanks

I have no confirmatory evidence that it is a bug. I have not been able to reproduce it.

As there are no messages in the /var/ipfire/httpd/error_log then that indicates whatever is causing the problem is nothing to do with syntactical errors in any of the cgi pages.

Are you also using Edge when this problem happens or Firefox?

Maybe Edge has a log file somewhere that might give some clues as to what is happening when it is freezing.

If it is Firefox then maybe the Tools - Browser-Tools - Browser Console might show some messages to give clues.

Hi,
Thanks for your reply.
I’m not having any problems loading the page under Firefox.
I opened the development tool to analyze a bit and here’s the error I get under Brave or Chrome:

The Content Security Policy (CSP) prevents the evaluation of arbitrary strings as JavaScript to make it more difficult for an attacker to inject unathorized code on your site.

To solve this issue, avoid using eval(), new Function(), setTimeout([string], ...) and setInterval([string], ...) for evaluating strings.

If you absolutely must: you can enable string evaluation by adding unsafe-eval as an allowed source in a script-src directive.

⚠️ Allowing string evaluation comes at the risk of inline script injection.

1 directive
Source location	Directive	Status

Thanks

1 Like

Okay. We do use some javascript in various places.

  • We use setTimeout in Pakfire

  • We use setInterval in rrdimage for updating the graphs on a periodic basis so that you don’t have to refresh the browser page to get an updated graph.

  • As far as I can see we don’t use the javascript eval, although the bash and perl eval are used in some places.

  • The javascript function showhide is used in the ids page to enable you to look at the detailed rule entries within each rule. That is so that you can show or hide individual rule entries. Without javascript I think you would need to open every single rule at the same time which would make an enormously long page.

  • The javascript functions check_all and uncheck_all are used in the Location Block so you can check all or uncheck all countries rather than having to check all of them one by one.

  • The javascript function() command is used in the Guardian addon.

  • The javascript function() is used in the ids page for when you have to enter a subscription code for a provider.

  • The javascript function is used several times in the Dynamic DNS process to, for example, create an array of all DDNS providers that use tokens. It is also used to deal with showing or hiding the username/password or token sections when required.

There are several other places where javascript is used in IPFire that there is no point in continuing to search and describe. Whether all of the above would cause a similar issue as you have experienced, I have no idea.

It may make sense to raise a bug for this so that others more knowledgeable than myself can review the error message being provided and decide what the best approach to deal with it is.

Hi @bonnietwin,
thank you for taking the time to reply.
I’ve told @ms about the problem… I’m waiting for his reply :wink:
Have a nice day

Hello Michaël,

I am not sure what we can do about this since this seems to be a bug in the browser. The page itself is plain HTML with about four lines of Javascript which are pretty straight forward and only being used to open/close the individual sections.

A crash report from the browser would be helpful.

2 Likes

Re,

Indeed Michael…in no-fail mode, my Brave browser displays the page correctly without freezing. After several tests, I found the culprit…it’s my Bitwarden extension. I reparameterized the extension so that it only activates when clicked, and not permanently. I’m happy with this way of working and the page no longer freezes.

Many thanks to you 2 for your answers :blush:

Hi All,

I’ve noticed that when this issue occurs, it’s often related to browser extensions. In my case, it’s usually Dark Reader, especially when loading the ThreatFox ruleset.

Disabling browser extensions for IPFire’s WUI might be a good idea for both troubleshooting and security reasons, either way.

Thanks,
A G

3 Likes