On 2022-08-03, chris <chris-nospam@tridac.net> wrote:
> On 08/03/22 10:26, Johnny Billquist wrote:
>> On 2022-08-03 01:08, Richard Maher wrote:
>>> On 2/08/2022 9:04 pm, Simon Clubley wrote:
>>>
>>>> You aren't even allowed (quite rightly) to run unencrypted protocols
>>>> such as telnet on many networks any more.
>>>>
>>>> The time of DECnet Phase IV has well and truly passed.
>>>>
>>>
>>> Can you not run it over TCP/IP and IPSec?
>>
>> Yes you can.
>>

So, in order to provide DECnet with any security in today's world,
you have to run it on top of a rival networking protocol (and one
born in the Unix world at that :-)).

Doesn't anyone see the irony in that ?

Or to put it another way, if you have to run it on top of TCP/IP,
you may as well just use the rest of TCP/IP instead of DECnet. :-)

>
> So not a problem in security terms then.

Most certainly is still a security issue. You are still running the
higher-level DECnet protocols and drivers on top of the TCP/IP stack.

BTW people, has anyone checked to see what privileges EVL (the DECnet
Phase IV logger) is running with on your systems ?

Not what it is installed with, but what it is running with ?

(Use $ show proc/priv/id={PID})

The same logger that has a DECnet port open to the outside world ?

Would be interesting to see if that has been fixed on Itanium or x86-64.

May also want to check what it's installed with as well, as that should
be the only privileges it should require.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 08/03/22 13:29, Simon Clubley wrote:
> On 2022-08-03, chris<chris-nospam@tridac.net> wrote:
>> On 08/03/22 10:26, Johnny Billquist wrote:
>>> On 2022-08-03 01:08, Richard Maher wrote:
>>>> On 2/08/2022 9:04 pm, Simon Clubley wrote:
>>>>
>>>>> You aren't even allowed (quite rightly) to run unencrypted protocols
>>>>> such as telnet on many networks any more.
>>>>>
>>>>> The time of DECnet Phase IV has well and truly passed.
>>>>>
>>>>
>>>> Can you not run it over TCP/IP and IPSec?
>>>
>>> Yes you can.
>>>
>
> So, in order to provide DECnet with any security in today's world,
> you have to run it on top of a rival networking protocol (and one
> born in the Unix world at that :-)).
>
> Doesn't anyone see the irony in that ?
>

Agree, but one of the main problems with vms in the past was the
complete lack of industry standard networking, other than from third
party vendors.

>
> Or to put it another way, if you have to run it on top of TCP/IP,
> you may as well just use the rest of TCP/IP instead of DECnet. :-)
>
>>
>> So not a problem in security terms then.
>
> Most certainly is still a security issue. You are still running the
> higher-level DECnet protocols and drivers on top of the TCP/IP stack.

One assumes that it would be encapsulated within tcp/ip, which becomes
the transport and can be encrypted at that level. Even standard decnet
would have no security problems in an isolated network, if sensibly managed.

There are probably many people that still need decnet and while I
can understand why Linux would drop it, there are probably many other
ways to make it work with other solutions. Tru64, for a start...

Chris

>
> BTW people, has anyone checked to see what privileges EVL (the DECnet
> Phase IV logger) is running with on your systems ?
>
> Not what it is installed with, but what it is running with ?
>
> (Use $ show proc/priv/id={PID})
>
> The same logger that has a DECnet port open to the outside world ?
>
> Would be interesting to see if that has been fixed on Itanium or x86-64.
>
> May also want to check what it's installed with as well, as that should
> be the only privileges it should require.
>
> Simon.
>

Simon Clubley formulated the question :
>
> Or to put it another way, if you have to run it on top of TCP/IP,
> you may as well just use the rest of TCP/IP instead of DECnet. :-)
>
May be because TCP/IP does not offer anything like FAL and task to
task communication, used all over the place in thousands of DCL
command files ?

--
Marc Van Dyck

