I'm looking at sharing a printer over the internet, what are the implications?

Question

Is it safe to NAT to the TCP/IP printer on the appropriate port in the router? Will I get unwanted documents from hackers or is this not a huge problem?

Answer 1

Keep in mind that even printer firmware (presuming it's a printer and not a print server like CUPS) has security vulnerabilities. There have been reports of printers getting 'bots installed on them. You may get random messages from people, much like junk-fax.

Answer 2

If you can run ssh (and Linux et al.) you can set up a VPN. You could also consider OpenVPN or IPSec. However, for small and especially ad hoc deployments ... ssh is probably the easiest and will work from most places and through most NAT/NAPT and other weird local networks. (Think WiFi from our laptop at random local coffee shops).

OpenSSH version 4.3 and later supports a VPN tunnel feature. So you can start your ssh connection with options like -w0:0 ... and (assuming you've made your /dev/net/tun device and done the appropriate tunctl magic to enable any sort of TAP/tun networking at all).

Once you've established such a tunnel you should be able to securely access your printer, your file shares, your e-mail, internal web interaces, etc. through that tunnel.

Eventually I'll write up a proper HOWTO on this (most of those I found on the 'net are missing some details). Also I'll want to fiddle with some of them get get it running as non-root and put a wrapper around it to automatically restart things on disconnect, etc. But here's some basic notes.

I'm assuming your running Linux ... Debian or Ubuntu. (Should work under any newer distro, and probably is a little easier for RHEL/CentOS or Novell since I think those will have the tunctl command in a different package).

• Create a static high-metric reject route:

  route add -host 172.31.1.2 reject

• Create your master tun device:

  cd /dev/ && MAKEDEV tun; ls -l /dev/net/tun*

• Run the tunctl to set persistence on next available tunnel (tun0 etc).

  tunctl -t tun0 ## -u $SOMEUSER ???

(The tunctl command seems to be available from the uml-utilities package which seems odd since it's used with OpenVPN, Vtun, and now OpenSSH/VPN configurations quite apart from user-mode Linux; also it seems to make "magic" persistent changes and I haven't figured out where this is being stored. I really have to go read the sources)!

• Add PermitTunnel yes or PermitTunnel point-to-point to /etc/ssh/sshd_config

• Create a key pair

  ssh-keygen

• Deploy the public key to the server from the client:

  cat /.../.ssh/id_*.pub | ssh "root@$VPNGATE" 'cat >> /root/.ssh/authorized_keys'

(NOTE: there are details for doing this using a restricted access key, adding said restrictions to the end of the key in the authorized_keys adding sudo NOPASSWD: entries for ifup and ifdown and so on. (see: Shadows of Epiphany for more details).

• Run the following script:

  ssh -f -w0:0 "root@$VPNGATE" 'ifconfig tun0 172.31.1.2 pointopoint 172.31.1.1 mtu 536 up'

  ifconfig tun0 172.31.1.1 pointopoint 172.31.1.2 mtu 536 up

... and you should now have a working VPN tunnel. The ifconfig will create a route with a lower metric so that will work. You can now access any services on $VPNGATE (including its printer, NFS, etc) just is if you were dialed into it over a dedicated PPP modem connection.

Note: to access other systems behind $VPNGATE you'll have to ensure that those systems know about your 172.31.. (VPN) routes (at least their default routers should have static routes pointing to $VPNGATE ... for the return trips, of course. Alternatively you could perform NAT on $VPNGATE so that all your remote/laptop traffic "looks like" traffic from $VPNGATE to the rest of your network. Either way, you'll also have to sysctl -w net.ipv4.ip_forward (on $VPNGATE) just as you would for any other sort of routing.

As you can see this is a very rough outline and I have to figure out a few more details for my own usage.

• What exactly is tunctl doing? Where is it storing these settings changes?
• What is the best MTU for these tunnels? (Running a 1500 MTU interface through an encrypted/multiplexed channel that's also running at 1500 MTU just sounds wrong)!
• How should I detect that the link it down and bring it back up? (When should I use tunctl -d or explicitly ifconfig tun0 0.0.0.0 down for example).
• Fussy details about restricting access to non-root users.