Chapter 26
Network Security
|
|
|
|
|
 |
In this chapter: |
|
|
|
  |
How the network's topology influences security
|
  |
Determining which services are needed on which machines
|
  |
Using TCP wrappers that offer services to selected clients
|
|
|
|
 |
|
In chapter 24 we talked about host security. Here, we want to
extend the discussion to networked machines. These
topics are not exclusive of each other. Host security becomes even
more important if the machine is networked. With a standalone machine,
you know who your users are and who has physical access to the
terminals. Once your machine is either networked in the company-wide
local area network or on the Internet, you have to deal with
an unlimited number of people who will have access to your machine. The
physical barrier is gone. Being on the Internet means that your
machine is accessible by anyone anywhere.
In this chapter we'll try to build new barriers that deny access to
unauthorized guests. The last barrier is local security, which we
covered in Chapter 24. Even if we hope that no one
makes it that far, knowing that preventive measures are in place is a
good thing. In order to catch or even recognize an intruder. We'll see
that tools like Tripwire are priceless.
|
26.1 | Network Setup |
|
In Part III we discussed several network services and how to configure
them on a SuSE Linux system. Table 26-1
gives us a
quick review of these services. The table sorts the services into
stand-alone services and services wrapped by inetd.
|
Table 26-1 |
Overview of Network Services |
|
Name |
Service Description |
Standalone |
inetd |
echo |
echo input |
|
X |
daytime |
time (human readable) |
|
X |
time |
time (binary format) |
|
X |
chargen |
character generator |
|
X |
shell |
remote shell execution |
|
X |
login |
remote login |
|
X |
telnet |
remote terminal |
|
X |
talk |
online chat |
|
X |
ntalk |
online multi chat |
|
X |
finger |
user status report |
|
X |
systat |
system status report |
|
X |
netstat |
network status report |
|
X |
pop |
post office (mail) |
|
X |
ident |
user identification |
|
X |
ssh |
secure shell |
X |
|
DNS |
domain name resolution |
X |
|
NIS |
network information |
X |
|
FTP |
file transfer |
|
X |
HTTP |
world wide web |
X |
(X) |
SMTP |
mail transport/delivery |
X |
|
SMB |
filesystem export |
X |
(X) |
NFS |
filesystem export |
X |
|
DHCP |
host configuration |
X |
|
|
|
This distinction becomes important soon enough as we talk about using
the TCP wrapper as an additional level of protection for
inetd based services. Before you think about how to
protect the services you offer, you should be certain that you want to
offer them at all.
|
 |
If you are using your home set up, where the only network connection
is your modem dialup to your Internet service provider, you probably
don't need any of these services. Disable them all to increase your system
security. By not offering any service, nobody can abuse them and break
into your system.
|
|
If you are maintaining systems in a bigger environment,
things are different. It still makes sense to categorize the
machines you maintain of and develop standard setups for different
kinds of machines. Figure 26-1
shows a typical setup for a
medium-sized network.
|
Figure 26-1 |
 |
