Xinetd Sensors

By Steve Grubb

Xinetd 2.1.8.9pre15 and later versions have a new feature called sensors that can help protect a system from attacks. By itself, it cannot guarantee security of a computer but it does help. For anyone wanting a full blown firewall to protect their system, they should get a full blown firewall. xinetd or inetd/tcp_wrappers security is used for a different purpose or for an additional layer of security. To get some perspective, lets examine tcp_wrappers first.

tcp_wrappers allows one to create a certain level of protection where it is impossible or inappropriate to setup a firewall. Such places might be where IP addresses are added or deleted frequently, or where services are added or deleted frequently. Or some OS's simply don't have the mechanisms in place to stop/filter packets in the tcp stack. In essence tcp_wrappers provides security by: allowing access to a service, denying access, logging connections, and doing a reverse lookup of the IP addresses to make sure it is from an allowed domain.

Xinetd extended the inetd/tcp_wrapper combination by allowing new ways for access control. It has the equivalents of hosts.allow and hosts.deny in its configuration. These are the only_from and no_access directives. Xinetd also comes with access_times, cps, per_source, max_load, and the rlimit family of directives. These directives basically deny access based on the evaluation of the resources. If the time of day is wrong and the access_time is used, access to the service is denied. If a machine with a particular IP address reconnects to the same resource more than the per_source limit allows, then the new connection is denied.

The pre15 release of xinetd introduced a new way to control access called the sensor. The idea for the sensor came from looking at server logs and seeing ftp login attempts on every single IP address on my machine at the same time. Many of these IP addresses were not connected to a domain name at all, so there was no way that this could be a legitimate user. I realized that this was someone running a script trying to get into my machine. The script blindly tried every IP address on the machine trying to find a security hole.

I realized that these blind scripts can be stopped in their tracks if the machine could pickup connection attempts on services that are not used. For example, I do not use irc on my machine. If anyone tries to connect to it, I know for a fact that this person is up to no good. Same thing for services I do use, but on IP addresses that aren't used right now.

Many people write these scripts to just increment the IP address and then try each port in sequential order. Other people use stealth scans to see what services exist and then they attack that service with a script just for that services known weaknesses. There is probably no way to stop a cracker from exploiting a known hole in a legitimate service...but you can trip them up a little. The sensor patch will not harden your system from IP addresses performing stealth scans. It only hardens against connections that finish the 3 way handshake. In reality, these are the only people you need to harden against because you can't hack a machine on stealth scans alone. (It may be possible to do a DoS attack with stealth scans, but this isn't the same as having a compromised computer.) You have to actually connect and issue commands to the actual service to get it to fail.

You can harden your machine to these kind of attacks with the judicious use of sensors. For the sake of discussion, take a look at the following system map:

In the above example, this system only uses IP addresses .6 & .7. On those addresses, IRC is not used. One could protect the machine by putting sensors on .5 & .8's ftp, http ports and  .6 & .7's IRC. The theory is that someone will run nmap against the machine and find ftp or something that they have a script for. Then they will try that script against your server. So, you want to place a couple of sensors on services that you are using so you can find attacks. Also, you want to place a sensor on a juicy target that people will want to attack like talk, irc, rpc, smb, mysql, netbios, etc. Use your imagination. Note: anything you setup as a sensor will be seen by stealth scans as that service. They won't know its a sensor until they connect. One other important thing to note, the sensor will only stop connections of the services started by Xinetd. It will not do anything for standalone servers. The new layout would look like this:

A Xinetd.conf that does this would look something like this:

service irc
{
    socket_type = stream
    wait = no
    user = root
    flags = SENSOR
    id = irc-1
    type = INTERNAL
    bind = 192.168.1.6
    log_on_success = HOST PID
    deny_time = 120
}

service irc
{
    socket_type = stream
    wait = no
    user = root
    flags = SENSOR
    id = irc-2
    type = INTERNAL
    bind = 192.168.1.7
    log_on_success = HOST PID
    deny_time = 120
}

