Indeed. An insecure write-able SNMP was exactly what I had in
mind.
Tops-20 has two glaring defects in this regard (IMHO)
First, if, on a loaded system, you sat on ^C on the CTY--really hammered on it--you could blow the EXEC up. Normally, this would result in an immediate logout. However, in CTY case, you wound up in the MINI-EXEC as a logged in OPERATOR job with full OPERATOR capabilities.
There are reasons for this (say you a debugging an EXEC that gets sick before you can login). However, for the general case, we all thought that this was 'a pretty bad thing'. However when I SPR'ed it (with a suggested patch to only do this if ), DEC's response was effectively, "Secure your machine room".
Sigh. Anyway, it's on my list of things to fix (in MEXEC.MAC at
EXEC2+25)
On 3/2/22 2:25 PM, Johnny Billquist wrote:
One obvious reason it might not be is the fact that if something security wise is screwed up, you are in a deep pile of poo poo.
Was it HP Integrity servers that had some root kit on the ILO, or something like that...?
Back in the day, I liked to have the disks with important software, like the OS and core applications, write protected during normal operations. Little chance of that getting corrupted... But it did require you to physical be by the disks if you wanted to upgrade things, since you needed to hit that write protect switch. But I was happy with that.
Johnny
On 2022-03-02 20:19, Thomas DeBellis wrote:
'almost'?
I found myself curious as to when it wouldn't be. Could you elaborate? Did you have something in mind, perhaps having SNMP on all the time?
We expended substantial effort to make our 20's effectively 'lights out'; nobody in the machine--EVER--except to mount tapes and disks or to boot and that was during third shift. They could even be configured for remote management in the boot regard if you had local (wired) terminals on the first DH11.
You could set the switches of the front end that indicated which terminal would become the CTY. One of these terminals happened to be TTY7:, which was several blocks away (in my office). Saved me walking and the howling cold of the machine room...
As far as I am aware, at Big Bank, we will not install any machines that don't do complete lights out. That policy is at least two decades old.
------------------------------------------------------------------------
On 3/2/22 12:58 AM, Dave McGuire wrote:
I'm not a PyDECnet user yet, but I will say this, remote manageability is almost always a good thing.
-Dave
------------------------------------------------------------------------
On 3/1/22 20:16, Paul Koning wrote:
Question for PyDECnet users: as I mentioned, there's a new API, cleaner than the old one. A major addition is access to the Session Control layer, in other words external programs can talk to the API to use DECnet communication services, inbound or outbound. This is how I implemented a simple subset NCP and NFT.
That API runs over a Unix domain socket, in connection mode. It's quite similar to TCP but inherently local to the machine where PyDECnet is running. That's nice for security, of course. But on the other hand, it means that there isn't a way for a PyDECnet running on one machine to offer a portal into DECnet for nearby machines. If you keep a DECnet router in the basement, your laptop can't run NCP since it has no access to that socket.
It would not be all that difficult to add an option for running that same API over a TCP port, possibly with some sort of access filtering. Is there interest in such a thing?
_______________________________________________
HECnet mailing list -- hecnet@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se