| Sample Topology of a medium sized Network |
|
The machines within this network are clustered into four groups that
reflect their functions and level of attention you should give them in
terms of security.
|
26.1.1 | Firewalls |
|
A firewall machine virtually separates networks from each other, even
if they are physically connected through the firewall machine. The
purpose is to prevent intruders from breaking into the internal
network, while allowing users on the inside to access services on the
outside of the firewall. In figure 26-1 you see two
distinct firewall machines. One is the 'inside' firewall machine,
which separates the workstation's network from the publicly accessible
portion. The other is the 'outside' firewall that secures the publicly
accessible servers from the Internet. We'll learn more about firewalls
in chapter 1
, so I'll cover only a few points here.
Firewalls are your primary weapon against attacks. Their only purpose
is to filter traffic and block those connections that you don't want
to have. There should be no way to logon to a firewall machine over
the network. You should disable all services on the firewall
machines. The last machine you want to be hacked is a firewall. Once
this barrier is down, your network protection is gone.
The reason for having two dedicated firewall machines in this setup is
the need to access services from the Internet. You may want to have a
Web presence for your customers to do business online or offer FTP
service. You may also want to run a mail server or maintain your own
domain name server. This means the firewall directed to the Internet
has to allow this kind of traffic. The other firewall can be set up to
be much more restrictive. Very little traffic has to pass this
barrier. No one should be able to access your local work environment
from the outside.
|
26.1.2 | Publicly Accessible Servers |
|
These machines are the most vulnerable portions of the network. They
have to provide services to the public and so must be
accessible by virtually everyone. It is a good idea to have single
machines dedicated to each service. These machines should only allow
access to the service specified. For convenience you may
want to devise remote login using secure shell to ease the
maintenance for these services.
Dedicating machines to individual services allows you to avoid a
single point of failure. Assume that you run your mail and Web
server on the same machine. One of those services may be hacked
(sendmail was always a popular target for break in
attempts). Instead of losing one service, you will lose all services
installed on this machine. Avoid single point of failures by
separating services with machines dedicated to them. As an extra layer
of precaution, don't share filesystems (NFS happens to be highly
insecure) between those machines.
|
26.1.3 | Local Server |
|
The local server is protected by two firewall stages. This eases some
security needs, but shouldn't make us too lax about the network
setup. Obviously, this machine has to provide all services needed by
the workstations connected to it. Carefully evaluate which services
you really need and those that are unnecessary. Shut down the ones you
don't need and make sure the open services are only available for the
clients in your local network. Later on we'll see how to use TCP
wrappers to filter requests by IP addresses. This is an additional
level of security that you should use. There is no such thing as the
perfect firewall. Accidents happen, and they usually do at the worst
moment. Use the existing mechanisms and set up the server
accordingly. The more barriers you build the better.
|
26.1.4 | Workstations |
|
These machines are mostly clients which mean they ordinarily don't
need to provide any services. Some services, like finger
and talk are intended to be used from client to client,
so you may want to allow those. Each site has it's own particular
needs, and you will have to determine which services you'll need and
which you'll want to shut down. It's also a question of user
education. At first glance the rlogin service may be
convenient, but once you know how to use the secure shell, you'll see
that it not only brings increased security, but also makes forwarding
of X Window connections and automatic logon (without password request)
much easier. We covered this subject before, but educating users in
new technologies is worth it. Spend time creating a standard setup for
your users and prepare a document explaining it. Get rid of old-timers
like rlogin, rsh and
telnet. There are better replacements and are not harder
to use. As with ssh, once you (and your users) are used
to it, the benefits are worth the transition process.
|
26.2 | The TCP Wrapper |
|
Earlier we talked about wrapping the inetd controlled services.
Here we'll see how to do it and which advances this mechanism
has as opposed to starting the service directly with inetd
SuSE uses tcpd as a TCP wrapper. The tcpd
program can be set up to monitor incoming requests for all services
normally started by inetd. Basically, it can be used for
all services which have one-to-one mapping onto executable files. The
operation is as follows: whenever a request for service arrives, the
inetd daemon is tricked into running the
tcpd program instead of the desired
server. Tcpd logs the request and does some additional
checks. When all is well, tcpd runs the appropriate
server program and goes away. Optional features are: pattern-based
access control, protection against hosts that pretend to have someone
else's host name, and protection against hosts that pretend to have
someone else's IP address.
|
 |