service ftp
{
    socket_type = stream
    wait = no
    user = root
    flags = SENSOR
    id = ftp-1
    type = INTERNAL
    bind = 192.168.1.5
    log_on_success = HOST PID
    deny_time = 120
}

service ftp
{
    socket_type = stream
    wait = no
    user = root
    flags = SENSOR
    id = ftp-2
    type = INTERNAL
    bind = 192.168.1.8
    log_on_success = HOST PID
    deny_time = 120
}

service ftp
{
    socket_type = stream
    wait = no
    user = root
    id = ftp-3
    server = /usr/sbin/proftpd
    instances = 10
    log_on_success += DURATION HOST
    log_on_failure += HOST
    nice = -2
    bind = 192.168.1.6
}

service ftp
{
    socket_type = stream
    wait = no
    user = root
    id = ftp-4
    server = /usr/sbin/proftpd
    instances = 10
    log_on_success += DURATION HOST
    log_on_failure += HOST
    nice = -2
    bind = 192.168.1.7
}

service www
{
    socket_type = stream
    wait = no
    user = root
    flags = SENSOR
    id = www-1
    type = INTERNAL
    bind = 192.168.1.5
    log_on_success = HOST PID
    deny_time = 120
}

service www
{
    socket_type = stream
    wait = no
    user = root
    flags = SENSOR
    id = www-2
    type = INTERNAL
    bind = 192.168.1.8
    log_on_success = HOST PID
    deny_time = 120
}

service pop-3
{
    socket_type = stream
    wait = no
    user = root
    server = /usr/sbin/ipop3d
    instances = 10
    log_on_success += DURATION HOST
    log_on_failure += HOST
    nice = 10
    bind = 192.168.1.6
}

NOTE: you do have to take care to make sure that Apache isn't listening on .5 & .8's ports. Also if you are using pre15 or later with the libwrap option turned on, you might need to add the appropriate ports to the hosts.allow file so that tcp_wrappers doesn't interfere with the acceptance of the connection. Test it and review the server logs. If you see connections rejected by tcp_wrappers, add the ports to the hosts.allow file. If you did not link with libwrap, SENSORS will work fine and this note does not apply.

To test the configuration (after restarting Xinetd) try to connect to 192.168.1.6 with ftp. You connect fine. Then use telnet 192.,168.1.5:194. You will get a "connection to host lost" message. Then try to reconnect with ftp to the .6 address. You should see a connection refused message. Then you also want to examine the server logs. You will see that there is now a message in the logs with the IP address of the person tripping the sensor. You could also get industrious and write a snort rule to pick this out of the server logs to warn of an attack.

In this example, the deny time was set to 120, which means 2 hrs. Many ISP's recycle the IP addresses assigned to dialup accounts. So there has to be a mechanism to scrub the banned IP addresses so that people that just dialed up aren't penalized for the person using that IP address prior to them. I recommend setting it long enough to be inconvenient and short enough that the list doesn't fill up. It also really depends on your volume and how frequently your server gets attacked.

It is also possible to use the sensors purely for logging messages. If you set deny_time=NEVER, then it will only log the connection attempt and will not put it on the global_no_access list. This would allow you to see patterns of attack without stopping it. There are also several utilities that automatically harden a system using ipchains/iptables using snort logs as the input. So, used this way, the SENSORS could provide data that ultimately goes into firewall rules. There is also a plugin for snort that supports the Intrusion Detection Message Exchange Format (IDMEF). This lets a machine under attack notify response systems and management systems of a security incident. More info about this can be found here: http://www.silicondefense.com/idwg/index.htm

Hopefully, this helps to explain the motivation and usage of this under utilized feature of Xinetd. If you have any interesting uses of the SENSORS facility, please forward them to myself and I will update this page as needed.

Please direct any comments to: linux_4ever@yahoo.com.

This page was last updated: 25 June, 2003