Secure your PaperCut NG/MF server
“As an infosec professional or a security-conscious sysadmin, I am looking to make our PaperCut server as secure as possible. What configuration changes can we make to PaperCut applications to ace our next pen-test or harden our server against would-be ne’er-do-wells?”
This article focuses on the security of the PaperCut application server. Your organization may have other means to secure your environment such as a Web Application Firewall, but this article focuses on the things you can configure within PaperCut to enhance security, with a focus on the embedded web server. For the sake of brevity, some security settings that are already on by default, like CSRF Validation, are not mentioned here. The instructions below represent a collection of our best advice when it comes to securing your PaperCut server.
Be aware that there are tradeoffs to each of these options. We have had many support phone calls and remote sessions with customers who forgot they had enabled these settings or did not fully test their environments and as a result they were forced to troubleshoot why users began seeing certificate errors in the browser or why older copiers stopped working with PaperCut. For each section, we’ve tried our best to describe what can go wrong and specifically what you should test after implementing.
First and most importantly, please regularly update PaperCut software (in addition to your server OS) for the latest security enhancements. Subscribe to our Release History to be informed when new versions are released.
What can go wrong? Upgrading PaperCut is a relatively safe process. It’s rare for something to go awry, but if something does then our Support team is standing at the ready to help.
This allows users to verify the identity of your PaperCut server. Without it, users accessing the PaperCut server’s web interface over HTTPS will see an error message that the certificate is untrusted because PaperCut comes preinstalled with a self-signed certificate.
What can go wrong? Certificates may expire every few months or even after several years. By that time people usually forget how the certificate was generated in the first place and the original sysadmin has moved on. If you install a custom signed certificate, be sure to document the steps and set a reminder for your future self to renew your certificate before it expires.
Once a self-signed certificate is installed on the server, now you can automatically redirect clients towards secure HTTPS connections so that their connection is encrypted by default.
What can go wrong? If you don’t have a proper and working certificate installed on your PaperCut server or if it expires and this settings is enabled then clients will suddenly stop being able to connect to the server, and users browsing to the web interface of the server will get an error message in the browser suggesting that the server is untrusted. Furthermore, if you enable this setting on your PaperCut server it will also be inherited on any Site Servers. This means it is also necessary to install and test a valid signed certificate on any PaperCut Site Servers as well, otherwise MFDs may be unable to securely connect to the server.
Prevent PaperCut from allowing connections with devices and clients which use weak ciphers and insecure protocols that are vulnerable to being intercepted and decrypted.
What can go wrong? Many customers have enabled this setting only to find that their decades-old copiers running outdated firmware can no longer connect to the PaperCut server. Be sure to test any older hardware after making this configuration change.
Starting with PaperCut NG/MF 17.1, a session cookie generated for access originating over a secure connection is automatically provided alongside both the “Secure” and “HttpOnly” flags within the HTTP response header. The “Secure” flag ensures that the details of a session cookie will not be disclosed if a browser subsequently requests the information over a plain HTTP connection, whilst the “HttpOnly” flag dictates that the cookie can only be accessed by the server itself, minimizing the chance of it being intercepted and interpreted by a third party.
For sites with particularly rigorous concerns around cookies, additional configuration can allow these flags to be included uniformly for all other cookie types issued by the web server. This generally won’t be needed because, if you already followed the steps in the section above to Force clients to use SSL/HTTPS, then cookies will already be secure. The following setting is specifically to address when penetration tests flag less significant cookies like the locale setting (which we don’t manage).
Steps to force secure cookies:
- In a text editor, open the following file:
[application-directory]/server/server.properties. (On a 64-bit PaperCut MF server, this path might be C:\Program Files\PaperCut MF\server\server.properties).
- Save the file.
- Restart the PaperCut Application Server service.
What can go wrong? We’re not sure if this setting has caused problems for anyone yet. Let us know if toggling this setting causes a specific problem in your environment.
PaperCut NG/MF’s web server requires the ability to redirect users to new pages. When performing a redirect, the target location is based on the Host header that the web browser requested. If the host header is omitted (e.g. by manually crafting an HTTP request), the target location is based on the server’s own hostname or IP address. In a NAT environment this might not be ideal if the server’s IP address is considered private.
This can also apply if security audit software reports “Web Server HTTP Header Internal IP Disclosure” or something similar.
What can go wrong? When this option is used it is important that all users access PaperCut via this defined host name, and that this host name is accessible to all users. This could be a problem if your organization uses a reverse proxy. This might also be a problem if the server name doesn’t match the common name or subject alternative name on the certificate.
Normally users access the web interface of the PaperCut server by going to a URL like this: https://papercut.yourorg.edu:9192, where the port used by PaperCut (9192) is visible. There is a common misconception that displaying the port in this manner can lead to a security risk.
We believe that hiding the port number doesn’t really do much to enhance the security of the PaperCut server and is needless “security through obscurity”, but we still recommend configuring PaperCut to listen on standard ports like 80 and 443. When you do this, users will be able to browse the web interface of the server without needing to enter the port number.
Make this change not to enhance security, but so that users and admins have an easier URL to remember.
What can go wrong? Occasionally we see someone has enabled this setting on their PaperCut server only to find out that the page fails to load. 9/10 times we find out it’s because there’s another web server application running on the same server, like IIS, which is trying to hog port 80. Make sure there’s no other web server application running on this server monopolizing port 80 or 443 before you make this change.
The exact steps to do this will depend on the host or network-based firewall you are using to protect your environment.
What can go wrong? Not having the correct ports opened on your server may cause the application to behave in unexpected ways. When troubleshooting anything odd, you may want to try disabling the firewall temporarily on your server to see if that resolves the problem. If it does, then it may be time to revisit the Firewall policy.
Through the admin interface on your PaperCut server you can configure what IP addresses are allowed for various components including admin login, devices, site servers, secondary print servers, XML Web service callers, and proxy servers for Mobile Client access.
For organizations where security is paramount, consider whitelisting a range or comma separated list of IP addresses. These settings are found in Options > Advanced > Security.
For the XML Web Service APIs PaperCut only allows access from localhost/127.0.0.1 and still requires an authentication token. All calls not passing the token will be rejected.
What can go wrong? This one almost goes without saying that you should test after making any changes to ensure that all PaperCut components on the network are still able to communicate with the server, especially if you have any Secondary PaperCut servers, Site Servers, workstations running the Direct Print Monitor, or are using any 3rd party integrations that leverage the Web Services API.
These are simply industry best practices and goes for any IT infrastructure or software suite. Here’s how they apply to PaperCut…
- Monitor logs - The Audit Logs (found in the admin interface under Logs > Audit Logs) in PaperCut will show you who’s made what changes. Set a reminder to review these periodically to see how your PaperCut server is being managed.
- Disable any unneeded features - Fewer features enabled means your servers and systems have less attack surface.
- Follow the principle of least privilege - Make sure each PaperCut administrator or user is given a unique account to log in with (as opposed to the generic “admin” account) and manage their permissions in PaperCut under Options > Admin Rights.
- Lock down access to the server - PaperCut stores a couple important things in file system on the server, like credentials to access an external database for example. Limit the number of people with local administrator rights on the server running PaperCut and audit access regularly.
Print Deploy is an optional PaperCut feature for print queue management and deployment. There are separate steps for this feature to install a signed certificate and manage the allowed ciphers and protocols.
Still have questions?
Let us know! We love chatting about what’s going on under the hood. Feel free to leave a comment below or visit our Support Portal for further assistance.
Keywords: penetration test, pen test, vulnerability assessment, security settings, harden