On 2022-08-03, chris <chris-nospam@tridac.net> wrote:
> On 08/03/22 13:29, Simon Clubley wrote:
>>
>> Most certainly is still a security issue. You are still running the
>> higher-level DECnet protocols and drivers on top of the TCP/IP stack.
>
> One assumes that it would be encapsulated within tcp/ip, which becomes
> the transport and can be encrypted at that level. Even standard decnet
> would have no security problems in an isolated network, if sensibly managed.
>

As I understand it, the normal DECnet Phase IV components and drivers
for the upper DECnet Phase IV layers are still running on top of the
TCP/IP transport layer, so if there's a vulnerability in those components,
it could still be exploited.

For example, I have a way of crashing EVL on Alpha and VAX from across
the network by sending EVL a malformed event message. (This work was
done late last year when the VAX hobbyist licence still existed.)

I never found a way of getting shellcode to run within EVL, but it's
always possible someone could find a more lethal version of the problem
I discovered.

Could a malformed event message delivered over TCP/IP still crash EVL ?
I don't know, but if the TCP/IP integration works the way I think it
does, that's a distinct possibility.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 08/03/22 18:44, Simon Clubley wrote:
> On 2022-08-03, chris<chris-nospam@tridac.net> wrote:
>> On 08/03/22 13:29, Simon Clubley wrote:
>>>
>>> Most certainly is still a security issue. You are still running the
>>> higher-level DECnet protocols and drivers on top of the TCP/IP stack.
>>
>> One assumes that it would be encapsulated within tcp/ip, which becomes
>> the transport and can be encrypted at that level. Even standard decnet
>> would have no security problems in an isolated network, if sensibly managed.
>>
>
> As I understand it, the normal DECnet Phase IV components and drivers
> for the upper DECnet Phase IV layers are still running on top of the
> TCP/IP transport layer, so if there's a vulnerability in those components,
> it could still be exploited.
>
> For example, I have a way of crashing EVL on Alpha and VAX from across
> the network by sending EVL a malformed event message. (This work was
> done late last year when the VAX hobbyist licence still existed.)
>
> I never found a way of getting shellcode to run within EVL, but it's
> always possible someone could find a more lethal version of the problem
> I discovered.
>
> Could a malformed event message delivered over TCP/IP still crash EVL ?
> I don't know, but if the TCP/IP integration works the way I think it
> does, that's a distinct possibility.
>
> Simon.
>

Need to define what you mean by the transport layer ?. Unlikely that
decnet would be using udp, as that is connectionless and best effort,
and unlikely they would be using raw ip either, another layer down, so
reasonable to assume it would be encapsulated in tcp/ip. Not enough
info and depends where in the stack the decnet data is fed. Perhaps
someone else has more detail, but tcp/ip would make the most sense
from a reliability pov.

Thing is, if there is a need, people will find a way. Just need to
think outside the box sometimes...

Chris

As a side note to all this DECNET talk has it not occurred to anyone
that the dreaded unencrypted password hack was negated by the end of
ethernet as a broadcast medium? :-)

bill

On Wednesday, August 3, 2022 at 2:31:04 PM UTC-4, chris wrote:
> Need to define what you mean by the transport layer ?. Unlikely that
> decnet would be using udp, as that is connectionless and best effort,
> and unlikely they would be using raw ip either, another layer down, so
> reasonable to assume it would be encapsulated in tcp/ip.

DECnet link layer is already point to point and assumes unreliable
communication so using UDP as just just another transport option
is perfectly viable. It already knows how to maintain sessions, so
there is no need for TCP.

On 2022-08-03 19:38:22 +0000, Bill Gunshannon said:

> As a side note to all this DECNET talk has it not occurred to anyone
> that the dreaded unencrypted password hack was negated by the end of
> ethernet as a broadcast medium? :-)

Is the exploit in a switching network as easy as a promiscuous-mode
connection to a broadcast network? No.

But having a Miscreant In The Middle of a connection is still a thing...

Switch port mirroring, and DNS and ARP shenanigans, and Wi-Fi
eavesdropping, and compromising the local DECnet router, among other
means.

Switch compromises are a thing, and switches from various vendors have
had issues.

