Network Security
 

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.
 
 

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.

 
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.
 

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.
 

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.
 

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.
 

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 

 

[...] 

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 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.
 
 

ALL:ALL  

ALL:.simpsons.com  

in.telnetd:.simpsons.com  

The access control language of tcpd implements the following patterns:
 

In addition, some wildcards are supported:
 

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 ...  

daemon_list : @pcnetgroup ALL@ALL