Archive for the tag 'xinetd'

SBDavid
Dec 13th, 2010

xinetd Services & security errata

xinetd Services & security errata

Services controlled by the xinetd super service only run when a there is an active connection. Examples of services controlled by xinetd include Telnet, IMAP, and POP3.

Because new instances of these services are launched by xinetd each time a new request is received, connections that occur after an upgrade are handled by the updated software. However, if there are active connections at the time the xinetd controlled service is upgraded, they are serviced by the older version of the software.

To kill off older instances of a particular xinetd controlled service, upgrade the package for the service then halt all processes currently running. To determine if the process is running, use the ps command and then use the kill or killall command to halt current instances of the service.

For example, if security errata imap packages are released, upgrade the packages, then type the following command as root into a shell prompt:

ps aux | grep imap

This command returns all active IMAP sessions. Individual sessions can then be terminated by issuing the following command:

kill [ PID ]

If this fails to terminate the session, use the following command instead:

kill -9 [ PID ]
SBDavid
Sep 30th, 2009

Controlling Server Resources from denial of service using Xinetd

Controlling Server Resources from denial of service using Xinetd

Another important feature of xinetd is its ability to control the amount of resources which services under its control can utilize.

It does this by way of the following directives:

cps = [number_of_connections] [wait_period] — Dictates the connections allowed to the service per second. This directive accepts only integer values.

instances = [number_of_connections] — Dictates the total number of connections allowed to a service. This directive accepts either an integer value or UNLIMITED.

per_source = [number_of_connections] — Dictates the connections allowed to a service by each host. This directive accepts either an integer value or UNLIMITED.

rlimit_as = [number[K|M]] — Dictates the amount of memory address space the service can occupy in kilobytes or megabytes. This directive accepts either an integer value or UNLIMITED.

rlimit_cpu = [number_of_seconds] — Dictates the amount of time in seconds that a service may occupy the CPU. This directive accepts either an integer value or UNLIMITED.

Using these directives can help prevent any one xinetd service from overwhelming the system, resulting in a denial of service.

SBDavid
Sep 29th, 2009

Securing Services With TCP Wrappers and xinetd

Securing Services With TCP Wrappers and xinetd

TCP wrappers provide access control to a variety of services. Most modern network services, such as SSH, Telnet, and FTP, make use of TCP wrappers, which stand guard between an in-coming request and the requested service.

The benefits offered by TCP wrappers are enhanced when used in conjunction with xinetd, a super service that provides additional access, logging, binding, redirection, and resource utilization control.

For a thorough list of TCP wrapper functionality and control language, refer to the hosts_options man page.

To implement a TCP wrappers banner for a service, use the banner option.

This example implements a banner for vsftpd. To begin, create a banner file. It can be any-where on the system, but it must bear same name as the daemon. For this example, the file is called /etc/banners/vsftpd.

The contents of the file look like this:

Hello, %c All activity on ftp.serverbuddies.com is logged.

The %c token supplies a variety of client information, such as the username and hostname, or the username and IP address to make the connection even more intimidating.

For this banner to be presented to incoming connections, add the following line to the /etc/hosts.allow file:

vsftpd : ALL : banners /etc/banners/