Broadly, computer security is often divided into two fields: host security, and network security. Host security concerns the integrity of an individual host, which is a single node on a network. Network security focuses much more on the integrity of an entire network and analysis from this point of view. This is a useful paradigm for constructing a secure computing environment. Secure each host, then secure the whole network.

For Linux machine, the risks to both host and network security are great. These risks stem from several root causes. One of the largest factors is that since the source code for most software on a Linux system is freely available, would-be attackers are free to analyze it and locate security holes.

There are several types of people who carry out this type of analysis. Some of them are willing to share their findings while many others are not. Those who share their security related discoveries are often called "white hat" hackers. Those who do not share their findings then fall into two categories, the "grey hats" and the "black hats". These metaphorical hats denote the ethical stance of the people in question. Never assume that the "White hats" have found all of the holes.

For the end administrator, it is important to know that there are a huge number of possible ways to attack a system and you should never assume that a given piece of software is completely safe. Measures should always be taken to mitigate risk. Security is ultimately about risk management, and that's how it should be approached.

The Secure Shell Protocol is a modern, advanced standard for securely connecting multiple hosts. For the morbidly curious it is defined in a RFC (Request For Comment); use Google to find it. The protocol is designed to do much more than simply substitute for telnet or rsh. It is a highly layered, configurable communication system which can be used to connect hosts with several different types of communication channels.

Examples include:

1. X11 forwarding
2. SSH port forwarding (tunnels)

I must also point out that OpenSSH is itself open to several forms of attack, and I encourage administrators to restrict the hosts that are allowed into your boxen. Other security professionals have recommended the use of the commercial SSH package instead.

For further information on how to use SSH, there are two excellent articles on the LUG web server (see Links section below) SSH keys are particularly useful to me, since I use many systems on a daily basis.

SSH port forwarding is a very powerful tool for securely connecting two hosts. This can be done in several ways.

Relevant excerpt from man page:

ssh [-L port:host:hostport] [-R port:host:hostport] [-D port] hostname | user@hostname

1) Local port is forwarded to remote port (static) Use '-L' 2) Remote port is forwarded to Local port (static) Use '-R' 3) Local port is forwarded to remote port (dynamic, specific to application) use '-D' (this is new)

The first two are the most common. The third type of forward is specific to an application protocol, and as of OpenSSH 3.1p1 it only works as a SOCKS4 proxy.

Note that in the syntax for the '-L' and '-R' options, the "host" entry is a hostname or IP, that is relative to the machine you are actually connecting to. You are actually connecting to a machine where you have an account to set up the forward, and the "host" is contacted from the server you are connecting to. This is probably the most confusing part of the port forwarding scheme, and hopefully the examples below will clear it up.

Examples:

1) My computer is outside of Georgia Tech and I want to connect to the news server using the NNTP Protocol. The NNTP protocol uses port 119 and the news server is news.gatech.edu. The news server only accepts connections from hosts inside the GT network, so I need a port forward from some machine inside the network. I want to connect to my local machine's port 9999 and have it forward to

I have an account on acme.gatech.edu, so I will use it to do the forward to news.gatech.edu. Note that I do not have an account on news.gatech.edu.

Command Line:

ssh -L 9999:news.gatech.edu:119 gt1234a@acme.gatech.edu -N -C

The '-N' option tells OpenSSH not to execute a remote command, so i can just background ssh (ctrl-Z) after I authenticate. The '-C' option tells OpenSSH to compress the data (very useful for X11 forwarding, too).

Alternatively, I could have used local port 119 (if I were root) and then simply told my news-reader the server is "localhost" and it would happily connect to localhost:119 but in reality connect to news.gatech.edu. Kinda tricky, eh?

