5.10. Network Security and access control.

Let me start this section by warning you that securing your machine and network against malicious attack is a complex art. I do not consider myself an expert in this field. The following mechanisms I describe will help. If you are serious about security, then I recommend you do some research of your own into the subject. There are many good references on the Internet relating to the security, including the Security-HOWTO

An important rule of thumb is: `Don't run servers you don't intend to use'. Many distributions come configured with all sorts of services that are configured and automatically started. To ensure even a minimum level of safety, you should go through your /etc/inetd.conf file. Comment out (place a `#' at the start of the line) any entries for services you don't intend to use. Good candidates are services such as: shell, login, exec, uucp, ftp and informational services such as finger, netstat and systat.

There are all sorts of security and access control mechanisms. I'll now describe the most elementary:

5.10.1. /etc/ftpusers

The /etc/ftpusers file is a simple mechanism that allows you to deny certain users from logging into your machine via ftp. When an incoming ftp connection is received, the /etc/ftpusers file is read by the ftp daemon program (ftpd). The file is a simple list of those users who are not allowed login. It might look something like:

	# /etc/ftpusers - users not allowed to login via ftp
	root
	uucp
	bin
	mail

5.10.2. /etc/securetty

The /etc/securetty file allows you to specify which tty devices root are allowed for login. The /etc/securetty file is read by the login program (usually /bin/login). Its format is a list of the tty devices names allowed: on all others root login is disallowed:

	# /etc/securetty - tty's on which root is allowed to login
	tty1
	tty2
	tty3
	tty4

5.10.3. The tcpd hosts access control mechanism.

The tcpd program listed in the samone /etc/inetd.conf provides logging and access control mechanisms to services. It is configured to protect.

When it is invoked by the inetd program, it reads two files containing access rules. It will then either alallow oreny access to the server it is protecting.

It will search the rules files until the first match is found. If no match is found, then it assumes that access should be allowed to anyone. The files it searches in sequence are: /etc/hosts.allow, /etc/hosts.deny. I'll describe each of these in turn. For a complete description of this facility, you should refer to the appropriate man pages (hosts_access(5) is a good starting point).

5.10.3.1. /etc/hosts.allow

The /etc/hosts.allow file is a configuration file of the /usr/sbin/tcpd program. The hosts.allow file contains rules describing which hosts are allowed access to a service on your machine.

The file format is quite simple:

	# /etc/hosts.allow
	#
	# <service list>: <host list> [: command]

service list: This is a comma delimited list of server names where this rule applies. Example server names are: ftpd, telnetd and fingerd.
host list: This is a comma delimited list of host names. You may also use IP addresses here. You may additionally specify either hostnames or addresses using wildcard characters to match groups of hosts. Examples include: gw.vk2ktj.ampr.org to match a specific host, .uts.edu.au to match any hostname ending in that string, 44. to match any IP address commencing with those digits. There are some special tokens to simplify configuration. Some of these are: ALL matches every host, LOCAL matches any host whose name does not contain a `.' ie is in the same domain as your machine and PARANOID matches any host whose name does not match its address (name spoofing). There is one last token that is also useful. The EXCEPT token allows you to provide a list with exceptions. This will be covered in an example later.
command: This is an optional parameter. This parameter is the full pathname of a command that would be executed everytime this rule is matched. It could, for example, run a command that would attempt to identify who is logged onto the connecting host. It could also generate a mail message or some other warning to a system administrator that someone is attempting to connect. There are a number of expansions that may be included. Some common examples are: %h expands to the name of the connecting host or address if it doesn't have a name, %d the daemon name being called.

An example:

  # /etc/hosts.allow
  #
  # Allow mail to anyone
  in.smtpd: ALL
  # All telnet and ftp to only hosts within my domain and my host at home.
  telnetd, ftpd: LOCAL, myhost.athome.org.au
  # Allow finger to anyone but keep a record of who they are.
  fingerd: ALL: (finger @%h | mail -s "finger from %h" root)

5.10.3.2. /etc/hosts.deny

The /etc/hosts.deny file is a configuration file of the /usr/sbin/tcpd program. The hosts.deny file contains rules describing which hosts are disallowed access to a service on your machine.

A simple sample would look something like this:

  # /etc/hosts.deny
  #
  # Disallow all hosts with suspect hostnames
  ALL: PARANOID
  #
  # Disallow all hosts.
  ALL: ALL

The PARANOID entry is redundant because the other entry traps everything in any case. Either of these entries would make a reasonable default (depending on your particular requirement).

Having an ALL: ALL default in the /etc/hosts.deny and then specifically enabling on those services and hosts that you want in the /etc/hosts.allow file is the safest configuration.

5.10.4. /etc/hosts.equiv

The hosts.equiv file is used to grant certain hosts and users access rights to accounts on your machine without having to supply a password. This is useful in a secure environment where you control all machines, but is otherwise a security hazard . Your machine is only as secure as the least secure of the trusted hosts. To maximize security, don't use this mechanism. Encourage your users not to use the .rhosts file as well.

5.10.5. Configure your ftp daemon properly.

Many sites will be interested in running an anonymous ftp server to allow other people to upload and download files without requiring a specific userid. If you decide to offer this facility, make sure you configure the ftp daemon properly for anonymous access. Most man pages for ftpd(8) describe in some length the proper procedures. You should always ensure that you follow these instructions. An important tip is to not use a copy of your /etc/passwd file in the anonymous account /etc directory. Make sure you strip out all account details (except those that you must have), otherwise you will be vulnerable to brute force password cracking techniques.

5.10.6. Network Firewalling.

Not allowing datagrams to even reach your machine (or servers) is an excellent means of security. This is covered in depth in the Firewall-HOWTO, and (more concisely) in a later section of this document.

5.10.7. Other suggestions.

Here are some other (potentially religious) suggestions for you to consider:

sendmail: Despite its popularity, the sendmail daemon appears with frightening regularity on security warning announcements. My recommendation is not to run it.
NFS and other Sun RPC services: Be wary of these services. There are all sorts of possible exploits for them. It is difficult finding an option to services like NFS. If you configure them, make sure you are careful to whom you allow mount rights.