Path: ...!weretis.net!feeder9.news.weretis.net!newsfeed.endofthelinebbs.com!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!nnrp.usenet.blueworldhosting.com!.POSTED!not-for-mail
From: "Edward Rawde" <invalid@invalid.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Win11 explorer bug?
Date: Thu, 12 Dec 2024 18:50:50 -0500
Organization: BWH Usenet Archive (https://usenet.blueworldhosting.com)
Lines: 92
Message-ID: <vjfssr$2k7k$1@nnrp.usenet.blueworldhosting.com>
References: <13vgljdqp79a2onuijph2om08fk99u2fdm@4ax.com> <vjablv$14se5$1@dont-email.me> <addhljp8i0d5t42lavnd37a8e883ijhsqt@4ax.com> <vjaeii$14se5$2@dont-email.me> <gquhljd83745shtckfjgtd5u6iphkprprc@4ax.com> <vjblle$1fd6a$1@dont-email.me> <gsnjljdvnhu7m25ops26ek9lvca5eqvk2n@4ax.com> <vjec62$22pn8$1@dont-email.me> <vjefoe$23fh4$1@dont-email.me> <uj2r2lxum3.ln2@Telcontar.valinor> <vjennd$24vi6$1@dont-email.me> <vjf008$2flf4$1@dont-email.me> <sbor2lxim3.ln2@Telcontar.valinor> <t2lmljp0l4krqj1gibee87jme141m0efmp@4ax.com> <vjfobk$2vgfa$1@dont-email.me>
Injection-Date: Thu, 12 Dec 2024 23:50:51 -0000 (UTC)
Injection-Info: nnrp.usenet.blueworldhosting.com;
	logging-data="86260"; mail-complaints-to="usenet@blueworldhosting.com"
Cancel-Lock: sha1:JSkFpG7mnUQYi4WRAtqK/EOPFQI= sha256:rkr31vvMjLEENtv693sob23uRwY9jLYkccaTFrgfQgY=
	sha1:UcYSh2WCu+lol3DtowXC4FSZ2iU= sha256:zUgMOSr3nQP914xKD3MxhVSxhr6XYlF+LMf0h7fkL1g=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MSMail-Priority: Normal
X-Priority: 3
Bytes: 5927

"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!
>
>