It’s A Bad, Bad, Bad, Bad World

Learn what you need to know before

Security can be daunting. Hardly a day goes by without some new report of a
major network or prominent Web site being exploited. It’s not really a surprise that this is
happening. In fact, there’s a pretty simple equation driving the increase in security incidents:
more computers + more Internet connections = fun for intruders. Today a teenager running Windows 95
at home can download a program that manipulates holes in an operating system or network service
(called an “exploit”) and gain unauthorized access to your system, even if you’re half a world


Security Opener

Security involves tradeoffs. Often the tradeoff is between security and ease of use. There is no
such thing as a totally secure system that is still useable. The trick is to decide how much your
data and time are worth, and how much protection you are going to provide. Securing your system is
also a progressive process; it cannot be done overnight. But by improving security in stages, you
will both balance these tradeoffs and protect your systems in the best possible way.

The Linux security arena is progressing at a lightning pace. Several projects are underway to
provide a more secure distribution, as well as improving the security of the current ones. Many
people believe that the free software strategy that Linux employs provides a superior vehicle to
improve security (See this month’s In the Trenches, pg. 20 for more.) Having direct
access to the source code lets a whole wold of security experts spot a potential problem, or to jump
in and fix a vulnerability, without having to wait for the vendor to even be aware it exists.

Types of Attack

The diversity of
today’s networks exposes systems to many security-related vulnerabilities. These are some of the
most popular.

*The Denial of Service attack is a vulnerability used by intruders to prevent legitimate users from
accessing their data. The notorious TCP SYN Flood attack of July 1996 was a denial of service
attack. It succeeded by drowning a victim’s host with a torrent of false requests for service from
unresolvable hosts. These requests quickly consumed the host computer’s memory, rendering it
incapable of responding to legitimate requests.

* Spoofing is a type of attack in which someone pretends to be someone else. This can be used to
route data destined for one host to another, thereby allowing attackers to intercept data not
originally intended for them. Email spoofing is something you’re probably familiar with. Unsolicited
email (a.k.a. spam) can appear to originate from a nonexistent host, to which you cannot respond.
This is done by modifying the header of the email message. IP spoofing occurs when an attacker
masquerades his machine as a host on the target’s network, which fools the target machine into
thinking that packets are coming from a trusted machine.

* Poorly written or misconfigured services and programs also present a significant problem. A
version of software on one host has the same vulnerabilities as the same version of software on
another host. Using this information, intruders can quickly exploit multiple systems using the same
attack. CGI scripts (programs that Web servers run), for example, in the past have been coerced into
giving intruders access to prohibited areas. Buffer overflows, an exploit that occurs when a program
is tricked into overwriting a section of memory outside of it’s normal bounds, have also been the
source of many problems.

* Lazy, inattentive, novice and uninformed system administrators are a source of vulnerability.
Security requires constant attention to your vendor’s list of current vulnerabilities, as well as
auditing and monitoring. A lazy administrator making temporary changes to make his job easier can
easily make things easier for an intruder too. Management that does not allocate enough time, skill
and resources may also prevent an administrator from doing his job to the best of his ability. Even
seemingly inconsequential changes get noticed. Many intruders have nothing but time, and will
repeatedly probe your system, regardless of how well connected or publicly visible your Linux box is
to the Internet.

* Permissive access to systems can create a number of problems. The root account should only be used
for administrative purposes, and only when absolutely necessary. When anybody at all can obtain root
privileges, your chance of maintaining a secure system is zero. Having more than one user with root
access makes auditing difficult; it can be hard to tell if a change was made by one of those with
root access, or by an intruder. The most difficult step in an intruder’s attempt to gain control of
the system is obtaining any account on the system. Once this is done, there’s a pretty good chance
he’ll be able to obtain root privileges.

