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:
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.
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.
"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."
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?
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.
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.