M. Fahrizal Rahman Blog

By Kapil Hari Paranjape

Taken from LinuxGazette.com

1  The Evil That Lurks Within

Securing a local network (LAN) usually means creating firewall rules, host access rules and proper configuration of Mail, DNS and web servers. All these methods are primarily based on the assumption that the threat to your network is from the big bad internet. In this article I will take a reverse point of view—that is, users of the local network who are (possibly) the bad guys.

Such an assumption may be justified in the following contexts:

• The network is large one, like a campus-wide network. The network administrator has no knowledge of or control over all the different computers that are connected to the LAN.
• A typical wireless network where everyone in your neighbourhood can use your internet link.
• You are in a cut-throat corporate office (perhaps this applies to some academic departments as well) where you do not really trust your colleagues—and all of them wear black-hats.

Although I spoke about “users” above, the real actors in a computer network are computers. By making the (often false!) assumption that each computer is doing exactly what its user wants it to do, I will reduce the question to the following:

How can computer Abdul that wants to talk to computer Chin be reasonably confident that computer Betaal is not able to intercept the conversation and/or impersonate Chin?

2  Not a telephone network

In order to understand why a slightly sophisticated solution is required, we need to realise that a LAN is a not like a telephone network and an IP address is not an identifying label in the same sense that a telephone number is.

The more sophisticated reader will know about “hardware” addresses (also known as Ethernet or MAC addresses) which are built into the hardware unlike IP addresses. However, the description of the network given in the paragraph below is equally appropriate if you replace “IP address” with “MAC address”.

A typical LAN is a packet based network. Each computer is always “connected” to all other computers. Conversations are based on packets which are sent “via the wire” and are “heard” by all the computers on the network. Each packet is labelled by the recipient’s IP address so that the relevant party can “listen to it” (in other words, copy it to its memory). The packet also contains sender’s IP address so that the recipient knows where to send replies.

Computer Betaal (as the ghost in the machine) can collect (copies of) packets meant for any destination and can also inject packets with any label(s) desired.

So, Abdul must (digitally) sign every packet sent out and encrypt it so that only Chin can read it. If Abdul only signed the packets, then Betaal (still) could collect them. Since there are a lot of packets that make up any conversation, Betaal could re-send the packets later in a more profitable order—thus delivering a blow to Chin. If Abdul only encrypted the packets then Betaal could inject his own encrypted packets of gobble-de-gook (illegible/undecipherable data) and disrupt the conversation between Abdul and Chin.

Let me re-state this in jargon. “In a packet based network, secrecy and authenticity go hand in hand.”

3  Secure Shell

When Tatu Ylonen originally wrote ssh it was thought of as a replacement for telnet and rsh which are programs/protocols for remote logins (for remote shell access). However, ssh is a network protocol, so it can be used to create secure conversations between computers.

Each SSH server has a private key—usually located at /etc/ssh/ssh_host_rsa_key. Often, there is a second private key in /etc/ssh/ssh_host_dsa_key. Network administrator’s job is to collect public keys associated to each of these private keys (in the same place, with a .pub extension) and distribute them to all computers on the network.

The simplest way to do this is to go to each computer and copy these files to a USB stick:

   cp /etc/ssh/ssh_host_rsa_key.pub /media/usb/<ip_addr>.rsa.pub
   cp /etc/ssh/ssh_host_dsa_key.pub /media/usb/<ip_addr>.dsa.pub

Admin then creates a “known hosts” file:

   for type in rsa dsa
   do
       for i in /media/usb/*.$type.pub
       do
         addr=$(basename $i .$type.pub)
         (echo -n "$addr "; cut -f1-2 -d' '< $i)>> known_hosts
       done
   done

This known_hosts file is then copied to /etc/ssh/ssh_known_hosts on each computer. Finally, we set configuration parameters

   echo "StrictHostKeyChecking yes" >> /etc/ssh/ssh_config

on each computer. (Users on each computer may also need to modify the configuration file $HOME/.ssh/config if it exists and remove/edit $HOME/.ssh/known_hosts if it exists).

After this (admittedly) long-winded (but not difficult) procedure, Abdul and Chin have each other’s public keys. So, Abdul can encrypt packets which only Chin can read and Chin can verify signatures made by Abdul. (The actual SSH protocol is more complex and doesn’t concern us here).

So, now, on Abdul one can do ssh Chin and be confident that it is Chin who is answering. Chin will still ask for the password unless all servers enable HostBasedAuthentication in /etc/ssh/sshd_config. This procedure might be risky for Chin, unless the root user on Abdul is to be considered equivalent to the root user on Chin.

What about other (than SSH) types of data exchange? Luckily, this too has been thought of. If Abdul wants to open TCP port (say) 80 on Chin now, then Abdul runs

   ssh -q -f -N -L 8080:localhost:80 Chin

Now, opening http://localhost:8080 on Abdul gives Chin’s web server.

What about securing all of data exchange? This has been thought of as well. In fact, SSH provides at least two ways:

1. Applications that can use the SOCKS protocol (like Mozilla and Thunderbird) can use a tunnel created by this command:

            ssh -q -f -N -D 1080 Chin

   There are also wrapper libraries like tsocks that can “teach” any TCP application to use SOCKS.

2. One can also create a TCP host in the LAN which supports encrypted traffic. This allows one to enable this configuration on all hosts in LAN one host at the time without disrupting the existing network in the process. Once all hosts are configured for IPsec, this can be replaced with

      spdadd $IP_ADDR $NETMASK any -P out ipsec
         esp/transport//require
         ah/transport//require;
   
      spdadd $NETMASK $IP_ADDR any -P in ipsec
         esp/transport//require
         ah/transport//require;

   6  Conclusion and Acknowledgements

   Now, it is relatively easy to configure machines to use encryption and authentication in a local area network. Today, computers and networks are fast enough, so extra calculations and extra network packets, that are required for this, do not cause noticeable delays. Also, it is quite easy to implement such a solution without bringing down the entire network until all machines are reconfigured.

   So! What are you waiting for? Choose a solution that is appropriate for your use and put it into use!

   In the IMSc network we have tested and implemented the openvpn solution. A number of my colleagues here helped debug various aspects of this. I thank them all for their help. The documentation of ssh and openvpn is also very good. There is a number of great articles on IPsec including those from LG that have been mentioned above. I thank the authors of these documents for their assistance.

   Popularity: 26% [?]