[Info-vax] Some SEARCH commands

[Mark Berryman]

On 3/1/19 1: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 ?

I don't need a shared secret to make the use of proxies MORE secure than 
not using them.

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

I see you do not understand networking very well.  Both DECnet and IP 
operate at layer 3 and above.  Both require other protocols below layer 
3 to communicate.  Both DECnet and IP use CSMA/CD to talk over Ethernet. 
  DECnet usually uses DDCMP to talk over serial lines.  IP has a number 
of choices, HDLC being a common one.  Using IP to provide the layer-2 
path for DECnet does not in any way require IP to know anything at all 
about DECnet.  You are simply using a different transport mechanism than 
the one built into DECnet.  One that is easily encrypted.  It is still a 
DECnet network.  DECnet still establishes its neighbors and DECnet 
commands are still used for network maintenance.

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

Yep, hardware.  The same as is needed to protect an IP network in 
today's world.  With the same need to properly configure said hardware. 
This is why, among other reasons, devices without the necessary 
correctly configured hardware protecting them are being broken into all 
of the time.

(Of course, badly written software can overcome the protection of the 
best of hardware, but that is an entirely different discussion and does 
not apply here).

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

Nope.  IP knows nothing about certificates.  Applications built on IP 
can use certificates but not IP itself.  I can just as easily write an 
application using DECnet, or other network protocols, that uses 
certificates.  (Of course, all of the weaknesses in certificates are 
fodder for a different discussion).

Spoofing a particular node, and spoofing a particular identity (which is 
where certificates come in) are different things.  There are ways to 
identify each other down at the node level.  Solution 1 above uses one 
such mechanism.

Mark Berryman