When the Unix operating system was developed in the late 1960′s, security was not a major
focus. Since Linux is a descendant of Unix, it has inherited many of its historical security
problems. Many Linux distributors, for example, still ship their products with insecure network
services enabled. Unfortunately, this means that it’s up to you to analyze and audit your system for
these potential vulnerabilities, and constantly monitor your systems for problems. This article will
help you to simplify the process of building a more secure system,as well as to improve the security
of your existing ones.

Developing a Security Policy

Whether you already have Linux machines on
your network, or are starting a new network, the first thing you must do is develop a security
policy. A good security policy is a well thought out, complete, written statement of the rules you
will use to protect your assets.

Your policy should describe what network services are permitted, who is responsible for those
services, who has access to them, and what to do in the event of an intrusion or violation of the
policy. Once this policy is written and reviewed by the responsible parties, it can also be used as
a basis for security audits. It will also serve as justification for providing or denying your users
a particular service. Without a written policy, you cannot effectively secure the machines or your

While you’re developing your security policy, keep this well-regarded security aphorism in mind:
That which is not expressly permitted is prohibited. This means that unless explicit access
is granted, access to that service should be denied. This is called the “default deny” security
policy. The converse of this is the “default allow” model. Whichever you chose to implement depends
on how you want to balance that security vs. ease-of-use tradeoff.

Building a New Server

Installing your Linux box properly from the
beginning offers the best opportunity to configure it securely, implement your security policy,
audit, and reduce the amount of problems you could have later on. Even before you install Linux on
your server, you should determine exactly what the machine will be doing. For example, a Web server
installation will be different from a server built to support dial-up users.

Once you’ve decided what services the machine will offer, stick to the plan. Don’t install
programs that you don’t need. Keep the machine disconnected from the public network until you’ve
completed as much as you can of the installation and auditing process. Install only the required
components, and incrementally add more services as they are required. For example, don’t install the
X Window System if you don’t need it. If you’re not doing development work, skip the development
tools. Don’t provide anything that could make an intruder’s job easier. There may not
currently be any vulnerabilities in the packages you install, but there’s still a chance it could be
misconfigured, and when a vulnerability does arise, you’ll have to constantly keep up with the
security updates.

When you’re finished with the basic operating system installation and configuration, check your
vendor’s Web site for possible security updates; apply them if you need to and then make a backup of
your system so you can refer to it later as a reference point. If something goes terribly wrong,
this backup will help you determine what was changed. Tripwire is a useful tool that can be used to
make a snapshot of your filesystem, allowing you to unequivocally determine if a file has been
modified, added, or removed. Additional information and an unsupported commercial version of
Tripwire for Red Hat Linux can be downloaded from http://www.tripwiresecurity.com.

Disabling Running Services

Once you have completed the operating system
installation, you can start evaluating the server more closely. Use your distribution’s package
management tools to scan the list of installed packages, then remove those that are unnecessary. If
you have a question about the function of a particular package or program, either post a question to
one of the mailing lists, or remove it until you can determine what it does.

Become familiar with the system, and which files are important for security. Your first step in
securing your machine should be to remove all unnecessary services. The Internet
daemon,inetd, is responsible for listening on many network ports at a time, and starting the
appropriate network daemon when a connection is received.

Many of the services running from inetd are legacy programs, which are hardly ever
required, yet typically enabled by default. Examine the /etc/ inetd.conf file on your system,
which contains the list of network services that inetd is responsible for starting. If
there’s a service listed that you don’t understand, you can look it up in the man pages, or you can
simply disable it. Use netstat -a and ps aux to obtain a list of the network
services and processes running. Investigate those you do not understand. Services such as finger,
and chargen were once useful, but today provide information that is helpful to an

System logs are the primary source of information about your system. The integrity of these logs
must be preserved and maintained or they become worthless. The primary method of logging system
information is syslogd, the syslog daemon. The syslog daemon configuration
information is stored in the /etc/syslog.conf file. It tells you what system information
should go to which file or device. Intruders will often attempt to cover their tracks by deleting or
inserting arbitrary information into these files.

Logging and Auditing

