Welcome To BlogerDesign

Quiz time: What do you think are the two most important files on your system? Justify your answer. Note: There's not necessarily a right or wrong answer to this, so tell me what you think. My answer to this "quiz" is the substance of today's article.

Personally, I think the two most important files on anybody's system are /etc/inetd.conf and /etc/sysconfig.conf. These two files are probably the least reviewed, most poorly understood files on the average system. While I believe Caldera, Debian, Red Hat, and others do a good job, I don't trust them to set up these two files.

By default, any average install will include inetd and syslogd. One is in charge of starting a number of servers on the system (typically Telnet, FTP, finger, and a number of others), and the other is in charge of telling syslogd what to log. On every system I've set up, these two files have had to be modified. Okay, my modifications are specific to the system and its use, but the modifications tend to look similar across various system types—that is, servers, firewalls, workstations, and special-purpose systems. Basically four different variations on those particular files exist.

So what's wrong with what Caldera or Debian or Red Hat or anyone puts in their particular files? Nothing. They're just not right for me, so they're not right. It's a case of trying to put together a configuration suitable for the majority of the situations. Kinda like the "universal" part—it doesn't fit anything.

Starting Your Customization

The first thing I always do is look at /etc/inetd.conf. Lately, all the distros I've looked at use TCP Wrappers. There really is no excuse for not doing so, and if your distro doesn't use it, I'd say it's time for a new distro. I comment out all the services I don't want running at all, and then I restart inetd.

I then check the /etc/inetd.conf file with tcpdck. Everyone should get in this habit. The tcpdchk utility will tell you if you've managed to munge your inetd.conf file. I've looked at and modified /etc/inetd.conf hundreds of times (probably more like thousands), and I still use it. There's just no excuse not to. I've fat-fingered keys before and will almost certainly do it again.

Then I set up my /etc/hosts.allow file. I choose not to use /etc/hosts.deny, but you must ensure that your TCP Wrappers software has been written with process_options. Most distributions have done this. You might also want to verify whether your distribution is compiled in the PARANOID option. Caldera and Debian don't, but Red Hat does. I can't speak for the others at this moment, but be aware that even with Caldera, Debian, and Red Hat, this could change in the very next release.

Once I have what I think is a well-done /etc/hosts.allow file, I always check it, too. I check every single service that I allow to run from inetd.conf using tcpdmatch. I check a combination of IP/hostnames with or without users that are supposed to be permitted access, and then I do the same with one or more that should be denied access.

Checking Out Your System's Content

Let's take a look at the output of tcpdchk on a sample system:

# tcpdchk

warning: /etc/inetd.conf, line 75: in.tftpd: not found in /usr/sbin: No such file or directory

Well, that's not good. The output tells me that on line 75, the TFTP daemon is enabled, but it doesn't exist on the system. Good thing, because I didn't install it. In fact, I don't want TFTP enabled. Commenting out line 75 and the output from tcpdchk becomes nothing. That's good. The tcpdchk utility checks for programs and also ensures that an entry for the program can be found in /etc/services. After all, inetd has to know which port to bind. If nothing's wrong, you get no output.

This brings me to my next point. I didn't want TFTP enabled at all. Good thing I didn't install it. But tcpdchk won't tell me what is enabled; I have to check that myself. The tool I use for this is netstat. In this case, I'll use netstat -a to show me not just current connections, but servers listening on ports for connections (this is a partial listing):

