[Info-vax] SAMBA and Ransomeware

[Scott Dorsey]

Stephen Hoffman  <seaohveh at hoffmanlabs.invalid> wrote:
>On 2017-07-16 22:15:35 +0000, Scott Dorsey said:
>
>>>> This means that SMB is a moving target, and any attempt at supporting 
>>>> SMB is going to require constant attention and a lot of updating.  
>>>> There is no way around that I fear.
>
>We're not going back to the 1990s or early 2000s era.   We have to work 
>within the constraints and the environment we have.   That means no SMB 
>1, no DECnet, no telnet, no ftp, and hoping we end-users can keep SCS 
>private until and unless we get a secure and authenticated replacement.

Absolutely, and that's reasonable because SMB version 1 is a horror, and
it was a horror when it came out.

I am just pointing out that SMB version 2 is only going to be around for
a limited time as it is.  SMB 3.0 is already out, and the next version is
going to be on the way soon.  It's a moving target.

>I'd like stable servers, too.   But I know we won't ever have that.   

There's some stuff that we can have stable.  There is other stuff that we
cannot have stable.

My job as an admin is to keep that other stuff up to date, and to keep as
much line of demarcation between that other stuff and the stable stuff as
possible.

>OpenVMS servers are routinely badly down-revision with Apache, no TLS 
>for Mail, and issued with other services including the ISC BIND port 
>and such.  VSI is addressing some of these, but it's inherently a 
>moving target.

Apache is a moving target.  Email isn't so much of an issue, but TLS
extensions to SMTP would be nice to have.  BIND is going to be more of
an issue in the future than it was in the past.


   Given we won't ever have stable servers — not what we 
>had five or ten or more years ago — what does that mean for our OpenVMS 
>servers?   It means... We'll have to patch our servers.  Faster.  We'll 
>have to be able to roll our upgrades for uptime.   It means we'll have 
>to isolate those services into sandboxes to contain damage.   Better 
>backups.  Firewalls.  VPN servers.  

All of these are true, but I'm going to say that isolation with sandboxes
is the absolute key to keeping these things secure, and everything else
you mention is secondary to that.

Isolation also means that we'll be patching just the server application, not
the kernel most of the time, and that's important.

>The ability to apply kernel patches 
>without reboot akin to Linux; with fewer reboots, and with easier 
>application and server designs allowing rolling upgrades or whatever.  
>That might be rolling upgrades in-box using VMs or across multiple 
>boxes using SCSv2 and newer and easier rolling-upgrade APIs, or 
>whatever.  

This is absolutely true.

> Our app designs stink, and the OpenVMS APIs are really 
>primitive, but I digress.

I claim that the primitive APIs are a feature and that when you limit 
control flow to a small number of simple primitive calls that it makes it
much easier to tell what is going on and keep things secure and debugged.

As far as the app designs stinking, well, that's true but the standards of
the industry in that regard are fearfully low.

>Again: we can live in and can desire and seek Y2K-era security and 
>long-term server stability and the rest of the uptime era, or we can 
>deal with the environment we have now, with the need to deploy patches 
>more quickly, and prepare for the environment we're clearly headed 
>toward. 

I think we can have both, by forcing modularity, so that the parts that need
constant patching can be constantly patched _without_ affecting the parts that
do not.  Modularity and diminished interconnection between modules is where
control comes from.

>In this case, that means newer Samba or a replacement SMB server 
>package, or use of WebDAV or other alternative protocols, or shuttering 
>the OpenVMS servers at the sites that require services OpenVMS can no 
>longer provide or can no longer provide securely.   Going toward 
>embedded and emulated and static and eventual replacement, and not 
>coming back, and not getting new deployments and upgrades.

Yes, this is clear, and it's clear that the replacement SMB server package
is going to need to be replaced with something else in a couple years so
it's not a single change.  But it's also clear that if we can build systems
so that SMB is segregated from the kernel then we can have security, the
ability to patch without rebooting, and all of the benefits of the future
while retaining the benefits of Y2K.

>We're headed for 2022 and 2027, and not back to Y2K.

Yes, but that doesn't mean we should throw out the good part.
--scott
-- 
"C'est un Nagra. C'est suisse, et tres, tres precis."