[Info-vax] SAMBA and Ransomeware

[Stephen Hoffman]

On 2017-07-16 22:15:35 +0000, Scott Dorsey said:

> =?UTF-8?Q?Arne_Vajh=c3=b8j?=  <arne at vajhoej.dk> wrote:
>> On 7/16/2017 3:26 PM, Scott Dorsey wrote:
>>> Stephen Hoffman  <seaohveh at hoffmanlabs.invalid> wrote:
>>>> Ned Pile of the Microsoft SMB team has repeatedly stated that running 
>>>> SMB 1 is very bad, and needs to stop.  Here's a longer write-up on that 
>>>> topic:
>>>> 
>>>> https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/
>>>> 
>>>> Samba 3.6 and later support SMB 2 (from 2011) and Samba 4.3 added SMB 
>>>> 3.1.1 (2015).   The OpenVMS CIFS port is based on 3.0.28a.   So... 
>>>> there's no way around using SMB 1 with the current Samba port.
>>> 
>>> This is true and unfortunate.
>>> 
>>> Some of the issue here is that the SMB protocol really wasn't designed 
>>> for security, and Microsoft over the years has tacked more and more 
>>> stuff on it to improve security and availability.  We can expect that 
>>> they will continue to do this in the future.

SMB 1 wasn't secure.   It's also ancient.    DECnet and SCS are also 
old.   And insecure.    Current SMB does rather better here.   DECnet 
really needs to be overhauled or deprecated and removed, and SCS needs 
work, and we increasingly can't depend on internal networks to be 
trusted and secure.

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


>> Like web browsers, web servers, browser plugins, JavaScript engines, 
>> SSL libraries, application servers, CMS'es, mail servers and a ton of 
>> other stuff.
> 
> Like some of that stuff, yeah.  But most of that stuff I don't want on 
> a server in the first place.  And the stuff I do want on a server, I 
> want to fight to make as stable as possible.  But an SMB server 
> inherently cannot be.


I'd like stable servers, too.   But I know we won't ever have that.   
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.   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.  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.   Our app designs stink, and the OpenVMS APIs are really 
primitive, but I digress.

> The web browser is an excellent analogy, though...  and it's a reason 
> why  I don't want to see a serious web browser on VMS.  It takes up far 
> too much support effort for the gain it provides.

I don't expect we'll see one, but we will see REST and HTTP clients and 
HTTP and HTTPS servers on OpenVMS, and those are vulnerable, too.   
Again, we can live in the past, with the pleasantly dangerous delusion 
that "OpenVMS is secure", or we can migrate to more secure versions of 
OpenVMS — VSI is working on that — and to security features and 
processes and upgrades which better contend with our current 
environment.   Or we can migrate to other platforms which do provide 
support for the environment we are in now.   We're not in the Y2K era 
any more.   Security and authentication and increasingly automated 
tools are what we're all working with and contending with, attackers 
and defenders both.

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.   Wrist watches commonly have more capacity and more 
performance than most of the VAX servers.   For those folks here that 
are fond of disparaging or ranting about Microsoft or other vendors, 
please do look at what they're doing, what they have available now, and 
what they're working on.  Microsoft and Linux and other choices are far 
more competitive than they once were, far more secure, and are far 
ahead of OpenVMS in various areas.   The sorts of areas that show up on 
RFPs and bid requests, too.   Times and requirements and environments 
all change.   We either change, or we and our apps and our servers 
retire in place.

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.

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


-- 
Pure Personal Opinion | HoffmanLabs LLC