[Info-vax] DECnet challenge

[Mark Berryman]

On 3/1/19 4:47 PM, Stephen Hoffman wrote:

[ a good summary on the difficulties of maintaining complex systems]

However, I'm sure how much that applies here since, these days, most 
routers and switches are centrally managed.  I would agree that trying 
to maintain rulesets individually on more than a small handful of 
devices will likely work fine until the person who implemented it was no 
longer available.  Then errors would creep in.

On the other hand, setting up such rules in a management station which 
then pushes them to all required devices could easily be maintained 
across both staff and talent churn.

> ps: As for your question, I'd likely start with side channels on the 
> servers and extracting keys, and with attempting to mess with the IP 
> network (ARP, iBGP, WAP, DHCP) via an infested printer or infested 
> client.  

You aren't likely to get very far in compromising a DECnet network using 
IP hosts or protocols.  Off of the top of my head, it seems the most 
likely thing you could accomplish would be to interrupt the traffic. 
However, if you did that, you'd be interrupting lots of traffic and that 
would almost certainly get you noticed.

> I'd also consider tossing DECnet routing messages from rogue 
> DECnet hosts (IV is tougher here than V, if the switches are paying 
> attention), or from existing DECnet or IP hosts that have "mysteriously" 
> become routers for DECnet traffic.  

The configuration would prevent a non-authorized host from trying to 
become a DECnet router.  However, if you had admin access to one of the 
existing DECnet hosts, you could certainly try playing games with its 
routing setup.  However, then OPCOM on my host would alert me to those 
changes and then we would have words.

> And I'd be more interested in 
> watching the DECnet and SCS traffic than necessarily spoofing a DECnet 
> proxy through obtaining a privileged network position via routing or 
> mirroring or finding bugs, as the cleartext or poorly-hashed creds 
> visible via DECnet and SCS and telnet and FTP are going to be useful for 
> furthering access.  

Ah, but there is the challenge.  HOW would you watch that traffic?

> Am I certain to get into the DECnet network?  No.  
> Can a good team block these paths?  Sure.  But I'm still not inclined to 
> prefer to run unencrypted and unauthenticated and cleartext network 
> traffic.

Here, I think most would agree with you.  If I were at a place that 
wanted to continue to run DECnet in today's world, I would recommend the 
following (in order of preference):

1. Convert to phase V, turn off the DECnet protocol and use strictly 
DECnet-over-IP, and encrypt the IP traffic.  While the NCL syntax 
certainly suffers from "design by committee" it is really not that 
difficult to learn.  Most of what one needs to do is automated for you 
anyway.

2. If you simply can't go to phase V then turn off the DECnet protocol 
on all of your LAN interfaces, install Multinet or the VSI stack (if you 
do not already have it) and configure IP-based links for your DECnet 
traffic.  Then encrypt that traffic.

3. Can't (or won't) do either of the above.  Then configure your 
infrastructure devices as outlined in the challenge.  You'll still be 
transmitting in the clear but at least its possible to set up your 
network so that is very difficult for anyone unauthorized to see that 
in-the-clear traffic.

Any of these steps will make your DECnet network more secure than what 
you are probably running now and all of them will let you keep the 
advantages of DECnet that you are currently using.

Mark Berryman