Getting In

Getting In

Step 1: Find a Server Outside

In order to open a path in through a firewall, you still need an SSH server on the outside.

Step 2: Check the Server Configuration

The server must be configured to allow port forwarding. If you intend to open an insecure (that is, "nonencrypted") service, then I strongly recommend that you limit access to the SSH server box itself by setting the server GatewayPorts option to "off." If you don't, you are effectively exposing the service to the entire Internet. This totally defeats the purpose of the firewall. Your network manager would almost certainly not approve.

Step 3: Check the Client Configuration

We are going to assume you are talking to the same server as in the " Getting Out " example. At this point, your client-side configuration file looks like this:

 Host frosting.bakery.org 
 Port 22 # This isn't really needed, 22 is the default 
 LocalForward 15143 localhost:143 
 LocalForward 15025 localhost:25 
 LocalForward 15080 corporatesecrets.bodyshop.com:80 

Step 4: Make the Connection from the Inside

To open the inbound door, we have to do another port forward. This one is a bit different. Let's assume that what you want to do is to be able to log in to a Unix box called netteam.somesuch.com . They are so confident in their firewall and they trust their employees so much that they use just Telnet. They aren't using SSH themselves .

The Telnet protocol uses port 23. Here's what you might add to allow yourself to Telnet in securely from home:

 Host frosting.bakery.org 
 Port 22 # This isn't really needed, 22 is the default 
 LocalForward 15143 localhost:143 
 LocalForward 15025 localhost:25 
 LocalForward 15080 corporatesecrets.bodyshop.com:80 
  RemoteForward 7023 netteam.somesuch.com:23  

What this does is to make SSH on the server side set up a listener on port 7023. When you connect to port 7023 on frosting.bakery.org , you are actually carried through the encrypted connection to the client side, where the box running the client will connect to port 23 on netteam.somesuch.com . Note that this means you must SSH to frosting.bakery.org before you leave work in order for the connection to be up.

Step 5: Make the Connection from the Outside

Here's what you would do when you are logged in to frosting.bakery.org from home and you want to connect to work:

  $ telnet localhost 7023  
  Trying 127.0.0.1...  
  Connected to localhost  
  Escape character is '^]'.  
  Welcome to SuSE Linux 6.4 (i386) - Kernel 2.2.14 (1).  
  netteam login:  

That's all there is to it! So long as you have limited connections by setting GatewayPorts to "no," you are just as secure as always ( assuming you can be trsuted to keep your home machine secure, which may be a big assumption) because everything you type or display actually travels on the pre-existing SSH connection you made from inside the firewall. It is all encrypted.

The Only Tunnel You Will Ever Need

In the preceding example we showed you how to "export" an internal port to the outside world. We also told you to limit connections on the exported service to the SSH server box so you would not expose any traffic to prying eyes. Well, there is a way to export a service that you can safely access from anywhere , a service that will allow you to connect to anything on the inside, whether or not you exported it from the inside!

If it hasn't already occurred to you, I am talking about forwarding an OpenSSH server you have on the inside of the firewall to the outside! This may seem goofy, but it works. With this, you export an SSH server to a port on frosting. You can then SSH from any box on the Internet to the forwarded SSH port on frosting. You are authenticating not to the SSH server on frosting, but rather to the SSH server inside the firewall. You can, on your client machine, specify any LocalForward or RemoteForward connections you wish and you can reach anything at all inside or outside. Not only that, but the links are totally secure, because everything is encrypted end to end, with a little bit of double encryption as things pass through the forwarded and encrypted SSH connection.

Personally, this is the only " Getting In " that I do. It is the only way to have absolutely everything encrypted and the only way to make the machine inside the firewall authenticate everything and everybody. When you RemoteForward other ports, you are in essence trusting that the machine outside is properly authenticating. When you remote forward SSH, you are merely giving outsiders a chance to authenticate to the SSH server properly configured and ensconsed inside the firewall. This is a very powerful and secure way to enable remote access over untrusted networks.

 



Multitool Linux. Practical Uses for Open Source Software
Multitool Linux: Practical Uses for Open Source Software
ISBN: 0201734206
EAN: 2147483647
Year: 2002
Pages: 257

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net