Not detecting printer

GSA is not detecting a printer.
This is a thermal toilet paper printer for bank tellers. I don’t want to skip the scan for these devices (as they have known flaws to patch), but I also don’t want to waste 6’ of paper every Tuesday, either.
Manufacturer: Digital Check
Model: SmartSource ReceiptNOW Elite

per nmap,
110/tcp open pop3-proxy Astaro firewall pop3 proxy
443/tcp open ssl/http nginx
4000/tcp open remoteanything?
9100/tcp open jetdirect?

telnet it not on, initial HTML screen is a generic login. so there is not much here to detect. how do I prevent GSA from printing gabage?

Can you re-run your NMAP with a fingerprint as well with the -A parameters to get a bit more context ?

nmap -A <IP>

here’s the entire response from nmap -A

Starting Nmap 7.94 ( ) at 2024-05-21 14:01 PDT
Nmap scan report for
Host is up (0.024s latency).
Not shown: 996 closed tcp ports (conn-refused)
110/tcp open pop3-proxy Astaro firewall pop3 proxy
443/tcp open ssl/http nginx
| tls-nextprotoneg:
|_ http/1.1
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=Local
| Not valid before: 2024-05-16T21:41:32
|Not valid after: 2034-05-14T21:41:32
|http-title: 400 The plain HTTP request was sent to HTTPS port
| tls-alpn:
| http-auth:
Basic realm=Authentication Required
4000/tcp open remoteanything?
9100/tcp open jetdirect?
Service Info: Device: firewall

Service detection performed. Please report any incorrect results at Nmap OS/Service Fingerprint and Correction Submission Page .
Nmap done: 1 IP address (1 host up) scanned in 198.03 seconds

The port 9100/tcp could be removed from the used port list so that the printer doesn’t print if this port is receiving data.

But…if I cannot print to port 9100, then I have deployed a $1000 paperweight. I was hoping more that Greenbone would detect the device as a printer, and thus not hammer its port 9100 and spew paper on the floor.

A CVE scan would be a better option than including that device in the Full and Fast or other active checks scan.

From the docs:

Not every vulnerability justifies a new scan of the network or of individual systems. If the appliance has already obtained information about vulnerabilities by previous scans, it can make a prognosis of which security risks could currently exist.

Using the CVE scanner allows for a quick prediction of possible security risks without the need of another vulnerability scan. This is especially interesting for environments in which most vulnerabilities have been removed or remediated by using the appliance. If new security risks are predicted, an actual vulnerability scan can be run to verify the prognosis.

The CVE scanner checks the CPEs of the target hosts present in the latest report for the same IP address for assigned CVEs present in the current SecInfo (see Chapter 14). Only reports of tasks that have the Add results to Assets setting enabled will be included. It is not relevant whether the setting is enabled before or after the scan.

As noticed initially:

telnet it not on, initial HTML screen is a generic login. so there is not much here to detect

but also shown in the second posted nmap output there is no real info available that this device is a printer (nmap even detects it as a Device: firewall).

And even if the device would be detected as a printer all what would be done is to exclude the port 9100/tcp automatically from further scanning / sending data to it, so this is basically the same as just excluding the port manually like suggested previously.

The same approach is btw. also done by nmap, but there this port (including a few others) are generally excluded (Exclude T:9100-9107 in nmap-service-probes) from any service probes (independent if the device is a printer or not).

It is just not possible to scan port 9100 (or any of the other “RAW printing” ports) in a reliable way without causing the printer to print out paper as this is some kind of a Catch 22:

If you want to scan this port you need to send data to it but in turn the whole purpose of these “RAW printing” ports is to print any data it receives.

Currently there are only these options for this specific device:

  1. Remove 9100/tcp from the port list as suggested initially
  2. Remove the paper from the paper tray before the device is getting scanned
  3. Same as 2. with a single “Full and Fast” scan and by doing subsequent CVE scans as outlined by @rippledj
1 Like

I guess in this case the CVE scan would not work since it does not assign a CPE to the task? :thinking:

Also, if NVD is not enriching CVE data with CPEs, then this would also cause a serious issue detecting in the future.

My understanding now is that the “Full and fast” settings for “Exclude PJL printer ports from scan” and “Exclude printers from scan” are not tripping, due to limited feedback from the printer. Is it reasonable to set up a pair of scans:

  1. one for this model of printer that skips 9100, and
  2. the main scan of the entire /24 LAN but now omitting the specific IP addresses of the affected model?
    My thought is that skipping 9100 entirely may not catch something. I want to be thorough, but am I overthinking the best solution?

thank you for the assessment. I believe you are correct here, in that the weak response from this device does not indicate a CPE. Omitting port 9100 on these IP addresses seems to be the best option; I will just need to be careful to manually maintain a spreadsheet. (and, let my third party testers as well know what to avoid.)

Thank you everyone (Lukas, cfi, rippledj) for your help on this. I have a much better understanding of the scan process now.

1 Like

As a side note:

From my experiences it is always the best to exclude printers from general scans and only scan them in a controlled way (e.g. by removing the paper tray and having an eye on them during the scan).

Printers are usually / generally quite fragile, e.g. their network stack is often heavily fragile and the printer might lock up / freeze / crash completely while getting scanned.

1 Like