Secure Printing?

RiverWolf asks: "As a Systems Administrator (a.k.a. 'paranoid security freak') I spend much of my time tightening down systems, loading patches, and just generally making sure no one does what they're not supposed too. While tools like ssh have become a staple for file transfer and terminal sessions, I recently began looking at all the little print servers we have throughout my offices and wondered "hmm, can those things be sniffed?". Until now, my focus for printing has always been 'just get it working', but if someone can sniff the print jobs (like payroll and other confidential information) as they go across the network, then it doesn't matter how locked down eveything else is. Is there a standard for secure (encrypted transmission) network printing, or does anyone know of a way to do this? I found this document that deals with it in a round about fashion, but with dozens of printers spread throughout multiple locations, I don't see it as an option."

Comments

ssl?

[photon317]

It should be pretty trivial to wrap unix print clients and servers in an openssl tunnel. The same has been doen before with mail (smtp, pop3, imap, etc) protocols and others, with minimal (in some cases zero) modification to the original client/server source code.

Good Question

[metacosm]

This becomes more of an issue with printers that just have a direct ethernet jacks. Also, a scary fact is lots of them have default administrative modes that allow crackers to literally just telnet too them and type in a password. Printers are becoming a security issue at many places, I would love to see some intelligent feedback in this thread.

