Securing Web Access with SSH | Hacking Ubuntu: Serious Hacks Mods and Customizations (ExtremeTech)

When you use the network from the comfort of your own home or small office, there is a degree of security because you are not sharing the Internet connection. You can access your favorite web sites or manage your bank account with relatively little risk of someone watching you. Although an evil hacker on the network between you and your bank can see your connection, the odds are very slim that someone is actually on the exact network route between you and your bank.

Unfortunately, the same sense of security cannot be said for remote locations. Coffee shops, airports, bookstores, libraries, hotels, and other places that offer network access for free (or a fee) not only cannot protect you from eavesdropping, but they will happily offer the same free (or fee) connection to anyone-even an attacker. I've been in enough crowded coffee shops to realize that the chances of someone eavesdropping could be as high as 25 percent (and that's assuming that I'm not in the coffee shop with my laptop). Some people do it for fun or curiosity, but other people can be malicious-playing with connections or stealing passwords and accounts. Even using SSL and HTTPS cannot offer you much protection against an active attacker.

Since you don't know who might be listening, it is best to play it safe. If you want to access the network securely and want the freedom of browsing from anywhere, then consider using a Secure Shell (SSH) tunnel. SSH provides an encrypted connection between two computers, and can forward network traffic across the tunnel. To do this, you will need:

Two computers. One will be your server at home (or at your trusted location), and the other will be your laptop that you will take with you to the coffee shop.
A SOCKS server proxy running on the server. This is how you will relay your traffic from the coffee shop, over the SSH connection to your home, and proxy out to the network.

The goal is to use SSH to create a secure tunnel from your laptop at the coffee shop to your home. You will send all web traffic through the tunnel and relay the web requests through your own SOCKS server. This way, all your web traffic is encrypted as it passes through the coffee shop.

Although this approach is not foolproof, it is about as safe as accessing the network from your home. The basic steps are:

Install a SSH server at your home.
Open your home SSH server to the Internet. This way, you can access it from the coffee shop, library, or any other public location.
Install and configure a SOCKS server that can be accessed only from your home.
Test the configuration before going to the public location.
Establish the full end-to-end tunnel and start relaying your web traffic.
Configure your SSH connection based on your speed requirements.

Installing the SSH Server

The first thing you will need to do is install the SSH server. The Ubuntu installation gives you an SSH client, but not a server. To get the server, install the openssh-server package.

 sudo apt-get install openssh-server

Besides installing the server, this package will also generate cryptographic keys, add itself to /etc/init.d for automatically starting at boot, and starts the daemon. I usually check the default server's configuration found in /etc/ssh/sshd_config:

Make sure X11 forwarding is enabled (X11Forwarding yes). This way, if your laptop supports X-Windows, then you can run graphical applications from the remote system. For the SSH client (/etc/ssh/ssh_config), you will also want to enable X11Forwarding. If either the client or server does not support this option, then you cannot run graphical applications across the tunnel.
Check to make sure KeepAlive yes is set. This prevents an idle SSH connection from being disconnected by an overzealous firewall.
I like to enable a banner message (Banner /etc/issue.net). This way, people see a friendly greeting when they connect to the SSH server. This message is displayed before the user is prompted for a password. You will also want to edit the /etc/issue.net file. The default banner gives the operating system version and that could be a security risk. I changed mine so it displays this happy message (see Figure 5.5):
```
     All connections and packets are being recorded.     Unauthorized access attempts can and will be viewed as a network     attack. Where unauthorized access is enforceable by law, it will     be prosecuted. 
```
Figure 5-5: A SSH connection showing the /etc/issue.net message

After making any changes to the server's configuration, you will need to restart the daemon.

 sudo /etc/init.d/ssh restart

Opening Ports

Since you will be accessing the SSH server from the Internet, you will need to open the SSH port to the world. If you have a firewall, it will need to allow traffic to enter on TCP port 22.

Tip

For the cautious user, consider changing the SSH server to a different port (/etc/ssh/sshd_ config, Port option). This way, worms and kiddies scanning for active SSH servers will be unlikely to find your server. Although this is security-by-obscurity, it is very effective against automated attacks.

Every firewall is different, so you will need to check how to open a port. If you are using a small home firewall and NAT system, then look for a setting for incoming connections. At minimum, you will need to supply the port (22) and the SSH server's IP address. Depending on your firewall, you may also need to supply the protocol (TCP).

After you have the port opened, test it. Using the ssh command, connect to the server using your laptop. This will do two things: first, it will validate that the port is open and the SSH server is running properly. Second, it will transfer over the server's key to the laptop. This way, when you go to the coffee shop nobody will be able to hijack your SSH connection.

Starting a Proxy

The second key component for creating a secured relay system is to install the proxy on your home system. There are two packages that provide this functionality: socks4-server and dante-server. Both servers provide SOCKS proxies and both are basically equivalent, although socks4-server does require a little more configuration. In any case, you will only need to install one SOCKS server-do not install both. Since both servers use the same port (1080/tcp), only one can run at a time.

Using Socks4-Server

The socks4-server package provides a basic SOCKS version 4 proxy that is intended for use through inetd. To use this, you will need an inetd agent, such as xinetd. You will also need to edit /etc/sockd.conf to allow network traffic.

Install both server packages:

 sudo apt-get install xinetd socks4-server

As root, create a socks service for xinetd. The contents of /etc/xinetd.d/socks should look like:

 service socks {   disable = no   socket_type = stream   protocol = tcp   wait = no   user = daemon   group = sys   server = /usr/sbin/sockd }