The syslog service provides many different
logging options, which give you a great deal of control in setting up how and where the log
information goes. The /etc/syslog.conf file can be modified to send all authentication
information to a separate file, for example. This can make auditing and management a whole lot

Among the wealth of freely available tools to improve security of your Linux box are a number of
different firewalls and other border patrol tools. These include packet filters, application
gateways (proxy gateways), and IP masquerading.

Firewalls and Border Patrol

Firewalls restrict the information that is
allowed in and out of your protected network. A firewall is configured to reside between an internal
network and an external untrusted network. It establishes a perimeter that controls all entry and
exit points to your internal network. The only access from your network to the external network is
through that firewall.

Packet Filters

Packet filtering is a method of filtering network traffic
as it passes between the firewall’s network interfaces at the network level. The network data is
then analyzed according to the information available in the data packet, and access is granted or
denied based on how the firewall is configured. Implementing a packet filtering firewall requires
that you have an intimate knowledge of how network protocols work, and which services are required
on your network. The source and destination hosts, the type of network service you’ll be permitting
(telnet for example), and network protocols (TCP, UDP, ICMP, etc) are all evaluated, and compared to
the list of firewall rules that have been created.

The Linux 2.0 and 2.2 kernels contains support for packet filters, and most distributions
include the necessary software (ipfwadm on Linux 2.0 and ipchains on Linux 2.2) to
implement it. (See this month’s Best Defense, pg. 56 for more on the future of packet
filtering -Ed)

Proxy Gateways

Application gateways (sometimes called proxy gateways) act
on behalf of another program. Unlike packet filters, they work at the connection rather than the
packet level. A host with a proxy server installed becomes both a server and a client, and acts as a
choke between the final destination and the client. The application gateway listens for incoming
client service requests, which it then forwards on to the destination supplied by the client. Once
it has fulfilled this request, it forwards the data back to the client. Application gateways
maintain two separate connections between external and internal systems. Internal systems,
therefore, never speak directly to untrusted external systems.

Security Proxy
Figure 1: The proxy server only lets specific services in and out of the

Proxy servers (Figure 1) are typically small, carefully-written programs that run on a
server and are able to analyze the data passing through it. They are configured to only permit
specific services in and out of the network they protect. For example, a host configured to proxy
telnet and FTP will not automatically permit other services in and out of the server; they
will be blocked. Application gateways and packet filters can be combined to provide better security
and flexibility than if either was used alone. The Apache Web server can be configured to proxy SSL
(the Secure Socket Layer encryption generally used for secure Web connections), FTP and HTTP.
Authentication can be added to this, restricting who is permitted access to the external network.

IP Masquerading

Linux also supports masquerading of IP packets. Using
ipfwadm for Linux 2.0, or ipchains for Linux 2.2, a server can be configured so that
every packet forwarded through it has its source address translated to the IP address of the Linux
box, not the address of the client making the connection. On the packet’s return trip, the proper
address gets substituted back into the translated address, and the packet gets routed to the
original client.

Not only does this provide anonymity for the host behind the Linux box, but it also has the
advantage of preserving the amount of registered IP addresses that your company uses. You only need
one IP address for your entire network.

In a home network, masquerading is typically used to allow both your Windows machine and your
Linux box to make use of the same dialup connection.

Since the machine examines every packet that goes in and out of the network, it can be used on
your firewall to provide security for the hosts behind the Linux box as well. However, a proxy
server is certainly a better choice.

Using TCP Wrappers

The TCP Wrapper program is perhaps the most widely
deployed freely available security tool in existence. Chances are it is already installed on your
Linux box. Its works like a firewall in that it accepts or rejects network connections based on IP
address and service type. It also provides a greater level of logging than would otherwise be
available, which is useful for tracking intrusion attempts.

The TCP Wrapper program, tcpd, is generally started by inetd from network services
listed in the /etc/inetd. conf file. The program works by becoming a security layer around
the network services that are started from the Internet daemon, and select other services.

