DALnetizen - robsd.ws: stunnel+services HOWTO

Securing NON-SSL aware Network Daemons using OpenSSL and Stunnel.
Overview:

This article will attempt to provide a quick and painless approach to adding SSL awarness to network services whos code does not provide for encrypting traffic to and from a server and client. I will use VNC and telnet as examples in this article as they both transmit passwords and traffic across a network in plaintext format. However, stunnel and openssl can be used to " wrap " any service you choose to run without re-compiling the service. Many reading this will quickly point out that SSH port forwarding already has the ability to provide a encrypted tunnel between a client and server and thats true. But, SSH port forwarding DEMANDS that you have a shell account on the server to forward the port. Many Administrators simply dont like providing shell access to just anyone. I know, I know... with VNC, the user can simply open a xterm to gain a shell, but we will deal with that.

Lets start with a VNC process on a UNIX server...

You basically have two choices with VNC, Cambride University VNC that is the original VNC, or tightvnc which is an enhanced version of the original and has many more features, especially in the area of speed. You can download windows binaries or UNIX source from both websites. FreeBSD has both implementations of VNC in the ports collection as of FreeBSD 4.6 Happy Installing! :)

Obtaining Stunnel

Stunnel can be obtained from stunnel.org both in windows binary format and UNIX source. FreeBSD also provides this in its port collection. Stunnel will be used in conjunction with OpenSSL to provide a encrypted tunnel between a host and server. Happy Installing! :)

Lets not forget good ole OpenSSL

Mosy likely, if you are using FreeBSD or Linux, you already have OpenSSL installed. Simply typing ' openssl version ' should spit out which version of OpenSSL you are running. If you dont have OpenSSL installed, you can obtain it from the openssl.org website Or, if you are running FreeBSD, you can install openssl from the ports collection. Please make sure you are running, or installing OpenSSL version 0.9.6e as anything <= 0.9.6d has a security issue.
Windows DOES NOT have OpenSSL installed by default. If you want to be able to connect from a windows box to a UNIX box, you will have to compile OpenSSL using a UNIX openssl source package and a compiler such as ming32. But, if you have a friend running OpenSSL on windows, all you need is the files libssl32.dll and libeay32.dll in c:\windows\system to do the tunneling in windows. This however will NOT give you total OpenSSL functionality.
I will provide these two files that were built by a friend using OpenSSL 0.9.6e on windows. I will NOT however be responsible if you use these files and you break windows. I know they do not contain a backdoor, or virii, but you dont know me either, and common sence says you dont use a binary someone from the net just gave you either. Use AT YOUR OWN RISK

libeay32.dll
libssl32.dll

Again, place the 2 files in c:\windows\system

Starting a Xvnc process

This is as simple as typing in a UNIX shell: vncserver :1

You can add more options to vncserver by reading ' man vncserver '

After starting the process, you will be presented with an ability to set a password, after which, you will have a Xvnc process running on DISPLAY 1

While this article does not go into setting up VNC, I would like to point out that you stop a user from opening a xterm or running commands simply by removing the the options to open those apps on your window manager.

For example, if you want your users ( and I recommend installing Fluxbox because it is a very simple, very small window manager that has a very small memory footprint which is good if you will be providing remote desktops to more than one person ) not to be able to run a xterm in Fluxbox, you can remove " [exec] (xterm) {xterm.....} " from their ~/.fluxbox/menu file, as well as any other applications that allow you to run a process from the application. Again, common sence says choose who you allow access to wisely. To make fluxbox the default window manager in VNC, simple add:

#!/bin/sh
fluxbox

to the users ~/.vnc/xstartup file.

If you want a Xvnc process to run for a particular user, say ' betty ', if the machine is rebooted, simple make a shell script that runs ' su - betty -c '/path/to/your/vncserver :1' in your start-up scripts.

OK, lets run stunnel

1. On the server running VNC, create the file ' /var/log/stunnel.log '

2. When you installed stunnel, you were prompted to create a stunnel.pem file which is the certificate the server will present to the client. Go ahead and let the installation make stunnel.pem and note where it puts it. However, we will be making our own to add some randomness to the encryption in just a bit. If you have never created a certificate, and are unsure what answers need to be answered when making the cert, here is a rough example

