Posts Tagged ‘ security

Securing Synergy

At work, I have several computers on my desk, but I prefer to only use one mouse and keyboard to control all of them. To accomplish this, I use Synergy. The more recent versions of Synergy come with the ability to perform encryption on the connections through Synergy itself, but I did not feel it adequate enough or easy enough to use for my needs. Instead, I run Synergy on my machine which has the keyboard and mouse attached to it, then on my client machines, I tunnel the remote server’s synergy port to the local machine, and connect locally, This tunnels all Synergy traffic through SSH transparently, and is extremely secure. I like this level of security because often times, I am typing personal, sensitive, or confidential information on one of the client machines using the server’s keyboard.

In my setup, cota.austin.ibm.com is the Synergy server. All SSH is done through public key encryption to make the connection painless.
Here is the script I use:

#!/bin/bash -x

function clean()
{
    for job in `ps -eo pid,args | grep ssh | grep 24800 | grep -v grep | awk '{print $1}'`
    do
        kill -9 $job
    done
}

trap clean SIGINT

ssh -f -N -L localhost:24800:cota.austin.ibm.com:24800 cemeyer@cota.austin.ibm.com
synergyc -f localhost
clean

I hope this helps someone else looking for an easy way to secure down Synergy.

Patching Seaside for deployment

I’m currently in the process of deploying a Seaside application on my server at the University, and I noticed something that I needed to fix before I went any further. By default, the server adapters that ship with Seaside will listen on all interfaces for connections. Since I plan on proxying my Pharo image behind an Apache server, with Apache doing all of the authentication, I did not want my Seaside server to be accessible to outside clients on the port its listening on. This would allow them to bypass my authentication mechanisms I have in place.

I dug through the Seaside code a bit and found what I needed to patch. Note here, I only am patching the WAListenerAdaptor since that is the adaptor which supports Comet (which my application makes heavy use of).

Here is the original code:

WAListenerAdaptor>>listenLoop
	| socket |
	socket := Socket newTCP.
	socket 
		listenOn: port
		backlogSize: 50.
	socket isValid ifFalse: [ self error: 'Cannot listen on port ' , port greaseString ].
	
	[ 
	[ socket isValid ifFalse: [ ^ self listenLoop ].
	self waitForConnection: socket ] repeat ] ifCurtailed: 
		[ (Delay forMilliseconds: 10) wait.
		socket destroy ]

And the patched code:

WAListenerAdaptor>>listenLoop
	| socket |
	socket := Socket newTCP.
	socket 
		listenOn: port
		backlogSize: 50
		interface: NetNameResolver loopBackAddress.
	socket isValid ifFalse: [ self error: 'Cannot listen on port ' , port greaseString ].
	
	[ 
	[ socket isValid ifFalse: [ ^ self listenLoop ].
	self waitForConnection: socket ] repeat ] ifCurtailed: 
		[ (Delay forMilliseconds: 10) wait.
		socket destroy ]

Notice how I changed the socket initialization message to include the interface keyword, and supplied it with the loop back address. Now my application is only accessible via 127.0.0.1 or localhost, and not via its external IP.

The alternative would have been to leave the code unpatched and instead write some iptables firewall rules to block on the port the Seaside adaptor is listening on, but this seemed like a simpler solution and allows me to leave the rest of my system untouched. Also, this solution is the only possible way to do it if you do not have root access to the machine to add iptables rules.