Trinity Remote Support Pack 2.0 for Windows

Quickstart

-Download clients here
-Passwords needed for downloadable TRSP clients:
*password VNC: remote4u
*demo account on host remote.trinityhome.org will use rsa key, so no login data required
-trsrun-2_0-nq-demo.exe does not ask the user for confirmation to allow remote control!
-Publicly open ports on remote.trinityhome.org range from 6000 to 16500, all else is blocked
-Demo user needs to tell the port he connected to.

What is it?

The Trinity Remote Support Pack version 2 (TRSP) for Windows is a set of existing free tools put together in a package with some simple scripts. The purpose of it is to enable an administrator to take remote control of a distant user 's computer, even though that computer is on the Internet behind a firewall, without the need to modify anything in the firewall. The manipulations a user has to perform are very simple: download, execute and report the assigned tunneled portnumber *. Et voilà: you can access the computer in few seconds.

*Only in the demo account. Full, paying accounts can get the ports themselves by opening a session on the administrator's side. So the user can just lay back and watch his computer get repaired.

How is it done?

Well, as I said, TRSP for Windows is a set of existing tools and some simple scripts. The tool to get a remote desktop is the well known UltraVNC. More on that later.
The nifty part of TRSP is done by a very good secure shell (ssh) client, namely putty. The ssh protocol has a feature called reverse ssh-tunnel. I will try to explain this as simple as possible by an example:
A client computer runs putty and connects to a machine running a ssh server somewhere on the Internet. We 'll call this the machine-in-the-middle or MITM
The client autologs in with a valid username and rsa key. The username and rsa key are hardcoded in each TRSP package.
His ssh session opens up a random listening port on the machine-in-the-middle (f.i. port 11473). This listening port runs through the existing connection as a tunnel back to the user's computer to the port where his VNC server is listening on, in most cases port 5900.
Now the administrator fires up his VNC viewer and connects to the machine-in-the-middle to port 11473.
This connection gets patched through to the user in distress.
His VNC server responds with a challenge that asks the user to allow the incoming connection.
After the user clicks yes, the administrator will be prompted for the password and...
...he 's in.
Now, TRSP just puts this in a self-extracting, self executing package that does most of these steps automatically.
The default password for VNC included in TRSP is "remote4u"

Here 's a kiddie diagram (TRSP version 1, but the principle is the same, only port 6000 is now a random port), drawn in plain old Paint (I 'm not a Visio wizz) that should make a little more clearer. The example works with a user running VNC server, listening on his local machine on port 5900. He connects to the machine-in-the-middle with ssh. This ssh session opens a listening port on the machine-in-the-middle at port 6000. Vnc traffic is in red, ssh traffic in green.

Subversions

Basically, there are 3 subversions of TRSP.

One that installs itself, TRS Pack (trspack-2_0-demo.exe) and stays on the computer. This installs UltraVNC (kills any existing versions of winvnc and installs VNC server and client). It copies putty.exe, nc.exe, an rsa key and the scripts that automate the connection to your alluserfolder\trinity (on XP: C:\Documents and Settings\Trinity, on Vista C:\Programdata\Trinity) + an icon to your desktop to start TRSP afterwards. This version is also intesting for an administrator, since the VNC version is besides the server also the viewer. The admin is free to install any vnc viewer he likes of course.

The other version TRS Run (trsrun-2_0-demo.exe) gets run in the user's temp folder and deleted on exit. Furthermore, this version does not require any administrative rights on the client side. Very handy when dealing with corporate remote users that are not admin on their computer.

The third version is TRS Run-no-query (trsrun-2_0-nq-demo.exe). It 's the same as the previous one, but there is no prompt for the user when an administrator tries to connect to a PC. The admin only has to enter the password. This is for users that just do no get it! Since portnumbers are random and the firewall prohibits port sniffing, finding out what port the session listens to should be really hard. I guess it 's ok to use this version with people that trust you. Nevertheless, nothing is impossible and I might have missed some security issue.

I wanna make use of it with an unlimited account

Well, you can get your account here. The fee is 10€ for setting up an account and 3€ for a 1 month subscription. If you take an account for a whole year, you can get it for (10€ setup) + 30 €.

Contact us, make a donation and we 'll create you your own custom TRSP's with your own download page and a simple hostname alias you can communicate to your users (e.g. helpme.trinityhome.org). The only thing we ask of you is fair use. You tell us how frequently you think you 're going to use it and don 't eat up the poor 512kbit bandwidth of this server by doing big file transfers over VNC. 512kbit is far more than enough for a VNC remote desktop. If the service would become too popular, it will move to a higher bandwidth line.

Be aware that anyone you share your tool with (that you provide the custom VNC password) is able to take over your user's computer because he will see all open ports related to your user. Make sure you can trust these people.

Do it yourself (SDK)

There 's also a TRSP SDK: you can customize your own TRSP, so you can run it on your own server.
First install 7-zip, included in the SDK or get the latest version at www.7-zip.org.

-Basically what you need to do is to run putty, clear the current settings and/or add your own for your ssh server. After that you export the registry key [HKEY_CURRENT_USER\Software\SimonTatham] to puttysettings.reg and copy it to yoursdkfolder\admin and yoursdkfolder\nonadmin.

-Next, go and change the session name you gave in putty so that it reflects in trinisup.cmd (admin version) and setup.cmd (non-admin version)

