Sentinel dynfw blocking google servers

Hi,

recently, I have been having problems with many websites using *.googleapis.com . Turns out, the root cause is Sentinel dynfw blocking google servers:

For instance: fonts.googleapis.com now resolves to 142.251.36.74 for me (I am using nic.cz DNS servers), which is currently in the blocklist. What gives?

EDIT: PING star-mini.c10r.facebook.com (157.240.30.35)

157.240.30.35 also in the dynfw blocklist… I guess it’s my mistake to completely block everything in the blacklist (implementing a transparent firewall), is it? If my device initiates a connection to a blacklisted IP, I should allow the response?

You done the research right, the address is indeed in greylist.csv, as well as in dynfw blacklist. I can’t imagine scenario where google or facebook are doing port scan using address listed as explicitly theirs. Only explanation seems that the CDN was breached and the’re not aware of the situation.
I suggest you report both 142.251.36.74 and 157.240.30.35 to their respective owners with notice that service with those ips perform malicious activity. I can provide You all necessary information on behalf of our team from database if you needed, question is whether we use this public channel, or you rather use email communication. The details being 1. what activity is the server performing, 2. time schedule of those activities, we won’t share user details (any device identification) in that regard.
We’d report it ourselves, but you were to find it first, so the merit is yours.

1 Like

Honestly, I don’t know where to report that. Here? Google - Security Bug Report
/ Redirecting...
Couldn’t they be sharing addresses with some customer VMs or something (sounds like a terrible idea, though)?

I’d suggest Google Safe Browsing: Report a Malware Page for google server. We’re figuring out how to approach the incident from security POV.

Maybe this?

Occasionally, we receive reports about Google products that issue network requests to third-party services, with an attacker-controlled destination IP address/port number. The attack scenario usually mentions a Google product acting as a proxy to perform an IP/port scanning attack.

1 Like

So it is feature I guess…

So to reply to your initial question, you may allow the CDN at your own risk. The dynfw blocks incoming traffic anyway. And we do not advise anyone to use greylist for full blown blocking.

Edit: We will figure out how to handle on our end. I have raised internal project ticket in that regard.

1 Like

I have handled it by implementing a simplistic connection tracking in nftables, so connections initiated from my network to the blacklisted IPs will work. Isn’t that how it works in your ipset/iptables implementation anyway (or maybe just with flow offload enabled)?

Also, is dynfw client nftables sets (in addition to ipsets) support something you would be interested in in a pull request?