Last month, the SNIA Networking Storage Forum (NSF) took a different perspective on the storage networking technologies we cover by discussing technologies and practices that you may want to reconsider. The webcast was called “Storage Technologies & Practices Ripe for Refresh.”  I encourage you to watch it on-demand.  It was an interesting session where my colleagues Eric Hibbard, John Kim, and Alex McDonald explored security problems, aging network protocols, and NAS protocols. It was quite popular. In fact, we’re planning more in this series, so stay tuned. The audience asked us some great questions during the live event and as promised, here are our answers: Q. How can I tell if my SSH connections are secure? A. Short of doing a security scan of a server’s SSH port (typically TCP/IP port 22) it can be difficult to know if your connection is secure. In general, the following are recommended:

1. Use SSH version 2 or later
2. Disable server SSH root logins
3. Authenticate clients to servers by using SSH key pairs (don’t use the same keys on multiple systems)
4. Change the default SSH port
5. Filter connections using TCP wrappers or similar network filtering
6. Set idle timeouts that close SSH connections. If you don’t need SSH on a server, make sure it is disabled.

Q.  How can customers determine if they are using updated security technologies?  A. Security technologies can be both security features/capabilities as well as elements that address the security posture of a system at any given point in time. From a feature perspective, it is often difficult to change or add them, so it is important to consider requirements for things like encryption, key management, access controls, etc. up front; assume that what you start with is probably all that you will get going forward. Security posture, on the other hand, can be very different. It typically involves configuration changes (e.g., enabling/disabling a security feature), applying patches to operating systems and applications, and updating software to newer versions when security patches are no longer available or are inadequate. Performing regular security scans of systems is also an important element because they will help verify the system is being maintained properly as well as to provide alerts for new problems as the threat landscape changes. Q. This is not really a question, but rather a comment on NAS protocols, their security is only as good as the authorization on the files. e.g. 777 or everyone type ACLs.     A. The NFSv4 and SMB3 protocols are as secure as you want to make them. Assigning inappropriate authorization is a user error, not a protocol problem. Q. Can most modern storage systems and operating systems support NFSv4 and SMBv3? A. The majority of NAS systems from most vendors can support NFSv4 and SMB3, and many will allow access to the same files with either protocol. (But see the caveats below.) There’s the open source Samba (see here  for a protocol that’s SMB3 for Linux and Unix), and Microsoft Windows Server supports NFS v2 v3 and v4.1. Q. Do obsolete protocols have an impact on multi-protocol (NFS + SMB) access to data?  A. Yes, in several areas; the two biggies are security and locking. On security, NFS and SMB share in common the same terminology (ACLs or access control lists) to describe the security on objects like files and directories; but the underlying security models are different. See this NFS4 ACL overview for more details. Locking is a complex area, and the general rule is; don’t share files between SMB and NFS unless you’re fully aware of how locking works. Obsolete protocols definitely don’t help here, so best avoided. Even with up-to-date protocol stacks there are lots of other gotchas. If you must share between NFS and SMB, involve the vendor of the system that is providing you with this capability, and adhere to their best practices. From a security perspective, multi-protocol access to data is fraught with access control problems because the access privilege models can vary significantly. This can lead to a situation where an escalation of privileges can occur, granting someone access to data that they should not be allowed to access. Adding obsolete protocols to this mix can further expose data because of the granularity of the access privilege model or complete lack of one. Q: Could we use robust log system and real-time analysis and real-time configuration, in the transport layer? A: The network transport layer is Layer 4 in the 7-layer OSI model, most commonly using the TCP or UDP protocols. Both packet logging and filtering tools can be used to monitor Layer 4 traffic, and real-time analysis can be done by a packet analyzer, firewall, intrusion detection/prevention system (IDS/IPS). These tools typically allow capture or filtering of packets based on a combination of their source and destination IP addresses, source and destination ports, and the protocol type (TCP/UDP). More sophisticated networking equipment might also track connections and use deep packet inspection to identify applications at OSI layers 5-7 in the network traffic. Doing such analysis can identify the use of obsolete protocols or applications or detect malware or suspicious activity. Real-time configuration could be used to turn off obsolete or unneeded protocols on servers that no longer need them or to block their traffic from using the network.