-Generate an rsa keypair with puttygen or import a private one you created on your server which is linked to your user. Put this key called id_rsa.ppk in the Admin2, Non-admin2 and Non-admin2-nq folders. Paste the public key in authorized_keys on the MITM in the user 's home/.ssh folder.

-Once customized, execute newpack-admin2.cmd, newpack-nonadmin2.cmd and newpack-nonadmin2-nq.cmd to respectively create the installable, administrative rights required version and the runtime, non-admin versions. Be sure to mention the username you 're going to use.

-Publish it on your own website and direct users who need your remote control to your site to have them download your custom TRSP.
Be sure to change the VNC password and copy ultravnc.ini to their respective locations on the SDK.

Download trinity_remote_support_SDK_2_0.exe

What you need on the server side (MITM)

Well, you need the machine-in-the-middle and that requires a publicly available ssh server (ssh version 2) with a basic user account. For ease of use, have it run with the option Gatewayports On. This allows to have administrators connect remote directly instead of needing to set up a reverse-ssh session to the machine on their own. Also the ssh daemon listens on port 443. This is a port that is most generally allowed outgoing by pretty strict corporate or public firewalls (webservers on https run on it)
If you don 't have such a machine (an old pc with Linux on your own home connection with a dyndns name would do already), you can get an account with us, for a small donation of course. The fee is 10€ for setting up an account and 3€/month subscription. If you take an account for a whole year, you can get it for (10€ setup) + 30 €.
You would receive your own username that you would provide to your users for setting up remote ports. This user does not get a shell, just a login with a display message.
You can always try with the demo account. This session is time limited for 120 seconds. After that, the session kills itself and you are disconnected. This demo is intended as a proof of concept. If you 're a really fast admin, you could get some things done, but 2 minutes is not much. The port assigned for this session is mentionned to the user in distress, which has to communicate it.

The machine-in-the-middle where it runs on is secured with a few measures that should make it hard on hackers trying to sneak in on your listening vnc users. I recommend people wanting to set one up for themselves to follow these guidelines. People with better propositions are welcome to let us know.
-First of all, the machine runs on VMWare, so it 's not a real machine.

It gets a regular snapshot so that in the event of a successful break in, we could revert to the snapshot and try to figure out how they got in without any damage.

-The machine only runs ssh and a random port generating service on port 80 (most of the time open in public LANs). Nothing else. No webserver, no ftp, no rsync, nada.

-No real shell accounts allowed. I don 't want to become a nanny and manage users that abuse their shell access to perform hacking and cracking of any sort. Your account will get a welcome message and that 's it.

-As tight as possible firewall rules. See below how the rules are set up together with their self explanatory comments.

-Private user accounts can get a secured admin port that is only accessible for admins from 1 or more source IP addresses. Dynamic dns names are also allowed, the rules get refreshed hourly and the source ips get updated.

-If you want to create your own machine-in-the-middle (MITM), you could deactivate the GatewayPorts in the sshd_config and connect yourself over a secured channel with your ssh client to the MITM. In this case I didn 't do it because it complicates things and it would not secure you more (since the demo account would be able to access the ports too via ssh.

-Also for your own MITM: tighten your firewall rules to allow only a few source IPs + your local LAN f.i.

-On the MITM side there are some more things to modify.
In the SDK you find the folder server. Copy trspsrv2 to a location in your path on your server (e.g. /usr/local/sbin). Add these lines to one of your startup scripts, e.g. /etc/init.d/local:

echo "TRSP service started at `date`" >>/var/log/trspsrv
nohup trspsrv2 >>/var/log/trspsrv &

-Recommended also is to modify your user's shell to a dummy shell. The dummy shell is also included in the folder rwelcome and is called "rwelcome". Put it f.i. in /usr/local/bin, add /usr/local/bin/rwelcome to /etc/shells and modify the user in /etc/passwd where it says /bin/bash to /usr/local/bin/rwelcome

Again, also make sure to run a tight firewall. Firewall rules are below.

Firewall rules for machine-in-the-middle remote.trinityhome.org

#!/bin/bash
#set -x
iptables -F
iptables -F SSH_RECENT
iptables -F ALLTCP_RECENT
iptables -X SSH_RECENT
iptables -X ALLTCP_RECENT

# Always allow traffic on loopback address
iptables -A OUTPUT -d localhost -j ACCEPT
iptables -A INPUT -d localhost -j ACCEPT

# Don 't allow outgoing connections
test r$1 != r-o && iptables -A OUTPUT -m state --state NEW,INVALID -j DROP
# Allow established connections for ssh to burst
iptables -A INPUT -m tcp -p tcp --dport 443 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow a limit of 3 new connections per minute on ssh
iptables -N SSH_RECENT
iptables -A INPUT -m state --state NEW -p tcp --dport 443 -j SSH_RECENT
iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j SSH_RECENT
iptables -A SSH_RECENT -m recent --set --name SSH
iptables -A SSH_RECENT -m recent --update --seconds 60 --hitcount 3 --name SSH -j DROP
# Drop new ssh connections if limit is reached
# Allow a limit of 10 new connections per minute on any other port
iptables -N ALLTCP_RECENT
iptables -A INPUT -m state --state NEW -p tcp -j ALLTCP_RECENT
iptables -A ALLTCP_RECENT -m recent --set --name TCPALL
iptables -A ALLTCP_RECENT -m recent --update --seconds 60 --hitcount 10 --name TCPALL -j DROP
#Allow public ports and 443 where ssh runs on, drop all others
iptables -A INPUT -m state --state NEW -p tcp --dport 6000:16500 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp -j DROP