2) I have a local network of a few machines, and I am running a webserver that only my internal network can see (it's behind a firewall). But, I want to be able to use that webserver when I'm away from the home network in another office on a separate network.

So, here we set up a similar forward, but now we shall initiate the forward from the server, instead. This time we will forward a remote port (on another private network) to our local webserver port. Our webserver machine is running a server on port 8080.

Say we want to forward a port on "workstation1.company.net" to our internal server. In this case we must have an account on the machine in question, "workstation1".

Command Line:

ssh -R 1234:localhost:8080 tunnel@workstation1.company.net -N -C

So, when I'm logged into workstation1 at the other office, I point my web browser to http://localhost:1234/ and I can access the webserver in my home office just like I was there. Magic.

You might be wondering why I used "localhost" as the hostname in the ssh command. This is because I was forwarding a port to the local machine. I could have also forwarded the remote port to another machine's server in the network. Now that's getting complicated

You can verify that the tunnels are in place using the netstat command to examine which ports are open and what IP they are bound to. OpenSSH always binds to 127.0.0.1 so no one else from another host can abuse your tunnel.

What is a VPN? Broad Definition: (my own) A VPN is a way to securely connect two or more physically separate networks over the Internet.

This means that we have a "virtual" network that is comprised of the two separate network, and nobody in between the networks can understand the VPN traffic.

Why is it useful?

VPNs are usually used in business settings where sensitive data must be transmitted between different business locations that are often very far away physically. It offers a more general solution than simply using SSH because they encrypt *all* IP traffic, and they are totally transparent to the end hosts. The burden of encryption is moved to the VPN gateways, which handle all of the details of security.

There are two major categories of VPN technologies in place today:

• IPSec (part of IPv6)
• non standardized: CIPE, vpnd, etc

IPSec is a standardized VPN technology for IP networks. It is a part of IPv6 and must be included in any IPv6 implementation and it is optionally available for IPv4 implementations as well.

There are other methods of connected networks using encryption that can also be called VPNs, but I will stick to IPSec as it is most common and a real standard though rather complex.

It would be a waste of space to try and describe the IPSec protocols in this document, you can read the relavent RFCs/Books for that. I can describe IPSec as "just another layer" of IP that adds encryption and uses UDP for authentication. It is very flexible like SSH and there are many implementations that are very different in what they provide.

There are two important pieces to IPsec:

• Authentication - proving the identities of the hosts
• Encryption - agreement on the method, key exchange,etc.

VPNs are an extremely complex technology, which is why they are probably mostly used in business settings where they are needed most. They can be rather expensive (both money and time) to set up and maintain. When they break, it is often a nightmare to debug them. I'm just dripping with optimism, aren't I? :-)

For Linux, the foremost software is called Free S/WAN which is named after a commercial product (Secure WAN). It is a free IPv4 IPSec implementation for Linux Kernel 2.4.x. It comes in one package with two parts:

1) Kernel Level Support

• requires patching
• requires GMP (GNU MultiPrecision Arithmetic Library)
• Creates IPSec networking modules
• Creates new ipsecX interfaces that correspond to physical interfaces

2) Proprietary user space tools

• scripts that support SYSV style init
• userspace tools to augment kernel modules
• Can start/stop/reload IPsec
• Supports various levels of logging
• Pluto - Name of the authentication daemon - UDP port 500
• /etc/ipsec.conf is the main config file

To Install it, download the tarball from the site, configure a Linux kernel source tree, and use the targets from the freeswan makefile to build your kernel. The Freeswan makefile will also install the userspace tools for you. I'm not sure if any major distributiors have created packages of them yet.

The configuration of FreeSwan is rather difficult, ask anyone's who has tried it. There are several examples on their online documentation. But to understand what is going on, the adminstrator needs a very good understanding of IP networking and of the IPSec protocols.

Interoperability with other VPNs

• Shared Key
• RSA
• X.509 certs
• difficulties

Unfortunately, it is often very hard to get two different VPN products which supposedly speak the same language (IPSec) to talk to each other. Linux Freeswan for example, does not (by default) support X.509 certificates, which is the most common method of authentication for commercial products. There is a patch for support, but it is, again, tricky to get it to work.

IPSec does support a lowest-common-demoninator form of authentication called shared key which is just that, a shared key between the two VPN hosts. FreeSwan also supports RSA authentication, though I haven't seen any commercial products which support that method.

In my experiences with some of the earlier versions of FreeSwan, I have encountered many bugs and problems in the code. Not to say that it does not work, it certainly does, but be aware that it is still very much a work in progress.