That seems unlikely, to say the least. We don't use NAT, we have enough IPv4 to go around. But as I say, the printers are firewalled from the internet.
Per my last, I'm wondering why the big jobs did not show in the audit log, but my remote user tests on port 9100 do.
No chance you have enabled port forwarding on your router to direct port 9100 at your 7970 is there?
Because this came out last thursday and it is possible you were hit, luckily you would just undo that simple redirect on your router.
https://nexusconsultancy.co.uk/blog/printer-part-flaming-botnet/
https://www.therecycler.com/posts/150000-oem-printers-hacked/
All those reports are being overly dramatic, in no way are the printers owned, it is simply a run-of-the-mill print job that looks for printers available on the internet.
Thanks for the reply.
Our printer is not acessible via ftp.
On the Web portal, software upgrade is disabled but cloning and weblet install are allowed. We don't use the default password, and our printers are firewalled from the internet. There is nothing going through from offsite at that time (initiated by the printer).
If I send a file to the printer with netcat to port 9100, it prints and I get the same kind of banner page (remote user, raw tcp). But I also get an entry in the audit log. For the big jobs, there was no such entry. There was an entry in the front panel job history, but it's now rolled over and I did not take pictures, only some handwritten notes.
It's somewhat of a mystery. I don't recall it happening before, and I'll be happy if it does not happen again. I'd like to understand, though. I'm not sure I have a complete unbroken paper set (banner + initial pages) but I can see some PostScript on the printed pages, e.g.
%%Page: 8 8
%%PageBoundingBox: 1 2 600 780
/DeviceRGB dup setcolorspace /colspABC exch def
etc.
along with a lot of stuff like $JcC<$JcC<$JcC<
so it does not look to me like a virus or firmware update.
Most of it is encrypted and are only supposedly readable with an in-house program Xerox controls.
You won't find anything on your server anyway, the file is most certainly either a virus/trojan (it prints the file instead of executes it) or a file that was submitted via FTP mistakenly. In a lot of cases I have come across, a person actually sets up FTP scanning on the device, but they send the scan to the IP of the printer, which in effect is just a real weird way to do a copy ;-) . When the machine receives a file that appears print ready by FTP, it assumes it is a firmware update, when it turns out it is not, it prints it. Sadly, since the file is not proper, it prints the broken PS/PCL code.
You can disable Software updates by default and only turn them on when you are initiating an update to stop the ftp issue, and , if you use a print server, just disable RAW/port 9100 from printing (LPD is vastly superior, so use that), then any job would need to be IPP or LPD and both of which will show the submitter information if it is indeed something that was intended to print.
But, you can if need be go through Xerox (2nd level support) who can get your log file and send it to Engineering to decrypt and diagnose (Assuming you have a maintenance agreement this is not a billed service) I can state for a fact as a 2nd level rep, we cannot decrypt it, so as anything that goes to Engineering, it will be a long ways off of 1 day turnaround if you go that route.
We have a WorkCentre 7970, software version 072.200.024.14107
A couple of days ago someone tried to print 2600 pages of malformed postscript, and succeeded somewhat. I'd like to find out what machine it was and so prevent it happening again.
The jobs show up on the cover pages as "Remote User" and "Raw TCP". They are in the front panel
completed jobs list with a date/time and page count, but I can't see them in the audit file downloaded from the printer, and I can't see them in our official printserver logs. I assume someone's device discovered the printer and sent the job directly.
I note that there is a file "Basic Network Logs" that can be downloaded. I tried that and get some 300M of data in a tarball, but the two files inside are unreadable, with an .enc suffix.
I was wondering if those logs would in fact have the information I need, if they can be decoded.