FlexCache now FREE!

Recently NetApp reintroduced FlexCache into ONTAP where both the origin and the cache can run on ONTAP 9.5 or higher.  That did come with a license; term & capacity based.  Well, the great folks at NetApp have decided that it should be part of the ONTAP package.  That means that its now freeeeeeeeeeee. 

Hold your horses.  That doesn't mean that you can now go creating FlexCache volumes all over the place in ONTAP.  There's no magic that can do that.  That just means you still need to get a license, but it costs $0.00!  Go bug your NetApp account team to go get you one.  I
n a future ONTAP version, you will be able to create FlexCache volumes without a license.  This may even be a P release!  (All the more reason to upgrade to P releases)

You want to kick the tires?  Go on over to https://www.netapp.com/us/info/what-is-flex-cache.aspx and see what you can do.

LDAPS is dead! Long live LDAPS!

So, as a TME for NFS, Name Services and SMB, I always get the question...

Does ONTAP support LDAPs??

StartTLS is insecure compared to LDAPS, right?

Well, let me tell you something........

LDAPS is sooo 90's.  There!  I said it!  90's?  really?   Yep!   RFC1777 was published in 1995!  And guess what?  There was no standard written for LDAP over SSL!  This was just assumed and taken from HTTPS at the time. The LDAP vendors took it, and rolled with it.

Enter LDAPv3.

RFC2251 was started and completed in 1997.  That didn't have any additional verbiage for on-the-wire encryption, but when RFC2830 was written in 2000, it made an extension for LDAPv3 specifically for StartTLS.  RFC4511 combined them into one LDAP v3 standard in 2006.  Once LDAP v3 was ratified and made it into mainstream in the early 2000's, LDAP vendors started to deprecate the LDAPS encryption method for StartTLS.

Deprecate.   That's a big word.   But what that means is that to "be usable but regarded as obsolete and best avoided, typically due to having been superseded."  Don't believe me?   Check it out:
https://www.openldap.org/faq/data/cache/605.html
https://directory.apache.org/api/user-guide/5.1-ldaps.html
https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol#Protocol_overview
I can go on....  Just do a Google search for LDAPS deprecated and see.

Clustered Data ONTAP started without any LDAPS support in favor of StartTLS because of the above reasons.  All LDAP vendors had to support the StartTLS extension because it was part of the standard.  Also, because LDAPS was deprecated, it could be yanked at any time.

But....  StartTLS is not as secure as LDAPS!!  It runs over a plaintext port!

Well, if you leave your LDAP install wide open, sure.  Your LDAP is still insecure.  But there are countermeasures that you can deploy to make sure StartTLS is secure.

1.  Make sure that StartTLS is enabled.  DUH.
   This requires certificates.   Certificates are hard, but learn them.  They make things secure.  For internal, self-signed certs are OK as long as the domains and permutations of them are accounted for.
2. Prevent queries without StartTLS.
   Now that StartTLS is enabled, you can set up LDAP servers to prevent LDAP commands unless the connection is StartTLS upgraded.  This can be done on a DIT (directory information tree) basis. 
3. Prevent LDAP binds without StartTLS
   There is also a way to prevent BINDs from happening in plaintext.  Consult your LDAP vendor's documentation on how to do this.
4. Prevent LDAP clients to send plaintext creds
   You still want to prevent your clients from sending their credentials in plaintext.  This means setting the minimum bind level at SASL.  The credentials passed will also be encrypted.

Doing all this will ensure that the LDAP communication is always secure.

How do you configure LDAP to work with StartTLS in ONTAP?  Easy.  Install the root certificate for the LDAP server's enterprise and then change the LDAP client config for -use-start-tls true and you are set to go.
Here's how your traffic looks: 

I don't see any holes in there.  Application data means its encrypted and is all buttoned up!  

What about ONTAP and LDAPS?   Well...  low and behold......   9.5 introduced the ability to do LDAPS.   Even though its deprecated and there are alternatives, the ability to do LDAPS was granted.
How do we do it?
Change the port in the ldap config to port 636.  Make sure -use-start-tls is turned to false and the same enterprise root cert is installed into ONTAP.  Is this more secure? Less secure?  Who knows.  Not my debate.
Here's what your traffic looks like:

You decide.  They look almost identical to me except for the LDAP START_TLS packets at the beginning.

FlexCache is BAAAAAAACK!!!!