Connections that are monitored by tcpd are reported through the
syslog(3) facility. This means you can look up all service
requests in the file /var/log/messages. Each record contains a
time stamp, the client host name and the name of the requested
service. The information can be useful to detect unwanted activities,
especially when logfile information from several hosts is merged.
|
|
Another option is that tcpd supports a simple form of
access control that is based on pattern matching. The access control
software provides hooks for executing shell commands when a pattern
fires. We'll talk more about this in a second.
The authentication scheme of some protocols (rlogin,
rsh, etc.) relies on host names. Some implementations
believe the host name that they get from any random name server; while
other implementations are more careful but use a flawed algorithm.
Tcpd verifies the client host name that is returned by
the address-to-name DNS server by looking at the host
name and address that are returned by the
name-to-address DNS server. If any discrepancy is
detected, tcpd concludes that it is dealing with a host
that is pretending to have someone else's host name and refuses the
service.
Optionally, tcpd disables source-routing socket options
on every connection that it deals with. This will take care of most
attacks from hosts that pretend to have an address that belongs to
someone else's network. UDP services do not benefit from this
protection.
Remember that this protection affects only services provided by the
local host itself. If the host acts as a router and forwards traffic
to other machines, those machines will have to use tcpd
to benefit from its protection mechanisms.
|
26.2.1 | Enabling tcpd |
|
In chapter 11 we saw how to configure inetd
to start services mapped to port numbers and it was mentioned that
tcpd is already used in the standard SuSE setup. If you
look at the preinstalled file /etc/inetd.conf, you will
notice that in the last column in the configuration, where the service
daemon is supposed to be, it actually contains tcpd with
the service daemon as parameter:
|
|
[...]
#
# These are standard services.
#
ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -a
# ftp stream tcp nowait root /usr/sbin/tcpd proftpd
# ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd
#
# If you want telnetd not to "keep-alives" (e.g. if it runs over a ISDN
# uplink), add "-n". See 'man telnetd' for more deatails.
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
# nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/leafnode
# smtp stream tcp nowait root /usr/sbin/sendmail sendmail -bs
# printer stream tcp nowait root /usr/sbin/tcpd /usr/bin/lpd -i
#
# Shell, login, exec and talk are BSD protocols.
# The option "-h" permits ``.rhosts'' files for the superuser. Please look at
# man-page of rlogind and rshd to see more configuration possibilities about
# .rhosts files.
shell stream tcp nowait root /usr/sbin/tcpd in.rshd -L
# shell stream tcp nowait root /usr/sbin/tcpd in.rshd -aL
#
# If you want rlogind not to "keep-alives" (e.g. if it runs over a ISDN
# uplink), add "-n". See 'man rlogind' for more deatails.
login stream tcp nowait root /usr/sbin/tcpd in.rlogind
# login stream tcp nowait root /usr/sbin/tcpd in.rlogind -a
# exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
talk dgram udp wait root /usr/sbin/tcpd in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd in.talkd
[...]
|
|
For each service the program /usr/sbin/tcpd is listed and
gets the actual server as passed on as parameter together with the
servers parameters.
This means that SuSE has already set up the TCP wrapper for us. Remember to do
the same if you add or change services in this file.
|
26.2.2 | Configuring tcpd |
|
Tcpd uses two files with rules to determine who has
access to a service and who has not. These files are
/etc/hosts.allow and /etc/hosts.deny. If a
client tries to access a service, hosts.access will
consulted and will search for a rule which allows this client to
access the desired service. If nothing is found, the search continues
in hosts.deny, and if a rule from this file matches the
client/service pair, access will be denied. If the search didn't find
any matching entries, access will be granted. A non-existing access
control file is treated as if it were an empty file. Thus, access
control can be turned off by providing no-access control files.
Each access control file contains zero or more rules. These rules are
processed in order of appearance. The search terminates when a
matching rule is found. The rules should satisfy the following format
convention:
|
|
daemon list : client list [ : shell command ]
|
|
The daemon list is a list of one or more daemon
process names or wildcards. The client list is a list
of one or more host names, host addresses, patterns or wildcards that
will be matched against the client host name or address. List elements
should be separated by blanks and/or commas.
|
| Shell Commands |
|
The optional shell command is executed by /bin/sh with
standard input, output, and error connected to
/dev/null. The shell commands should not rely on the
PATH setting. Instead, they should use absolute path
names, or they should begin with an explicit
PATH=whatever statement. Within the shell command you can
use some \% expansions to pass information about the rules invocation
to the command. Table 26-2
lists these expansions.
|
Table 26-2 |
tcpd shell expansions |
|
Parameter |
Meaning |
%a |
The client host address |
%A |
The server host address |
%c |
Client information: user@host, user@address, a host name, or just an address, depending on how much information is available |
%d |
The daemon process name |
%h |
The client host name or address, if the host name is unavailable. |
%H |
The server host name or address, if the host name is unavailable. |
%n |
The client host name (or "unknown" or "paranoid"). |
%N |
The server host name (or "unknown" or "paranoid"). |
%p |
The daemon process id. |
%s |
Server information: daemon@host, daemon@address, or just a daemon name, depending on how much information is available. |
%u |
The client user name (or "unknown"). |
%% |
Expands to a single '%' character. |
|
|
|
 |
You can use these shell commands to perform additional logging or
to fire off an alarm if an unwanted host tries to connect to
your machine. You can also set up simple traps , i.e., if some machine
tries to access an unauthorized service at your machine, you can run a
finger command to this host to get a list of users logged in at
that time and write it to a log file.
|
|
But this brings us too far ahead. We should first look at some
examples to understand the general structure of the rules. Before
this, we'll discuss a general issue regarding the use of
tcpd. You will have to make a decision on whether you
want to have a mostly open system or a mostly closed one. 'Mostly
open' means that you first allow everything, then use the deny file to
filter a small set of services. 'Mostly closed' means that everything
is forbidden that hasn't been explicitly allowed. The latter is
recommended for the vast majority of systems. It's far more effective
to keep a high level of security, because the danger of forgetting a
service that shouldn't be open is eliminated. If you add services,
they are not available until you explicitly 'set them free'.
To close down all services, use the line
|
|
ALL:ALL
|
|
in /etc/hosts.deny. The first ALL stands for
all daemons defined in /etc/inetd.conf. The second
argument ALL matches all hosts. All services are closed
to everyone. To provide access to services, you have to allow them in
/etc/hosts.allow. Given your local domain is
simpsons.com and you want to allow services only for
members of this domain, the line
|
|
ALL:.simpsons.com
|
|
in /etc/hosts.allow would do exactly this. Specifying
ALL as daemon list means all daemons again, and the
domain name in the client list enables these services for all members
of this domain. If you don't want to allow all services, but only
telnet, then replace ALL with the name of
the daemon as specified in /etc/inetd.conf:
|
|
in.telnetd:.simpsons.com
|
|
This will allow only machines of the domain simpsons.com
to telnet to your machine. We've already used some possible shortcuts
and wildcards, so it's time to see what other tools we can use.
|
| Replacement Patterns |
|
The access control language of tcpd implements the
following patterns:
|
|
  |
