Hi, I have been receiving some blacklist download error notifications since this afternoon. I’ve checked the firewall and it doesn’t seem to be blocking anything. Does anyone have the same problem?
config getprop blacklist Url
Do you have FireHOL Level 3 enabled?
No only FireHOL Level 2
And no vxvault list?
However, I continue to receive emails as mentioned above, can you give me an indication where I can indicate? I tried the wget and it works as a shell.
Mi sono accorto , che quando avviata la procedura da cockpit shorewall bloccava :
IP: 140.82.121.4
Country: United States
Region: California
City: San Francisco
AS number: AS36459
Organization: GitHub, Inc.
ISP: GitHub, Inc.
At the moment I have included the IP in the White List that appears in the cockpit. If errors occur again, I’ll update you.
Yes, that github IP is on the Vxvault iplist and so it is also part of the FireHOL Level 3 blocklist. Until it is fixed upstream.
Try again after disabling vxvault list and if the error hits again paste here the output of the command reported on the error message.
Thank you for your indications, but what are the differences fi firehole 2 and 3? Thank you.
Sorry don’t know the whole details other than what it’s explained on the firehol page:
GitHub - firehol/blocklist-ipsets: ipsets dynamically updated with firehol's update-ipsets.sh script or https://iplists.firehol.org/
Level 2 provide protection against current brute force attacks. This level may have a small percentage of false positives, mainly due to dynamic IPs being re-used by other users.
An ipset made from blocklists that track attacks, during about the last 48 hours. (includes: blocklist_de dshield_1d greensnow)
Level 3:
An ipset made from blocklists that track attacks, spyware, viruses. It includes IPs than have been reported or detected in the last 30 days. (includes: bruteforceblocker ciarmy dshield_30d dshield_top_1000 malc0de maxmind_proxy_fraud myip shunlist snort_ipfilter sslbl_aggressive talosintel_ipfilter vxvault)
1 Like
@dnutan I think we could exclude by a template a list of IP that we know good.
However it might be better that sysadmins know what they are doing before to click save 
We could have a file there to exclude know false positive IP
Obviously the better is to report upstream.
If he IPs don’t change often.
Or dynamically (ex. by pinging github then add to whitelist) for sites that modules depend on (unless the remote case of a malicious attack changing github’s DNS settings and redirecting the domain to a bad actor, cannot recall but sounds familiar related to another entity).
1 Like
It was already reported on a couple of issues, decided to give a reminder anyway:
2 Likes