As for eavesdropping for access, the KRACK WPA2 802.11r flaw from
several years ago is an interesting exploit.

https://www.bleepingcomputer.com/news/security/list-of-firmware-and-driver-updates-for-krack-wpa2-vulnerability/

Oh, and given how DECnet network routing works, set up a
lower-addressed DECnet router and capture all of the DECnet traffic you
want.

If a DECnet router is announcing itself from a network printer, and
with very attractive path routing costs, you might have a problem.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-08-03 14:29, Simon Clubley wrote:
> On 2022-08-03, chris <chris-nospam@tridac.net> wrote:
>> On 08/03/22 10:26, Johnny Billquist wrote:
>>> On 2022-08-03 01:08, Richard Maher wrote:
>>>> On 2/08/2022 9:04 pm, Simon Clubley wrote:
>>>>
>>>>> You aren't even allowed (quite rightly) to run unencrypted protocols
>>>>> such as telnet on many networks any more.
>>>>>
>>>>> The time of DECnet Phase IV has well and truly passed.
>>>>>
>>>>
>>>> Can you not run it over TCP/IP and IPSec?
>>>
>>> Yes you can.
>>>
>
> So, in order to provide DECnet with any security in today's world,
> you have to run it on top of a rival networking protocol (and one
> born in the Unix world at that :-)).
>
> Doesn't anyone see the irony in that ?

No. No more than I see three wires used to transport the bits being any
different than a coax. Or X.25. What's the problem with using other
protocols or technologies as transports???

> Or to put it another way, if you have to run it on top of TCP/IP,
> you may as well just use the rest of TCP/IP instead of DECnet. :-)

Uh? Might not work so well if you have some systems that don't even talk
TCP/IP, and yet other cases where you have some specific application
that is using DECnet. Just because your system can talk TCP/IP don't
automatically mean all applications or hosts suddenly do.

>> So not a problem in security terms then.
>
> Most certainly is still a security issue. You are still running the
> higher-level DECnet protocols and drivers on top of the TCP/IP stack.

I take it you didn't get/see the IPsec keyword, right?

> BTW people, has anyone checked to see what privileges EVL (the DECnet
> Phase IV logger) is running with on your systems ?
>
> Not what it is installed with, but what it is running with ?
>
> (Use $ show proc/priv/id={PID})

Not an issue on my RSX system.

> The same logger that has a DECnet port open to the outside world ?

Which is DECnet. Don't have anything to do with TCP/IP, and means anyone
on the internet is not able to access it.

I think you are missing a whole bunch of understanding here.

Johnny

On 2022-08-03 19:44, Simon Clubley wrote:
> On 2022-08-03, chris <chris-nospam@tridac.net> wrote:
>> On 08/03/22 13:29, Simon Clubley wrote:
>>>
>>> Most certainly is still a security issue. You are still running the
>>> higher-level DECnet protocols and drivers on top of the TCP/IP stack.
>>
>> One assumes that it would be encapsulated within tcp/ip, which becomes
>> the transport and can be encrypted at that level. Even standard decnet
>> would have no security problems in an isolated network, if sensibly managed.
>>
>
> As I understand it, the normal DECnet Phase IV components and drivers
> for the upper DECnet Phase IV layers are still running on top of the
> TCP/IP transport layer, so if there's a vulnerability in those components,
> it could still be exploited.

Of course. But IPsec is supposed to provide you with security. But there
can be bugs anywhere.

> For example, I have a way of crashing EVL on Alpha and VAX from across
> the network by sending EVL a malformed event message. (This work was
> done late last year when the VAX hobbyist licence still existed.)

But since you can't talk to EVL unless you are on DECnet - not TCP/IP -
this is not really an issue. And DECnet over IP with IPsec means you'll
only have authorized point to point connections, so any third party
won't really be able to join the party.

> Could a malformed event message delivered over TCP/IP still crash EVL ?
> I don't know, but if the TCP/IP integration works the way I think it
> does, that's a distinct possibility.

