In the last couple of weeks, I have had a number of people ask me to consider a small side trip in this series. Classic wisdom says you do not turn on any network services you do not need, and, in past articles, I have explained how services are turned on and off through your /etc/inetd.conf file. The problem, as one reader pointed out, is that after he upgraded his system to Red Hat 7.1, inetd appeared to be gone, replaced with something called xinetd. Worse, things weren't quite working the way he expected--after upgrading to Red Hat 7.1, he noticed that he could no longer log on from his home clients and /etc/inetd.conf was gone. Since you, the readers, are my raison d'être, I will take some time from this discussion of network monitoring to cover xinetd. Besides, as it turns out, we do a little monitoring here as well.

On one level, xinetd does exactly the same things as inetd. I have often compared inetd's role to that of the telephone operator Lily Tomlin played way back when. Essentially, you call in to the operator (inetd), ask for the party you wish to speak to (TCP port or service), and, if all goes well (TCP wrappers allow you in), the operator connects you. But if it's simply a question of asking for a service and being connected, then why, you may ask, is inetd being replaced by xinetd? The answer is the same reason we want to keep an eye on what is happening on our networks: security.

xinetd features a number of enhancements over good old inetd, including extensive logging capabilities, limits on incoming connections (to prevent denial of service attacks), flexible access control for both local and remote connections, and much more (as they say on TV). Configuring xinetd to perform all this magic starts in the /etc/xinetd.conf file, where definitions for various services are broken up into paragraphs with this format:

    service_name
    {
        attribute assignment_operator value
        yet_another_attribute . . . etc
    }

If you look at your /etc/xinetd.conf, you'll notice that it may look fairly bare. In the case of my system, there is one section labeled "defaults" and an include parameter. Have a look.

    defaults
    {
        instances               = 60
        log_type                = SYSLOG authpriv
        log_on_success          = HOST PID
        log_on_failure          = HOST
        only_from               = 192.168.22.0 127.0.0.1
    }
    includedir /etc/xinetd.d

The defaults paragraph (or section) sets up some basics that will apply to all services on my system. The includedir statement at the end of the file tells xinetd where to find configuration specifics for other services on this system. If you do an ls on /etc/xinetd.d, you'll notice things like echo, finger, rlogin, and telnet and others--namely your standard network services. You don't have to do it this way. If you would rather see the whole thing in one place, you can include all the services in one configuration file. The above example just happens to be the way it is set up on my Red Hat system.

Notice in particular the line that says only_from. One of the ways xinetd increases security is through a binding mechanism that lets you have certain services available only to a specific interface. In other words, you could open FTP access up to your internal network on eth0, but not to the outside world on eth1. When you first install (or upgrade), you may notice that only 127.0.0.1 is allowed access. Since my internal network is on 192.168.22.0, I added that network address (my eth0) to the only_from line.

As with changes to the /etc/inetd.conf file, it is necessary to restart the dæmon before any of the changes you make take effect. To do that, you send a SIGUSR1 or a SIGUSR2 to the xinetd process, which you can find by doing a ps ax | grep xinetd. So there are two possibilities. Which should you choose? The answer is "it depends". Sending a SIGUSR1 does a soft reset while SIGUSR2 does a hard reset. For the most part the two wind up being the same but if you change your xinetd.conf and that change disables a service, then any existing connections will be terminated; whereas a SIGUSR1 will re-read the configuration file and apply the changes to new connections. So if I wanted to do a soft reset of xinetd, this would be my approach:

   # ps as | grep xinetd
   529 ?  S   0:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
   # kill -USR1 529

Now that we have that out of the way, let's have a look at the configuration file for the remote shell (RSH). On my system, this is a text file in the /etc/xinetd.x directory called "rsh".

   service shell
   {
        socket_type             = stream
        wait                    = no
        user                    = root
        log_on_success          += USERID
        log_on_failure          += USERID
        server                  = /usr/sbin/in.rshd
        disable                 = yes
   }

Even though we have a service definition in the /etc/xinetd.d directory, that doesn't necessarily mean that the service is available or even active. The last line, "disable = yes", shows us that. For a service to be available, "disable" must be set to no.

What about logging? Well, if we look at the defaults paragraph, it says "SYSLOG authpriv" for the log_type parameter. If I take a look at my /etc/syslog.conf file, I find that authpriv stuff gets logged to /var/log/secure.

   authpriv.*          /var/log/secure

If you would rather see all this stuff go through into another file (rather than letting syslog do its thing>, you can specify that with the FILE parameter, like this:

   log_type       = FILE /var/log/xinetd.log

We restart the xinetd process, and suddenly we are logging to a whole new file.

   # tail /var/log/xinetd.log
   01/7/18@16:38:03: START: pop3 pid=32665 from=127.0.0.1
   01/7/18@16:40:05: START: telnet pid=32671 from=127.0.0.1
   01/7/18@16:41:48: START: pop3 pid=32730 from=127.0.0.1
   01/7/18@16:43:13: START: pop3 pid=32750 from=127.0.0.1

Notice all the START flags. If you want to log when a service EXITs as well, then change your log_on_success attribute to include the EXIT parameter.

    log_on_success          = HOST PID EXIT

Just like that, our logs are starting to get very rich indeed. This is great, but what if we wanted to separate some of these services and have them log to their own specific locations. I'm fond of saying that too much information is just about right, but when you hit just about right, it starts to get a little busy. One rather busy service that comes to mind in a large office is POP3.

service pop3
{
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/ipop3d
        log_type                = FILE /var/log/ipop3.log

If, as above, we substitute a different log_user parameter, everything xinetd does still gets logged, but the POP3 stuff goes to the file /var/log/ipop3.log instead.

Let's look at some other useful parameters. You'll remember I said that xinetd can limit the number of incoming connections for a given service. This is done through the instances parameter. By default, all services offer an unlimited number of possible connections. If I wanted no more than 50 pop3 connections, I would add this line to my ipop3 configuration file (or paragraph)"

     instances     = 50

Another useful (and fun) thing you can set is a connection banner using the (you guessed it) banner attribute. For instance, whenever someone connects with, say, Telnet, I might want them to get a nice little message that congratulates them and tells them how clever they are. To do this I create a text file with the phrase (or phrases) I want them to see upon connecting. Then, I modify the appropriate service paragraph or section by adding this line:

   banner     = /usr/local/misc/telnet.txt

When our user connects to the system with Telnet we get something like this:

   $ telnet localhost
   Trying 127.0.0.1...
   Connected to localhost.
   Escape character is '^]'.
   Hey wow, you connected!  Aren't you clever?

So far so good? There is more, but I am getting close to my weekly allotment of electrons so I'll start wrapping this up. You can get all these wonderful configuration options, some of which I have mentioned and a couple I have not, but typing man xinetd.conf at the command prompt. If you do not already have xinetd and you would like to try it (as an alternative to inetd), you can do so by visiting https://www.xinetd.org and getting your very own copy.

Now that I have gone and shown you how to configure all of this manually, you might be asking, "Isn't there some way I can do this graphically?". Well, there is. One of my favorite administrative interfaces remains Webmin (which I covered earlier on this very corner).

Here's a screenshot of Webmin in action, editing the rlogin service.

When next we meet here at the SysAdmin's Corner, we'll get back into this network visualization stuff as we try to make sense out of all that noise flying about on your network. Until then, remember to ask yourself . . . if you are not watching your network, who is?

Looking for past articles to this series? Click here for a list.