| Linux Networking HOWTO - DocBook Rev .02 | ||
|---|---|---|
| Prev | Chapter 5. Generic Network Configuration Information. | Next |
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.
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 |
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 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).
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] |
This is a comma delimited list of server names that this rule applies to. Example server names are: ftpd, telnetd and fingerd.
This 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.
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, 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) |
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.
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.
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.
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.
Here are some other, potentially religious suggestions for you to consider.
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.
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.