[Info-vax] Some SEARCH commands

[Dave Froble]

On 2/28/2019 7:30 PM, Mark Berryman wrote:
> On 2/27/19 4:39 PM, Simon Clubley wrote:
>> On 2019-02-27, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>>>
>>> Search your various OpenVMS storage devices...
>>>
>>> $ SEARCH /NOWARN ddcu:[*...]*.* "::"""
>>>
>>> if files have currently or previously been stored in a DVCS or to some
>>> other archive, also search that.
>>>
>>> If you've found any matches to the SEARCH commands, might then want to
>>> ponder how easy it was to find what you just found.
>>>
>>> Might also want to ponder the last time what you found was changed.  If
>>> it's ever been changed.  And ponder who knows about it.
>>>
>>> And as a chaser to all that pondering, ponder that what you just found
>>> can (also) be broadcast across your network.
>>>
>>
>> And while you are all pondering this, also ponder that if you try
>> fixing the problem by using proxies instead of hardcoded passwords
>> then you are very likely to make your system _LESS_ secure and not
>> more secure.
>
> Eh?  Not in any configuration I have ever used.
>
>> This is because there is no such thing as a shared secret in DECnet
>> Phase IV proxies which means it is easy for an attacker to pretend
>> to be a trusted DECnet Phase IV node.
>
> Not if you are set up correctly.  A simple, security-conscious setup
> will prevent this.
>
>> DECnet Phase IV is a perfect example of a network protocol that
>> might have been reasonably secure if you could guarantee _total_
>> control of everything attached to a network but which is also
>> totally insecure in today's world.
>
> Not so.  Total control of everything on the network is most definitely
> not necessary.  I will illustrate with a couple of simple scenarios.
>
> Solution 1.
> How may nodes are left in your DECnet network?  Is it relatively small?
> Do all of your DECnet nodes also speak IP?
> Then shut off DECnet on your Ethernet interfaces and connect all of your
> DECnet nodes using point-to-point IP tunnels encrypted by IPSEC.  This
> solution not only makes it extremely difficult to spoof one of your
> DECnet nodes but now all traffic is encrypted before it ever leaves your
> host.  DECnet's in-the-clear nature is no longer an issue.  (Extremely
> difficult as in - a lot of other things would have to be compromised
> before your DECnet address could be).
>
> Solution 2.
> Can't use the above solution (why not)?
> Your DECnet routers should be configured to allow only the node numbers
> that belong on the LAN to enter the router.  This will prevent anyone
> trying to spoof a non-local DECnet address from ever leaving the LAN.
> All DECnet nodes have a unique MAC address.  Lock that MAC address down
> to the switch port to which the actual DECnet node is connected.  This
> will prevent any other node on the LAN from using a DECnet address that
> belongs some other host on the LAN.  If you have multiple LAN segments
> in the same DECnet area, lock those down as well so no host in the wrong
> LAN segment can use them.  These actions, which are trivial to
> implement, will prevent any host from spoofing a trusted DECnet host.
>
> It is actually easier to prevent the spoofing of a given DECnet address
> that it is to prevent the spoofing of IP addresses.  This is because all
> DECnet IV addresses are tied to a specific MAC address, which is not the
> case for IP.  Even though DECnet has not been updated in a few decades,
> one can make DECnet communications even more secure than, say, SMB2
> communications; which is a LOT more prevalent and used for similar
> functions.
>
> Mark Berryman

Take that, all you DECnet haters ....

Actually Mark, a very nice and helpful post.

But it won't shut Simon up ....

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486