# netstat -a
tcp        0      0 *:smtp                  *:*                     LISTEN    
tcp        0      0 *:7110                  *:*                     LISTEN    
tcp        0      0 volcan.pananix.c:domain *:*                     LISTEN    
tcp        0      0 localhost:domain        *:*                     LISTEN    
tcp        0      0 *:www                   *:*                     LISTEN    
tcp        0      0 *:printer               *:*                     LISTEN    
tcp        0      0 *:auth                  *:*                     LISTEN    
tcp        0      0 *:swat                  *:*                     LISTEN    
tcp        0      0 *:finger                *:*                     LISTEN    
tcp        0      0 *:uucp                  *:*                     LISTEN    
tcp        0      0 *:imap2                 *:*                     LISTEN    
tcp        0      0 *:pop3                  *:*                     LISTEN    
tcp        0      0 *:pop2                  *:*                     LISTEN    
tcp        0      0 *:exec                  *:*                     LISTEN    
tcp        0      0 *:login                 *:*                     LISTEN    
tcp        0      0 *:shell                 *:*                     LISTEN      

Here's the first mystery—what's that listening on 7110? Let's use the fuser command (specifying the TCP namespace) to find out:

# fuser -n tcp 7110
7110/tcp:             2967

And the winner is: process ID 2967. Okay, let's see what it is:

# ps awx | grep 2967
2967 ?        S      0:02 /usr/opt/applix/axdata/fontmetrics/gallium/fs/axfontfs -cf /usr/opt/applix/axdata/fontmetrics/gallium/fs/

Well, this looks like it's the Applix font server. That's okay with me, so let's look a little further. Most look innocuous enough—SMTP, DNS, HTTP, LP, AUTH, SWAT, and so on. But then we get down to EXEC, LOGIN, and SHELL. I don't think I want those "r" commands running. They're a bit too unsecure even for this system, which dials in to the Internet only infrequently.

So where are they running from? Let's use fuser, ps, and grep to find out (just like we did previously):

# fuser -n tcp shell
shell/tcp:             617

Our grep of ps awx shows this:

  617 ?        SW     0:00 [inetd]

This is our old friend inetd. So, we need to find the shell line, comment it out, save the file, and restart inetd.

Determining User Access

Once we have running only what we want running (all starting via TCPD), let's make sure that only the systems/users that we want to use a service can use it. We're going to allow a local Web program to use IMAPD to access users' mail, so we need to allow access to IMAPD from the local system but deny access from anywhere else. So, our line in /etc/hosts.allow looks like this:

imapd:  ALL except localhost, 127.0.0.1: DENY

Let's also allow only david on localhost or 127.0.0.1 to run the Samba Web Administration Tool (swat):

swat:  ALL except david@localhost, david@127.0.0.1 : DENY

We now have two lines we can test, so we pull out our handy-dandy checker tool, tcpdmatch, and check out our rules:

# tcpdmatch imapd pananix.com
client:   hostname mail.pananix.com
client:   address  209.127.112.154
server:   process  imapd
matched:  /etc/hosts.allow line 8
option:   DENY

access:   denied

Well, that looks good. Anyone coming from the foreign address of either mail.pananix.com or IP 209.127.112.154 will be denied access to IMAPD per line 8 of the hosts.allow file.

Now lets see if this service will run locally:

# tcpdmatch imapd localhost
client:   hostname localhost
client:   address  127.0.0.1
server:   process  imapd
access:   granted

Well, I'd say that's a ROGER. Now let's see how swat holds up to the rules:

# tcpdmatch swat localhost
client:   hostname localhost
client:   address  127.0.0.1
server:   process  swat
matched:  /etc/hosts.allow line 7
option:   DENY
access:   denied

Okay, so it appears no one can access swat, even locally. But we want user david to be able to run swat (at least locally):

]# tcpdmatch swat david@localhost
warning: /etc/inetd.conf, line 75: in.tftpd: not found in /usr/sbin: No such file or directory
client:   hostname localhost
client:   address  127.0.0.1
client:   username david
server:   process  swat
access:   granted

We've got success. But let's make sure it's not a fluke:

# tcpdmatch swat david@chiriqui.pananix.com
client:   hostname chiriqui.pananix.com
client:   address  192.168.0.2
client:   username david
server:   process  swat
matched:  /etc/hosts.allow line 7
option:   DENY
access:   denied

Looks like we're cooking with gas.