Community maintenance is complete. Thank you for your patience!

ONTAP Discussions

Disable RC4 or Enable FIPS

TMADOCTHOMAS

Hello,

 

Our security team is planning to disable RC4 ciphers for our Kerberos tickets on domain controllers. I'm trying to determine what (if anything) I need to do. I've read the following NetApp security advisory:

 

https://security.netapp.com/advisory/ntap-20150122-0001/

 

The Workarounds section indicates you can either enable FIPS 140-2 compliance which will automatically disable RC4 cipher support, or simply remove RC4 cipher support and leave everything else the same.

 

Pages 20 and 21 of the Security Hardening Guide (link below) reference this. The article highly recommends testing, but I don't know what we should test. Does anyone know the potential risks to either action (enabling FIPS or just disabling RC4)? Would I need to do either just because they are turning off RC4 for DC auth? Any direction will be helpful! Thank  you.

 

https://www.netapp.com/fr/media/10674-tr4569.pdf 

1 ACCEPTED SOLUTION

cruxrealm

Almost all new versions of  ssh client (including putty) use higher or more secure cipher/hash than RC4.  NetApp supports already higher secure cipher/hash.    This means you dont have to do anything and netapp will auto negotiate to whatever the DC will use (might require DC reset).    But you still need to work with your windows SA and find out if that is the only thing they are doing since I believe they are changing this to fix DC vulnerability which they also might disable SMB1 (and SMB2) DC connections and enable encryptions that you need to do the same in per cifs server.     If they have a test DC environment that they are using,  you might want to tap in to test an SVM connecting to it. 

 

Having said that,  it is still a good practice to disable weak protocols  (PCT v1.0,SSLv2,SSLv3,TLSv1.0,TLSv1.1), and ciphers/ hashing (RC2,RC4,MD5,3DES,DES) algorithms for security reasons.  You do not need to enable FIPs to disable weak protocols and ciphers.

 

If you are looking at enabling FIPs,  make sure all external resources connecting to NetApp also following and/or FIPs enabled.  Otherwise,  you will get lots of "unable to connect" on clients.

View solution in original post

10 REPLIES 10

ttran

Hello @TMADOCTHOMAS ,

 

The article is suggesting to test the security changes on a nonproduction system that has console access. This way in the event of losing access, you will still have a method to reverse the changes or further perform recovery. You will want to collaborate with the security team on the exact time when they are making the changes so you can perform the changes concurrently to avoid having to perform recovery scenarios.

 

Below is the snippet on page 21 of TR-4569: Security Hardening Guide for NetApp ONTAP 9 that explains in further detail on the changes and testing:

"Enabling FIPS 140-2 compliance has effects on other systems and communications internal and external to ONTAP 9. NetApp highly recommends testing these settings on a nonproduction system that has console access.

 

Note: If SSH is used to administer ONTAP 9, then you must use an OpenSSH 5.7 or later client. SSH clients must negotiate with the Elliptic Curve Digital Signature Algorithm (ECDSA) public key algorithm for the connection to be successful.

 

TLS security can be further hardened by only enabling TLS 1.2 and using Perfect Forward Secrecy (PFS)-capable cipher suites. PFS is a method of key exchange that, when used in combination with encryption protocols like TLS 1.2, helps prevent an attacker from decrypting all network sessions between a client and server. To enable only TLS 1.2 and PFS-capable ciphers suites, use the security config modify command from the advanced privilege level as shown in the following example.

 

Note: Before changing the SSL interface configuration, it is important to remember that the client must support the cipher’s mentioned (DHE, ECDHE) when connecting to ONTAP. Otherwise the connection is not allowed."

 

 

Regards,

 

Team NetApp

Team NetApp

TMADOCTHOMAS

Thanks for replying @ttran ! The issue is, I read the snippet you quoted but don't fully understand what it is saying. Do you have any further insight on these points?

 

  • "testing on a nonproduction system that has console access" - what does this mean? Console access to what, from what? If it means to the cluster from a Windows machine, what do they mean by a nonproduction system? If you've lost access, you've lost access, right? (Whether production or nonproduction). Does this imply that the only effect this change could have would be on SSH access to the cluster via Putty?
  • Regarding OpenSSH 5.7, do you know if Putty uses this? That's what I use for SSH access.

