Random Characters being printed

asked 2023-10-09 16:43:36 +0000

Hi All:

Started working at a new job. The org has 20+ Konica Minolta and Lexmark Printers. A new print server was put in (PAPERCUT MF) and a new W2019 Std Print Server VM was built and deployed to support this new mechanism for printing via Papercut.

Everymorning on various devices, there will be a series of printed pages with random characters at the top that reminds me a bit of a print driver misconfiguration. The tops of the pages will have two or three rows of random characters that print any where on 3 pages or sometimes as much as 100 pages.

This has been going on for years from what I understand and doesn't seem related at all to this new print server project that was done this summer.

Anyways, I was thinking of using WIRESHARK to help root cause where the SOURCE of the traffic is. I was thinking of putting a tap in front of one of the lesser used printers with the hopes of collecting the IP addresses of ANY IP source that may be trying to communicate to the printer.

TBH, I don't k now what DESTINATION port is being printed to but suspect it's PORT 9100, though it could be IPP (631) or other (LPR 515 or 721-731)

So my thought is to get a NETGEAR 5-port GS305ev2 and setup port mirroring. I'd plug one port into the LAN cable coming in from the switch, another into the printer, and mirror traffic coming from the switch port. Using Wireshark, I'd like to start a capture.

My question isn't so much how to start a capture, but how to setup a FILTER to capture EVERY UNIQUE SOURCE IP and PORT going to the PRINTER IP (ANY PORT).

My thought was to let this setup run for the night. We have no idea where the print jobs are coming from, but our users say that the random printed pages are on the printers before they start their jobs at 8:00am.

Something is sending jobs to these devices. My thought is to try and at least identify the SOURCE of the jobs and then to dig into those endpoints to see what applications may be configured to be printing to these printers.

IDK if it's some old device or scheduled print job using IP printing. Really have no idea.

Looking for thoughts and advise. IDK how to setup a capture filter to try and restrict the packets recorded. I'm simply trying to identify any endpoints that are communicating to one specific printer for now as a pilot. It's possible that the source identified MAY be the root cause of the random printing on all the printers. IDK.

edit retag flag offensive close merge delete

Comments

Why do you want to set a filter, don't you want to capture all traffic to see what's going on?

grahamb ( 2023-10-09 17:01:00 +0000 )edit

Just worried about having some massive PCAP log (haystack) to try rummage through really. I figure if I could limit the traffic, it'd be easier to identify UNIQUE sources.

Bubbawny ( 2023-10-09 17:04:10 +0000 )edit

add a comment

3 Answers

Sort by » oldest newest most voted

answered 2023-10-10 15:36:06 +0000

SYN-bit

18528 ●9 ●338 ●255 https://SYN-b.it

As said by others, you might as well capture all traffic to one or more printers to not only find out who (IP) is responsible, but also why, as you capture the full TCP streams.

If you do want to only capture the sources of systems that connect to the printer, then you could use a capture filter to capture the SYN, FIN and RST packets (that way you get to see who is connecting and how much data was exchanged). The corresponding capture filter would be:

tcp[13] & 7 > 0 for non-vlan tagged traffic
vlan and tcp[13] & 7 > 0 for vlan tagged traffic
tcp[13] & 7 > 0 or (vlan and tcp[13] & 7 > 0) if you want to capture both tagged and untagged SYN/FIN/RST packets

edit flag offensive delete link

Comments

Thank you, friend. I'll probably perform initial PCAP tomorrow. I'm awaiting a GS105ev2 to get here to place it inline with a printer for capture.

I was able to look at some devices logs and it definitely seems to be related to a network probe, though I'm not fully positive on that. In one of the logs, it does show one of our probe points showing up as establishing connections starting at 11:00pm everyday and running for several minutes, changing the source ephemeral port with each connection attempt. The device log however does not record which destination PORT that the session was capture on. So I've no idea if the probe is hitting IPP/9100 et al and is triggering the random characters to be printed.

My user base is very frustrated. This "ghost in the machine" has been going on for months and months ...(more)

Bubbawny ( 2023-10-10 15:44:51 +0000 )edit

add a comment

answered 2023-10-09 18:29:29 +0000

Chuckc
3023 ●6 ●608 ●20

Do you have a test/victim printer on the local LAN such that firewall rules won't interfere with testing?
How about scanning a printer with nmap or zenmap to try to recreate the issue.
Might help to see what ports the printers are listening on.
If you're pretty sure that it's TCP traffic, a capture filter like this will limit the capture to the first two packets of the TCP handshake:
ip host 192.168.200.50 and (tcp[tcpflags] & tcp-syn != 0)
These would show up in the Wireshark Statistics -> Conversations:TCP.
(Capture filter syntax with more examples: pcap-filter.7)
If uncertain about whether it's TCP or UDP, you could generate netflow records with something like nprobe then capture and view the records in Wireshark.

edit flag offensive delete link

Comments

TYVM!

This is why I want to tap inline. I suspect a FW is interfering. But I have a workstation I can use where no FW will interfere.
I'm not sure honestly if it's TCP. I suspect it is. The devices have multiple methods for printing enabled (IPP, RAW/9100 et al). So i'm not really sure how the data is getting fed. WE also do pentesting. it is very possible it's coming from an aggressive scan. Not sure. But I would think Wireshark PCAP should give me insights on this. I will eval L2 and L3 at some point.
Thanks for the recommendation. Much appreciated!

Bubbawny ( 2023-10-09 19:53:06 +0000 )edit

add a comment

answered 2023-10-09 17:33:08 +0000

André

176 ●70 ●3

Indeed you can configure the switch to forward the traffic to/from the printer port to the monitor port. See also CaptureSetup/Ethernet.

Since that will only capture the printer's traffic a capture filter is not necessary. In fact, applying a filter may filter out the cause of the problem...

Since you want to capture for a long duration, it is better to use dumpcap on the command line instead of using Wireshark GUI as it might crash when it runs out of memory.

edit flag offensive delete link

Comments

TYVM Andre! :)

I'm going to grab a Netgear GS105EV2 and see what pops up.

Bubbawny ( 2023-10-09 17:54:35 +0000 )edit

add a comment