I don't know what you are thinking, but it sounds like you don't
understand what IPsec is, or how it adds security to IP. But heck, even
without that, you'll not be able to inject any DECnet packets to a host
using DECnet over IP, since it's all point to point links, and you are
not one of the points. You can send packets all day long over TCP/IP if
you want to. Nothing will happen.

Johnny

On 2022-08-03 20:30, chris wrote:
> On 08/03/22 18:44, Simon Clubley wrote:
>> Could a malformed event message delivered over TCP/IP still crash EVL ?
>> I don't know, but if the TCP/IP integration works the way I think it
>> does, that's a distinct possibility.
>>
>> Simon.
>>
>
> Need to define what you mean by the transport layer ?. Unlikely that
> decnet would be using udp, as that is connectionless and best effort,
> and unlikely they would be using raw ip either, another layer down, so
> reasonable to assume it would be encapsulated in tcp/ip. Not enough
> info and depends where in the stack the decnet data is fed. Perhaps
> someone else has more detail, but tcp/ip would make the most sense
> from a reliability pov.
>
> Thing is, if there is a  need, people will find a way. Just need to
> think outside the box  sometimes...

Taking Multinet's DECnet-over-IP as the reference here. Yes, it can use
both UDP and TCP as the transport layer. But you need to configure on
both machines what the other end is (both IP and port). Packets from
other places are (obviously) not accepted.

It works just fine, and HECnet has been using this for many years now,
among other transports.

Johnny

On 2022-08-03 21:38, Bill Gunshannon wrote:
>
> As a side note to all this DECNET talk has it not occurred to anyone
> that the dreaded unencrypted password hack was negated by the end of
> ethernet as a broadcast medium?  :-)

Nope. Since that is irrelevant. The packets travel through multiple
hosts/routers usually, and the data can be picked up anywhere along the
way. Ethernet was never the crucial item in there.

Johnny

On 2022-08-03 21:46, David Jones wrote:
> On Wednesday, August 3, 2022 at 2:31:04 PM UTC-4, chris wrote:
>> Need to define what you mean by the transport layer ?. Unlikely that
>> decnet would be using udp, as that is connectionless and best effort,
>> and unlikely they would be using raw ip either, another layer down, so
>> reasonable to assume it would be encapsulated in tcp/ip.
>
> DECnet link layer is already point to point and assumes unreliable
> communication so using UDP as just just another transport option
> is perfectly viable. It already knows how to maintain sessions, so
> there is no need for TCP.

Actually, that's partially not true. And is a part of a big of a mess
elsewhere. DECnet point to point link assumes DDCMP like functionality.
And DDCMP assumes reliable communication. DECnet have two different
modes in which it operates. One over unreliable media, which is
basically ethernet, which is broadcast and all that. And the other is
point-to-point media, which is always assumed to be reliable.

Enter Multinet, who did a DECnet-over-IP implementation, using the point
to point type of link, and actually use UDP or TCP. And if you are using
UDP, and packets get lost, reordered, or duplicated, DECnet gets very
unhappy, and the link goes down, and then it has to come back up again.

TCP on the other hands fits very well with the DECnet view of
point-to-point links. So for anyone playing with this, remember that,
and use TCP. You'll be happier for that in the end. If you are very
local, with a reliable network, and so on, you can go for UDP if you
want, but consider yourself warned.

Johnny

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> So, in order to provide DECnet with any security in today's world,
> you have to run it on top of a rival networking protocol (and one
> born in the Unix world at that :-)).

Really?

The primary development of TCP/IP was done on PDP-10 systems running MIT's ITS
operating system, Stanford's WAITS oeprating system, BBN's TENEX operating
system, or DEC's TOPS-20 operating system (a TENEX derivative). Quite a lot
was done on other mainframe operating systems from other manufacturers.

TCP/IP was already the official protocol suite for the ARPANET/Internet before
the Berkeley software folks began implementing it on their version of Unix.

