Linux Security: A Whirlwind Tour

November 16, 2002 / Kurt Nelson / 0 Comments

Table of Contents

2. Security Rant

2.1. Common security paradigm

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.

2.2. The Hackers

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.

2.3. Security == Risk Management

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.

3. Advanced uses of SSH

3.2. Port Forwarding

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 Smile

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.

4. Virtual Private Networks

4.1. Intro

Security is a monstrously huge field and so to impart knowledge, I
must divide and conquer. In this presentation I will cover advanced
usage of OpenSSH and the rudimentary basics of VPNs under Linux and a
small rant about security.

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.

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.

4.2. VPN technologies

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? 🙂

4.3. Linux Free S/WAN

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.

4.4. Stability, bugs

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.