Services such as telnet, FTP and IMAP are wrapped with the TCP Wrappers daemon, which
then subsequently executes the telnet, ftp, or imap daemon if the connection is

There are two configuration files that are used to control access to the services running on the
host with TCP Wrappers installed. The file /etc/ hosts.allowcontains the list of hosts and
the services for which it is authorized. the other file, /etc/hosts.deny, contains the list
of rejected hosts and services. Once you’ve disabled any services from /etc/inetd.conf that
no host should be using, you can add additional authentication to the remaining services. Start by
denying all incoming connections, and then adding TCP Wrapper support for all of the remaining
services your host will be offering.

This can be done by adding the following to /etc/hosts.deny:


This states that all inetd services are denied to all hosts (including the local
machine!). If the host you’re trying to protect is not offering any services to other computers, you
can start with the following in your /etc/ hosts.allow file:

 ALL: localhost

which states that all services are available to your local host. To offer tel-net service, for
example, to your local network, for example, you can use the following:

 in.telnetd: 192.168.1.

Notice the trailing period. This line signifies that we should permit access to the entire
network. One by one, you can add the services you need using this syntax. The /etc/hosts. allow
file is searched starting from the top for a match to service a request. If none is found, then
the /etc/ hosts. deny file is searched for a host and protocol match. If no match is found
there, the connection is then permitted.

See the hosts_access manual page for a full description of the syntax of these files.
Keep in mind this is only going to protect the machine from services that are using TCP Wrappers.
Things like sendmail, DNS, and Web services won’t be protected by these methods.

Now that you have a basic idea of what tools are available to build a firewall, you need to
determine what firewall model you will use. The general firewall FAQ (http://www.clark.net/pub/mjr/pubs/fwfaq/index.htm), written by Marcus Ranum and Matt Curtin is a good place to start.

Setting up Your Firewall

Security Firewall
Figure 2: A firewall is your single point of contact to the external

Your firewall program will be executed at startup (by inetd, for
example) and should include rules like:

1) Set a default deny policy.

   ipchains -P forward DENY

2) Allow connections destined for the http service on the Web

   ipchains -A forward -j
ACCEPT -p TCP -i eth0
-d http

3) Allow responses from web server to requesting host.

   ipchains. -A forward -j
ACCEPT -p TCP -i eth1
-s ! -y

The first statement defines the policy stance as “default deny.” This says to not forward
packets between the firewall interfaces by default. The second statement says that we’ll be
permitting requests to our Web server, on the HTTP port at IP address 192. 168.1.100, to be
forwarded across the interfaces of the firewall. Requests coming in from the Internet on
eth0 , our external interface, are permitted to continue on to our Web server. The third
command states that the response to the incoming HTTP request can be forwarded back to the host that
requested it. TCP connections require packets going in both directions in order to work, but we do
not want to allow originating outgoing connections from the Web server.

