Secure Printing? 44
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."
ssl? (Score:2)
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.
network topology (Score:1)
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!
Re:network topology (Score:3, Informative)
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.
Re:network topology (Score:1)
But it can be detected, whereas sniffing a network with only hubs is easier to do undetected.
Re:network topology (Score:1)
Huh? (Score:2)
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.
Good Question (Score:3, Interesting)
Your network is only as good as the weakest link.
Re:Good Question (Score:1)
Re:Good Question (Score:2)
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
etc, etc.
Re:Good Question (Score:2)
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
tunnelling.... (Score:1)
How about direct connections? (Score:4, Insightful)
What's wrong with a private network or a direct computer->printer connection via parallel/usb in this special case?
Unsecure print servers (Score:2, Funny)
Re:Unsecure print servers (Score:3, Funny)
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 (Score:2)
Is it really worth the trouble? (Score:2, Insightful)
Re:Is it really worth the trouble? (Score:1)
But I thought that mutes were worth 25 points.
Re:Is it really worth the trouble? (Score:2)
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 [pwg.org], but I think you'd be hard pressed to find printers, print servers, and clients which support it.
Direct Connect (Score:1)
VLAN (Score:2)
(Assuming you are in fully switched network with everything going straight into VLAN capable switches of course.
Unstated assumptions (Score:3, Insightful)
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 (Score:2)
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 (Score:2)
Re:Many have missed the Point (Score:2)
Old Story (Score:1)
(It would have been even funnier if the professors knew about the trick and printed fake exams over the network and the real exams locally.)
Re:The doctor is in. (Score:2)
CUPS/IPP (Score:3, Informative)
Re:CUPS/IPP (Score:1)
Re:CUPS/IPP (Score:2)
Try this... (Score:1)
Although I like the simplicity of having direct attatchment to such confidential documentation printers, that might not be possible.
Have fun !
switched network? (Score:2, Informative)
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 [lprng.org] 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
Not quite. (Score:2)
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:Not quite. (Score:1)
> I'm afraid that this isn't so. It is trivial to
> sniff a switched network so switches don't offer
> any security.
How is it trivial to sniff a switched network? Assuming one doesn't have administrative access to the switch itself?
I'm not being fecicious. I'd really like to know. I've heard of some broadcast storm related hacks that good (ie. Cisco) switches protect against. But otherwise, how do you go about sniffing a switched network?
Also, I wouldn't go so far as to say that LPRng doesn't help. It helps solve a problem. It may not the the end-all solution to every printing security problem, but it's a piece of the puzzle.
Obviosly other aspects (firewalls, vlans, etc.) play a role as well.
And if you're the NSA or a defense contractor, you're not posting your security questions to slashdot, now are you? ;-)
Steve
Encryption in printers is available (Score:2)
Some things to keep in mind:
Ethernet printing (Score:1)
Use the Linux box as a ssh tunnel/gateway. On the workstation side all printing traffic will be ssh tunnled, on the other side where the printers reside in your awesome printer room. Use a managed hub that has mac addresses of the printers locked down and disallow any traffic from anything else.
OR... add a nic to the linux box for every printer and lock down the mac addresses of the printers there.
Something fishy happens all secure printing jobs get broke off and new prints get sent to the printers "Printer Security Alarm" as well as a message to your favoriate Pager or SMS to your cell.
DRACO-
vpn? (Score:2)
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.