Restart xinetd: sudo /etc/init.d/xinetd restart. At this point, the SOCKS server is accessible from the network, but not configured.
Configure the SOCKS server to allow traffic relaying. The default configuration file, /etc/sockd.conf, forbids all connections. At bare minimum, you will want to remove the "deny all" command and replace it with permissions for the local host. If you want other systems to use this proxy, then you will need to permit additional hosts or subnets.
```
 # deny ALL 0.0.0.0 .my.domain 0.0.0.0 permit localhost 255.255.255.255 ALL 0.0.0.0 
```

Warning

Permitting all network traffic to relay through your box is a huge security risk for machines accessible from the Internet. If this computer is directly connected to the Internet, then spammers will likely use your open SOCKS server to relay e-mail. The time between making a public SOCKS server and relaying spam could be as little as a few hours. For this secure tunnel, we only allow the local host to use the SOCKS server, and the SOCKS server is not accessible from outside the firewall. As long as you only permit access to the SOCKS server from the local host (and not the entire Internet), you should be secure enough.

In case the SOCKS server does not appear to work right, look in the /var/log/syslog file for error messages. Both sockd and xinetd log their status to this file.

Using Dante-Server

The Dante server supports both SOCKS version 4 and version 5. Although Dante can run from xinetd, it is usually used as a standalone server.

Install the Dante server. When you install this, it will try to start the server and it will immediately fail since it is not configured:
```
 sudo apt-get install dante-server 
```

Configure the server by editing the /etc/dante.conf file. You will need to enable a port as well as connection rules. For example:

 # log results to /var/log/syslog (for debugging) logoutput: syslog stderr # use 'ifconfig -a' to determine your # in this case, lo is the loopback port so it only allows localhost internal: lo port = 1080  # where to listen external: eth0            # where to relay # enable SOCKS connection methods method: username none #rfc931 clientmethod: none # configure which clients to relay; this only allows localhost client pass {   from: 127.0.0.1/32 to: 0.0.0.0/0 } pass {   from: 127.0.0.1/32 to: 0.0.0.0/0   protocol: tcp udp   log: connect error } # log all failed connections block {   from: 0.0.0.0/0 to: 0.0.0.0/0   log: connect error }

Restart the Dante server. Look at /var/log/syslog for any error messages:
```
 sudo /etc/init.d/dante start 
```

Testing the SOCKS Server

Regardless of which SOCKS server you installed, you will need to test it before you head to the coffee shop.

Open Firefox on the same host that has the SOCKS server.
Open the connection preferences: Edit Preferences General Connection Settings.

Tip
If you do not want to modify your default Firefox settings, then create a new profile for this test.
Enable the SOCKS server. The server should be running on localhost port 1080 (see Figure 5-6). If you are using socks4-server, then specify SOCKS v4 as the protocol. If you are using Dante, then either SOCKS v4 or SOCKS v5 will work.

Figure 5-6: Configuring Firefox to use the proxy
Use the browser to connect to a web site, for example, http://www.google.com.

If the connection works, you should see log entries in /var/log/syslog and the web page should be displayed. If the connection fails, look in /var/log/syslog for error messages or the reason for the failure.

Establishing the Tunnel

Now that you have working SSH and SOCKS servers, you can create a secure tunnel.

Find out your server's IP address. If you are doing this from home, then your ISP assigned you an IP address. If you have a stand-alone firewall, then connect to it and find out what its external (WAN) IP address is. On the other hand, if your computer is directly connected to the Internet, then you can run ifconfig -a to list your IP address (it is probably in the eth0 record). Without knowing your IP address, you will be unable to connect from the outside.

If the IP address starts with 10., 192.168., 172.16. to 172.31. or 169.254., then you are looking at a private network address. You will need to identify the public address before you can access the server from outside your local network.
On your laptop, use SSH to create a tunnel to the server. The tunnel should forward the local port 8080 to port 1080 on the server. For example, if your IP address is 1.2.3.4, then you would use:
```
 ssh 1.2.3.4 -L 8080:localhost:1080 
```
This command says to relay local connections to port 8080 to the host and port localhost:1080 on the server. The host name localhost will be resolved by the server.
On your laptop, configure your browser to use a proxy. In this case, you want to use local- host and port 8080 (not port 1080).
Test the connection by accessing a website.

If all goes well, you should see a web page. This means that all web connections go from your laptop to your local port 8080, where SSH securely tunnels all requests to the server, and the server sends it to the local SOCKS server, which in turn sends the request to the Internet.

Although this path does not remove the risk from someone sniffing the network connection between your home and the Internet, it does prevent anyone at the coffee shop from spying on your bank accounts.

Changing Ciphers for Speed

SSH uses cryptographic ciphers for protecting data, but not all ciphers are equal. By default, SSH uses AES. While AES is a very strong algorithm, it is not as fast as others. If you plan to use the Web over a secure tunnel, consider using a different algorithm, such as Blowfish. This cipher is strong enough for everyday use and is much faster. As a result, you will see a speed enhancement for requests sent over this secure tunnel:

 ssh -c blowfish 1.2.3.4 -L 8080:localhost:1080

Note

As cryptography goes, AES is considered to be a very strong algorithm. However, it isn't the fastest cryptographic algorithm. The Blowfish algorithm isn't necessarily as strong, but it is much faster.

Depending on the type of network traffic, you may always want to enable or disable compression. For example, X-Windows traffic can be heavily compressed, while images (for example, GIF and JPEG) and multimedia files such as MP3 and MOV cannot. If you are browsing the Web or streaming audio, then do not use compression-this is the default setting. But, if you are doing remote administration over X-Windows, then enable compression with the -C parameter:

 ssh -C -c blowfish 1.2.3.4 -L 8080:localhost:1080