Country Name (2 letter code) [PL]: US # for United States
State or Province Name (full name) [Some-State]: North Carolina
Locality Name (eg, city) []: your-city
Organization Name (eg, company) [Stunnel Developers Ltd]: whatever
Organizational Unit Name (eg, section) []: openssl certificate
Common Name (FQDN of your server) [localhost]: your domain name

*** Common Name is important, if you enter www.dog.com and someone connects to dog.com, there are problems. Put what you normally use, either dog.com , or www.dog.com

Please note, that we will be making a self-signed cert that does provide the same encryption ciphers as a signed cert from a CA authority, but it is not telling the client that you are definetly who you are. I recommend reading this to educate yourself on SSL certs.

Lets make stunnel.pem...

3. Make a directory /tmp/stunnel
4. copy 7 large files to /tmp/stunnel/
5. copy stunnel.cnf (use the one provided when you installed stunnel ) to /tmp/stunnel/
6. rename the 7 files as such: file1, file2, file3....file7
7. execute, in /tmp/stunnel/: openssl req -new -x509 -rand file1:file2:file3:file4:file5:file6:file7 -days 1825 -nodes -config stunnel.cnf -out stunnel.pem -keyout stunnel.pem
8. Make the permissions on stunnel.pem 600 , owned by root, group root ( wheel on FreeBSD )
9. replace stunnel.pem that was created during installation with stunnel.pem we just made.
10. Remove /tmp/stunnel

Now lets start the stunnel process...

11. On the server running VNC, execute: stunnel -o /var/log/stunnel.log -N securevnc -d 7777 -r you:5901 -p /path/to/your/stunnel.pem
* replace " you " with your domain name, IP address, or private net IP
* -d 7777 can be any port
* securevnc can be anything

What in the hell did we just do?

Well, VNC runs on port 5901 by default.. and by running the command in (11), we forwarded the non-SSL aware VNC process on 5901 to an SSL-aware process on 7777, applied logging to /var/log/stunnel.log, presented our cert stunnel.pem, and named the tcpwrapper service securevnc

12. Now, edit /etc/hosts.allow, and add securevnc: ALL : allow * If you only want your friend at 66.26.7.34 to be able to connect to the SSL-aware VNC process, do vncsecure: 66.26.7.34 : allow
* However, I find it alot easier to allow ALL, and firewall port 7777.

13. Restart the inetd daemon: killall -HUP inetd
14. If you are running a firewall, or have a router, make sure port 7777 is accessible to TCP/IP traffic and port 5901 is NOT accessible
15. If you need stunnel to run on start-up, simply make a shell script that executes the command in (11) on start-up

Thats it, you now should have a Xvnc process running in a users shell on port 5901. And a stunnel process on 7777 that you can verify with: ps ax |grep stunnel Xvnc

Ok, my fingers hurt, and I need a break. Lets have a beer to celebrate and pilfer thru a website showing one of my next projects while we are doing so.......

Ok, back to work....

OK, lets open this here VNC desktop

As a client, all you need installed is OpenSSL, Stunnel, VNC, you must know your VNC password, and what port the SSL-aware VNC server is running on.

Making the tunnel is as easy as this (UNIX): stunnel -c -d 5901 -r remoteVNCserver:7777 &

Running the Desktop locally is as easy as this: vncviewer localhost:1 0r vncviewer 127.0.0.1:1

Doh! What in the hell did we just do?

Well, remember, the remote server has an SSL aware VNC process running on port 7777... so we connected to it, and asked it to send us a encrypted tunnel on 5901, and we connected to the remote desktop locally on 5901

Making the tunnel on windows is as easy as this: Open a MS-DOS prompt, go to wherever you put stunnel-3.22.exe, and do: stunnel-3.22.exe -c -d 5901 -r remoteVNCserver:7777

You then minimize the DOS window, and start vncviewer and connect to localhost:1

So you dont wanna use VNC eh, and wanna secure telnet?

On the server running telnetd, simply replace 5901 with 23 ( the port telnetd runs on ), start telnetd, replace securevnc with say.. securetelnet ( LOL! ), add securetelnet to /etc/hosts.allow, and restart inetd

Connecting from a client is the same, except you would: telnet 127.0.0.1 7777

See my article on Securing ircd using OpenSSL and stunnel if this interest you.

Good Luck!

©VipOrX 2002