A string that begins with a dot (.) character.
A host name is matched if the last components of its name match the
specified pattern. We saw an example of this in the configuration
above.
|
  |
A string that ends with a dot (.) character.
A host address is matched if its first numeric fields match the given
string. For example, the pattern 192.168.0. matches the
address of all hosts in the 192.168.0.* class C net.
|
  |
A string that begins with an "@" character (@) is treated
as an NIS (formerly YP) netgroup name. A host name is matched if it
is a host member of the specified netgroup. Netgroup matches are not
supported for daemon process names or for client user names.
|
  |
An expression of the form n.n.n.n/m.m.m.m is interpreted
as a net/mask pair.
A host address is matched if net is equal to the
bitwise AND of the address and the
mask. For example, the pattern
131.155.72.0/255.255.254.0 matches every address in the
range 131.155.72.0 through 131.155.73.255.
|
|
|
|
| Wildcards |
|
In addition, some wildcards are supported:
|
|
  |
ALL:
The universal wildcard, which always matches.
|
  |
LOCAL:
Matches any host whose name does not contain a dot character.
|
  |
UNKNOWN:
Matches any user whose name is unknown, and matches any host whose
name or address are unknown. This pattern should be used with care:
host names may be unavailable due to temporary name server problems.
A network address will be unavailable when the software cannot figure
out what type of network it is talking to.
|
  |
KNOWN:
Matches any user whose name is known, and matches any host whose name
and address are known. This pattern should be used with care: host
names may be unavailable due to temporary name server problems. A
network address will be unavailable when the software cannot figure
out what type of network it is talking to.
|
  |
PARANOID:
Matches any host whose name does not match its address.
|
|
|
Last but not least, there is the EXCEPT
operator. Intended use is of the form: list_1 EXCEPT
list_2; this construct matches anything that matches
list_1 unless it matches list_2. The
EXCEPT operator can be used in daemon lists and in client
lists. The EXCEPT operator can be nested: if the control
language would permit the use of parentheses, a EXCEPT b EXCEPT
c would parse as (a EXCEPT (b EXCEPT c)).
|
| Client Username Lookup |
|
When the client host supports the RFC 931 protocol or one of its
descendants (TAP, IDENT, RFC 1413), the wrapper programs can retrieve
additional information about the owner of a connection. Client
username information, when available, is logged together with the
client host name, and can be used to match patterns like this:
|
|
daemon_list : ... user_pattern@host_pattern ...
|
|
A user pattern has the same syntax as a daemon process
pattern, so the same wildcards apply (netgroup membership
is not supported). One should not get carried away with
username lookups because:
|
|
  |
The client username information cannot be trusted
when it is needed most, such as when the client system has been
compromised. In general, ALL and (UN)KNOWN are the only
user name patterns that make sense.
|
  |
Username lookups are possible only with TCP-based
services, and only when the client host runs a
suitable daemon; in all other cases the result is
unknown.
|
  |
Username lookups may cause noticeable delays for
non-Unix users. The default timeout for username
lookups is 10 seconds- too short to cope with slow
networks, but long enough to irritate PC users.
|
|
|
Selective username lookups can alleviate the last problem. For
example, a rule like:
|
|
daemon_list : @pcnetgroup ALL@ALL
|
|
would match members of the PC netgroup without performing user
name lookups, but would perform username lookups with all
other systems.
You see that tcpd provides you with a wide variety of
configuration options which enable you to create a very selective
setup of who you want to open your machine too.
|
 |
This mechanism only covers local services controlled by
inetd. For standalone services, or services on other hosts (if
your machine acts as a router), you will need to use the kernel IP
filtering mechanisms that we'll cover in the following chapters.
|
|
|
 |
Summary: |
|
In this chapter, we learned that it makes sense to structure your
network into areas according to the type access and level of security needed. Publicly
accessible services should be outside of your local workstation network
and firewalls should be in place to secure the publicly accessible
machines and in a second stage your local workstations.
The TCP wrapper tcpd can be used to create a filter allowing
only selected hosts and users to access services on the local machine.
The recommended setup is to shut everyone out, then incrementally
open necessary services to specified machines and/or users.
|
 |