Running Telnet with Tcpserver

Most UNIX machines run network services using inetd. Although modern versions are not too bad, some versions of inetd are security nightmares: inetd runs as root, and does not offer configurable options for mitigating the damage in denial-of-service attacks.

Dan Bernstein's packages daemontools and ucspi-tcp offer an alternative method of handling network services. These tools are lightweight, configurable, reliable and secure. I suggest you consider scrapping inetd, especially if you only run a few network services. Note, that there's no reason not to use these tools for hundreds of services, either; some folks have a misguided prejudice against running many small processes. What they forget is that running lots of small processes is exactly what UNIX does best.

To get you started toward scrapping inetd, here are instructions for running your telnet daemon with Bernstein's tools.

First, of course, download the tools and follow the installation instructions. Create the directory /service, owned by root, with 0755 permissions (rwxr-xr-x).
Create the directory /service/telnet. Use 0700 permissions (rwx------) and owner root, since the telnet daemon must run as root.
Create a script called /service/telnet/run, which specifies how to run the service. Our script runs tcpserver, telling it to run telnet whenever a connection is made from the ethernet interface. Here is my script:
```
#!/bin/sh
# Run the telnet daemon under tcpserver control.
exec \
/usr/local/bin/tcpserver \
  -x/etc/tcpcontrol/telnet.cdb -c5 -H -llocalhost.localdomain \
  192.168.0.1 telnet \
/usr/sbin/in.telnetd
```
Let's look at the options given to tcpserver:

-x/etc/tcpcontrol/telnet.cdb tells tcpserver to read access-control rules from the specified file.

-c5 tells tcpserver to allow a total of five connections at any one time. Since I'm the only person likely to telnet to the firewall, five connections is more than ample. This limit cannot be set for inetd; that's the main reason that DOS attacks can bring down a machine running inetd.

-H tells tcpserver not to perform DNS lookups on connections. Theoretically, this disables a security feature. However, internal hosts are not in the DNS anyway, and performing this lookup will force an ISP connection for no reason, so it needs to be disabled.

-llocalhost.localdomain tells tcpserver not to use DNS lookups to determine the identity of the local machine, but to assume that the name is "localhost.localdomain" instead. This option is required for the same reason as the -H option.

The next two options, "192.168.0.1 telnet" tell tcpserver to listen to the telnet port at IP address 192.168.0.1--the address of my ethernet card. This prevents tcpserver from responding to connections to my machine at any other IP address (including the local host!). Since the ethernet card is invisible from the Internet, this effectively prevents anyone from telnetting into my machine from the Internet. That's just the way I want it: telnet is a security nightmare (among other things, it transmits passwords across the Internet in the open). If I'd wanted to offer everybody telnet access to my machine, I would have used '0' instead of the IP address.
Create the directory /etc/tcpcontrol, and the access rules file /etc/tcpcontrol/telnet.cdb. The cdb files required by tcpserver are based on rules files resembling the rules for Wietse Venema's tcp-wrappers. I created the file /etc/tcpcontrol/telnet.rules, with the following contents:
```
192.168.0.:allow
:deny
```
I then converted the rules file into the format required by tcpserver by changing directories to /etc/tcpcontrol and running the command:
```
tcprules telnet.cdb telnet.tmp < telnet.rules
```
The rules file is actually redundant in my case, since tcpserver only listens to the internal interface--and external hosts cannot reach that interface. However, it makes sense to use every available security measure. Besides, we might want to implement more complicated policies in the future, and building the rules file puts the relevant mechanism in place.

Arrange for the program svscan to be run at boot time in the /service directory. Under RedHat Linux, I created the following script and named it /etc/rc.d/init.d/service. Then I used symlinks to start it at runlevels 3, 4 and 5. You can do that using the runlevel editor in RedHat, or by following the conventions of your system.

#!/bin/sh
#
#	/etc/rc.d/init.d/service
#
# Starts the svscan program
#
test -x /usr/local/bin/svscan || exit 0
test -d /service || exit 0
#
#	See how we were called.
#
case "$1" in
  start)
	echo -n 'Starting Daemon services: '
	(cd /service && \
	   PATH=/bin:/usr/bin:/usr/local/bin /usr/local/bin/svscan &)
	echo "done."
	;;
  stop)
	echo -n 'Stopping daemon services: '
	/usr/local/bin/svc -dx /service/*
	echo "done."
	;;
  reload|restart)
	$0 stop
	$0 start
	;;
  status)
	/usr/local/bin/svstat /service/*
	;;
  *)
	echo "Usage: $0 {start|stop|restart|reload|status}"
	exit 1
esac

Stop inetd from managing telnet. Edit /etc/inetd.conf, and comment out the line for telnet. Then kill -HUP your inetd.
Start svscan in the /service directory, preferably using the script from step 5, and test your new telnet daemon.

To run other services, you can repeat these steps--omitting steps 1 and 5. You may need to tweak the script in the script /service/DIR/run for specific cases. For example, you should use the program setuidgid, supplied with daemontools, to run tcpserver as someone other than root whenever possible. And, of course, you can run non-network services as well, or network services which don't need tcpserver (such as Apache or SSH).

Once you've taken every service away from inetd, you can safely disable or uninstall it. I know: inetd has become so imbedded in the psyches of UNIX users that you're afraid you aren't supposed to remove it. Go ahead! It isn't actually needed for anything.