Usually, you have the most to worry about network security from websites you visit and phishing links in emails. However, security issues regularly target network servers. Just ask your website administrator about that. Network services come under attack all the time.
RPM Remote Print Manager® ("RPM") is a print server, and like all print servers, it's still a network service. Anyone in your domain can connect with RPM for any reason. Unfortunately, that reason may have nothing to do with printing.
In this article:
How RPM deals with network scanners using web requests
How to arm RPM against network scanners using invalid print requests
How RPM secures your printer by isolating print jobs
How RPM deals with network scanners using web requests
Web servers are among the most common network servers on the internet. Not only that but many devices, such as printers, have a built-in web server. For that reason, now that RPM reports on questionable LPD commands using critical events, we're starting to see reports like the following:
The critical events dialog shown here tells us that RPM received, on the LPD protocol port, commands such as "GET / HTTP 1.1" and similar. These are commands that your web browser would send a Web server. This report tells me that a program running on a computer with address 192.168.6.17 has found the RPM printer port and is attempting to query it. This activity should not interfere with RPM's normal operations.
In this situation, we recommend that this user add the address "192.168.6.17" to the firewall on the computer running RPM and then check that other computer for rogue programs.
How to arm RPM against network scanners using invalid print requests
We have been getting reports from customers for years about "strange queue names appearing in the user interface" and asking how to stop this. Here is an example from an earlier blog post:
Using diagnostic logging, we determined that a network scanner would send "probes" or incomplete LPD requests designed to get a print server to fail.
We generally handle bad input gracefully, but the problem became severe enough that we took several steps to deal with it more decisively:
we log the bad input
we close the connection
we generate a critical event so that you, the user, can see what the command was and the sender's IP address.
For this kind of problem, we have two recommendations for you to consider.
First, contact your network administrator and give them the IP address of the computer sending these print commands. There is no reason we can think of why this is a good thing.
At the same time, add the client IP address to your local Windows firewall to prevent that program from contacting you again. If this blocks your print traffic, then you'll have to allow the traffic but follow up with your administrator about deactivating the probe.
Second, you can block RPM from creating new queues on request. This action only affects queues resulting from incoming print requests. You can still create queues in the user interface without restriction.
To configure RPM to block queues from being created from print requests:
Go to Configure / Port Settings
select the "lpd" protocol from the list
Click "Modify Port"
Turn the setting "Auto-create queues on request" off
A previous post "How to prevent queue names appearing in RPM," discusses this section in much more detail.
How RPM secures your printer by isolating print jobs
You might have heard of "SQL injection," where someone inserts commands in a form entry to do something behind the scenes in a web server. Or you might be aware that an infected or malicious web server might embed a virus and get you to download it. RPM does not allow anything like that. For one, the LPD protocol doesn't allow that kind of behavior. But, more importantly, we have made decisions regarding security all along with RPM. Here are the main points of that security.
RPM treats incoming print jobs as data only. RPM never executes print jobs in any sense. They are only passed along as data to actions which you configure yourself.
You configure actions on your local PC.
The UI can connect to a remote RPM, but this is something you allow on the remote RPM.
Conclusion
You may find yourself one day with dozens of weird queue names, or a critical events dialog with dozens of messages. While annoying, neither of these should affect your operations, and there are steps outlined above, which you can take to track down and eliminate the problem.