I wonder how much else you pontificate on about which you know so little...

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On 2022-08-04 01:42, Rich Alderson wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> So, in order to provide DECnet with any security in today's world,
>> you have to run it on top of a rival networking protocol (and one
>> born in the Unix world at that :-)).
>
> Really?
>
> The primary development of TCP/IP was done on PDP-10 systems running MIT's ITS
> operating system, Stanford's WAITS oeprating system, BBN's TENEX operating
> system, or DEC's TOPS-20 operating system (a TENEX derivative). Quite a lot
> was done on other mainframe operating systems from other manufacturers.
>
> TCP/IP was already the official protocol suite for the ARPANET/Internet before
> the Berkeley software folks began implementing it on their version of Unix.
>
> I wonder how much else you pontificate on about which you know so little...

Good point. I didn't even catch that bit this time. It do annoy me a lot
that people think that TCP/IP came from Unix. When TCP/IP was sailing
up, Unix was all about UUCP (yuck).

Johnny

On 2022-08-03, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> As a side note to all this DECNET talk has it not occurred to anyone
> that the dreaded unencrypted password hack was negated by the end of
> ethernet as a broadcast medium? :-)
>

Given the insecure nature of DECnet on the wire, that has _never_
even been considered by me as something worth probing. :-)

Any DECnet probing by me has been trying to find flaws in the target
server's software components after malformed messages and such like
were delivered to the target server.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-08-03, Johnny Billquist <bqt@softjar.se> wrote:
> On 2022-08-03 14:29, Simon Clubley wrote:
>> On 2022-08-03, chris <chris-nospam@tridac.net> wrote:
>>> On 08/03/22 10:26, Johnny Billquist wrote:
>>>> On 2022-08-03 01:08, Richard Maher wrote:
>>>>> On 2/08/2022 9:04 pm, Simon Clubley wrote:
>>>>>
>>>>>> You aren't even allowed (quite rightly) to run unencrypted protocols
>>>>>> such as telnet on many networks any more.
>>>>>>
>>>>>> The time of DECnet Phase IV has well and truly passed.
>>>>>>
>>>>>
>>>>> Can you not run it over TCP/IP and IPSec?
>>>>
>>>> Yes you can.
>>>>
>>
>> So, in order to provide DECnet with any security in today's world,
>> you have to run it on top of a rival networking protocol (and one
>> born in the Unix world at that :-)).
>>
>> Doesn't anyone see the irony in that ?
>
> No. No more than I see three wires used to transport the bits being any
> different than a coax. Or X.25. What's the problem with using other
> protocols or technologies as transports???
>

Because of all the "VMS! Number 1!!!" stuff that's posted around here. :-)

>>
>> Most certainly is still a security issue. You are still running the
>> higher-level DECnet protocols and drivers on top of the TCP/IP stack.
>
> I take it you didn't get/see the IPsec keyword, right?
>

Yes I did. All IPsec does is to stop packets from being intercepted
while in transit. It does nothing to stop malformed packets from being
transmitted by an authorised node in an IPsec network to another server
on the same IPsec network.

>> BTW people, has anyone checked to see what privileges EVL (the DECnet
>> Phase IV logger) is running with on your systems ?
>>
>> Not what it is installed with, but what it is running with ?
>>
>> (Use $ show proc/priv/id={PID})
>
> Not an issue on my RSX system.
>

:-)

It's interesting that no-one from VMS-land has commented on this.

Normally, when you all think I've posted something that's incorrect,
you all jump on me with _great_ enthusiasm. :-)

The fact no-one has posted any response to this, suggests this command
has been run by the usual suspects and that you are seeing the same
thing I am, and that privately, you don't like what you are seeing
although you are probably not going to admit that in public. :-)

However, I hope that, if you have duplicated that I am seeing, it might
be making you wonder privately if there's anything else that might be
like this and it might prompt you to have a closer look.

>> The same logger that has a DECnet port open to the outside world ?
>
> Which is DECnet. Don't have anything to do with TCP/IP, and means anyone
> on the internet is not able to access it.
>
> I think you are missing a whole bunch of understanding here.
>