The ! -y combination is used hereto match TCP packets that do not (specified by the
exclamation point) contain TCP connection requests. By preventing connections from being initiated
by from your Web server, you can prevent it from becoming the source of a potential attack. This is
a very simple example. Consult the IP Chains HOWTO (http://metalab.unc.edu/mdw/HOWTO/IPCHAINS-HOWTO.html) for more in-depth information.

Firewalls are not a simple plug-in solution. A misconfigured firewall may actually be worse than
no firewall at all. Firewalls won’t protect your network from a modem listening for incoming calls
on your desk. Firewalls require diligence. You must monitor the firewall logs, keep track of
security updates, and make sure you stick to your firewall policy.

Investigating your system requires that you think like an intruder and learn how they work.
Reviewing your security policy and auditing your system for potential vulnerabilities is a mandatory
step toward securing your machines and network. By checking your system for vulnerabilities,
configuration problems, and exposure, you can get an idea of what an intruder would find.

Analyzing your System

Port scanners — programs that probe hosts and services on a network
looking for activity — can be used to make sure you are offering the services you expect to be
offering. Once an intruder has discovered your network, he will want to find out which hosts are
available, and what exploits he will need to break into your system. The Swiss Army knife of port
scanners is nmap, a tool that can provide the user with a list of the hosts on a network, the
services it is offering, and even the type and revision of the operating system. Once the intruder
obtains this information, he can find the appropriate exploit for your host.

Listing One: Typical nmap

 root# nmap -n -O -p 80 -sS

Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on (
Port State Protocol Service
80 open tcp http
TCP Sequence Prediction: Class=random positive increments
Difficulty=2572426 (Good luck!)
Remote operating system guess: Linux 2.1.122 – 2.1.132; 2.2.0-pre1 – 2.2.2

Nmap run completed — 1 IP address (1 host up) scanned in 1 second

Running nmap on a Web server might look like Listing One. It shows a scan of a
single host on a local network, to determine if it’s running a web server on port 80. Many times an
intruder will only scan specific ports at a time, to avoid unnecessary log entries,making intrusion
detection more difficult. This scan was successful in determining that it is a Linux machine, and it
is in fact running a Web server. Since it’sa Linux box, chances are it’s running Apache. The
intruder can then use this information to gather exploits for the Apache Web server, and try to gain
access. You can find the latest version of nmap at http://www.insecure.org/nmap.

Security Report
Figure 3: A sample Nessus host scanner report.

There are many other tools you can use to audit the security of your machine. Figure 3
shows a sample report from the Nessus host scanner, a graphical security tool that scans your host
for security vulnerabilities. Internet Security Systems produces several commercial products that
can be evaluated on your local host for free. SAINT, the Security Administrator’s Integrated Network
Tool (derived from SATAN), gathers as much information about remote hosts and networks as possible.

The Trinux Linux security toolkit, available at http://www.trinux.org, is a mini Linux
distribution small enough to fit in your shirt pocket, and contains many different tools to scan the
machines on your network. With such a great collection of security tools in one location,
administrators can turn a PC into a powerful machine to help in both locating security problems with
systems, and determining where the vulnerabilities might be. Take advantage of the developer’s
knowledge and ability to gather many of the most popular security tools in one location.

Security Checklist

If your goal
is to make your system as secure as possible, then you can start by removing at least all of the security problems that you do
know about. The most common ways a cracker can gain access include:

* Null passwords, unused accounts, and accounts with passwords the same as the account name are
amongst the easiest to exploit as well as prevent. An intruder doesn’t even need to see the shadow
file (the file that contains the encrypted passwords for accounts stored in the /etc/passwd file) to
perform this type of attack. Be sure to delete old accounts, enforce choosing good passwords, and
disable any unused accounts.

* Password “cracking” generally works by encrypting words from a dictionary and comparing the
resulting encrypted text with the stored password. Once a match is found, the intruder can gain
access. Periodically running Crack, or a similar password cracking programs, can ensure you have no
easily guessable passwords.

* r-services, such as rlogin, rsh and rcp, use the concept of “transitive trust”, whereby a user can
login to another machine on the network without a password by creating a .rhosts file in the home
directory of the user on the remote host. A .rhosts (read as “dot rhosts”) file in root’s home
directory could allow unauthorized root access to the system. Be sure to disable these services in
/etc/inetd.conf. The “secure shell”, ssh, is a common replacement for these insecure utilities, and
uses public-key cryptography to provide both host and user authentication, as well as data

* Provide as little information about your system as possible. Choose names for your hosts that
don’t obviously indicate their function. Sometimes this is hard to avoid, but calling your firewall
firewall.abccorp. com leaves little for the intruder to guess. Remove login banners that provide an
abundance of information about your company, or even the type of operating system you are using.

Dave Wreski is an Internet security engineer for a Fortune 500 company. He is a co-author of the
Linux Security HOWTO, and is developing the linuxsecurity.com Web site. He can be reached at

Comments are closed.