Security Basics

Last issue we covered the packet filtering schemes Linux uses at the moment, and will use in the near future. In keeping with my effort to defy any kind of road map of these articles, I will devote this column to some basic issues involved in increasing the security of a Linux box. The art of implementing a security policy is very much one of balancing ease of use with security.

Last issue we covered the packet filtering schemes Linux uses at the moment, and will use in the near future. In keeping with my effort to defy any kind of road map of these articles, I will devote this column to some basic issues involved in increasing the security of a Linux box. The art of implementing a security policy is very much one of balancing ease of use with security.

The Golden Rule: There Is No Security

Many people consider the word “secure” to be an absolute term. Either a box is secure or it
isn’t, right? Wrong. At best, this polarized view of security is naive. At worst, it’s

Consider the security of your household. Perhaps you have a home alarm system, but does it work
if the thief cuts the power? What if someone holds a gun to your head and makes you enter the
combination to deactivate it?

Like physical security, computer security involves trade-offs: How much is something worth and
what is the risk? Judging this in a world without absolutes is the essence of computer security.
There’s no point installing machine-gun placements and voice-recognition systems to protect your
Netscape bookmarks. And besides, if you go overboard on security requirements, you’ll find people
(yourself included) subverting security in order to get actual work done. The result is often far
worse than loosening security in a controlled manner.

So how do we assess risk? How can we know if someone will try to subvert our security, and how
can we evaluate their chances of succeeding? The answer to the first half of the question is fairly
simple. There are many scanning programs that are used to find vulnerable boxes. If you’re on the
Internet, you will probably be probed even if you have nothing interesting on your machine. Insecure
boxes are used as hard-to-trace launching points for attacks on more secure boxes. So you might as
well assume that someone will try to subvert your system. The risk is proportional to the time you
spend online and the security protection (if any) offered by your ISP.

What about evaluating the odds of an intruder succeeding? Well it turns out that there is quite
a bit any sysadmin can do to reduce the chance of a successful attack, and that’s what this column
will concentrate on.


Start with this assumption: There are bugs in every component of the system you are trying to
secure. It’s probably true. Assume there are bugs in the hardware, the kernel, and the applications
running on it. A small number of these bugs have security implications, but the more things you have
running, the more likely you are to have a vulnerability. The way to reduce these bugs is to
eliminate all that is unnecessary.

First, it’s a good idea to remove any hardware that is not required. Consider the case of a
modem card that’s been plugged in by accident. You may not be able to see how it would make a
difference, but if the device driver for that modem contains a bug, you will be affected, even if
you don’t use the modem. In general, it’s best to be paranoid.