We're starting to hear alot of "Global Namespace" in the industry.  Buzz, buzz, buzz.  Well, what really is a "Global Namespace"?   Well, it can be broken into 2 categories.

1. Your whole data structure is under one "root" volume and the data is actually stored all over the place.  But it's all under one directory tree with soft links, symlinks, junction points, widelinks, and a whole bevy of tricks.
   
   
   OR
2. Your dataset is available in multiple places in a read-write configuration (caching) and no matter where you are in the company's network (via VPN, overseas, in a remote office, at the datacenter) you get a similar response time to that dataset and its all read-writable.

Which one do YOU want?

The first one SOUNDS great, but what benefit does it have?   Well, now you don't have to go search the P: drive AND the M: drive AND the T: drive for what you want, you just have one MASSIVE-looking drive.  But your still searching through the subdirs to find your data.  It's nice... but just smoke and mirrors and your gaining VERY little.

On the Linux side, its a LITTLE better since your automounter just mounts stuff automagically under some path (maybe /data) and everything underneath looks like a single file system.  BUT you have the same Windows dilemma.  Is it REALLY better for your clients?  Also think of applications that now have to go down some unGAWDly path to get at its data.

THEN you have the whole performance issue.  Your Windows P: drive, which is the same as the Linux /data/pdrive path is hella ethernet miles away and performance SUUUX.  

Sooooooooo

Let's look at the second one.  Now this sounds good, but is it?  Well, this means that your data is in multiple places at once and that when you look at it from anywhere in the world, the performance is "local" and its a writable copy.   Awesome!  How does all this coordinate?  Well, ONTAP has a cool new thing called FlexCache.  Well, is it really new?   Well, yes it is. But it isn't.  

We had something in 7-mode called FlexCache.  It was good for its purpose, but lacked enhancements.    Bring the data in a read-heavy, but still writable capacity closer to whatever needs it. It was great for what it did, but the potential to move it forward and give it more features was limited by the backend technology.  Enter FlexCache in ONTAP starting with 9.5.  Its a whole new rewrite of the technology which can give so much more!

First of all, what are the use cases?  There are a few.  The first ones that come to mind is working on the same data in multiple places.  This is an example of AI, EDA, Media Rendering, Code distribution, and other similar workloads.  You have a single "master" data set, but you want other pieces to be able to read the same data and write some results or something into that same dataset.  The next one that comes to mind is creating multiple read-heavy copies to keep the "hot volume" syndrome down.  We all know there's challenges when multiple clients are reading the exact same file(s).  So let's spread the load!

So...  how do I get it and use it?
Starting in ONTAP 9.5, the new FlexCache is available. Give it a spin.  Let your mind explore the options you can use this new feature for.

I do have a Technical Report for the deep dive.  You can find it here:  https://www.netapp.com/us/media/tr-4743.pdf

Go for it!

Does ONTAP need SMB1? No!

There are some rumors flying around that ONTAP, the OS behind NetApp storage appliances require SMB1 to operate in a Windows AD environment.  Well???

That would be false.

Data ONTAP 7-mode has had SMB2 available to it since SMB 2.0 was introduced.   When the OS talks with Domain Controllers for authentication, SMB1 was recommended for the longest time, but several years ago, that recommendation was lifted due to some enhancements in the SMB2 protocol.

Clustered ONTAP has had SMB2 available since inception and has had support for SMB3 since it's inception.  At some point, there still was a dependency on SMB1 for Domain Controller authentication traffic and some other features, but that has since been eliminated.  Those version are 8.3.2P5, 9.0P1 and 9.1 and above.

Starting in ONTAP 9.2, you can actually turn off SMB1 completely with the following 2 commands:

vserver cifs security modify -vserver svm1 -smb1-enabled-for-dc-connections false

vserver cifs options modify -vserver svm1 -smb1-enabled false

DONE!

SMB1 is baaaaaad!

Every once in a while, something comes along in the IT world where everyone panics.  And I mean PANICS!  The lastest SMB1 vulnerability is that panic generator.  It's so bad that they created 6 different CVEs to cover it.

Vulnerability title	CVE number
Windows SMB Remote Code Execution Vulnerability	CVE-2017-0143
Windows SMB Remote Code Execution Vulnerability	CVE-2017-0144
Windows SMB Remote Code Execution Vulnerability	CVE-2017-0145
Windows SMB Remote Code Execution Vulnerability	CVE-2017-0146
Windows SMB Remote Code Execution Vulnerability	CVE-2017-0148

