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 at all and while 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 subject, 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 configured and automatically started. To ensure even a minimum level of safety you should go through your /etc/inetd.conf file and 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 describe the most elementary of them.

/etc/ftpusers

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

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

/etc/securetty

The /etc/securetty file allows you to specify which tty devices root is allowed to login on. 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

== The tcpd hosts access control mechanism.==

The tcpd program you will have seen listed in the same /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 and either allows or denies access to the server it is protecting accordingly.

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

/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
      is a comma delimited list of server names that this rule applies
      to.  Example server names are: ftpd, telnetd and fingerd.


   host list
      is a comma delimited list of host names. You may also use IP
      addresses here. You may additionally specify 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
      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, or to 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)

/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 really redundant because the other entry traps everything in any case. Either of these entry 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.

/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 a security hazard otherwise. Your machine is only as secure as the least secure of the trusted hosts. To maximize security, don't use this mechanism and encourage your users not to use the .rhosts file as well.

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 how to go about this. 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.

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.

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. Its up
      to you, but I choose not to run it.


   NFS and other Sun RPC services
      be wary of these. There are all sorts of possible exploits for
      these services. It is difficult finding an option to services
      like NFS, but if you configure them, make sure you are careful
      with who you allow mount rights to.