The main question, again is: what is the scope of potential risk in making these changes? If it is ONLY the possibility of losing SSH access, I'll do it, because I at least have console access and can reverse the changes. If it's a greater risk, such as affecting CIFS authentication, I may need to think it through a bit more.

 

Also, I'm not sure if the fact that they are disabling RC4 ciphers for our Kerberos tickets on domain controllers means that I even need to change anything. Any insight?

cruxrealm

Almost all new versions of  ssh client (including putty) use higher or more secure cipher/hash than RC4.  NetApp supports already higher secure cipher/hash.    This means you dont have to do anything and netapp will auto negotiate to whatever the DC will use (might require DC reset).    But you still need to work with your windows SA and find out if that is the only thing they are doing since I believe they are changing this to fix DC vulnerability which they also might disable SMB1 (and SMB2) DC connections and enable encryptions that you need to do the same in per cifs server.     If they have a test DC environment that they are using,  you might want to tap in to test an SVM connecting to it. 

 

Having said that,  it is still a good practice to disable weak protocols  (PCT v1.0,SSLv2,SSLv3,TLSv1.0,TLSv1.1), and ciphers/ hashing (RC2,RC4,MD5,3DES,DES) algorithms for security reasons.  You do not need to enable FIPs to disable weak protocols and ciphers.

 

If you are looking at enabling FIPs,  make sure all external resources connecting to NetApp also following and/or FIPs enabled.  Otherwise,  you will get lots of "unable to connect" on clients.

View solution in original post

not_a_Lone_wolf

Thanks for the amazing explanation. I have a query : Is it necessary to enable FIPS 140-2 in order to disallow /disable weak ciphers like rc4 on NetApp, on ONTAP 9.x?  As per https://security.netapp.com/advisory/ntap-20150122-0001/ , In clustered Data ONTAP 8.2.2, the RC4 cipher will only be disabled by enabling FIPS 140-2 mode. 

kryan

No - ONTAP 9.x includes the "security" command to configure the default SSL and SSH parameters. The advisory guidance was specific to clustered Data ONTAP 8.2.x.

 

https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-cm-cmpr-980%2Fsecurity__ssh__modify.html

https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.dot-cm-cmpr-980%2Fsecurity__ssl__modify.html

 

not_a_Lone_wolf

Thank you for sharing the links. However, in the same advisory, the below is also mentioned:

  • clustered Data ONTAP 9.x:
    • Enable FIPS 140-2 compliance mode to disable RC4 cipher support in cluster-wide control plane interfaces:
      ::*> security config modify -is-fips-enabled true	
    • Default ciphers can also be disabled in the 9.x versions of ONTAP using the '-supported-ciphers' option with the 'security config' command:
      ::*> security config modify -supported-ciphers CURRENT_CIPHER_STRING:!RC4

kryan

Yes, the shared links correspond to the second option in the advisory. Either of those options can be used in the current Full Support versions of ONTAP (9.5+). The product documentation should be consulted for the proper command syntax since it may have changed over time/versions.

 

When that advisory was originally posted, cDOT 8.2 & 8.3 were still under Full Support status. The only mitigation for those releases was to enable FIPS 140-2 compliance mode.

TMADOCTHOMAS

Thank you @cruxrealm ! That is very helpful. I'll make sure I update to the latest version of Putty and I should be good. I agree it makes sense to disable RC4 anyway, and sounds like that change is the least likely to potentially cause an issue. I'm thinking I will let them make their change, and then disable RC4. Thank you again for the help!

What I would recommend is testing on a non-production filer or one that if you lose access, it isn't a big deal. If you don't have that, you can download an ONTAP simulator or spin up a Cloud Volumes ONTAP instance briefly and see what happens.

 

If you're testing settings in the future for CIFS/NFS access, you can always set up a new SVM to test that won't impact production as well.

@paul_stejskal , thank you! Great idea about setting up a new CIFS Server. As for losing access, I actually am on premises for our main production cluster, so even if I lost access I could plug in my laptop and re-enable RC4. Once we knew that was working I could do the remaining remote office NetApp's. Having said that, I do have a very old test system I could try this out on first, and will definitely do that once I decide to make this change! Thank you again.

Announcements
NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner
Public