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?
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.
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.
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.
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.
What I’ve done till now:
First I created with the actual IP addresses two new hosts, and then I united these in a new host group called „Emerging threats“.
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.
Following pmueller’s advice I created an outgoing firewall rule that allowed an HTTPS connection from red interface to above mentioned host group:
Today I had to realise that IP addresses unfortunately will be changed daily. As of today they are looking like:
AS14618 will be hosted by Amazon web services. Following link is showing up, there is a huge range of IP addresses belonging to this Autonomous System. https://stat.ripe.net/data/announced-prefixes/data.json?preferred_version=1.1&resource=AS14618
(FYI: to see all IPs you have to expand data and prefixes first, and click „alle ausklappen“ in the second headline).
I do not know how to meet this challenge. It has no sense changing the host addresses every day. Does anybody have an idea?
