FYI: IPFire is NOT vulnerable to CVE-2021-44228

Hi all,

a lot of infosec sites, CERT advisories, and similar channels are currently reporting about a simple to exploit, zero-day RCE (things don’t get much worse, do they?) in Apache Log4j, being tracked as CVE-2021-44228.

Before anybody asks: IPFire 2.x is not affected by this vulnerability, and neither is the project’s infrastructure.

I just thought it would make sense to post this here proactively, so infosec/security/anti-abuse people do not have to have nightmares/headaches (depending on your timezone and sleeping pattern) about their IPFire machines being compromised as well. :slight_smile:

To those interested, further information on this vulnerability is, for example, available here:

EDIT: Since a lot of questions regarding this vulnerability still arrive the developers, we just published this blog post to improve spreading the news. :slight_smile:

Thanks, and best regards,
Peter Müller

14 Likes

I read thru this and the recent blog post.

But there is no ET EXPLOIT Apache log4j within IPS.

Is there an easy way to cause Intrusion Prevention System to update?
-or-
It this a paid version versus a free version?

In Snort/VRT GPLv2 Community Rules you find several “SERVER-OTHER Apache Log4j logging remote code execution attempt”.

I had the free version. Try clicking the update button to get a fresh set of rules. I have no idea for how long they were in there.

1 Like

Hi,

please refer to these posts on the ET updates mailing list for further information:

By default, the IPS rulesets are updated daily, so these should be present on IPFire installations having the “Emerging Threats Community ruleset” enabled.

Thanks, and best regards,
Peter Müller

2 Likes

This can be configured to a weekly update.

1 Like

For me it is an old ruleset:

Ruleset (2021-12-01 21:39:24)

But I see no update button! So how do I update?

1 Like

I think if you press the save button in the Ruleset Settings box then it will update the ruleset that you have selected.

I just tried it on my system and now have

Ruleset (2021-12-14 01:25:02)

and it has the log4j rules and they are selected by default

2 Likes

No update for me! I tried the Save in the Ruleset Settings box (and just for fun in the Intrusion Prevention System box). It did not update.

This is using IPFire 2.27 (x86_64) - Core Update 161

I looked thru the messages log using

grep -ie "oinkmaster" -ie "suricata" /var/log/message

but did not find any update-ish type lines.

Is the “Emerging Threats Community ruleset” better than the “Snort/VRT GPLv2 Community Rules”?

OK: wiki.ipfire.org - Rulesets

Hi Jon,

Strange. I am also using Core Update 161.
Just to confirm you do have the frequency set to daily.

My only suggestion is to change the ruleset to the Snort/VRT Community rules and press save. You will get a completely different ruleset installed. Select the rules in the bottom section and Apply them and then save in the top IPS section and it should go to green and start. The ruleset time stamp should be very new.

Mine was

Ruleset (2021-12-14 21:23:15)

Be aware that when you do this your setting chosen in the Emerging Threats Community ruleset will be lost so take a note of which rules you had selected.

Then reselect the Emerging Threats Community ruleset and press save. Then select the required rules in the lower section and press Apply.
The timestamp for this ruleset on my system was then

Ruleset (2021-12-14 21:26:12)

:crossed_fingers: that this works for you. If not then I have no further idea what the problem could be.

This is what I did in the past. And it worked as expected and the ruleset was updated to something current.

But, I didn’t want to do this again and have to re-set all of the rules. Especially the sub-rules.

So this will help me for today, but what about next time?

I was trying to find the code for the ruleset update. I thought I would stumble across it in fcrontab, or an fcron.daily, fcron.weekly, and I could not locate it. (and maybe that is the problem?!?)

I did find this:

[root@ipfire ~] # /etc/rc.d/init.d/suricata
Usage: /etc/rc.d/init.d/suricata {start|stop|restart|reload|status}

does a reload also update the ruleset?

Adolf @bonnietwin - what messages appeared in your message log when the update happened?

forgot to answer this question.

I changed it from weekly to daily and there is no difference. Still the same date.

This was the issue though I don’t know why. The suricata link was missing from fcron.weekly.

When I changed the Automatic Rule Update from Weekly to Daily …

… the suricata link appeared in fcron.daily. Changing the Automatic Rule Update from Daily to Weekly causes it to appear back in fcron.weekly.

My ruleset seems to be updating now:

Ruleset (2021-12-14 18:35:44)

2 Likes

DailyUpdate

ManualUpdate

Hi, I had one system that would not update the rules. I found that by setting the AutomaticRuleUpdate to Disabled and pressing Save it brought up a manual UpdateRuleset button!
Pressed that button and Save and voila the rules were updated :slight_smile: Then set the AutomaticRuleUpdate back to Daily and Saved.

2 Likes

If you look at the link in fcron.xx you’ll find the real update command
/usr/local/bin/update-ids-ruleset
This does an immediate update.

2 Likes

Nice find! I never knew this existed!
:+1:

Yes! That is what lead me to the missing fcron.xx. I knew something had to run the update-ids-ruleset command (a link) but I just couldn’t find it!!

1 Like

Yes, this is more obscure than it should be.

1 Like