Re: Win11 explorer bug?

"Don Y" <blockedofcourse@foo.invalid> wrote in message news:vjfobk$2vgfa$1@dont-email.me...

On 12/12/2024 2:31 PM, Joe Gwinn wrote:

The device has a limited life expectancy, anyway. About 10 years. The
boiler needs replacement of rubber gasket every year or two. There is a
mandatory yearly maintenance visit. With the remote controller,
maintenance visits are every two years, because the remote server
monitors the parameters and decides when a visit is needed.
>
So, that convenience is decisive for me. Win win.

>
A dodge occurs to me:  Install a simple firewall between external
Internet and internal network that hosts such things as cameras and
furnaces.  Set the firewall to accept only one of a small set of white
listed sources, and otherwise not to reply.

>
First, not all ISPs will allow inbound connections.  E.g., many
hide their subscribers behind NAT so incoming connections can't
find specific hosts.

They tried to put me on lsn/cgnat. I was given a static IPv4 when I complained.
Previously the IP had been sufficiently static but not totally static.

>
Second, there is nothing that prevents a device THAT YOU HAVE
WILLINGLY INSTALLED from having malware in it that compromises
your internal network.  This, because most folks only implement
perimeter security mechanisms.  So, a device is free to "call out"
and open a connection that allows an external actor to get past
any such peripheral defenses.

It's true that this is a situation you want to avoid but a properly designed internal network will not allow the malware free access
to services it doesn't have access credentials for. And devices such as cameras can be on their own internal network separately
packet filtered as necesary.

>
And, because any of your protections likely deal with the
internal vs. external networks as separate, homogenous entities,
there is no way for you to easily determine where (physically)
traffic is originating or terminating.  A device can pretend (from
the standpoint of packet inspection) to be any device on "your"
network.

That still doesn't mean it has access credentials for anything it shouldn't have.

>
[There are commercial devices available with exactly this capability,
used for pen-testing.]
>

White lists have the advantage of immunity to attempts from random
places.  The lack of response if not white listed will defeat most
port IP address and scanners, even though the firewall most likely can
be hacked if known.

>
Many appliances advertise their presence -- through established
protocols.  So, in addition to knowing it is there, they know WHAT
the device is and what rev level software, etc.
>
Building a collection of scripts that target specific vulnerabilities
in specific devices is then a practical attack plan.
>

Upgrade the firewall from time to time, to sorta keep up with the
threats.

>
The only practical way to protect a device (or network) is to impose
constraints on both ends.
>
E.g., my "knock protocol" burdens folks who try to access my server.
But, it keeps the server secure -- and well hidden.
>
In my distributed system project, I use separate tunnels from each
device to the switch.  So, the credentials for the device connected to
port #5 are of no value to you if you try to access the network
via port #8.
>
Furthermore, I know WHAT is at the end of each of those wires and
dynamically control the interactions allowed over those connections.
>
E.g., an "exposed/accessible" security camera should never have a need
to issue a command to open the garage door.  And, any attempt to do so
(assuming the encryption has been compromised by reverse-engineering
THE camera that was previously attached to that wire), will cause
the system to mark that network port ("wire") as tainted.  So, even if
you tried to feed bogus video (because I *think* you are a camera)
to the system, it would ignore that input.
>
Red/Blue team exercises are incredibly educational!  Until you actually
try to break security, you don't realize just how silly most mechanisms
actually are!
>