144.

function OpenWin(url, w, h) { if(!w) w = 400; if(!h) h = 300; window.open(url, "_new", "width=" + w + ",height=" + h + ",menubar=no,toobar=no,scrollbars=yes", true); }

Book: LPI Linux Certification in a Nutshell
Section: Chapter 20.  Networking Services (Topic 1.13)



20.1 Objective 1: Configure and Manage inetd and Related Services

Most network services execute as software daemons, which "listen" to a specific port for inbound requests from client software on the outside. (See Section 19.1 for a discussion on ports.) For example, the Telnet daemon, telnetd, listens on port 23 for inbound requests from Telnet clients. Each such request is handled by the daemon, which starts the login process for the client. If a single server were to offer many such services, many of the telnetd daemons would be running at any one time to handle multiple inbound Telnet requests.

In order to reduce the number of daemons necessary to service requests, the Internet superdaemon, or inetd, was created. Instead of running individual daemons for each service, inetd runs as a single service listening to all of the desired port numbers (23 for telnet, 21 for ftp, etc.). When an inbound request is received, it is handed off to the actual daemon for processing. With this scheme, the host daemons are still used as before, but they run only when needed and are started by inetd, freeing resources for other tasks.

This scheme also offers another convenience. Instead of launching the target daemons directly, inetd is usually configured to use the TCP wrappers access control facility. TCP wrappers, or tcpd , allows the administrator to define restrictions on the origin of inbound requests. TCP wrappers is described fully in Section 21.1.

inetd is well suited for services requested on a relatively infrequent basis, such as telnet and ftp. However, using inetd on services such as Apache would significantly impact the performance of a heavily used server under constant load. In such cases, it is common to simply configure the web server to handle its own connections.

20.1.1 The inetd Configuration File

inetd is usually started during system initialization and continues to run indefinitely (or until the process is stopped). When started (and later in response to signal SIGHUP), inetd reads its configuration file from /etc/inetd.conf, which is nothing more than a plain text file that defines the services managed by inetd. (Commented lines begin with #.) Example 20-1 shows portions of an inetd.conf, with lines wrapped to fit the page (your inetd.conf will be different and should be configured with your security requirements in mind; more on this later).

Example 20-1. Sample inetd.conf File
# /etc/inetd.conf # Internet server configuration database # See inetd(8) for further information. # <service_name> <socket_type> <proto> <flags> <user>  <server_path>      <args> # ftp              stream       tcp    nowait   root    /user/sbin/tcpd   /user/sbin/in.ftpd telnet           stream       tcp    nowait   root    /usr/sbin/tcpd    /usr/sbin/in.telnetd # pop-2            stream       tcp    nowait   root    /usr/sbin/tcpd    ipop2d pop-3            stream       tcp    nowait   root    /usr/sbin/tcpd    ipop3d imap             stream       tcp    nowait   root    /usr/sbin/tcpd    imapd # finger           stream       tcp    nowait   nobody  /usr/sbin/tcpd    /usr/sbin/in-fingerd ident            stream       tcp    nowait   nobody  /usr/sbin/identd  identd -I # tftp             dgram        udp    wait     nobody  /usr/sbin/tcpd    /usr/sbin/in.tftpd /boot bootps           dgram        udp    wait     root    /usr/sbin/bootpd  bootpd -i -t 120

Each noncommented line in inetd.conf must contain each of the following fields:

service_name

This is the name of a service as defined in /etc/services.

socket_type

This entry specifies one of a few types of communications the service will use. It's usually stream or dgram.

proto

This field specifies the service's protocol from among those in /etc/protocols. For most services, it will be either tcp or udp, which correspond to the stream and dgram socket types.

flags

The wait/nowait (.max) flag is used only for datagram services, where it helps to control the handling of inbound requests and is typically set to wait. It should be set to nowait for others. You can limit the number of server instances spawned by inetd within any 60-second interval by appending a dot and the maximum number (.max). For example, to limit the service to 20 instances, use .20 after the nowait flag:

nowait.20

The default maximum is 40 instances (.40).

user[.group]

This entry specifies the username (and optionally the group name) under which the service should execute, allowing them to be run with fewer permissions than root. A typical entry is the user nobody.

server_ path

This field is the full path to the executable daemon of the server program. When TCP wrappers is used, this entry specifies tcpd, as shown in Example 20-1.

args

This last entry on the line may consist of multiple fields. It contains the name of the server daemon and all arguments that are to be passed to it.[1]

[1] The daemon name is actually the first argument, or argv[0] from a programming point of view.

In many Linux installations, a majority of the lines in inetd.conf are commented out to increase security. The fewer services a system offers, the more likely it is to stand up to an attack. You should review your file to be certain that only necessary services are offered.

20.1.1.1 TCP wrappers with inetd

If you have a need to control access to inetd-managed services by IP address or by domain name, you may wish to configure TCP wrappers. For each inbound connection to a service protected by TCP wrappers, tcpd consults two files that define access:

/etc/hosts.allow

If a rule in this file is met, access to the service is allowed.

/etc/hosts.deny

If a rule in this file is met, access to the service is denied.

Rules in these files can be constructed to match all services or alternatively to match specific services. If no match occurs in the two files, access to the service (or services) is allowed. It is common to specify particular rules in the .allow file and provide a blanket denial in the .deny file, thereby limiting access to clients you specifically allow.

The language in the control files consists of a service list, followed by a colon, followed by a list of hosts. Hosts may be specified by name or by IP address. For example, to deny access to all service except inbound ftp from the local domain, these two simple files could be used:

hosts.allow

This entry allows FTP access to clients in the local domain:

ftp: LOCAL
hosts.deny

This entry denies access to all services from all clients:

ALL: ALL

The hosts.deny file is consulted after hosts.allow, enabling the administrator to define specific allow rules that will be matched prior to deny rules or a blanket denial.

20.1.2 Starting and Stopping Services

If inetd is not running, all of the services it manages are disabled. Likewise, if inetd is reconfigured, any changes to individual managed services take effect at the same time. To cause inetd to reread its configuration file, simply send it SIGHUP:

$ killall -HUP inetd

All inetd services that are commented out or missing from /etc/inetd.conf will be disabled. However, a number of other services on Linux systems are managed through other means -- typically through the runlevel system and the series of scripts and links in /etc/rc.d. See Section 5.2 for details on starting and stopping services such as Apache (httpd).

On the Exam

You must be generally familiar with the content and function of inetd.conf, hosts.allow, and hosts.deny. Memorizing configuration details is not necessary, but be prepared for questions on available services and the effect of TCP wrappers rules in the hosts.allow and hosts.deny files. Be sure you understand what happens to services that are commented out of inetd.conf, and that inetd must be signaled to reread the control file after any changes.

 


LPI Linux Certification in a Nutshell
LPI Linux Certification in a Nutshell (In a Nutshell (OReilly))
ISBN: 0596005288
EAN: 2147483647
Year: 2000
Pages: 194

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net