Actually, I understand just fine, but I'm probably looking at it
in a different way to how you are.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-08-03, Rich Alderson <news@alderson.users.panix.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> So, in order to provide DECnet with any security in today's world,
>> you have to run it on top of a rival networking protocol (and one
>> born in the Unix world at that :-)).
>
> Really?
>
> The primary development of TCP/IP was done on PDP-10 systems running MIT's ITS
> operating system, Stanford's WAITS oeprating system, BBN's TENEX operating
> system, or DEC's TOPS-20 operating system (a TENEX derivative). Quite a lot
> was done on other mainframe operating systems from other manufacturers.
>

Actually, I was thinking of IPsec as the "rival networking protocol"
when I wrote that, which most certainly was born in the Unix world.

> TCP/IP was already the official protocol suite for the ARPANET/Internet before
> the Berkeley software folks began implementing it on their version of Unix.
>

That is very true, but it's also true that any TCP/IP based protocols
born within the last 30+ years have generally been created and developed
within a Unix world.

> I wonder how much else you pontificate on about which you know so little...
>

I'm not worried about accidentally saying something wrong because you will
_all_ take great pleasure in pointing that out :-), at which point I will
apologise if you are correct. (As I have done several times in the past).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 8/4/22 04:58, Johnny Billquist wrote:
>
>
> Good point. I didn't even catch that bit this time. It do annoy me a lot
> that people think that TCP/IP came from Unix. When TCP/IP was sailing
> up, Unix was all about UUCP (yuck).

Don;t knock UUCP. If it weren't for UUCP you wouldn't have USENET
today and probably not even email. :-)

And it happily continues to operate much like HECNET.

bill

On 8/3/22 2:32 PM, Stephen Hoffman wrote:
> On 2022-08-03 19:38:22 +0000, Bill Gunshannon said:
>
>> As a side note to all this DECNET talk has it not occurred to anyone
>> that the dreaded unencrypted password hack was negated by the end of
>> ethernet as a broadcast medium?  :-)
>
> Is the exploit in a switching network as easy as a promiscuous-mode
> connection to a broadcast network? No.
>
> But having a Miscreant In The Middle of a connection is still a thing...
>
> Switch port mirroring, and DNS and ARP shenanigans, and Wi-Fi
> eavesdropping, and compromising the local DECnet router, among other means.
>
> Switch compromises are a thing, and switches from various vendors have
> had issues.

Properly stated in the past tense. For example, in the switches in use
here, there are no currently known or unfixed switch exploits for seeing
traffic you should not and there have not been for some time.

>
> As for eavesdropping for access, the KRACK WPA2 802.11r flaw from
> several years ago is an interesting exploit.
>
> https://www.bleepingcomputer.com/news/security/list-of-firmware-and-driver-updates-for-krack-wpa2-vulnerability/

If 802.11r was enabled. 802.11r is designed to allow ease of roaming
between one wireless AP and another. If such roaming is not expected or
intended, 802.11r would not usually be enabled. There are many places
where this is the case.

>
>
> Oh, and given how DECnet network routing works, set up a lower-addressed
> DECnet router and capture all of the DECnet traffic you want.
>
> If a DECnet router is announcing itself from a network printer, and with
> very attractive path routing costs, you might have a problem.

If your DECnet traffic runs in its own VLAN, such exploits would become
somewhat more difficult since any port a miscreant could plug into
wouldn't have access to that VLAN.

Mark Berryman

On 2022-08-04 15:27, Bill Gunshannon wrote:
> On 8/4/22 04:58, Johnny Billquist wrote:
>>
>>
>> Good point. I didn't even catch that bit this time. It do annoy me a
>> lot that people think that TCP/IP came from Unix. When TCP/IP was
>> sailing up, Unix was all about UUCP (yuck).
>
> Don;t knock UUCP.  If it weren't for UUCP you wouldn't have USENET
> today and probably not even email.  :-)
>
> And it happily continues to operate much like HECNET.

I would not agree at all with the connection between email and UUCP.
Email existed, and worked much better on other systems than UUCP ever
offered, and earlier than UUCP as well.

You could possibly make the claim for usenet news, although I would
suspect something else would have been there otherwise.

Yes. I do knock on UUCP. It was the best that existed on those systems.
That don't mean it was any good.

