Saturday, August 22, 2009

HowTo stunnel

I ran into a problem that I thought stunnel might be the solution, but found Fedora's stunnel RPM to be in complete. First it has no init script and second it's documentation is lacking. Further the same problems exist with the stunnel.org code (which I couldn't get to compile!) I'm sure there is more than two problems, but...

Over at Gaztronics.net, there is a working init script. Grab it and save it to /etc/init.d. Next we need an stunnel.conf (also not included, though there is an example... which won't work.) I found a good set of example files over at Edna Narrabilis' Blog. These may need a few tweaks, but since I'm working on an remote mySql issue, these are good.

Notice in Edna's configs, there are really only two differences between the client and the server. First, not the client=yes directive: just to be safe, add client=no to the server side. Second, notice the client's connect line includes the server's name. Drop her configs on each sides /etc/stunnel directory.

Now that we've got the Fedora RPM, Gaztronics init.d, and Edna's configs, we need an SSL certificate. When you generate the certs on both sides, it is important that for Common Name, you use the fully qualified, DNS resolvable, name for each machine.

As I mentioned, I made a few tweaks. For instance, I moved the PID out of /tmp. I also forced a few other options. Just for good measure, do this first:
mkdir /opt/stunnel
chown nobody /opt/stunnel
chmod 700 /opt/stunnel


Server
syslog=yes
debug=7
output=/opt/stunnel/stunnel.log  
cert=/etc/stunnel/stunnel.pem
pid=/opt/stunnel/stunnel.pid
foreground=no
setuid=nobody
setgid=nobody
client=no
[mysql-svr]
accept=6639
connect=3306
Client
syslog=yes
debug=7
output=/opt/stunnel/stunnel.log
cert=/etc/stunnel/stunnel.pem
pid=/opt/stunnel/stunnel.pid
foreground=no
setuid=nobody
setgid=nobody
client=yes
[mysql-client]
accept=localhost:6639
connect=fqdn.target.tld:6639

One thing to notice: we are flipping the port as they go across the network from 3306 to 6639. This way we can use iptables to block 3306 as adefense against automated SQL injection attacks. I found that If I tried to do the client accept at 3306, it didn't work, but I think that's a mySql thing.

No comments:

Post a Comment