Now more than ever customers have questions and concerns about best practices for securing the KeyReporter web interface and information it contains. Here we’ll explore some common questions and suggestions for KeyReporter, with a focus on the new Remote Connect feature added in 7.6.0.7. Note that as of writing 7.6.0.8 is the current release which greatly enhances the options for the Remote links.
Overview
Like any web service one should consider what information is presented and who can access the site. KeyReporter by design has a Guest view that Administrators can customize by choosing which Maps to make public, and what if any Dashboard Widgets are shown. The introduction of the Remote links means that IP information can be available as well, which many institutions prefer not to advertise. So, consider these questions:
- Will you be making KeyReporter viewable outside of your networks? That is, will a VPN be required to see the site?
- Will you be embedding KeyReporter maps and lists in your other public facing websites? If so, you could create missing content if one is secured and the other is not.
- If you’re using the Remote links feature, are the workstations also publicly accessible or will VPN be needed for those? Remember, we do not add our own connection technology, ultimately RDP and/or VNC will need to be open and enabled on the workstations.
- Did you put a valid SSL certificate in place? To actually have trusted HTTPS connections to KeyReporter, you will need to put in a valid certificate per https://www.sassafras.com/hrl/7.6/kr_ssl.html
Concerns
Is KeyReporter secure?
Web security standards and recommendations are constantly changing and we strive to respond to those promptly in patch releases. You should first make sure you are running the latest version of KeyServer to ensure the latest version of KeyReporter. If you have a stand alone instance ensure that is up to date as well.
By default we have certain security settings in the kr.conf file of KeyReporter that may not appear in older configurations. You can always install a demo of KeyServer on a local workstation for testing to see what the current defaults are. You can then merge those into your production server as needed. These include headers for blocking cross site scripting attacks and other things which we do not put in place during upgrades. The reason is it’s possible in some environments this would block embedded content and we don’t want to disrupt your current operation.
What is KeyReporter running on?
We have a custom built web service. There is no IIS or Apache under the hood, just like there is no MSSQL behind KeyServer. As a result we are in a way both more secure as there are less features, and more limited as there are less features. It gives us the flexibility to rapidly respond to security concerns with new patches, but you may not find advanced webserver capabilities to customize.
Recommendations
By no means are we looking to say how you should configure your environment, these are only our thoughts on what may be best practice considerations. These take into account various customer environments and industry experience over the years.
Secure your environment.
Having the server and workstations behind a firewall is prudent to keep all resources and information safe. The implementation of a VPN may not be cheap or easy if your organization does not already have one, but it’s certainly a good idea. As mentioned however, be mindful if you are embedding KeyReporter content in public facing websites as you’ll create blocked content issues.
If you don’t have a VPN and need to make KeyReporter public, there are several security points to consider:
- Only open the needed ports in your Firewall. HTTP and HTTPS will be needed, but nothing else has to be allowed from outside your walls into the KeyServer system. You CAN allow UDP 19283 so that KeyAccess clients can report in or access policies if need be, especially if you don’t have VPN, but it’s not required. Remember that all usage data on a client will report back to the server when it can connect based on any cached observe policy information it has. We do not recommend opening TCP 19283 as that is the administrative port and should only be accessible from secure connections.
- Push all traffic to HTTPS. In the KeyReporter Settings in KeyConfigure you can set this option, and it ensures secure encrypted communications. This is especially important for password transmission when you log in to KeyReporter. HTTP needs to be open in the firewall to reach the server, but it then pushes the connection to HTTPS.
- Consider using nonstandard ports. This does make getting to the site harder for users as they need to put the port number at the end of the URL, but it lowers attacks when you don’t use the default ports. This is more highly recommended if all your content gets embedded in another website and users don’t contact KeyReporter directly. Because you put the port numbers in the embed links, the users don’t need to be bothered with it, but your site is public and more secure due to the nonstandard ports.
- Use all current security headers in the KeyReporter configuration file. As mentioned these can be gleaned from a demo install, or you can contact Sassafras Support for assistance. Some settings may cause issues if you are embedding content which may require other settings to make exceptions for the embedding site.
- Disable old TLS versions. By default KeyReporter will negotiate the highest security level possible with the client. However, security scanning software much like hackers will try to exploit older protocols. You can set KeyReporter to use only TLS 1.2 and higher for maximum security. See the very bottom of https://www.sassafras.com/hrl/7.6/kr_ssl.html for how to do this.
Consider Visible Information
If you are making KeyReporter publicly accessible, consider what the Guest view has been provided. As an Administrator you can put a wide variety of Widgets on the Guest Dashboard. In some settings this may not be used at all, so the default view will be the Maps. Other organizations may find value in showing various usage statistics for resources. While internally in a design firm a list of users in a limited license application is useful, giving up employee ids to the world may not be a good idea. And of course there is the Remote links capability now, which while rich in options could expose lists of IP addresses. The latter is often considered a risk because giving a list of IPs to attack gets hackers one step closer to their goal as they know both the address and OS from the Availability list in KeyReporter. Also consider that all this data is available under the hood as this is a web service that can access the data internally. As such there are various queries that can be made in the URL to get other data that allows these graphics to be rendered.
Use a Stand Alone KeyReporter
This option causes some limitations in administration and does not add data security. However, it does mean that an attack on the web service will not impact the KeyServer because they are running on separate machines. See TN8080 for full details on setting this up.
Total Authentication
In the end you may want to not allow Guest access and instead have all users authenticate to KeyReporter. This further secures all the data and is fairly easy if you have external authentication like Active Directory. See TN2884 for details on setting this up. Note that new features in 7.7 like the Community role greatly simplify this potential process.
Conclusion
Whew! That’s a lot of information! Security is never a short or light topic unfortunately, but with each passing day it’s more important in a digital world. Hopefully this article helped answer some questions and concerns, gave you some food for thought, and offered new tips and tricks. And again, support is always here to help you with any questions you have on this and other complex topics!
Subscribe