Supposedly this zero-day vulnerability can leak information and allow for remote code execution.

What?   Zero day??   Remote code execution? Huh?  Let me try to break this down for you and give you the "what this means to me" speech.

1.  Zero-day Exploit

This is just a highly technical term to say this vulnerability has been in place since the initial release of this code/function/feature.  For this SMB1 vulnerability, this means that the vulnerability has been in Windows since at least Windows Vista (which is the earliest version that Microsoft still supports), and could possibly even be in Windows XP, Windows 2003 and Windows 2000.  But since Microsoft no longer officially supports those Windows versions so they won't divulge that information.

2. Remote code execution

This one is a little more nebulous of a term.   Well... ok you can execute something remotely on some machine.   Great!   I can do a "dir" on a remote machine.  Which machine?  The "server" or the "client"?  With SMB1 there is the concept if the "server"; the machine serving the files.  and the "client"; the machine that connects to the "server" to read, change or delete those files.  These particular SMB1 vulnerabilities allow for a malicious (read: highly modified) client to exploit that vulnerability to run commands on the SMB server. This can lead to being able to download things like password databases and other mean things.

TURN OFF SMB1!

The SMB1 code is old.  Ancient in fact.  It was developed for Windows 2000.  It's inefficient, clunky and chatty.  That being said, there are still devices out there that use it and cannot use anything newer.  Network printers, Linux hosts (fairly recent ones too) and a number of embedded systems still use the old SMB1 code to communicate and cannot use the SMB2 or 3 protocol to communicate so turning off SMB1 completely in your environment may not be possible.  What you can do in this situation is to turn off the protocol on devices that do not require any SMB1 connections to it.  Microsoft has a way to do this through GPOs (Group Policy Objects).  There is a good Technet blog on this here: https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/

But I have a NetApp filer and can't turn off SMB1.   What can I do?

NetApp, both 7-mode and clustered Data ONTAP have SMB servers built in.  If you have them licensed, then you can serve Windows file shares through it.  Is it vulnerable?  Probably not.  The vulnerabilities with Windows, and specifically with these SMB1 ones are within the Windows Operating System code.  Data ONTAP does not run Windows Operating System code.  It has a custom built SMB server that adheres to the protocol standards, but the source code that runs that protocol is completely different than the Windows source code so the risk of having the vulnerability in two completely different implementations are almost non-existent.

How do I know if I still need SMB1??????

With devices still around that require SMB1 for their functionality to work, You need to be informed if devices are still using it.  The way the SMB dialects work, the negatiation on which version to use is basically a highest common denominator type negotiation.  When the client connects to the SMB server, the client sends all the SMB dialects it supports.  (SMB1, SMB2, SMB2,1, SMB3, etc)   THe server then picks the highest common version.  So if a server supports SMB1, SMB2 and SMB2.1 and the client supports SMB1, SMB2, SMB2.1 and SMB3, the result of that negotiation will result in an SMB2.1 conversation.

In 7-mode, you can see which version clients have been negotiated to by running the command:

cifs sessions -p smb

Then you get the output as follows:

Server Registers as 'TOASTER' in Windows domain 'MYDOMAIN'
Root volume language is not set. Use vol lang.
Selected domain controller \\TOASTER for authentication
====================================================
PC IP(PC Name) (user) #shares #files
10.10.1.15() (MYDOMAIN\administrator - pcuser) 2 0


The above indicates that you still have a device at 10.10.1.15 running SMB1.

In cDOT, you have a similar command:

cluster::> cifs session show -protocol-version SMB1

which outputs

Node:    cluster-01
Vserver: CIFS-SVM
Connection Session                                        Open            Idle
ID         ID      Workstation      Windows User         Files            Time
---------- ------- ---------------- ---------------- --------- ---------------
4268056359 1       10.10.1.15      MYDOMAIN\                0              5s
                                    administrator


and you can tell which systems have negotiated to SMB1.

Can I firewall it?

Well....   yes....    well..... no.....   well.........

There is but one TCP port that all SMB dialects use and that is port 445.  If you block port 445 within your internal network, then absolutely no Windows File Services will be available regardless of SMB dialect.  BUT I fully suggest that at your internet connection, you block all inbound and outbound connections to port 445!  It's always smart to allow only absolutely necessary traffic in and out of your network but that's getting into a post for another time.

