[Info-vax] Some SEARCH commands

[Dave Froble]

On 3/1/2019 3:25 AM, Simon Clubley wrote:
> On 2019-02-28, Mark Berryman <mark at theberrymans.com> 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.
>>
>
> So where exactly is the shared secret support in DECnet Phase IV ?
>
>>> 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).
>>
>
> Oh, I see. You need to use the security features in another network
> stack (TCP/IP) to protect your DECnet Phase IV nodes because DECnet
> Phase IV doesn't even have any such basic protections (by today's
> standards).
>
> It also means all your TCP/IP stacks need to support the routing of
> DECnet Phase IV over TCP/IP and it also means you are no longer running
> a DECnet Phase IV network, but a TCP/IP network with DECnet being
> merely an application level protocol.
>
>> 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.
>>
>
> So you need to use your hardware to protect your DECnet Phase IV nodes
> (and need to have that hardware installed) because DECnet Phase IV nodes
> do not have the needed features to protect themselves in today's world.
>
>> 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.
>>
>
> Sorry Mark, but that is wrong as when they are setup correctly you can
> make it vastly harder to spoof an IP node than it is to spoof a DECnet
> Phase IV node.

Not if Mark's suggestions are followed.  If you're responding to them, 
then don't attempt to ignore them.

> That is because you can protect IP based nodes from spoofing by using
> certificates which is simply not possible with DECnet Phase IV.
> The certificate acts as a shared secret between IP nodes.
>
> Simon.
>

Ayep!

All those SSL2, SSL3, TLS1.0, and TLS1.1 were so secure, until they weren't.

I'd assume that any hardware security will be a bit harder to penetrate 
than any software security.

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