Setting up secure self-check connections using SIP tunneled through SSH

Posted on Fri 16 April 2010 in Libraries

Updated 2010-04-27: Fix corrupted characters introduced by copying from my GroupWise client. Thanks to Joe Atzberger for pointing that out.

I set up a secure SIP connection from our self-check machine to our Evergreen server located about 450km away, and thought I would put together a quick blog post on how things are working in production with SIP in Conifer. It seems a lot of sites run SIP without a secured connection, based on how our self-check sales rep and technical support person talked to me on the phone as though they were talking to someone with two heads when I mentioned my concerns about security - and they had no advice to offer on setting up an encrypted connection. So I guess the subject doesn't come up too often.

That doesn't excuse us as proper systems librarians from protecting as much patron information from exposure as possible. So here's how we do things at Laurentian University - some hostnames / IP addresses changed to protect the innocent:

  1. The SIP server runs on one of our Evergreen server boxes; let's call it carbon.example.com. carbon itself has no direct access to or from the Internet.

  2. carbon has been set up with an iptables rule allowing access via port 6001 from starburst.example.com. starburst lives out in the demilitarized zone of our ISP.

  3. starburst has been set up to allow access via port 22 from two specific addresses at our library - no VPN connection required. We're keeping this as locked down as possible, hence the source IP address restriction. We opted for no VPN connection because most VPN clients require manual steps to authenticate, and we need the self-check to make the connection automatically when it boots up. Don't worry, we'll get to the encryption part.

  4. From the self-check machine, we set up port-forwarding of carbon:6001 to localhost:6001 via the sipuser user on starburst. I have set up a hostname called "sip.example.com" that points at starburst.example.com; our ISP sysadmin has added a local user on starburst named "sipuser". We have then set up the SSH authorized_keys file so that SSH logins can't actually log in, and in fact the only thing they can do is forward port 6001 on carbon.

    In /home/sipuser/.ssh/authorized_keys, each entry should therefore begin with:

    command="/bin/false",no-port-forwarding,no-agent-forwarding,permitopen="carbon:6001" <key-type> <key> <name>

    1. On the self-check machine, I used ssh-keygen to generate an SSH key and then appended the public key to /home/sipuser/.ssh/authorized_keys on starburst to enable logins without using the UNIX password.

    2. On the self-check machine, the SSH command looks like:

      ssh -f -N -L 6001:carbon.example.com:6001 sipuser@sip.example.com

    3. Our self-check machine is running Windows Vista inside, so I've actually implemented it using Cygwin's "run" command in a shortcut and dropped it into the user's Start folder so that it automatically sets up the connection at startup time. The shortcut command is:

      C:\cygwin\bin\run.exe -p /bin ssh -f -N -L 6001:carbon.example.com:6001 sipuser@sip.example.com

  5. We're using SIP2 over raw sockets to communicate. We found that we had to supply the SIP username and password in the 3M self-check software. Apparently authentication is unnecessary for Unicorn's SIP implementation, and also apparently no library has ever been concerned about SIP2 being a clear-text protocol before!

  6. And all of that has worked exactly once so far, starting from a cold boot. I'm going to be giving it a bunch of tests tomorrow, but I'm very excited to have an end-to-end encrypted connection working out of the box.

Well - that was the substance of the email I wrote four months ago. Since then, the self-check has been turned off every night and has connected flawlessly every morning - with the exception of one weekend when we brought down Evergreen for system maintenance and someone *cough our vendor cough* forgot to start the SIP server again. I'm happy with the results, and it's really not that complicated. If your library uses self-check machines and runs SIP over the network in clear-text, isn't it time your library beefed up its security?

Evergreen