(Solved)Turning off Metar data url callouts? Linux

[Grumpus]

Posted this in Linux Mint forum and searched Ubuntu forums for a way to close the call out.
It seems to be hidden somewhere on the systems though I've identified the url and subnet I have been unable to stop the call out,
Tried both IP tables and firewalls and still no joy.
It is relative to the mate weather and gnome weather packages but uses evolution weather back-end.
I've found a couple of files with seeming configuration settings and an xml file with auto update function which changed to no did nothing to affect the call out.
The IP is legitimate and is NOAA but I go directly to the NOAA site which uses a different IP and is more specific to location.
Any suggestions would be appreciated as I believe it may be in a file I might have to use Vim or some other editor to change it unless someone knows the actual location.
Removing the weather packages upsets Linux Mint due to dependencies.
Packages removed from Ubuntu do not have the same effect.

I realize it's been a while for the Mint users to have the weather function due to a loss of the metar data update connection but there should be a way of turning it off.

[Grumpus]

This is starting to look like some kind of tracking function covered within normal weather output.
It may be the geo-location is needed to function the weather updates but if the weather updates are turned off and the IP for the weather server is blocked in IP tables and also in a simple firewall that should be enough to stop the out flow/in flow to the ip but somehow this is buried in the system and no one is owning up to where they hid it in order for someone to stop it.

Haven't given up and next steps may be contacting NOAA, seems totally wrong the NOAA server for aviationweather.gov can't be blocked.
This is a real screw up on someone's part.

[Sector11]

[quote=Grumpus]I've found a couple of files[/quote]
Can you show the path/to/and/name/ of the files.
Maybe they are on other Linux systems as well unless they are Ubuntu specific (Linux Mint = Ubuntu + the Touch of Clem)?

And I'm hoping they're not here - BunsenLabs (Debian based)!

[Grumpus]

@Sector11 - It might actually be embedded in the programming of the weather packages and not something where a config file would allow a comment out line delete.
For some reason, blocking seems to be ineffectual and data transfer strictly backdoor which leads me to embedded in the programming of the package and not something as simple as an xml file. Checked defaults and other gconf locations, removing both weather apps kills the clock display.

[Sector11]

OK, I was just wondering if maybe it had anything to do with the "conky" weather scripts available. Ubuntu ppa's seem to have a bunch and thought maybe one is installed by default.

Clock display killed ... on the panel or on the desktop? Either way I'd do what you did - get rid of it! Hate things that do something without "my" permission on my machine.

And you tell me what weather apps? I'm just curious as weather is one of my things.

[Grumpus]

There was an update a month or so ago for both the gnome weather and mate weather in Linux Mint also in Ubuntu/Unity
The issue appears to be with only the Mate desktop and panel with Linux Mint, posting made in Mint forum.
The display clock disappears after removing both the gnome and mate weather in Linux Mint but the metar data kept transferring.
Since it was coming from Bethesda instead of Annapolis it caught my eye and looks suspicious.
Was able to remove the gnome weather app without messing up the clock for Ubuntu/Unity.

[Drumbrake]

It seems to be hidden somewhere on the systems though I've identified the url and subnet I have been unable to stop the call out,
Tried both IP tables and firewalls and still no joy.

A proper firewall rule should stop it dead : for instance, if you used ufw as an interface to iptables, placing this rule

Code: Select all

ufw deny from <subnet>

at number 1 and

Code: Select all

ufw deny out to <subnet>

at number 2, it would be the end of the story.

Really there should be no way around this, unless something like upnp or port forwarding/port knocking is at play.

[Grumpus]

Tried the subnet and the individual IP using proper syntax in and out and port specific, checked and re-checked too many times.
Also I noticed the frequency is questionable and it may be some US government tag.
Bethesda/College Park (depends on which seek you perform) is nearby and it wouldn't be inconceivable for me to go there and shove my foot up someone's self important posterior.
IP monitor shows it as 443 secure., both transfers are on 443 (in) is larger than out and larger is around 8Kb.
Syntax: Both subnet and individuals
ufw deny from 140.x.x.x to any port 443
ufw deny to 140.x.x.x from any port 443
Also for port 80

This IP range is different than the IP range which I use to open the NOAA site from a bookmark which might be part of the problem if Sprint is masking the 140 subnet with their backbone IP range in 198.x.x.x

[Grumpus]

Possibly found the problem, some sort of hidden counter or tracker from the US Department of Commerce.
Have blocked that IP subnet to see what happens.
Also rearranged some other blocks to see if anything is affected.

