Encryption IV

Tunneling Traffic Through SSH

One of the key security issues you must deal with as a system
administrator is the fact that many commonly used network protocols
transfer information as clear text. Good examples of this are the POP3
and IMAP daemons we discussed in the preceding chapter. We noted that
for your Linux MTA to download e-mail messages to client systems, you
must first enable either your POP3 or IMAP daemon via xinetd. Once
done, end users can use an e-mail client to connect to the MTA and
download their mail using the appropriate protocol. The problem,
however, is the fact that both of these daemons transfer data as clear
text by default. That means the usernames and passwords users send to
authenticate to the MTA are sent as clear text along with all the con-
tents of their e-mail messages. This allows anyone with a sniffer to
capture packets and view the contents of the transmissions.



The good news is SSH can be used to encrypt clear-text traffic by
tunneling it through an SSH connection. When client software for the
tunneled protocol (such as an e-mail client using POP3) establishes a
connection with the local SSH client, the traffic is encrypted using
SSH and tunneled through to the SSH server. On the SSH server end, the
traffic is decrypted and then forwarded to the appropriate target
service (in this case, the POP3 daemon). This is great, because the
information is encrypted before being transmitted, even though the
original protocol (in this case, POP3) doesn’t support encryption.




Let’s walk through an example of how you can use SSH to tunnel POP3 traffic:



1. Make sure the ssh client is installed on the local system where the
   e-mail client will run.


2. Make sure the sshd daemon is installed and running on the POP3 server.


3. Ensure IP port 22 is open on the server where sshd is running.


4. On the system where sshd is running, switch to root and edit the
 


  /etc/ssh/sshd_config 



   file.


5. Locate the AllowTcpForwarding parameter, uncomment it if necessary,
   and then set it to a value of yes. An example is shown here:



    AllowTcpForwarding  yes



6. Save your changes to the file and exit the editor.


7. Restart the sshd daemon by entering systemctl restart sshd at the
   shell prompt (as root).



8. Switch to the client system.



9. Create a local ssh tunnel from a local high IP port (in this
   example, port 2345) to port 110 on the POP3 server using the following
   command (enter the remote user’s password when prompted):



    ssh -f -N -L 2345:pop3_host_address:110 user_name@pop3_host_address




   The options specified in this command do the following:



   • –N and –f 

     Tell ssh not to execute a command remotely on the server
      and to run in the background after prompting for the remote user’s
      password


   • –L 

      Specifies three things:

      • The local port to be used for the client end of the tunnel (in
        this case, 2345)

      • The hostname or IP address of the remote POP3 server

      • The port on the remote server that will be used for the server
        end of the tunnel (in this case, 110)



   You don’t have to use port 2345. You can use the same port on both
   ends if desired. However, be aware that you will need to switch to the
   root user if you want to use a port number less than 1024 on the
   client side of the tunnel. These are called privileged ports.



10. With the tunnel established, configure the local e-mail client
    program to retrieve mail from the local system on the port you
    configured for the client end of the SSH tunnel. In this example, you
    would configure it to get mail from the local system’s IP address on
    port 2345. An example of how to do this with the Evolution e-mail
    client is shown in Figure 18-6.


    Note that I used the hostname of the local host, not the POP3 server, in the Server field.
    I also added the port number of the workstation end of the tunnel to the end of the
    hostname.




At this point, when the client uses the POP3 protocol to download new
messages, the SSH client on the local system will encrypt the request
and forward it to the SSH server through the SSH tunnel you
established. The SSH server will receive the request, decrypt it, and
then pass the data on to the local port 110, where the POP3 daemon is
listening. The cool thing about this process is that it is completely
transparent to the e-mail client software. As far as it’s concerned,
it’s retrieving e-mail from a local POP3 server.



You can test the tunnel you created using the telnet command from the
client end of the tunnel. The syntax is


telnet localhost client_tunnel_port


Here’s an example:



telnet localhost 2345



When you do this, you should see a connection established with the remote system where the POP3 daemon is running. An example is shown in Figure 18-7.




You can also tunnel your X server traffic to remote X clients using an SSH connection. This is important because unencrypted X traffic provides an attacker with a gold mine of information that he or she can use to compromise your systems.






To configure a remote X client without encryption, you can use the
following procedure:


1. On the remote X client, enter



   xhost +X_server_hostname



   This tells the client to accept connections from the X server.



2. On the X server, enter



   DISPLAY=X_client_hostname:0.0



   and then enter



   export DISPLAY



   This tells the X server to display its output on the remote X client.




3. From the X client, use the ssh client to access the shell prompt on
   the X server and then run the graphical application you want displayed
   on the X client. For example, you could enter gedit at the shell
   prompt to remotely display the gedit text editor. You could also enter
   office at the shell prompt to remotely display the OpenOffice.org
   suite.








This procedure works, but all the X traffic is transmitted
unencrypted. This isn’t good. Instead, you should use SSH to tunnel
the X server traffic between the X server and the X client. You can do
this using one of the following options:



• Use the –X option with the ssh client program.


• Set the 


ForwardX11 


option to a value of 


yes


in the


 /etc/ssh/ssh_config 


  file on the X client system.




Once this is done, you then need to set the


X11Forwarding 


option to



yes 



in the



/etc/ssh/sshd_config 



file on the X server system.












LX0-104 Exam Objectives (X)