The candidate should be able to configure tcpwrappers to allow connections to specified servers from only certain hosts or subnets.
Key files, terms and utilities include:
inetd.conf, |
tcpd |
hosts.allow, hosts.deny |
xinetd |
Before tcp wrappers were born, a daemon called inetd was listening for incoming network connections and took it upon itself to start the appropriate server program when needed.
For security reasons, it became necessary to only allow certain type of incoming connections from certain hosts. The inetd daemon listens to incoming requests and instead of starting the server program needed, inetd starts tcpd which does some additional checks (such as where the request came from). If tcpd determines that the connection should be honored, the server program needed is launched by tcpd.
Tcp wrappers do not protect against network sniffing because tcp wrappers do not encrypt the traffic. Use ssh encryption to prevent network sniffing.
The first thing to do when you want a service to be started by
tcpd is to tell inetd that this
is the case. To tell inetd that we want the ftp
server wu-ftpd to be started by
tcpd, we must add the following line to
inetd's configuration file
/etc/inetd.conf:
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/wu-ftpd -l
The lines of /etc/inetd.conf are made up of the
following mandatory fields:
This is the name of the service as specified in the file
/etc/services, in this case “ftp”.
This is the socket type which should be one of “stream”, “dgram”, “raw”, “rdm” or “seqpacket”. In this case the socket type for ftp is “stream”.
This is the protocol type used as specified in the file
/etc/protocols, in this case “tcp”.
This entry specifies which user/group the program should run with. In this case, “root”.
This entry contains the pathname of the program to be executed by inetd when a request is made to that socket.
This is the program, with it's command line arguments, that is to be started by inetd if the criteria are met. In this case, this is /usr/sbin/wu-ftpd -l.
The next thing to do is to edit the contents of the files
/etc/hosts.allow and
/etc/hosts.deny which both use the same format:
daemon_list : client_list [ : shell_command ]
This is a list of one or more daemon process names or
wildcards. Consult the man page of
host_access(5) for details.
This 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. Consult the man page of
host_access(5) for details.
Command to be run by the shell when the rule matches.
The access control software consults two files. The search stops at the first match: Access will be granted when a (daemon,client) pair matches an entry in the /etc/hosts.allow file.
Or access will be denied when a (daemon,client) pair matches an
entry in the /etc/hosts.deny file.
Otherwise, access will be granted. A non-existing access control file is treated as an empty file. Thus, access control can be turned off by providing no access control files.
This stands for “eXtended InterNET services Daemon” and replaces the combo inetd and tcpd. xinetd can do the same things and offers extra functionality such as: more sophisticated access control, preventing DoS attacks, extensive logging. For more information, take a look at the Xinetd Homepage .