I don't mind if other people are having fun setting up such systems, but
it's definitely not something I would do.

HECnet exists because I had a need. And the need was not that I wanted
to recreate something for amusement.
How others use it is or look at it don't change anything for me.

Johnny

On 2022-08-04 14:04:44 +0000, Mark Berryman said:

> On 8/3/22 2:32 PM, Stephen Hoffman wrote:
>> Switch compromises are a thing, and switches from various vendors have
>> had issues.
>
> Properly stated in the past tense. For example, in the switches in use
> here, there are no currently known or unfixed switch exploits for
> seeing traffic you should not and there have not been for some time.

Other sites, not so much...

https://www.theregister.com/2022/08/05/cisco_smb_routers_critical_flaws/

They're far from the only network appliances that have been
(successfully) targeted, too.

> If your DECnet traffic runs in its own VLAN, such exploits would become
> somewhat more difficult since any port a miscreant could plug into
> wouldn't have access to that VLAN.

Yep. Same for iLO. For telnet and FTP traffic, too. Network isolation
is the US DoD / US NCSC Rainbow books era solution. Some folks manage
to maintain that isolation and that network trust (whether VLAN or
firewalls, or in a hosted data center) over time too, which is arguably
much harder than is the initial network setup. BeyondCorp has been
mentioned in this context, though DECnet and iLO and related would not
play well in that environment.

--
Pure Personal Opinion | HoffmanLabs LLC

Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
>Yep. Same for iLO. For telnet and FTP traffic, too. Network isolation
>is the US DoD / US NCSC Rainbow books era solution. Some folks manage
>to maintain that isolation and that network trust (whether VLAN or
>firewalls, or in a hosted data center) over time too, which is arguably
>much harder than is the initial network setup. BeyondCorp has been
>mentioned in this context, though DECnet and iLO and related would not
>play well in that environment.

UNTIL you get to B3 and higher levels in which case the system can be
expected to keep data isolated well enough to keep data of separate
classifications.

And of course the more complex a system gets the harder it is to validate...
so this does not happen often. There is the SCOMP but little else out there.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 8/6/22 1:38 PM, Stephen Hoffman wrote:
> On 2022-08-04 14:04:44 +0000, Mark Berryman said:
>
>> On 8/3/22 2:32 PM, Stephen Hoffman wrote:
>>> Switch compromises are a thing, and switches from various vendors
>>> have had issues.
>>
>> Properly stated in the past tense.  For example, in the switches in
>> use here, there are no currently known or unfixed switch exploits for
>> seeing traffic you should not and there have not been for some time.
>
> Other sites, not so much...
>
> https://www.theregister.com/2022/08/05/cisco_smb_routers_critical_flaws/
>
> They're far from the only network appliances that have been
> (successfully) targeted, too.

Point taken. I was in reference to enterprise-grade switches and these
are consumer-grade (almost everything labeled SMB these days is still
consumer-grade). Cisco's RV series routers actually have a very poor
track record when it comes to flaws. In this case, at least, you have
to already be on the network in order to exploit the flaws (which
probably means that a lot of small businesses using them won't bother to
patch).

As has been noted here, one of the main reasons security breaches are as
big a problem as they are is that those responsible to approving
expenditures on security refuse to do so. Good security costs money.
SMB routers are pretty cheap and you get what you pay for. If you are
really concerned about security, whether big corporation or small
business, it is not a good idea to go the SMB equipment route.

Sadly, when I was working helping small businesses with their networks,
too many of them were not interested in security, or even performance.
They just wanted cheap (and some had enough awareness of the situation
to claim "I'm too small to be target").

>
>> If your DECnet traffic runs in its own VLAN, such exploits would
>> become somewhat more difficult since any port a miscreant could plug
>> into wouldn't have access to that VLAN.
>
> Yep. Same for iLO. For telnet and FTP traffic, too. Network isolation is
> the US DoD / US NCSC Rainbow books era solution. Some folks manage to
> maintain that isolation and that network trust (whether VLAN or
> firewalls, or in a hosted data center) over time too, which is arguably
> much harder than is the initial network setup.  BeyondCorp has been
> mentioned in this context, though DECnet and iLO and related would not
> play well in that environment.

