Using xinetd

 in
Jose demonstrates how to start configuring and tweaking xinetd.
A Word about Access Control

Actually, a few words about how xinetd does access control. First of all, xinetd controls connections, not packets. It's a userland dæmon, just as inetd is. As such, while it would break a SYN or connect() attempt from a host that is prohibited from connecting to a service, it will not break “stealth” scans such as a FIN scan [a port scan utilizing TCP packets with the FIN flag set, often performed with a tool such as NMAP]. Don't rely on xinetd to be a firewall to break portscanning. A resourceful intruder will be able to use this information to gather access-control lists for your various services. Luckily, this can be logged by xinetd, and your paranoia sensors should go off when you review your logs.

Secondly, xinetd, as of 2.1.8.8pre3, performs name lookups when a system attempts to connect. Previously, it used to do lookups at startup, but this has been changed.

Using access control is really quite simple. The first directive is only_from, which lists the networks or hosts from which the we will accept connections from. This directive sets up rules that can be overridden by no_access. You can use network numbers, such as 10.0.0.0 or 10, or network names, including *.my.com or .my.com with this directive. Host names and IP addresses of hosts also can be used here. Use the directive 0.0.0.0 to match all hosts and to listen to all addresses. Denials are parsed once the criteria are met by using the no_access directive. Again, networks or hosts can be specified.

Service Configurations

Let's have a look at some basic applications of this information. The first service we'll look at is the echo service, which is internal to both inetd and xinetd.

service echo
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        type            = INTERNAL
        id              = echo-stream
}

Echo runs as root, is a tcp stream and is handled internally. The id directive of echo-stream would show up in the logs. In the absence of only_from or no_access directives, access to this service as configured is unlimited.

Now, let's look at a regular service, in this case the daytime service:

service daytime
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = nobody
        server          = /usr/sbin/in.date
        instances       = 1
        nice            = 10
        only_from       = 0.0.0.0
}

Again, anyone can connect to it, but we specify an executable to run (as nobody) to return the information. This one doesn't extend the previous example by much. We now look at another service for secure shell version 1. This was done to prevent resource exhaustion by sshd.

service ssh1
{
        socket_type     = stream
        protocol        = tcp
        instances       = 10
        nice            = 10
        wait            = no
        user            = root
        server          = /usr/local/sbin/sshd1
        server_args     = -i
        log_on_failure  += USERID
        only_from       = 192.168.0.0
        no_access       = 192.168.54.0
        no_access       += 192.168.33.0
}
Here, we build on what we were doing before. Recall that sshd needs to be started with the -i flag when it is started from a super server like inetd or xinetd, so we place that in the server_args directive. Note: adding the flags to the server directive will cause it to fail. Only ten people can use this service at any one time, which is not a problem on the server this example was taken from. We log, in addition to the default information, the user ID of the connecting party as described in RFC 1413 if they are unable to connect. Lastly, we have two networks listed which cannot access this service.

Logging and xinetd

The logging directive understands several values that can be used to get information about your server (see Table 2).

Table 2. Various Logging Directive Values

As such, typical lines to add specifics about logging may look like those listed below. For a service that successfully connects, we usually want to log the process ID of the service spawned, the host that connected and when it exited:

log_on_success  = PID HOST EXIT

This will give us useful information for debugging and minding normal server operations. For failures, we log what we would expect:

log_on_failure  = HOST RECORD ATTEMPT
Here we log the host that connected, the reason the connection was denied and additional information about the connecting host (sometimes the user ID that attempted to connect). These are recommended baselines to give you a good view of your server.

Recall that above, in our defaults section, we were logging to /var/adm/servicelog. We have directed all the information, both failures and successes, to be logged by xinetd. Most of our information will look like this:

00/9/13@16:05:07: START: pop3 pid=25679 from=192.168.152.133
00/9/13@16:05:09: EXIT: pop3 status=0 pid=25679
00/10/3@19:28:18: USERID: telnet OTHER :www

Using this information, it is easy to debug xinetd and normal operations. It is also easy to spot security issues such as connection attempts that you want to try to block. Simply grep for “FAIL” in the logs, and these entries will stand right out:

00/10/4@17:04:58: FAIL: telnet address from=216.237.57.154
00/10/8@22:25:09: FAIL: pop2 address from=202.112.14.184
Acting on security issues requires another article, but, suffice it to say, don't take the address reported as solid information, since it can be forged.

The xinetd.log file, by contrast, contains information from xinetd. This can be useful in debugging connections that give errors.

00/10/25@21:10:48 xinetd[50]: ERROR: service echo-stream,
accept:
Connection reset by peer
______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState