Scope
This collection of material has been written to further clarify one of the more mystical configuration files on today's Solaris Operating System. For this example, we make use of the latest distribution of Solaris (at this time, 7). The topics covered are quite familiar to most seasoned administrators, although this publication has been written with administrators from beginning to advanced skill levels in mind.
What IS inetd.conf?
For those of you new to Solaris (and UNIX), the terms "inetd" and "inetd.conf" may be a bit unfamiliar to you. inetd, commonly called the services super-server, is a single controlling daemon process that handles some network services operating on a UNIX System. This daemon controls such services as telnetd, ftpd, time, rlogind and some RPC services. The file /etc/inetd.conf is the configuration file for this daemon.
The /etc/inetd.conf file is a plain text file specifying the services offered through inetd. In this file are the processes controlled by inetd, the protocols they operate on, as well as how they operate and their full paths. The concept of one daemon controlling others may be somewhat cryptic, but there's a valid reason.
inetd is capable of starting two types of services. Standard services run through inetd via well-known assigned port numbers (such as telnetd on port 23, ftpd on port 21). A listing of services can be found listed in /etc/services on a UNIX System. This file is essentially an index of all system services, and the ports and protocols they operate on. The other type of services inetd is capable of running are TCPMUX. Having its roots in RFC 1078, TCPMUX services are non-standard services, running on various port numbers. Placing a service under the control of inetd reduces the load on the system, as the daemons are started by inetd only when a request (or query) for their respective service occurs.
How this affects you
As inetd runs on Solaris by default, a Solaris system is able to take advantage of all the good that comes out of offering these services. There are a wealth of services available on a Solaris system, with a wide variety of functions to make administration and daily operation easier and more efficient. This also means, however, that somebody with ill intent can take advantage of some of the bad.
With all the recent hype around DDoS (Distributed Denial of Service) Attacks, and the compromising of vast quantities of Solaris machines, trin00, tfn, and various new mutations of these attacks, a lot of the victims of these attacks are scratching their heads and asking themselves what could have been done to prevent becoming victims. Along the same lines, many sites that weren't affected are scratching their heads, and asking themselves what can be done to prevent them from becoming victims. Perhaps all of this could have been prevented if the administrators of these sites had a better understanding of the services inetd offers, and the risks associated with them.
The default configuration of inetd on a Solaris system leaves much to be desired from the security perspective. By saying this, I don't mean inoperable by any means, if not quite the contrary. An abundance of services are configured to run on a stock installation of Solaris. In a recent install of Solaris 2.7 on an Enterprise 450 I built, I was appalled by some of the things that were running by default. It's this problem I'd like to focus upon and analyze.
The Vital Services
Let's take a look at some of the defaults Solaris chooses when installing inetd. The inetd.conf file has numerous entries in it, and the first group of them I'd like to look at is what I consider the "Vital" services. I choose to call them "Vital" as these services tend to be standard, and necessary on every UNIX and/or Solaris system that's networked in any sort of production/development/enterprise environment.
Two of the most vital commonly used, and probably the only necessary services (in my opinion) are telnetd and ftpd. I'll not delve into these, as I feel they've been sufficiently discussed in RFC's, mailing lists, books, and a variety of other media. I will, however, make mention that I myself do not often use these. All too often machines are compromised, and in these days no network is safe. The days of using plain text protocols over networks with no worry are over.
However, in some environments, there's no option to NOT running them. It's instances such as these that I can only recommend limiting one's risk. Things such as firewalling, cryptographic virtual private networks, access limitation, rsh (restricted shell), and tcp wrapping can aid with this. While most of these our outside of our discussion, we will discuss tcp wrappers later.
I will, however, take time to mention the SSH protocol. The use of cryptography is the only safe and viable alternative internally and externally. Telnetd and ftpd are quickly being replaced by SSH and OpenSSH, and with great benefit to security of networks. It was not long ago I was sitting and listening to Alan Cox in a conversation, as he was chatting with a few others about the benefits of cryptography. He talked about how those (countries) who are lagging behind in making the transition to PKI, SSH, and other such security measures will be the first to go when the first real big round of cyber-terrorism between countries occurs. I feel that statement was valid not only in the present day political boiling pot we live in, but also in the corporate arena. The SSH protocol has been proven again and again, and OpenSSH (the free alternative to the commercial version) is coming along quite nicely. In short, use SSH.
The "Other" Stuff
And you say, "There are 50,000 other services in this file! Aren't any of them useful/necessary?" To me, most of them are what could be referred to as "gravy"; added bonuses or perhaps proprietary tools particular to Solaris. Well, let's get into what they are, and what they're for. The best way to do this is to start at the top of the inetd.conf file, and work our way down to the last "stock" service in a "stock" install of Solaris 7. In this paper we'll cover the tcp and udp services. In a second article, we'll analyze RPC services. With your terminal ready, and vi open to /etc/inetd.conf, let's begin.
The first two are already given: telnetd and ftpd. We'll skip those. Next, is name. As you can see in the file, name uses udp, and calls /usr/sbin/in.tnamed when requested. What would a call for in.tnamed be? Well, the roots come from our forefathers, DARPA. This daemon is compatible with the old IEN 116 standard, the predecessor of modern naming service, DNS. This protocol is obsolete, and is no longer used.
Next, we come to shell, or remote shell, as most of us know it. rsh uses tcp, and connects on well-known port 514. The purpose of this daemon is to allow a remote user to connect to a machine, authenticate, and execute a command on the machine. Somewhat like telnet, however, when the command terminates, so does the shell. This is a good utility, although there's some things I'm not particularly fond of. Here's why: WEAK SECURITY. This service relies on 2 types of access control lists. These lists are /etc/hosts.equiv, and $HOMEDIR/.rhosts. The principle is that if a user wants to connect to the machine using rsh, the user must have an entry for the host name in /etc/hosts.equiv. If this requirement isn't met, the next step is verification on a user level. This is done via checking the .rhost file for the users name on the connecting machine, and also for the hostname of the machine the user is connecting from. From this, there's an introduction of 2 problems. The first one is, if a machine on the network is compromised, and this machine has either host.equiv or .rhost entries on other machines, all the other machines with these matching entries are compromised. Next, there's the fact that spoofing is trivial. It can be done, and there's not much you can do to prevent somebody from doing it if they're determined. Finally, rsh makes no use of any sort of encryption between hosts. A person could sniff the network, and wait for the opportunity to hijack the terminal or collect user passwords, thus giving them system access. Finally, all authentication information is sent in plain text. These 4 weaknesses make rsh less than ideal.
Next in line is login, or remote login (rlogind). rlogin uses the same principles as rsh. Remote systems can be added to /etc/hosts.equiv, or a user can set up a .rhost file in their home directory. Yet again, the same problems exist with this one as with rsh; weak authentication, spoofing, compromising of a trusted host, and a lack of encryption.
rexec provides tcp services via well known port 512. This service allows for remote execution of commands upon request to the daemon. rexec relies on one of two means of authentication for connection and execution of commands. Either a user specified .netrc file, containing information from the user, or when the connection is initiated, the prompting for the username and password by the daemon process. This daemon has a majority of the same security problems as rsh and rlogin.
comsat is a mail notification daemon. It uses udp and runs on port 512. I find this useful on a machine that either serves as a gateway for all my operations, or a workstation I may have all my mail forwarded to. Not necessarily a vital service, although it is handy. It listens on port 512 for incoming mail, and when mail arrives, prints about the first 7 lines of the mail to terminal, excluding the header.
talk, or talkd, is another udp service, operating at port 517. This service allows users to remotely connect to the machine, and initiate talk sessions with users currently logged into another machine. There are no direct security implications involved with this service. The real problem lies with users from outside of the local machine being able to talk with users on the local machine. With a little social engineering, a user might be coaxed to give away a login and password, making it possible for a remote user to access the local users account.
uucp, or Unix to Unix copy protocol, is a tcp service relying on port 540. This service is a bit old and deprecated, having been largely replaced by SMTP and NNTP. The real problem with this service is, again, lack of line encryption, allowing the potential of sniffing passwords.
Now we'll look at tftp, or trivial file transfer protocol. This service uses udp, and operates on port 69. Some sites find this service necessary as it's needed for a diskless client to boot. The implementation of tftpd tends to be a security nightmare for a number of reasons. First, there's the fact that a tftp server offers no authentication means whatsoever. Next, the tftp server attempts to change it's home directory to /tftpboot, although if this directory doesn't exist, the results can be unpredictable. Next, tftpd allows a user to read all publicly readable files, and runs as user nobody. tftpd also allows a users to write to all publicly writable files. If you MUST run this server, consider running it with the -s flag, which enforces that a change of directory must succeed. See the man page for more information.
Next, finger, systat, and netstat. finger permits a user external to the system to look up another users information on the local machine, and operates on port 79. systat gives a list of the running processes on a machine to a remote user, and operates on port 11 using tcp. netstat makes use of tcp on port 15, and gives a wealth of information about all existing network connections on a machine. All three of these services are flagrant security risks. They provide a wealth of information to a user external to the machine, some of which might be useful to a would be attacker.
Time is a daemon process that runs for the internal system, using both tcp and udp on port 37 for machine formatted time. It's calculated by the number of seconds since Midnight, January 1 of 1900. Consider your operation. Is your shop a 24/7 shop? Do you have your shop staffed at 1 am? Allowing remote users this kind of information could lead to them ultimately discovering when to mount an attack against your systems.
Echo uses port 7 for tcp and udp traffic, and has its roots in RFC 862. It's implemented as a debugging and measurement tool, sending back to the originating source any data it receives. This opens great potential for Denial of Service attacks.
Discard functions on tcp and udp via port 9. This service has roots in RFC 863, and is implemented as a debugging tool. Its purpose is to throw away anything it receives.
Daytime is the same offering as time, except in human readable form. It functions on port 13.
chargen functions on port 19, and utilizes tcp and udp. Chargen awaits a connection while functioning under tcp, and once initiated, sends a continuous stream of data until the initiating source closes the connection. Under udp, the service awaits a datagram. When one is received, it responds with a datagram containing between 0 and 512 characters. This is frequently used in denial of service attacks.
The last service we'll cover is the printer daemon. The printer daemon functions on port 515 using tcp connections. The printer daemon is useful tool, making printing from workstations to a remote printer possible. The problem with this is security. Any sufficiently secure site will place printing resources either in a local network, or place an Access Control List structure guarding their print servers, for fear of wasting trees and money.
Conclusion
Thus far, we've discussed the current tcp and udp services offered through inetd on a stock Solaris installation. The next article in this series will cover the Sun RPC services, as well as some of the things we can use to make inetd more secure.
Acknowledgments and special thanks to: Alan Cox at Red Hat Inc., Josh Uziel and Casper Dik at Sun Microsystems, Steve Goldsby at Integrated Computer Solutions, Andy Kroll, and anybody I might have missed.
To read Back to the Basics: Solaris and inetd.conf Part Two, click here.
|