It is not difficult to maintain network isolation if your network team
uses good change management processes. Again sadly, as you are no doubt
aware, many places don't. But it was never a problem at any of the
places that I've worked.

Mark Berryman

On 2022-08-06 22:00:45 +0000, Mark Berryman said:

> On 8/6/22 1:38 PM, Stephen Hoffman wrote:
>> On 2022-08-04 14:04:44 +0000, Mark Berryman said:
>>
>>> On 8/3/22 2:32 PM, Stephen Hoffman wrote:
>>>> Switch compromises are a thing, and switches from various vendors have
>>>> had issues.
>>>
>>> Properly stated in the past tense.  For example, in the switches in use
>>> here, there are no currently known or unfixed switch exploits for
>>> seeing traffic you should not and there have not been for some time.
>>
>> Other sites, not so much...
>>
>> https://www.theregister.com/2022/08/05/cisco_smb_routers_critical_flaws/
>>
>> They're far from the only network appliances that have been
>> (successfully) targeted, too.
>
> Point taken. I was in reference to enterprise-grade switches and these
> are consumer-grade (almost everything labeled SMB these days is still
> consumer-grade). Cisco's RV series routers actually have a very poor
> track record when it comes to flaws. In this case, at least, you have
> to already be on the network in order to exploit the flaws (which
> probably means that a lot of small businesses using them won't bother
> to patch).

The earlier comment was about non-broadcast Ethernet networks being
more immune to promiscuous-mode monitoring and similar attacks which is
true to a degree but runs afoul of other means of traffic interception,
hence my pointer to compromising the RV or ASA or firewall or switch or
whatever. Setting up a DECnet host with a low-numbered DECnet address
as a router running on a handy and down-revision printer is another
means to intercept a whole lot of DECnet traffic.

> As has been noted here, one of the main reasons security breaches are
> as big a problem as they are is that those responsible to approving
> expenditures on security refuse to do so. Good security costs money.
> SMB routers are pretty cheap and you get what you pay for. If you are
> really concerned about security, whether big corporation or small
> business, it is not a good idea to go the SMB equipment route.

I'd not assume enterprise gear is all that much better, though it might
have better support. If you can keep the gear patched to current, and
get to ~secure settings Various OpenVMS system and app defaults aren't
all that great, for instance.

> Sadly, when I was working helping small businesses with their networks,
> too many of them were not interested in security, or even performance.

Which is why apps and platforms and network connections best use secure
defaults.

For those sites that are able to operate in more expert and more
vigilant modes, sure, you can easily get away with this isolation. I'd
still want an IP and MAC sniffer watching for and alerting on
unexpected traffic; for any newly-connected devices. And
legitimately-connected devices (e.g. printers) can be compromised. This
as I don't trust configurations to be maintained over time.

> They just wanted cheap (and some had enough awareness of the situation
> to claim "I'm too small to be target").

I've had that conversation with OpenVMS sites.

>>> If your DECnet traffic runs in its own VLAN, such exploits would become
>>> somewhat more difficult since any port a miscreant could plug into
>>> wouldn't have access to that VLAN.
>>
>> Yep. Same for iLO. For telnet and FTP traffic, too. Network isolation
>> is the US DoD / US NCSC Rainbow books era solution. Some folks manage
>> to maintain that isolation and that network trust (whether VLAN or
>> firewalls, or in a hosted data center) over time too, which is arguably
>> much harder than is the initial network setup.  BeyondCorp has been
>> mentioned in this context, though DECnet and iLO and related would not
>> play well in that environment.
>
> It is not difficult to maintain network isolation if your network team
> uses good change management processes. Again sadly, as you are no
> doubt aware, many places don't. But it was never a problem at any of
> the places that I've worked.

Yep. There are a whole lot of places that don't have a network
inventory for instance, and that haven't tested backup recoveries or
failovers or restarts in recent memory, and things can get problematic
from there.

--
Pure Personal Opinion | HoffmanLabs LLC