Multitunneling Grid Transactions - Lab Report Example

Reading Header: A PERFORMANCE STUDY OF MULTITUNNELING GRID TRANSACTIONS Your institution Your name Course name Course instructor March 15, 2009 An SSH tunnel can be described as an internet pipeline in which data move through. The data can be encrypted to avoid eavesdropping. Apart from this SSH can be used as a tool to connect machines on opposite sites of a firewall(s). The SSH tunnel forwards a TCP port at one end(local) to another TCP port at the other end (remote) through firewall. The following are the situations that this can be important Where one needs to talk directly to a specific TCP port to a machine that is separated by a firewall/gateway if it is possible to SSH into the gateway. Where it is possible to send data to a machine but one wants the data to be encrypted Where 1 and 2 are to be done. First application If we are in a situation in which one is using a machine named mymachine, and there is a program that can send data to a TCP port (say 5900) and another machine (remotemachine). There will be no problem if the two machines can communicate directly, but it will be a different situation if the machine is behind ‘firewall’. In such case the machine (remotemachine) will not be referred to directly and for the outside world the remote machine does not even exist. The communication between the remotemachine and the internet is through firewall. There is a break through when it is possible to SSH into the firewall. In such a case it happen that firewall knows about the remotemachine while mymachine knows about fire wall and so trios can be rigged up (Rob, 2001). The following SSH which is run on my machine will set up the tunnel ssh-N-L 33642: remotemachine: 5900 user@firewall Then these can telnet to remotemachine port 5900 by running the command on mymachine telnet localhost 33642 The main piece is “ssh user@firewall”- and literally this SSHing into the firewall. When a password is asked for, the one for the account on the firewall should be given. The N is not that important as its purpose is simply for keeping the pipe open. The RELAY part is the piece“-L33642:remotemachine:5900”. This alerts SSH that there is interest OPEN UP A SHELL on a firewall, but it is being used just as a relay. It should be noted that the remotemachine must be addressable from outside as the only necessity is for the firewall to know how to find it. The “L” commands SSH to listen to port 33642 which is on “mymachine” and the listening is done locally and any data received is redirected THROUGH firewall and on to port 5900 on “remotemachine”. From this it can be seen that telnet’ing to 33642 (localhost) is like telnet’ing to 5900(“remotemachine”) Things that can be noted: The port 33642 is randomly chosen. Any free port on “mymachine” can be used. The session is only encrypted between “mymachine” and firewall but between firewall and “remotemachine” the data is sent IN THE CLEAR though there is away to fix this as seen later. It is possible to chain up SSH tunnels so that they go through MULTIPLE gateways if necessary. There is a “-R” switch which does the OPPOSITE of capturing traffic on the remote side and forwarding it to the local machine (Rob, 2001). After knowing how to go through one firewall, it is possible to learn that SSH tunnels can be chained up to enable one to punch through multiple firewall levels. Let’s take an example of implementing the following diagram Mymachine----> Afirewall----> Bfirewall--> remotemachine As long as one has SSH accounts on both firewall. This can be very easy provided one has SSH accounts on both the firewalls (O’Reilly, 2003). The data will be encrypted all through EXCEPT at the last level between “Bfirewall” and “remotemachine”. This can be remedied in the following manner: SSH into “Afirewall” by logging in to a shell and run “netstat” in order to find a port in this example 4652. The last “hop” is set while logged in “Afirewall” ssh-N-L 4652:remotemachine:5900user@Bfirewall The command will pick up the port 4652 on “Afirewall” and it will be forwarded to THROUGH “Bfirewall” to its final destination at “remotemachine” port 5900 The next thing is to execute on “mymachine” the following ssh-N-L 33642: localhost:4652user@Afirewall this command will open up a tunnel from port 33642 on “mymachine” and this will be forwarded THROUGH “Afirewall” to ITSELF on port 4652 (it should be remembered that when –L is being used the machine name that appears within : : will be resolved from the point-of-view of “Afirewall”, which means localhost is ITSELF) A number of firewalls can be gone through by the above way i.e. SSH is run between each firewall IN TURN, the forwarding always being relayed to firewall ITSELF with the exception of the last “hop” (O’Reilly, 2003). Session encryption using an SSH The punching through firewalls is not the only usefulness of SSH tunnels, as this can be useful in encryption of channels from source to destination. Suppose it is possible to talk to the “remotemachine” directly, then you can directly telnet remote machine 5900 But this might not be the best way as the data will go over the internet in the open. There is a good way provided one has the ability to SSH in “remotemachine”. If this is the case the following commands, run on “mymachine”, can be considered ssh-N-L 33642:localhost:5900user@remotemachine telnet localhost 33642 The initial command gives an encrypted pipe which is from “mymachine” to “remotemachine” which forwards data to ITSELF. The second command is for opening up a telnet session on “mymachine” to port 33642. The session will be FORWARDED over the pipe to “remotemachine” that in turn forwards the session to ITSELF on port 5900. This ensures that the data is not running around in the open. The login information for “remotemachine”should be given when SSH asks for login. This technique can be combined while punching through firewalls. The strategy here is following the forwarding technique through multiple firewalls (multiple tunnels)as above, but at the last firewall “wimp out” is avoided and instead the “hop” option taken. The “forwarding to itself” method is used at EVERY step. This will however require one more step to the “remotemachine” The first thing is to get SSH shell session for each firewall, including the last one, going. This can be done by successively SSHing through each firewall. A free port is found for each port. Using an example of 4 firewalls (4 tunnels), with the free ports being 4651, 4652, 4653, and 4654 for each firewall. Let’s consider the following sequence a) On “Dfirewall” run: ssh-N-L 4654:localhost:5900user@remotemachine This will set up the security between “Dfirewall” and “remotemachine”-this used the technique that was described previously and there is no time the data is out in open b) On “Cfirewall” run ssh-N-L 4652:localhost4653 user@Dfirewall c) On “Bfirewall”run: ssh-N-L 4652: localhost: 4653 user@Cfirewall On “Afirewall” run: ssh-N-L 4651: localhost: 4652 user@Bfirewall d) On “mymachine” run: ssh-N-L 33642: localhost: 4651 user@Afirewall Now it is possible to telnet into “remotemachine” on “mymachine” using the command telnet localhost 33642 Double bagging There is a point of weakness in all the above if there is no total trust for the firewalls. This can result into a situation where a user on any firewall can sniff the traffic and even modify it. This issue is brought about by the fact that as data comes into the firewall it is decrypted, then sent to the appropriate port to be picked up with another copy of SSH. The data is encrypted and sent to the next firewall. The best solution is running SSH tunnel INSIDE the SSH tunnel. But this calls for use of an extra port on the local machine (Frank W). Using our previous example of four firewalls the following can be executed a) On “Dfirewall” run ssh –N-L 4654:localhost:22user@remotemachine It can be noted that the main difference in this case as compared to the previous example is that the forwarding is to port 22 (the SSH port) instead of the final destination port which is 5900. b) On “Cfirewall” run: ssh-N-L 4653: localhost: 4654 user@Dfirewall c) On “Bfirewall”run: ssh-N-L 4652: localhost: 4653 user@Bfirewall d) On “Afirewall” run ssh-N-L 4651: localhost: 4652 user@Bfirewall e) On “mymachine” run: ssh-N-L 43642:localhost:4651user@Afirewall Now we have an SSH tunnel which is from port 43642 to SSH server which is listening on port 22 which is on “remotemachine” When it comes to setting up the tunnel within the tunnel the following command can be executed ssh-p43642-N-L 33642: localhost: 5900-o HostKeyAlias= “remotemachine”localhost This will set up the tunnel from port 33642 on “mymachine” to port 5900 on “remotemachine” inside the previous tunnel which had been established from port 43642 on “mymachine” to port 22 on “remotemachine” Now it has been possible to connect one port which has one server, through multi tunnels (4 tunnels), to another port with a single server on the “remotemachine”. The “remotemachine” is connected to other machines which makes it part of a grid system. It is possible for somebody using my machine to access all the possible (some might be protected) information in the grid system through “remotemachine”. The beauty part of it is that “mymachine” is protected against any form of sniffing from other users. Thus it is possible to make a Multitunnel grid transaction on “mymachine” Where R switch is very important Suppose we did not have an SSH account on the firewall it could be a different scenario. We still have an interest to forward port 33642 on “mymachine” to port 5900 on “remotemachine”. This is being dealt with because “remotemachine” is hidden behind a firewall. However “mymachine” is not and can be assumed to be public. This means that “remotemachine” can actually see “mymachine” but not the other way round. If it is possible to have a physical access to “remotemachine” the following can be run on it ssh-N-R 33642: localhost: 5900 “mymachine” Which sets up a tunnel which forward all data from the REMOTE port (for this case “mymachine” port 33642) to port 5900 on localhost (which is “remotemachine”). After running this one can set up any program in order to listen to port 5900 and go “home” At home on “mymachine” it is easy to telnet into “remotemachine” port 5900 as follow telnet localhost 33642 References Episode discussion (17, Dec. 2008). Setup an SSH SOCKS proxy! Retrieved March 14, 2009 from http://revision3.com/hak5/SSHGamesBlogsPasswords/ Frank W. Quick-Tip: Reusing Open SSH connections to the same host. Retrieved March 14, 2009 from http://www.revsys.com/writings/quicktips/ssh-faster-connections.html Linode.com Forum, Linode Community Forums. (Feb 2009)Multiple SSH Tunnel Access .Retrieved March 14, 2009 from http://www.linode.com/forums/archive/o_t/t_3910/multiple_ssh_tunnel_access.html O’Reilly Network. (Feb.23, 2001) Using SSH Tunneling. Retrieved March 14, 2009 from http://www.terrencemiao.com/Webmail/msg00446.html Rob, F. (02/23/2001) Using SSH Tunneling .Retrieved March 14, 2009 from http://www.oreillynet.com/pub/a/wireless/2001/02/23/wep.html Spencer, S. SSH Tunneling (TCP port forwarding). Retrieved March 14, 2009 from http://www.spencerstirling.com/computergeek/sshtunnel.html Ubuntu Forums. (4/21/2008.) SSH tunnel through multiple hosts. Retrieved March 14, 2009 from http://ubuntuforums.org/archive/index.php/t-446659.html Peter K. Kaiser, Dougal R. McCreath (1992) Rock support in mining and underground construction: proceedings of the International Symposium on Rock Support, Sudbury. Canada: Taylor & Francis Sławomir T. (2001).Thin film magnetoresistive sensors London: CRC Press University of Michigan. (1975) Wireless world New York: IPC Business Press Read More