As companies small and large continue to experience unprecedented levels of security breaches and cyber attacks, our responsibility as technology professionals and champions of sound security practices continues to grow. In the realm of professional services, our clients look to us for recommended security practices not just within platform configurations, but also the storage and transmission of sensitive information.
In tandem, company employees responsible for IT must also continue to be diligent in their management of sensitive data, and set examples for both end-users and their IT departments as part of ongoing proactive security measures.
Like most things, this starts with awareness and understanding the implications of what sensitive information could be gained from what might at first, be seemingly innocent files.
Take for instance, the configuration files of Citrix ADCs (formerly NetScaler). At first glance, we might not think twice about where we store these files or whom we email them to. Delving a little further into the file’s contents however there’s a couple clues:
Passphrases and Passkeys:
Littered throughout the ns.conf files you’ll find encrypted code, representing passwords encrypted by the appliance using an AES256 key. The encryption renders the passphrases undecipherable to human eyes. The key is common to ADCs which lends itself well for administrators performing platform migrations or other activities that may require re-use of these configs or snippets of them.
The Risk: Without some solid cracking tools we’re unlikely to decipher the encrypted passphrases for our monitors, local users, RPC nodes, and server certificate key pairs, there’s perceived risk that the portability of these configs may render ns.conf files vulnerable to misuse. Should the ns.conf files be stored alongside easily accessible private and public certificate keys, that further heightens the risk of these files falling into the wrong hands through improper storage or non-secure transmission of files.
This one is a bit more obvious. ADC config files will be full of IP information. It is a configuration file after all. ’nuff said.
The Risk: Internal IPs might initially seem to be inconsequential, but their association in a config file with a server name or say, an authentication server, may provide exploitable information for unsavory characters about the internals of a corporate network.
Having spent 2 hours scrubbing our files repository of any ns.conf passphrases, it was evident this was utterly stupid. ns.conf files are coded in a structured and predictable manner, easily grep’d for patterns and manipulated. Similarly for IPs. The biggest barrier to good data management practices for these files is the effort needed to comb through files and just get the work done quickly and easily so it can be stored alongside your project files, platform documentation, or email transmission.
You can try it now at: https://adctools.ferroquesystems.com
It’s a simple drag and drop process, and outputs a scrubbed file in less than a second. By default, IPs are not obfuscated, this can be handled by checking a checkbox before selecting a file. Once processed, you’ll get some nice stats to the left side of the page, outlining the number of passphrases and IPs (if applicable) processed based on various classifications (monitors, auth servers, RPC passwords, cert passphrases, etc.).
The ns.conf files are not transmitted to the server, nor metadata stored server-side It’s free for all to use, download for offline use, and modify to your needs.
Phase II of this tool will involve adding in a separate function to assess the security posture of Citrix ADCs by analyzing the ns.conf files for recommended hardening practices for both the ADC config as well as SSL offloading services hosted upon them.
We hope this helps encourage better data management for ns.conf files for all. Check it out and tell us what you think! Any suggestions? Let us know!