NO JOY. Tried the site I bookmark to see if it was affected. Page opened and appeared to be normal, blanked page, closed tab.
Unfortunately within a few moments the 140.90.x.x range showed back up, was initially blocked and then dumped the whole load again.
It's 1340 bytes out and approx. 8088 bytes in, IMO this is a weakness which someone might be able to exploit and needs to be stopped.
Also, if this can't be exploited it might be a redundancy on the part of the Sprint network 198.70.0.0/x performing some form of man in the middle between the original site and providing a canned version.

[Grumpus]

Further along with this there's nothing on the NOAA websites which show/explain how to remove/block airplaneweather.gov or .com connections.
Does seem to be reduced in frequency if I don't use the bookmarked link but the jury is still out.

[mightyglydd]

jury is still out.

Uh-huh...

[Drumbrake]

Tried the subnet and the individual IP using proper syntax in and out and port specific, checked and re-checked too many times.
(...)
Syntax: Both subnet and individuals
ufw deny from 140.x.x.x to any port 443
ufw deny to 140.x.x.x from any port 443
Also for port 80

Here's what I would do:

Code: Select all

ufw insert 1 deny from 140.x.x.x
ufw insert 2 deny out to 140.x.x.x
ufw reload

that would insert rules for "blanket blocking" (all ports, in and out) for such subnet at the top of the list, so that they get applied before all other rules - rules order is important, if any other rule that eventually allows some IPs from that subnet comes before your blocking rules, it will override them.

It should work, no matter if requests start from your computer towards those addresses : for instance, if I block Amazon servers, no matter how hard I try, Firefox won't update any more.

BTW, you have ufw set with default policy of "deny (incoming), allow (outgoing)" , which will only allow incoming connections in response to requests made by your computer, right?

[Grumpus]

@Drumbrake - I'll make some changes and see what happens but believe I've covered the order issue.
Tried the blanket approach and restructuring the load orders. Looks a lot like the Ubuntu Linux embedded AWS stuff where nothing works.
Simple or complicated doesn't appear to make a great deal of difference which is what concerns me.

@mightyglydd - You realize there's a No Clown ordinance as it scares the children.

[Drumbrake]

OK, but did tools such as ss and netstat at least tell you what applications are actually making such connections?

As I've said, in a normal Linux OS with a working firewall, incoming connections are only accepted in response to a request starting from the OS itself (it's not Windows where the computer is bombarded by connections coming from everywhere -or out of nowhere for that matter- the minute the system is switched on) so you should be able to at least trace back the application/program that made the request(s) and proceed from there.

[Grumpus]

Knowing the application is not the issue. It's somewhere inside the code for either evolution data or inside the gnome or Mate weather packages.
Let me remark this problem did not exist until the recent update in both Mint and Ubuntu weather packages a couple of months ago.
I've done excessive administrative level searches and cannot find the specific line of code, xml, cfg or other file which triggers the call.
I'm also not completely sure the information which shows being transferred completes, packet notice without effect, and repetitious due to blockage on this end.
I tried removing Gnome weather and Mate weather in Mint as stated but this also removed an evolution backend package and disabled the panel clock.
Dependency with Evolution data server is why it appears to be relevant.
Re-install of packages appeared to resolve the clock but had no affect on the control of the out bound signal.
The check mark to open or close the weather seems useless in Mint.
Removing the weather package in Ubuntu did not affect the clock and there is no signal when running the Ubuntu system without the weather application.
However there was also no indication of out bound signals for the Ubuntu OS only the Mint.
Both systems updated there weather apps the same week.

I'm still trying to block the signal
IP is identified as airplaneweather/NOAA HOWEVER . . .
a trace shows these in the line:
12 ae7.edge2.Washington4.level3.net 4.68.110.49 147.309
14 GOV0084.ear2.Washington1.Level3.net 4.79.198.10 191.307
Leaving the tinfoil by the roadside it could be a counter or some form of identifier for use of the weather system. Best guess.

Full trace of the IP.
1 66.1.116.192 66.1.116.192 533.547
1 66.1.116.192 66.1.116.192 198.223
2 68.28.113.91 68.28.113.91 156.037
3 68.28.113.17 68.28.113.17 154.198
4 10.148.16.18 10.148.16.18 126.769
5 10.158.207.77 10.158.207.77 127.867
6 10.158.207.73 10.158.207.73 116.344
7 68.28.117.69 68.28.117.69 127.444
8 144.228.183.237 144.228.183.237 124.651
9 144.232.14.5 144.232.14.5 113.464
10 144.232.7.183 144.232.7.183 130.484
11 144.232.14.8 144.232.14.8 141.481
12 ae7.edge2.Washington4.level3.net 4.68.110.49 147.309
14 GOV0084.ear2.Washington1.Level3.net 4.79.198.10 191.307
15 140.90.111.36 140.90.111.36 171.324