Why do I never find Google in the protocol?

I am very keen to keep the US tech-companies off my PC.
I edited the URL-filter as below.
Almost all connections are G-made, but I just sometimes find M$.ie in the protocol(s).

I understand that “ESTABLISHED” is the trick not to reject the attacker instantaneously, but to pretend the attack was a success.
But please let me know:

  1. Why was the period significantly extended (compared to former versions)?
  2. Where does the “haul”, the “pickings” go to? +
  3. Is there a way to get hold of that information?

Thank you very much in advance
Tobias

www.google.de and correspondingly for the other

@olduser , welcome to the IPFire community!

Your post doesn’t show your settings. Therefore, it is a bit ‘tricky’ to answer your questions. :wink:

1 Like

Thank you. At first, I copied and pasted the attached list, but new users are not allowed to have > 2 links.


So, this is my complete blacklist - hitherto.

For HTTPS connections this list may be useless.

The client resolves the name ( ww.google.com, f.e. ) and communicates with IP given by resolution. Therefore proxy never sees those URLs.

Ways to manage this are IP Block Lists ( a collection of known ‘bad’ IPs ) or blocking lists for DNS ( called RPZ ).

Understood. “RPZ” stands for?

My other questions are not yet replied to:

I understand that “ESTABLISHED” is the trick not to reject the attacker instantaneously, but to pretend the attack was a success.
But please let me know:

Why was the period significantly extended (compared to former versions)?
Where does the “haul”, the “pickings” go to? +
Is there a way to get hold of that information?

My understanding is this should work.
But you must use non transparent proxy.
And block HTTPS access to the out side world.
Block ports 80 and 443.

When I block port 443 in the fiber glass modem, Pakfire will not update.
And the time server does not work.
Where do you suggest to block

  • HTTPS access
  • post 443 and port 80?

In the IPFire WUI
My guess is your client PC is Buy passing the Proxy.
Very common problem

Thank you. It seems to work.
At first, I deleted everything, but there is a “Hydra”-effect…
So, I just killed 443.
And I unticked “transparent on green”.

1 Like

Sorry for being so nasty, but why is the German service immediately appearing in my protocol, whereas my “major enemy” G seems to be “invulnerable”?

Proxy blocking works even with HTTPS, but only if the client wants to access an URL ( in clear text ). In this case the name resolution is done in the proxy. But if the client does the resolution at his own, HTTPS requests ( the packets seen by the proxy ) are directed to IPs.

Not sure what “protocol”
This all gets weird when one organization host so much of the internet.
Google,AWS, Cloud Flare, Azure.

Well, this very protocol.
Don’t understand what you mean by this "This all gets weird when one organization host so much of the internet.
Google,AWS, Cloud Flare, Azure.

I am simply interested to block G as much as possible!

Do you want to block all sites hosted on Google? That would be a bit dramatic.

My FF is only displaying URLs if I tell him t do so - even HTTPS-URLs.
Each time, a hint appears, and then I decide to visit or not.

The IP that has triggered the DROP_HOSTILE chain is nothing to do with Google.
That IP is part of a set owned by EdgeCenter LLC from the Russian Federation.
It has been listed in the Spamhaus DROP list due to being involved in spam or hacking or criminal activities.

The IP that has ended up with the DROP_CTINVALID chain is from an Ukrainian Hosting service. DROP_CTINVALID is where conntrack has flagged packets up as not belonging to any established connection and has therefore marked the packets as invalid.
Again nothing to do with Google.

If you want to block anything to do with Google then the IP ranges they use are


    64.233.160.0 – 64.233.191.255 
    66.102.0.0 – 66.102.15.255
    66.249.64.0 – 66.249.95.255
    72.14.192.0 – 72.14.255.255
    74.125.0.0 – 74.125.255.255
    209.85.128.0 – 209.85.255.255
    216.239.32.0 – 216.239.63.255
    64.18.0.0 - 64.18.15.255
    108.177.8.0 - 108.177.15.255
    172.217.0.0 - 172.217.31.255
    173.194.0.0 - 173.194.255.255
    207.126.144.0 - 207.126.159.255
    216.58.192.0 - 216.58.223.255

However this will also block all websites that are hosted on a Google hosting service. So websites that are nothing to do with Google directly but are hosted on a Google cloud hosting service.

So I think you need to be clearer on what about Google it is that you are trying to block.

That is incorrect.

An ESTABLISHED connection status means one that is actively connected and working. It has not been blocked and will not be blocked.

I have no idea what period you are referring to here. The period of what?

Anything that is blocked due to Firewall Rules is shown in the Firewall Logs. If the blocks are due to user created Firewall Rules then these will also be shown in the Firewall Logs as long as the logging for the involved rules was enabled. If not enabled then no information is shown in the logs.

If the block is due to an action from the URL Filter then this would be in the WUI (Web User Interface) menu item Logs - System Logs and then select URLFILTER Blacklist as the Section: in the drop down box. This presumes that you have logging enabled in the Web Proxy WUI page.

You can access any dropped packet information by looking in the appropriate logs. Just make sure that you have the logging enabled.

2 Likes

Thanks. Leave RUS/UKR outside - I just wanted to show that my log has no sign of Google.


Kyberio does not appear, either, in the firewall protocol…
“ESTABLISHED” now for more > 4 days - earlier that period was much shorter. But what does that term actually mean? Is it “captured” or put in custody?
Yes, G. is also a hoster - pityful enough. My issue is that sites like welt.de are “fetching” external applications to grasp data with their help.
Even when I look into the source code, I can only find a few of them.
My understanding is that I = my firewall has no chance to block “Mother’s little helpers” because they have coded them, so, their “ranking” is so as if I would have “invited” them. However, I just wanted to surf on a URL - and had no intention to become a victim of their spy activities.
Thank you for the gorgeous list of URL-ranges.
No, I am not in the position to block “all” of them - even it I wanted to.
G is an evil, and I want to keep all of their “services” as far as possible from my PCs, laptops and hard disks. I use neither “smart” phones nor tablets because they are not compatible with my “sausage” fingers and I would feel lost and entirely w/o any shield, shelter and protection.
“these will also be shown in the Firewall Logs as long as the logging for the involved rules was enabled. If not enabled then no information is shown in the logs.”
Yes, I strive at making use of all blocking possibilities IPF is offering, and I did see very few IPs “ending up” in the protocol. By why does G not appear there, despite of the fact that it has been “ESTABLISHED”?

What about domains like googlesyndication.com, googletagservices.com, googleapis.com and so on?

You can search the forum for Blocking Cloud Flare.
That’s a interesting rabbit hole.

Yes, indeed!