Tuesday, December 20, 2016

Securing I

Configuring xinetd and inetd


In this part of this chapter, you learn how to configure Linux
“super-daemons.” Most Linux distributions install a wide variety of
network services during the system installation process. Most of these
services, such as Telnet, are very handy and provide a valuable
service. However, they aren’t needed most of the time. We need a way
to provide these services when requested but then unload them when
they aren’t needed, saving memory, reducing CPU utilization, and
increasing the overall security of the system.



Depending on your distribution, there are two ways to do this. The
following options are discussed here:



Configuring xinetd
Configuring inetd





Configuring xinetd

Many Linux distributions include a special daemon called xinetd that
can be used to manage a number of different network services. In this
part of this chapter, you learn how to configure and use xinetd. We’ll
discuss the following topics:



How xinetd works
Configuring xinetd network services
Using TCP Wrappers



Let’s begin by discussing how the xinetd daemon works.



How xinetd Works

The xinetd daemon is a super-daemon. It’s called a super-daemon
because it acts as an intermediary between the user requesting network
services and the daemons on the system that provide the actual
service. This is shown in Figure 17-26.




When a request for one of the network services managed by xinetd
arrives at the system, it is received and processed by xinetd, not the
network daemon being requested. The xinetd daemon then starts the
daemon for the requested service and forwards the request to it. When
the request has been fulfilled and the network service is no longer
needed, xinetd unloads the daemon from memory.




Some of the network services managed by xinetd include the following:



• chargen
• daytime
• echo
• ftp
• pop3
• rsync
• smtp




Configuring xinetd Network Services


As with all the network services I’ve discussed, the xinetd
configuration files are stored in /etc. The xinetd daemon itself is
configured using the



/etc/xinetd.conf 


file. Generally speaking, you won’t need to make many changes to this file. The default
configuration usually works very well.



At the end of this file you will notice a directive that reads



includedir /etc/xinetd.d



This line tells the xinetd daemon to use the configuration files in
/etc/xinetd.d. These files tell xinetd how to start each service when
requested. Each of these files is used to configure the startup of a
particular service managed by xinetd.


For example, the 


vsftpd file 


in


/etc/xinetd.d 


is used to configure the vsftpd FTP server daemon. The xinetd configuration
settings for vsftpd in this file are shown here:



service ftp
{

socket_type     = stream
protocol        = tcp
wait            = no
user            = root
server          = /usr/sbin/vsftpd

# server_args        =
# log_on_success     += DURATION USERID
# log_on_failure     += USERID
# nice               = 10
   disable            = yes


}




This file doesn’t configure the daemon itself. It only tells xinetd
how to start up the daemon. The actual configuration file for the
vsftpd daemon itself is in /etc/vsftpd.conf.


One of the most important parameters in the 


/etc/xinetd.d/vsftpd



file is the disable directive.


This directive specifies whether or not xinetd is allowed to start the
daemon when requested.



In the preceding example, this directive is set to yes, which means the daemon will not 
be started when requested. 



The daemon to actually start is specified by the 


server = directive


In the example, xinetd will start the /usr/sbin/vsftpd daemon. 


server          = /usr/sbin/vsftpd



To enable this daemon, you need to edit this file and change the disable
parameter to a value of no.



disable            = no




After changing a value in any of the files in /etc/xinetd.d, you need to 
restart the xinetd daemon using its init script in /etc/rc.d/init.d or /etc/init.d.



TIP  If you enable a service provided by xinetd, you’ll need to create
an exception in your Linux system’s host firewall to allow traffic for
the IP port used by the daemon.






Using TCP Wrappers


If you enable a particular service using its configuration file in the
/etc/xinetd.d/ directory, any host can connect to it through xinetd.



However, depending on how your system is deployed, you may need to
control access to these network services. You may want to limit access
to only a specific set of hosts and deny access to everyone else.



If this is the case, you need to configure these services to use TCP
Wrappers, which are used by xinetd to start and run the network
services using a set of configuration files that specify who can and
who can’t access the service.




To use TCP Wrappers, you first need to enable the functionality in
each service’s configuration file in /etc/xinetd.d. Do the following:



1. Verify that the tcpd package has been installed on your Linux system.


2. Open the appropriate configuration file in a text editor.


3. Comment out the existing server = line from the file.


4. Add the following line:


     server      = /usr/sbin/tcpd


This will cause xinetd to start the tcpd daemon instead of the service
daemon itself.



5. Add the following line:


     server_args       = path_to_daemon


This tells the tcpd daemon to then run the requested network daemon.
In the example shown here, the /etc/xinetd.d/telnet file has been
configured to run the vsftpd daemon within a TCP Wrapper:



service ftp
     {
# #
socket_type     = stream
protocol        = tcp
wait            = no
user            = root
# server          = /usr/sbin/vsftpd


server          = /usr/sbin/tcpd
server_args     = /usr/sbin/vsftpd


# log_on_success     += DURATION USERID
# log_on_failure     += USERID
# nice               = 10
   disable            = no

}



6. Save the file and restart the xinetd daemon.





Next, you need to create your access controls. The tcpd daemon uses
the 



/etc/hosts.allow 


and


/etc/hosts.deny 



files to specify who can access the services it manages.



Entries in /etc/hosts.allow are allowed access.


Hosts in /etc/hosts.deny are not allowed access. 



The syntax for both of these files is



service: host_addresses



As these files are processed, the search stops as soon as a matching
condition is found in a file. Files are no longer processed after this
occurs. The following steps occur in the order shown:


Access will be granted if a matching entry is found in the
  /etc/hosts.allow file.

If not, access will be denied if a matching entry is found in the
  /etc/hosts.deny file.

If this does not occur, access will be granted.




For example, suppose you needed to configure the /etc/hosts.allow file
to allow access to the vsftpd daemon for just a few specific hosts.
The following entry grants access to the vsftpd service to hosts with
the IP addresses of 192.168.1.10 and 192.168.1.102.



vsftpd:     192.168.1.10, 192.168.1.102




Some distributions use the inetd daemon instead of xinetd. This daemon
works in much the same manner as xinetd. Let’s learn how it works
next.







Configuring inetd


The inetd daemon is a super-daemon like xinetd, but it is typically
used on older Linux distributions. Like xinetd, the inetd daemon acts
as a mediator for connection requests to network services running on
the Linux host. It accepts connection requests from client systems,
starts the requested service, and then forwards the requests from
clients to the newly started daemon. When the transaction is complete
and the connection from the client is terminated, the daemon is
stopped on the Linux host.



As we discussed with xinetd, managing the network services on your
Linux host in this way has advantages and disadvantages. Key among
these is the fact that it conserves system memory and CPU resources.
The network daemon is started only when it is needed. When it isn’t
needed, it’s removed from memory until it is requested again. However,
this benefit comes at a cost in terms of latency. When a service is
requested by a client, the client must wait for a short period of time
while the necessary daemon is loaded and the connection established.
Therefore, inetd (and xinetd) should only be used to manage network
services that are needed only occasionally on the system.




The inetd daemon is configured using the 



/etc/inetd.conf 



file. Unlike the xinetd daemon, all the services managed by inetd are configured in
this single configuration file. 



Each line in this file configures a single service to be managed by inetd. The syntax used in 
inted.conf is shown here:



service_name  socket_type  protocol  flags  user  executable  arguments




Each of the parameters in this line is described in Table 17-6. Here
is a sample entry in inetd.conf for the vsftpd daemon:








ftp    stream    tcp    nowait    ftp      /usr/sbin/tcpd     vsftpd




Notice in this example that you can use TCP Wrappers with inetd just
as you did with xinetd. In this example, when a client tries to
establish an FTP connection with this Linux host, the inetd daemon
will start the tcpd daemon and pass to it the name of the actual
daemon to be started (vsftpd) as a server argument. As with xinetd,
using TCP Wrappers with inetd allows you to control access to the
network services running on the host using




the



/etc/hosts.allow 



and



/etc/ hosts.deny 



files.










LX0-104 Exam Objectives (V and U, 323, 647 - 689)

No comments:

Post a Comment