Getting Out

Getting Out

Here we assume that you are inside a network that is either restrictive or highly monitored or both. Let's assume there are a couple of services you wish to reach outside. The first is your mail server (which you access via IMAP and SMTP), and the second is a Web site you wish to visit without being monitored by your network's transparent proxy. Legitimate reasons to do so abound:

·                 You work for a contracting company and must access company private information while at a client site.

·                 You need to communicate with your physician .

·                 Your immediate supervisor (and local network administrator) is engaged in illegal activity and you wish to report it anonymously to law enforcement authorities.

This last reason may seem unlikely , and indeed it is; but it is certainly not impossible . The first and second reasons are so commonplace that they are scarcely worth pointing out.

Let me take a moment to advise you not to abuse the capabilities we describe here. If an activity is illegal, immoral, or against company policy, the mere fact that you may be able to hide it from your administrators or employers doesn't change the act. If you are thinking, "Aha! This will let me surf dirty picture sites at work!" or "Aha! This will let me run my Internet stock 'Pump and Dump' scheme at work!" then let me warn you that there is more than one way to find you out. Your own computer keeps copies of Web sites you visit. Your history list may be queried when you connect to internal sites.

Step 1: Find Yourself an OpenSSH Server Outside

Before you can get out, you need someone on the outside. You need an account on a box outside the firewall. That box has to be running SSHD (the secure shell daemon), the server for SSH.

Let's assume you have a box on a DSL connection and you are running Linux on that box. Furthermore, let's assume that you have SSHD up and running on that box. The box is called frosting.bakery.org .

From inside you need a Linux box and the OpenSSH client. We will assume that you have connected to "bakery" for logins and file transfers as shown in the previous chapters. This means that you have generated all the keys and that the hosts know one another's public keys already.

Step 2: Check the Server Configuration

Make sure your client location is allowed in (check the AllowHosts and DenyHosts settings). Be sure to set GatewayPorts as appropriate for your security requirements (if forwarding a secured service, go ahead and use GatewayPorts; otherwise say "no.")

Step 3: Check the Client Configuration

Let's assume the client does not have an entry in your .ssh/config file yet. Let's add one:

 Host frosting.bakery.org 
 Port 22 # This isn't really needed, 22 is the default 

There's your base. Now let's get you access to your mail and that Web site you wish to reach unbeknownst to your client.

Step 4: Secure Access to the Server Box

Remember that you want private secure access to your e-mail services from within your client's network. You need to be able to read your mail using IMAP and to send your mail using SMTP. In all of these cases, I am going to assume that you have clients that can be made to use ports other than the defaults. If this is not so, either you may have to jump through some hoops, or you may be out of luck.

First you must select some ports on the client machine to use as "proxies" for the services you wish to receive. I like to pick a "base" port and then use the standard port numbers for services relative to the base. For example, IMAP is port 143 and SMTP is port 25. I would select a "base," like port 15000, and then I would put IMAP at 15143 and SMTP at 15025. If I ever forward any other services I would likewise move them up 15000 ports.

To make this mapping, add the following lines to .ssh/config:

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

Remember, LocalForward is a directive to the client to forward the given port on the client machine to the given address and port from the point of view of the server machine. Thus, localhost means the server machine itself, not the client. Once you connect to the server, these port forwards are active. Now just tell your mail software to use IMAP to pick up messages from localhost (meaning the client) port 15143 and to send mail to localhost port 15025. Although insofar as the mail client is concerned it is connecting to abnormal ports on the local machine, SSH "tunnels" the protcols through to the correct ports on frosting.bakery.org .

Step 5: Secure Tunnel to an Insecure Service

Okay, so we have tunneled through to services on the same box as the SSHD process. That's handy. But what about reading private and sensitive company information from within a client site?

Assuming that your outside machine ( frosting.bakery.org ) has access to the Web site in question (let's call it corporatesecrets.bodyshop.com ), we just add another line to our .ssh/config file:

 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  

As you can see, the forward doesn't have to be on the same box as the SSH server (SSHD). It may be on any box that the server box can reach.

One Section That Will Pay for the Book

I'm going to reveal a secret here that will singlehandedly make this book worth your purchase price. Once you start port forwarding, you will discover an annoying side effect. If you are connected to a remote server in a shell session that has forwarded ports in either direction and you then attempt to SCP (copy files) to or from the same remote host, you will get a message like:

  mschwarz@mars:~ scp pubkey.asc mschwarz@frosting.bakery.org:.  
  mschwarz@frosting.bakery.org's password:  
  bind: Address already in use  
  Disconnecting: cannot listen port: 15143  
  lost connection  
  mschwarz@mars:~  

You are getting this message because SCP uses SSH to do the copying, so the same .ssh/config entry is being used to configure the SCP session. Great, right? Well, not once port forwarding is involved. Only one process can open a socket for listen. When you try to SCP to the same host you are SSH'd in to, the connection fails because there is already an SSH session listening to (in this case) port 15143.

You might think you are completely stuck. But this is Linux. There's a simple dodge. It turns out that .ssh/config Host entries are matched on exactly what is passed on the command line, not on any real or resolved address. By this I mean that if frosting.bakery.org has a numeric IP address of 112.211.122.221 (which it doesn't ”I just made that IP address up, although I'm sure someone has it), you can use both:

  Host frosting.bakery.org  

and

  Host 112.211.122.221  

in your .ssh/config file and give them totally different options. For example, you can use the named entry to do port forwarding but have no port forwarding on the numeric one, and then you will be able to use that to do SCP even while SSH'd in.

Note that you can make this even easier. If you have root access to the client box, you can use the /etc/hosts file to create several aliases to the same box. Each alias name can have its own configuration in the .ssh/config file.

Telling you this up front will save you a lot of hassle. See? We told you this book was worth buying!

 



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