Second, you should compile your own kernel and remove any unneeded services from your OS. There
is an excellent guide to compiling your own kernel in the Linux Kernel HOWTO, available from the
Linux Documentation Project (http://metalab.unc.edu/LDP. There’s also an excellent guide in this month’s issue – Ed.).

Finally, and most importantly, make sure that programs you do not need are not running and
preferably are not installed on the Linux box at all. Two categories of programs deserve particular
scrutiny: those that listen to network traffic coming from the outside world and those that have
special capabilities. The first category of program is fairly simple to find. As root, run the

 % netstat –inet -a -p

This will list all the programs listening for IP traffic. You might see a number of things
running that you didn’t suspect. In particular, a program called inetd often listens for many
smaller services. You can control what it does with the file /etc/inetd.conf. If any one of
these programs can be compromised, it may allow a remote attacker to gain local access. You want to
simply turn off inetd altogether. If you’re running a standalone system out of your home,
there’s a good chance you won’t need any of the services that inetd supports.

The second category of program to look at are those that allow a local, unprivileged user to
gain special privileges on your system. If there is a bug in such a program, an intruder may be able
to abuse these privileges. Programs with special capabilities can be found using the command:

 % find / -type f -perm +6000 -exec ls -l {} \;

If you find any such programs that you don’t need, they should be neutered (using chmod
to take away their setuid and setgid bits; see the man page), or removed

Tracking and Logging

If someone does manage to compromise your box, you’ll want to be notified. You’ll also want a
way of double-checking if you suspect a compromise has occurred.

Balance is the key to logging. You don’t want so much information that you are flooded with
information you cannot process. To get around this, I recommend two logs: one for things that should
never happen, and a second, more verbose log that can be examined later. Since the first log
will contain much less, and much more vital, information, it should be sent somewhere where you will
notice updates to it immediately (your e-mail box for example). You will also want to archive these
logs in a single file for later reference. The second log, with more detail, will generally not be
analyzed unless you believe a compromise has occurred. From it, you will hope to gain some hint of
the events leading up to the compromise. The syslog.conf(5)man page details the control of
the system logging daemon. You might want to log critical notes to a printer or to a separate
logging host, set up for that purpose. This guarantees that at least one copy of the log cannot be
altered by an intruder that has compromised your machine.

For detecting compromises, I recommend Tripwire. Tripwire is a software package that works by
recording digital signatures of files. These signatures can then be compared to the current
signatures to detect what files have changed. Tripwire is most valuable on a system that doesn’t
change very often. It is functionally equivalent to taking a copy of your entire filesystem for
later comparison. When you want to check your machine, take it off the network and boot off a fresh
kernel (usually a read-only boot floppy is good for this) and then run Tripwire to check your files.
It is important not to run any program or kernel on the machine that has been exposed, as these
could invalidate your results. (Modified Linux kernels that cover up the real contents of files are
known to exist, for example.)

Tripwire exists in both older, free software versions and newer, commercial versions. The
commercial version of Tripwire is currently free for use under Linux, but the source code for the
software is not provided.

Follow Security Advisories

It’s important that you stay abreast of security advisories, either those from your Linux
distribution vendor, who will release security updates soon after problems are reported, or from a
list such as BugTraq (see Best Defense, September 1999) or both. This will reduce the window
of opportunity for intrusions.

Proxies Versus Packet Filters

People often ask me what technique they should use on their firewall: proxies or packet filters.
The answer is simple: both. Proxies are programs that intercept connections and establish new
connections to the outside world, shuffling data between them. Because no packets actually pass
between the internal network and the external one, internal hosts are protected from view and from
probes. In addition, because proxies usually understand the protocol being spoken, they restrict
what data can actually be sent. For example, a mail proxy should understand SMTP (the Simple Mail
Transfer Protocol) and not forward invalid commands.

Packet filtering should be used to prevent bypassing of the proxies, control who can talk to the
proxies, and limit (and possibly log) what packets can come out of the box itself. Proxies
frequently have methods of controlling who can use them; use these in addition to packet filtering.
Logging whatever unusual packets are generated by the firewall can help you catch compromises or

Linux kernel masquerading can be used to do a limited form of connection tracking. Masquerading
means that packets from an internal host are altered as they pass outward through a Linux box to
make them look as if they originated from the Linux box itself; reply packets are mangled back
automatically. The masquerading code in the kernel will deal with reply packets. The ipchains
tool is used to enable masquerading (or ipfwadm in pre- 2.2 kernels) and to block out other

Defense in Depth

This concept, of using multiple techniques for the same purpose, is a form of “defense in depth”;
it’s a fancy term for not putting all your eggs in one basket. The idea is not to have a single point
of failure for the security of your network. For example, it is important that your internal systems
are also secured, using equivalent or lighter versions of the same techniques you use on your
firewall. This reduces your reliance on the firewall itself for your security, both in case the
security on the firewall is compromised and also because, in a real network, your firewall is not
the only entrance; floppy disks, modems on people’s desks, and MIME attachments in e-mail are
additional, unavoidable hazards.

Minimal Allowance

For some situations, it is possible to restrict not just what is running on your Linux box, but
also when it is exposed to a hostile network. This would require restricting the hours that you are
connected, either by implementing a 9-5 policy or by using some kind of dial-on-demand system, such
as diald or pppd’s dial-on-demand capability.

A Security Routine

It is useful to establish a regular security routine: Check your logs regularly for unusual
events, run Tripwire, and take a look at the physical machine. Think carefully about what you will
do if you detect a compromise; how will you go about reinstallation?

If you don’t check your security on a regular basis and re-evaluate your security choices, the
system you thought was secure may very well drift into an insecure state. This is equivalent to
having good locks on all the doors but not checking to see that the doors are locked each night
before you go to bed.

Each of the techniques we’ve discussed is useful in and of itself. There are many not listed
here that can be used under various circumstances. Generally, however, you have to balance the risk
you face against the time and expense you can afford. For more information, the Linux Security HOWTO
is an excellent resource. Enjoy.

Security Sites on the Net

BugTraq Mailing List Archive:

CERT coordination center (incident reporting and alerts):

Red Hat’s Security Page:

Debian’s Security Page:

Linux Security HOWTO:

Paul “Rusty” Russell is now paid by WatchGuard to maintain the current Linux packet filter code
and develop cool new GPL networky stuff for the Linux Kernel while spending the money WatchGuard
sends. He can be reached at paul.russell@rustcorp.com.au.

Comments are closed.