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,
PORT STATE SERVICE VERSION
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?
Starting Nmap 7.94 ( https://nmap.org ) at 2024-05-21 14:01 PDT
Nmap scan report for 192.168.1.53
Host is up (0.024s latency).
Not shown: 996 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
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/1.1
| http-auth:
| HTTP/1.1 401 UNAUTHORIZED\x0D
| Basic realm=Authentication Required
4000/tcp open remoteanything?
9100/tcp open jetdirect?
Service Info: Device: firewall
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.
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:
Remove 9100/tcp from the port list as suggested initially
Remove the paper from the paper tray before the device is getting scanned
Same as 2. with a single “Full and Fast” scan and by doing subsequent CVE scans as outlined by @rippledj
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:
one for this model of printer that skips 9100, and
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.)
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.