Your network is only as good as the weakest link. :(

Re:Good Question

[Peter H.S.]

This becomes more of an issue with printers that just have a direct ethernet jacks.

All those LAN embedded devices like printers, printservers, routers, managed switches are becoming a security risk for several reasons:

1. They are often not designed with security in mind. Eg. even fairly new switches doesn't support SSH or SNMP v.3. Most printers are a joke regarding security, and the vendors doesn't always seem eager to fix known problems. See the article on http://freshmeat.net/articles/view/445/
Note how one can use eg. a printer that supports ftp, to scan the network, or how some printers has vendor enabled backdoors.

2. The vendors embedded of these embedded devices, doesn't seem to test their devices so rigously:
eg. when the Code Red worm was at its height, people were reporting that all kind of equipment with build in web-servers, was crashing or locking up. Not because they suffered from the same buffer overflow problem as MS IIS, but because the large amount of invalid request, would expose memory leaks or other similar errors.
And again, the vendors aren't always quick to admit or fix the problems. Eg. When the recent SNMP problem affecting huge amount of different vendors equipment was discovered, a lot of vendors denied, or ignored, that their equipment was affected.

3. Such embedded devices are often "configure and forget". When a managed switch or a printserver works, people tend to forget to track and install new security releases of firmware.

4. People tend to think, that devices on the LAN side are secure, and therefore tend not to update, or lock down the devices. This is only true sofar, that such devices are less likely to become targets for hackers, as long as all the LAN side servers are easier to hack.
Again, Code Red showed how people are less likely to secure their LAN side; many, many internal networks broke down, or was shut down, because CR was wrecking havoc once it had gotten inside.
Another thing CR showed was, that VPN's aren't a security tool, but a security risk, since a lot of sites were infected, by compromised machines logging into the LAN by VPN.

Of course, a lot of the problems above, can be worked around by good admins, with a decent budget for designing their network in a secure manner.
A hacker once described most networks as "hard on the outside, but soft and mushy on the inside". (this hacker would, interestingly, often use plain old war-dialing, to circumvent the firewall and IDS).

Maybe more people should start regarding their LAN as just as exposed as anything on the internet side, and employ a "defence in depth" strategy, including making an inventory of their embedded devices, formalize the tracking and installing of new firmware, and generally locking them down. Eg. place a really locked down BSD /Linux box with the CUPSd printer server in front of the printers. That way one gets encryption and authentification, anti spoofing, "load balancing", logging, secure administration (SSH & SSL), and a firewall that not only controls traffic to the printers, but also from them. And why not place IDS's on the LAN side too?
etc, etc.

Re:Good Question

[PatJensen]

I'd like to voice my agreement with your concerns. It saddens me that entire Cisco Catalyst based infrastructures will not be supported by SSH and Cisco's willingness to dump the 2900XL switch product line in favor for the 2950/3950. They no longer release major feature updates, on their 4M and 8M switches. I went to Networkers in San Diego and sat in the IOS session with all the major companies in attendance and there was an overwhelming response to users that wanted SSH (login + file xfer) functionality in IOS. So far they've only been including it in their Firewall/encryption feature set images, which are expensive. This makes it harder for small businesses or SOHO users to get the needed functionality for their lower end routers. As far as switches go, they are only offering SSH in CatOS 6.5 on newer Sup3 5000's and 6500's. No SSH support in their access layer switches, which would be the most vulnerable. What's the deal?

What a bummer, why is it that HP offers SSH in all their 1 meg OS images for all their switches? Low end and high end. I sometimes wonder if its worth it to go the Cisco route these days, but I digress.

Good points.

Pat

How about direct connections?

[BusterB]

If you're printing confidential information like payroll, the the printer is probably not in a public location. Otherwise, it's just as easy to look at the paper coming out as it is to sniff packets, if not easier.

What's wrong with a private network or a direct computer->printer connection via parallel/usb in this special case?

Unsecure print servers

[wompser]

Perhaps a little bit off topic, but one of my favorite pranks when I used to work in downtown Seattle was printing "Happy April Fool's Day" on every printer simultaneously at a freinds company. You would have thought with 25 printers they woudl have a more secure network!

Re:Unsecure print servers

[zulux]

A friend had a nack for finding Windows network printers on his local cable loop and printing out (using a generic PCL3 driver) a "How to Make Your Windows Computer Invisible To The Internet, and Why This Is a Good Thing" information packet.

Re:Unsecure print servers

[|<amikaze]

I found my friend's open printer and printed goatse off on it. Later that evening, he called me up and asked me for help securing his machine :)

Re:network topology

[inkfox]

Just make sure there's no hubs between your server and your printer, that they're on a switched network, and that client-to-server traffic is all encrypted. voila!

Many switches will fall over into broadcasting everything, or everything for a specific MAC if a MAC has appeared on more than one port.

Sniffing traffic on a switched network is often as easy as falsifying a MAC, pinging about now and then to keep the switch confused, and listening.

Is it really worth the trouble?

[jsimon12]

Why bother? I am sure some people would say it would be needed for government or secret, blah blah. Well I work in a "secure" government facility and the physical security alone is enough to make printing in the area safe and secure, and the network is isolated and sheilded, etc etc etc, so to me this is a mute point. Anyway once you print it it can be intercepted, copied etc, not to mention the fact that the last page is still technically on the print drum till it is used again.

Re:Is it really worth the trouble?

[Chelloveck]

[...] not to mention the fact that the last page is still technically on the print drum till it is used again.

And, in some cases, the printers have debug modes where its entire memory (including the data spool) can be read out via SNMP. I believe this is a feature of the HP JetDirect print servers.

I don't know that there is a general way in which network printers can be secured. There's probably an encryption option in IPP, but I think you'd be hard pressed to find printers, print servers, and clients which support it.

VLAN

[martin]

Many swiches now incorporate VLAN technology which a good application for this kind of problem.

(Assuming you are in fully switched network with everything going straight into VLAN capable switches of course.

Unstated assumptions

[coyote-san]

LPRng seems to support Kerberos, but I don't know if it provides data encryption or is just used for authentication. I've also been playing around with the idea of adding direct SSL support to LPRng as an experiment, but it would probably only work with this bounce queues from another system.

The reason I'm mentioning this is to point out the unstated assumption that the worst that happens is that somebody can sniff the traffic to your printer. To me, that takes a distance back seat to the risk that somebody could impersonate your printer or feed it additional jobs.

As an example of this, imagine a shared printer in the sales department where someone has quietly changed the IP address - the print jobs are actually going to a laptop hidden in a closet where they'er spooled off to a competitor before being forwarded to the expected printer.

Or imagine monthly checks being spooled to the same system where the attacker can learn exactly who you get services from... and/or insert checks to dummy organizations they control into the data stream.

You can use SSL tunnels to provide a measure of confidentiality, but if you're serious about security you really need to be thinking about autheticating the printer (and possibly clients as well).

Many have missed the Point

[haplo21112]

Most office printers there days are IP connected. Therefore there is a crucial lan path that is nearly impossible to encrypt which is from the printer server to the print device. The Print device has the print engine inside it which is just reading the Print language so to speak, in most cases postscript. The server is nothing more than a switching station for print jobs to send them off to the proper printers. More so since these printers are IP connected to begin with the printer server can be avoided entirely as a client workstation can be setup by a savy(and enabled user) to print directly to the printer via IP. In the end its the printer makers themseleves which might need to be involved in solving this providing encryption in the device itself and the printer drivers.
It is certainly possible to sniff the traffic going to the printers IP and pick out the Postscript/PCL/etc commands which generate the print out and then recreate the document as things sit right now. The answer would be to encrypt in the drivers and decrypt in the print engine on the printer I would imagine, using some kind of public/private key echange, or perhaps a tunnel....

Re:Many have missed the Point

[coyote-san]

If you're concerned about security, it's not hard to toss a second NIC into a trusted system and set up a daemon to handle a bounce queue. That queue can handle encryption and authentication, and the printer itself is sitting on a crossover cable connected only to that trusted print server.

Re:Many have missed the Point

[haplo21112]

Yes but in most cases like where I sit right now, the print server handles 30+ queues...not exactly practical...personally I think the thread is more aparanoid than one needs to be within their own company walls...but I wanted to be clear on the issues.

CUPS/IPP

[cbcbcb]

CUPS allows use of IPP (Internet Printing Protocol) over SSL. I don't know whether Windows even supports IPP but it's pretty nifty on UNIX systems.

Re:CUPS/IPP

[Enry]

But Win2k (at least) doesn't implement authentication or encryption. At least I couldn't get it to work with a CUPS server.

switched network?

[stevef]

You are using a switched network, right? If so, snooping is not an issue (well, not a BIG issue anyways). Otherwise you have much larger problems on your hands than printing. It amazes me that people are still using hubs... it's 2002 right? Although I have to admit, my campus is guilty. The people I support are on a switched network, but we had to provide our own infrastructure. Everyone else in the building are on 10BaseT hubs :(

Otherwise, look at LPRng which supports tcp_wrappers, doesn't run as root, doesn't need to run as a daemon on all systems, supports access control so you don't have to su - to delete print jobs, stop the printer, etc. Supports kerberos... I could go on.

-Steve

Encryption in printers is available

[Fencepost]

The company I work for resells two different kinds, primarily with a print package of our own that's used among other things for quite a bit of financial and medical printing. One brand is based on Lexmark printers and one based on HPs; the companies that manufacture them basically do their own custom firmware that's added in with the original firmware. Jobs are either produced encrypted by software packages that are able to do it or are encrypted by the driver (the only ones I know of are on Windows, sorry), then sent to the printer.

Some things to keep in mind:

• Expect to pay a fairly significant premium for encryption, I'm not sure how much.
• Expect to pay more of a premium, because almost all of the secure printers will also support MICR and you'll be paying for that capability even if you use regular toner.
• Expect to track the passwords unless you're using the same one on all systems and never changing it.
• Realize that whatever package your payroll people use is probably set up for either local printers or this kind of encryption.

vpn?

[smoon]

First, to everyone who thinks that having a switched network adds much of anything in the way of anti-sniffing security, you should probably look at tools like ettercap or dsniff _now_.

Since an encrypted channel between the printer and the workstation (most likely a windows client, possibly a *nix client) would have to be supported by both the printer and the client, you've got an ugly situation -- both the client and server need to support the encryption/authentication/etc. protocol.

This would be fine if you were just about to discard all of your printers and start fresh again, were able to find suitable products, and the products offered acceptable encryption. Given that this situation is rather unlikely, here's another approach:

Get a 'firewall' style box that supports vpns. Make sure that vpn 'clients' are available for all of your workstation platforms. Put all of the printers behind this vpn-device, on their own private network, including the server that 'shares' the printers.

When the user prints the print driver connects to the different network, through a vpn tunnel. The strength of the encryption on the vpn can be tuned independently of any other aspect of the system.

This leaves the rather obvious hole that someone could disconnect an ethernet cable from the printer, put in a small hub, and then sniff from there. Maybe you bolt the printers into a 'security box' that prevents access to the network connection, and do something similar to the wall jack. At some point you have to give up on paranoia and just monitor things.

Huh?

[FreeLinux]

Encrypted?? Sorry, I'm afraid not. Switches do not encrypt anything the traffic will still be plain text or plain PCL anyway. Additionally, sniffing a switched network is a trivial task.

I realize that old books state that one of the advantages of switches is security and the switch vendors preached this mantra for several years. But, it no longer holds true, if it ever did. The fact is that I can sniff your traffic on a switched network, even if your VLAN spans the globe.

Not quite.

[FreeLinux]

I'm afraid that this isn't so. It is trivial to sniff a switched network so switches don't offer any security. LPRng doesn't help either as the problem isnt the print server daemon it is the printer itself.

For those that don't see the issue, I'll try to explain. Most if not all network printers today, do not have a secure channel between the submitter and the printer itself. This means that print jobs can be intercepted and read from the wire. Big deal? Well suppose that the print job is an ultra secret NSA document or perhaps the blueprint for a secret weapon, that would be a big deal.

The second issue is control of the printer itself. Suppose that the printer is a cheque printer in a bank or insurance company. It is possible for you to submit your own job to the printer. This means that you can print your own cheques on the companies official cheque stock. Now, I understand that network printers have authentication which can be turned on to control access to the printer. But, this password based access control is communicated in plain text on the wire, like a telnet session. That means that even if you password protect the printer, it is possible to sniff a legitimate print job and get the password. Then you have control of the printer and again start submitting your own jobs.

Right now, the only means of securing printers is to directly attach the printer to the print server, either via cable or a VLAN with only the printer and the server on it and no means of routing beyond the VLAN. Also, a secure channel is required between the client workstation that generates the print job and the print server. This can be done with ssl or ssh or even IPSec.

What is needed is a network printer that will speak only ssl or IPSec between the printer and the submitter, then the password based access control can be effective.

Re:The doctor is in.

[SpatchMonkey]

That is pretty damn funny!