IPS Ruleset not updating

Security Intrusion Prevention
#1

No matter what IPS ruleset I set it does not update according to the Automatic Rule Update (daily, weekly etc…).

When I change to a different ruleset it does update the ruleset initially but then it doesn’t after that.

My IPFire IPS page:

12.13.2020-18.01
12.13.2020-18.01778×810 28.2 KB

I recently upgraded to IPFire 153 thinking that Suricata 6.0.0 might fix this issue. But it hasn’t.

Earlier this year I followed suggestions in this blog article by @pmueller (https://blog.ipfire.org/post/firewall-configuration-recommendations-for-ipfire-users) and successfully implemented additional security hardening which has generally worked well without any issues.

These are my current firewall rules:

12.13.2020-18.05
12.13.2020-18.05773×745 47.1 KB

Could someone please tell me if I need an additional Outgoing Firwall rule for IPS ruleset update to work properly?

Otherwise happy for for someone to point me to logs, cronjobs etc… that will allow me to troubleshoot further.

I run DNS over TLS which is appears to be running OK:

12.13.2020-18.10
12.13.2020-18.10784×451 21.6 KB

FYI my IPFire FireInfo profile is: https://fireinfo.ipfire.org/profile/3dbcacf4302069328e9accd0c3731b83c9494c10

Any comments / feedback or help on the above issue would be much appreciated from IPFire forum members.

Robert

#2

Hi,

unfortunately, I cannot reproduce this issue for both Core Update 152 and upcoming Core Update 153, using the ET community ruleset and an upstream proxy.

Your screenshot shows a rather current (12th December) date string. Just curious: How did you realise your IPS ruleset is not up to date if the timestamp displayed (to some extend) is?

Earlier this year I followed suggestions in this blog article by @pmueller (https://blog.ipfire.org/post/firewall-configuration-recommendations-for-ipfire-users) and successfully implemented additional security hardening which has generally worked well without any issues.

Thanks. Glad this is helpful. :slight_smile:

Just to have it mentioned: Firewall rule #4 is redundant since blocked / drop is the default policy (“policy: blocked”) anyway.

It depends: According to the description of some of your firewall rules, your IPFire machine seems to be sitting behind a proxy (“allow […] access to proxy server”). The IPS update mechanism uses the upstream proxy settings of the IPFire GUI. Are those set correctly? If so, is the (upstream?) proxy permitting HTTPS queries to the update source of your IPS ruleset?

The update script is located at /etc/fcron.daily/suricata. According to its source code, the IPS GUI should display a warning in case updating the rulesets failed:

# [...]

# Call the download function and gather the new ruleset.
if(&IDS::downloadruleset()) {
        # Store error message for displaying in the WUI.
        &IDS::_store_error_message("$Lang::tr{'could not download latest updates'}");

        # Unlock the IDS page.
        &IDS::unlock_ids_page();

        # Exit.
        exit 0;
}

# [...]

Yes, it does, thank you for providing so much information in the first place - I wish this would become a habit for all of the community members. :slight_smile:

Thanks, and best regards,
Peter Müller

#3

Hi Peter,

Thanks for taking the time to respond.

Your screenshot shows a rather current (12th December) date string. Just curious: How did you realise your IPS ruleset is not up to date if the timestamp displayed (to some extend) is?

Well observed. Its showing a recent date because as part of my testing I was changing the Ruleset (eg: from ET to Talos) and it actually does an update of the Ruleset - this is why the date is showing a recent date.

Just to have it mentioned: Firewall rule #4 is redundant since blocked / drop is the default policy (“policy: blocked”) anyway.

FYI… makes sense - I have removed rule #4 as suggested.

According to the description of some of your firewall rules, your IPFire machine seems to be sitting behind a proxy (“allow […] access to proxy server”). The IPS update mechanism uses the upstream proxy settings of the IPFire GUI. Are those set correctly? If so, is the (upstream?) proxy permitting HTTPS queries to the update source of your IPS ruleset?

A while back I starting testing the Web Proxy features of IPFire and set it up for a single device only (an iPAD). Perhaps the way I set this up is somehow interfering with the updating of an IPS ruleset? I will therefore temporarily disable Web Proxy and remove assocated Firewall rules to test this theory and eliminate as possible cause of my issue.

Firewall rules amended:

2020-12-15_9-11-13
2020-12-15_9-11-13786×662 134 KB

Service stopped:

2020-12-15_8-50-10
2020-12-15_8-50-10703×214 49.1 KB

I will let this config run for a few days and report back either way.

thank you for providing so much information in the first place - I wish this would become a habit for all of the community members.

Agreed, I know this greatly assists in troubleshooting. Most “users” when having an issue - whatever the systems or software - expect problem solvers to be mind readers then get frustrated / impatient when asked to provide basic info related to the problem.

Thanks for your input and I will report back here with my findings.

Great effort by all who assist on this Forum!

Regards,

Robert

#4

Hi @pmueller,

Some progress…

After further cleanup I am now seeing “could not download latest updates” message at top of IPFire IPS panel.

I am also seeing this error in the logs:

2020-12-16_6-03-33
2020-12-16_6-03-33751×143 27.9 KB

Any thoughts?

Robert

#5

Hi Robert,

I see.

It looks like your firewall cannot even establish a TCP connection to ET’s update service, which seems to be hosted by two (?) IP addresses in the United States:

[root@maverick ~]# host rules.emergingthreats.net
rules.emergingthreats.net has address 52.6.11.187
rules.emergingthreats.net has address 3.209.33.84
[root@maverick ~]# location lookup 3.209.33.84
3.209.33.84:
  Network                 : 3.208.0.0/12
  Country                 : United States of America
  Autonomous System       : AS14618
[root@maverick ~]# location lookup 52.6.11.187
52.6.11.187:
  Network                 : 52.4.0.0/14
  Country                 : United States of America
  Autonomous System       : AS14618

Your outgoing firewall ruleset does not permit that connection. Since I misunderstood you at the web proxy thing, you just need to write a firewall rule permitting traffic to those two IP addresses - provided they are not changing - at TCP port 443 from your firewall’s red interface.

In my point of view, that should do it.

Thanks, and best regards,
Peter Müller

1 Like
#6

Thanks @pmueller,

Have done as suggested:

2020-12-16_6-47-57
2020-12-16_6-47-57769×613 144 KB

Will let you know how this goes.

Much appreciate your input.

Robert

1 Like
#7

Hi @pmueller,

All good now - rulesets updating:

2020-12-17_7-45-32
2020-12-17_7-45-32796×744 110 KB

Thanks mate!

Robert

2 Likes
#8

Hi,

glad to hear this works. :slight_smile:

Thanks, and best regards,
Peter Müller