This feature was discontinued in SecurityKISS
Remote control of a computer over the Internet usually makes people think of hackers who take over control of a victim's system in order to perform further mischief. But you can also imagine more lawful applications of remote computer control like:
- work from home remotely on the office computer
- access your home PC when you are on travel
There are many so called 'Remote Desktop' software packages which virtually connect your local screen and keyboard with a distant machine:
- Virtual Network Computing (VNC) - platform independent system with 'multiple clients at the same time' support
- Remote Desktop Services (RDS) - a Microsoft system built-in into all Windows OS since XP
- Apple Remote Desktop (ARD) - a Macintosh application aimed at computer administrators
- Independent Computing Architecture (ICA) - a proprietary protocol designed by Citrix Systems
- X Window System (X11) - a cross-platform protocol originally designed for computer time-sharing
How it works?
The controlling computer (client) displays a copy of the controlled computer's (server) screen. Usually the copy is updated when a change on the server screen happens. Client also transmits its own keyboard and mouse events to the server where actions are implemented. The server then behaves as if the actions were performed locally.
Remote Desktop Access
Very often a remote computer you want to control is located behind a router/firewall isolating corporate or home network from the Internet. Normally such a computer can be addressed only by a local network address like 192.168.xxx.xxx which is not routeable over the Internet. Put another way, you cannot access it from outside.
If the local network is small and if you can configure the router you can set up port forwarding in order to pass connections from the router to single computer in the network for example:
- for Remote Desktop Protocol: port TCP 3389 must be forwarded
- for Apple Remote Desktop: TCP and UDP port 3283; for ARD 2.0 and later, TCP and UDP port 5900; for ARD 3.0 encrypted file transfer TCP port 22
- for VNC: TCP port 5900 is default
Port forwarding is not perfect because one port number can be forwarded only to one computer in the network. Moreover typical home and office networks use dynamic IP allocation (DHCP) what quickly makes the router's forward configuration obsolete.
Remote Desktop and dynamic IP
Remote Desktop access is hampered by DHCP not only within the local network. When Internet Provider uses DHCP to assign public IP addresses to their clients, you can be sure that sooner or later the initial IP address you saved will change. Once it happens you are cut off from the remote machine until you find out the new address. This can be done only with direct access to the remote computer what defeats the purpose of Remote Desktop.
Remote Desktop Security
Most of the Remote Desktop protocols were not designed with security in mind. Those that were, contain serious flaws what disqualify them from unprotected use. For example:
- VNC uses RFB protocol which is not a secure protocol. Although passwords are not sent in plain-text they are vulnerable to dictionary attack.
- Apple Remote Desktop prior to version 3.0 did not encrypt desktop graphics nor file transfers. Apple took a reasonable stance and recommends tunneling ARD.
- The newest versions of Microsoft Windows Remote Desktop use encryption but its implementation is full of fatal errors. Some vulnerabilities like these: 1, 2, 3, 4, 5 have been reported and fixed by Microsoft. Others are more fundamental as described by Massimiliano Montoro in the document Remote Desktop Protocol, the Good the Bad and the Ugly.
Octopus Tunneling solves the issues mentioned above:
- Local network routers/firewalls get irrelevant because the controlled computer does not wait for connection but initiates it.
- Port forwarding is not needed because the controlled computer is accessible directly by its local network address and all its ports are available for the controller.
- DHCP is harmless even after reconnections and network break downs. SecurityKISS Tunnel can auto reconnect without supervision and its local IP is associated with client ID. IP address remains the same per SecurityKISS server/port combination forever.
- Connections are secured with the same high encryption standards as regular SecurityKISS Tunnel.
This section is also available as a separate article
Octopus Tunneling allows forwarding traffic from one tunnel to another.
The tunnels from which data is forwarded may belong to one user (identified by client ID and individual certificate) or to two different users. In order to avoid confusion we are going to call them peers.
Octopus Tunneling is not confined to one-to-one links. You can define as many peers as you want and in this way create a network of trusted devices and users who can see each other as if they are in the same local network. It has the following implications:
Peers can address each other by private IP addresses in the same as computers in your home network. These addresses like 192.168.x.x or 10.10.x.x are non-routeable on the Internet what gives additional confidence that the transferred data will not be compromised
Firewalls and NATs become invisible between peers
Services that require direct IP access like FTP, web servers, games, remote desktop can be set up on one PC and are accessible by other peers
To some extent it is possible to emulate ethernet LAN (however IPX/SPX protocol is not supported)
Needless to say, all data is encrypted and Octopus Tunneling inherits all benefits of regular SecurityKISS Tunnel.
How it works
This solution goes back to the roots and allows configuring the real VPN (Virtual Private Network) for a group of users.
Normally SecurityKISS Tunnel is used to create encrypted one-to-one links between clients and the server. On the server client's IP address is replaced, data is decrypted and sent to destination.
Although very useful it distorts the VPN original idea which is to allow clients safely connect to each other and feel like at home even if they are geographically dispersed.
Since SecurityKISS users generally do not know each other, we can not permit such direct links by default. Instead we authorize individual users to request and approve forwarding between selected clients so that they have full control over who can be linked with them directly via Octopus Tunneling.
In Figure 2 client 1 and client 3 become peers. Both peers must agree on forwarding. Only then the link is created.
Apart from securing the link between two or more peers, Octopus Tunneling has a critical advantage over alternatives. While many ways exist to set up a safe point-to-point connection between nodes with public IP, Octopus Tunneling makes it possible at all if both peers are behind NAT/Firewall.
In Figure 3 direct communiction between peers is not possible because both peers are behind NAT/Firewall
With Octopus Tunneling firewalls are transparent because both underlying connections are initiated from the peers. There is no need to set up port forwarding or configure firewalls in any other way.
SecurityKISS solution is unique because in contrast to others it allows end users to decide who can join their network. SecurityKISS users become administrators of their own Virtual Private Networks.
The administration is straightforward - you only need to request or accept forwarding to a selected client ID on a selected server in the Client Panel.
SecurityKISS customers get access to Client Panel along with the account activation email. Free users need to send an email request with client ID to firstname.lastname@example.org in order to generate password.
Once you can log on to the Panel see Octopus Tunneling Forward Configuration Manual for details.