[Info-vax] SAMBA and Ransomeware

[Stephen Hoffman]

On 2017-07-12 14:48:40 +0000, Neil Rieck said:

> I posted my worry about SAMBA a few weeks back but just noticed this 
> blurb today.
> 
> https://www.theregister.co.uk/2017/07/11/hpe_stops_nonstop_server_samba_bugs/


I'd question running SMB 1 anywhere.   It's insecure.

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.

As for folks that need file shares?  The alternatives include WebDAV 
and NFS for those folks that need file sharing hosted on OpenVMS.

Here's another fun little discussion arising from stale open-source 
ports...  This with Apache.

https://httpd.apache.org/security/vulnerabilities_24.html
https://httpd.apache.org/security/vulnerabilities_22.html

Current Apache is 2.4.27.   The newest Apache port for OpenVMS is 
2.4.12; from VSI.   The most current HPE SWS/CSWS web server V2.2-1 
port is based on Apache 2.0.65.

Why do I mention Apache in the context of a Samba discussion, beyond 
the obvious parallels with issues and vulnerabilities with other 
down-revision software?   Apache is the usual implementation of the 
WebDAV service on OpenVMS.

For those interested in attacking OpenVMS servers, there's more than a 
few (other) areas to explore, too.   VSI is addressing various of these 
issues, but this current treadmill is not going to slow down.   If 
anything, it's going to get faster.  Which also all ties back to 
comments I've made else-thread about faster and easier and more 
automated patching, better telemetry, and other implementation details 
that are increasingly expected on any platform with "legendary 
security."

For now?   Until newer ports are available and are maintained closer to 
current releases?   I'd question sites exposing OpenVMS to the 
internet.    Block everything not absolutely required of the server at 
an external firewall, access the server via VPN or console or bastion 
host, and network-partition the OpenVMS servers from other 
network-connected hardware including printers and client computing 
systems.  Use encrypted and secured and non-locally-accessible backups 
(write-only remote archiving or otherwise), etc.

Even with actively maintained and current ports, I'd still question 
openly exposing OpenVMS servers.  This because knowledge of 
vulnerabilities increasingly spreads faster than many OpenVMS sites can 
receive notifications and schedule patch installations.  (n.b. 
attackers are perfectly willing to use a couple of steps to get to the 
server, they'll use whatever chain of local or other-hosts or printer 
exploits or whatnot to get where they want.  The network the system, 
and the vulnerability.)







-- 
Pure Personal Opinion | HoffmanLabs LLC