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.

Upgrade PaperCut NG/MF

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.

Install a CA-Signed certificate

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.

See: Installing a CA-Signed Certificate the Easy Way

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.

Force clients to connect using HTTPS

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.

As an added layer of security, you may also enable HTTP Strict Transport Security (HSTS) which will only allow HTTPS connections.

Without this setting enabled, a vulnerability scan may flag this as “HSTS Missing From HTTPS Server (RFC 6797) - The remote web server is not enforcing HSTS, as defined by RFC 6797”.

See: Forcing use of HTTPS/SSL only

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.

Use Strong Ciphers & Protocols

Prevent PaperCut from allowing connections with devices and clients which use weak ciphers and insecure protocols that are vulnerable to being intercepted and decrypted.

See: SSL Cipher Configuration - disable weak ciphers

What can go wrong? Some 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.

Ensure high-risk features are configured correctly

The 22.1.1 release contains security hardening features designed to uplift default security and provide additional layers of protection. In particular, we’ve added configuration and new defaults to make it hard for attackers to initiate a chained attack using PaperCut NG/MF.

Force Secure Cookies

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:

1. 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).

2. Paste the following section to the server.properties file to set the cookie policy.

   ### Cookie Policy ###
   # By default session cookie is set to be httpOnly and secure (if originating from secure connection).
   # Policy below can force all cookies (not just session) to be always httpOnly and secure even if not coming from secure
   # connection.
   # NOTE: Setting force-secure=Y will disable cookie session tracking for http origins.
   server.cookies.force-http-only=Y
   server.cookies.force-secure=Y

3. Save the file.

4. 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.

Disable Password Auto-completion

On older PaperCut servers a vulnerability scan may give this warning: “Web Server Allows Password Auto-Completion -The ‘autocomplete’ attribute is not disabled on password fields.”

This particular setting is managed by the advanced config key auth.web-login.autocomplete as documented in our article Customize the Login page . The value should be set to “N”. This setting is already the default for new PaperCut NG/MF installs as it prevents users on shared computers from accidentally caching their password in the browser.

What can go wrong? No issues we know of or that customers have raised.

Prevent the internal IP address from being disclosed

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.

See: Override the “host” header for redirects

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.

Have users access the Web Interface using standard ports

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.

See: Enable ports 80 (HTTP) and 443 (HTTPS)

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.

Restrict unnecessary ports on the Firewall

The exact steps to do this will depend on the host or network-based firewall you are using to protect your environment.

See: Firewall Ports used by NG & MF

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.

IP Address Allow-listing

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 allow-listing 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.

More on this topic is documented in our manual on the following page: Restrict access to the Application Server.

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.

Other best practices…

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.

What about Print Deploy?

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.

See: Enhance Print Deploy Security.

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.