Facebook https browsing can be turned off by applications.

For those of you playing along at home, we recently learned that Facebook has turned on secure browsing on it's whole site.  You can accomplish this by checking the "Browse Facebook on a secure connection (https) whenever possible" box in the Account Security section of your Account settings.  Now we know that this stops local hackers from stealing information when you are connected to a the network and this prevents advanced hackers from engineering hacks that can dump your information to them.  But I found something interesting the other day while auditing my applications settings.


This is not working so well.


As I went through some of my applications, I wanted to refresh my memory of why I installed some applications.  I click on the application's page in Facebook and I get a page that tells me that I need to switch back to http (non-secure) browsing in order for the application to work.  

So I play along.

Now to check the damage.   I look at the checkbox that I know I have checked previously to browse in https and it is not checked anymore!  WOW!  Facebook doesn't even let you know that this is a PERMANENT CHANGE TO YOUR ACCOUNT SETTINGS!!!!!


Just all the more reason to do what I do. 


Audit your applications!
Go through your list of applications every once in a while to make sure that nothing has crept in there that you don't want.  If that has happened, immediately remove the app from your profile.
Audit your settings!
The same should apply for your settings.  Go through your settings every so often to ensure that what you have set in the past is still applied.

As always, remember that in the end no one is responsible for your information but yourself.  Always check and double check to make sure your information is as private as you want it to be.

Facebook security http vs. https questions answered

There's been a lot of talk on Facebook lately about http and https and how to change it. Do any of the folks touting this wobegone actually understand what is going on here?  Do YOU know what the difference between http and https is?  Let me try to explain.

When a web browser tries to get to a web site, there is a conversation that happens in the network between the browser and the web server.  Basically you browser gives the web server a bunch of information about itself and then asks the web server to transmit back the page it's requesting.  When you're browser address bar has http:// in front of the web server, this happens in "plain text".  This means that anyone that can see the network traffic between your web browser and the web server can read in plain words what is going on in that conversation.  When you are writing an email, writing a Facebook status update, filling in a form on a website, writing a Facebook message, or sending ANY data to a web site, anyone can read that data that really wants to.  Now, this can happen only at the time that you hit save, send, login, update, or any other button that uploads the information.  As soon as the information is uploaded, that's it.  Noone else, besides the folks you sent it to, can read that data.

Now, when you're browser address bar has an https:// in front of the web server name, then the conversation is a little more involved.  First your browser asks the server for it's "keys", server certificate and then goes out to a certificate authority (such as Verisign, Microsoft, or others) and makes sure the server is who you think it is.  Then your browser takes the "keys", looks at it's own "key" and creates an encryption "key" that will scramble the data that is sent back and forth.  The server then looks at that key and makes sure everything is OK.  Then all data back and forth from the server to the browser is sent coded with the "key".  If someone were to look at that conversation in the network, it would look like gobbledygook to them.
This is the preferred way to log into web sites (since you don't want to send your password over the network so that anyone can read it), send emails, Facebook messages, web site forms, etc, etc, etc so that no one can read the information you are transmitting.

Why is everyone worried about this right now?  Because of Facebook "hacking"?  Will this prevent this???

NO!!!

There are very few opportunities to do this type of hacking. The first is an open WiFi network.  Open means that you have to do nothing to connect to it besides hit the button on your computer or phone that says "Connect".  If you did that, and I did the same thing, I can run a program in the network and listen to everything your computer/phone is saying out on the internet.  If you connect to a WiFi that is password protected, then I can't listen in because the WiFi network does basically the same as the web server in the https:// scenario.

The other two opportunities I have to do this is to send you a bogus email with a link to Facebook that looks like Facebook, but really is my bogus server where you put your information in.  Then my server records that information and sends you on to Facebook so you don't suspect anything.  The last one is that I need to hack into the internet.  This is a little more difficult since I will need to get into network devices owned by AT&T, MCI, Sprint, etc.  Not that easy.

Although this is always good practice to make sure that whenever you are sending private information to a web server, that you ensure https:// is in the address bar, this is not how many of the email and Facebook scams are getting your passwords.  They are getting it by "brute force".  Basically, they are just trying a bunch of passwords and getting a success because yours is easy to guess.  (and don't think you're being clever by using P@55w0rd).