Home > Articles > Open Source > Linux/UNIX/Open Source Operating Systems

  • Print
  • + Share This
From the author of

Getting to Know Your Enemy

For the serious newbies out there, here's how networks work on a really, really basic level. Your system's master process, the one that got the system going (after you pushed the on switch, that is) is called init. init's process ID is 1. It is always 1. If you want to check it out, find init in your process table using ps.

# ps ax | grep init
   1  ?   S    6:03 init

One of the services that init starts when your system boots is inetd. Its job is to listen for network requests, which it references by way of Internet socket numbers or ports. For instance, when you telnet to your system by typing telnet mysystem, you are actually requesting that inetd on mysystem start an in.telnetd process that handles communication over port 23. Then in.telnetd starts a process that eventually asks for your login name and password and, miraculously, you are logged in. Basically, inetd listens to find out what other daemons should wake up to answer the port request. If you want to see what those service numbers translate to, do a more (or less) on /etc/services, a text file that lists the known TCP service ports.

From a resources perspective, it makes sense to have a single process listening rather than one for each and every service. For those of you who can remember and visualize such things, picture Lily Tomlin as the telephone operator who (eventually) patches people through to the party to whom they wished to speak. She is inetd and the people to whom you wish to speak are the service daemons. You request extension 23 and, eventually, she puts you through.

When inetd starts, it reads a file called inetd.conf. You'll find this one in your /etc directory. Here are a couple of sample lines from inetd.conf.

#
# These are standard services.
#
ftp stream  tcp nowait  root /usr/sbin/tcpd in.ftpd -l -a
telnet  stream tcp  nowait root  /usr/sbin/tcpd   in.telnetd
#
# Shell, login, exec, comsat and talk are BSD protocols.
#
shell   stream  tcp nowait  root /usr/sbin/tcpd in.rshd
login   stream  tcp nowait  root /usr/sbin/tcpd in.rlogind
#exec   stream  tcp nowait  root /usr/sbin/tcpd in.rexecd

When a cracker first visits your site with the intention of breaking in, he will often employ a tool known as a port scanner to find out what inetd is listening for on your system.

One of my favorite port scanners is nmap. You can pick up nmap from http://www.insecure.org/nmap/index.html. The latest version even comes with a nice GUI front end called nmapfe. Let's run nmap against my test system and see what we get.

The options are -sS for TCP SYN, or half-open scan, and -O for OS fingerprinting. OS fingerprinting means that nmap will try to guess the OS version running on the system. A cracker who knows what release of an OS you are running will use that information to decide on the most likely exploits for a successful entry. Here's the nmap command and the output from my test system.

# nmap -sS -O localhost
  
Starting nmap V. 2.3BETA5 by Fyodor (fyodor@dhp.com,
http://www.insecure.org/nmap/)
Interesting ports on localhost (127.0.0.1):
Port  State    Protocol Service
21   open    tcp    ftp           
23   open    tcp    telnet         
25   open    tcp    smtp          
53   open    tcp    domain         
79   open    tcp    finger         
80   open    tcp    http          
98   open    tcp    linuxconf        
111   open    tcp    sunrpc         
113   open    tcp    auth          
139   open    tcp    netbios-ssn       
513   open    tcp    login          
514   open    tcp    shell          
515   open    tcp    printer         

TCP Sequence Prediction: Class=random positive increments
             Difficulty=4360068 (Good luck!)
Remote operating system guess: Linux 2.1.122 - 2.2.12

Nmap run completed -- 1 IP address (1 host up) scanned in 2
seconds

Those open ports are the jumping-off point for your crackers. With this information, they know what to bother with and what to forget about. If there is no daemon listening on a network port, why bother trying to get in that way?

Now go back and look at your /etc/inetd.conf file. Notice that exec is commented out (there's a hash mark, #, or octothorp, at the beginning of the line), but login is not. If you reference that with the output of nmap, you'll see that those services not commented out in inetd.conf are listed, while those with the hash mark at the beginning are not.

This is how you shut down unnecessary ports monitored by inetd. Your TCP wrapper is keeping an eye on those ports, but if no one needs to have access to remote shell, why have inetd listen for it at all? The wrapper's job is to provide access to specific services for specific IP addresses. In the first section, we did the quick lock-down with the wrapper. Now go through your list of services, decide what you need and what you don't, and then disable the don'ts by commenting out those lines.

To activate the changes, you need to restart inetd. Find inetd's process ID and send a SIGHUP to it. That means you do a kill - 1 on the process. Be careful. A kill -1 looks an awful lot like a kill 1. Do you remember what process had ID 1? Kill init, and you kill the whole system. If you are worried and don't mind typing a few extra keystrokes, use kill -SIGHUP instead of kill -1.

Now let's rerun nmap.

Starting nmap V. 2.3BETA5 by Fyodor (fyodor@dhp.com,
http://www.insecure.org/nmap/)
Interesting ports on localhost (127.0.0.1):
Port  State    Protocol Service
21   open    tcp    ftp           
23   open    tcp    telnet         
25   open    tcp    smtp          
53   open    tcp    domain         
80   open    tcp    http          
111   open    tcp    sunrpc         
113   open    tcp    auth          
139   open    tcp    netbios-ssn       
515   open    tcp    printer         

TCP Sequence Prediction: Class=random positive increments
             Difficulty=3487082 (Good luck!)
Remote operating system guess: Linux 2.1.122 - 2.2.12

Nmap run completed -- 1 IP address (1 host up) scanned in 3
seconds

This last run is the same as the one previous from a command standpoint, but finger, linuxconf, shell, and login are gone. I could argue that the smart thing would have been to leave rlogin in place and deactivate telnet, but keep in mind that this is an example. Disabling telnet may not be appropriate for your location. For those services that are run by inetd, disabling them in this manner completely removes them from external access, even beyond your /etc/hosts.allow file (discussed in the first part of this series).

What should you disable? If you are running a single, private machine that does not require anyone in the outside world to access it, then just about everything in the list could go. However, if you have a small network with a couple of PCs, you may still want to run ftp, telnet, or rlogin.

One final note. Use tools like port scanners wisely. Use them only to test the security of your own systems, and never, never use them to scan other people's systems. Remember, just as you are learning to deal with and watch for the cracker, so can others watch you.

  • + Share This
  • 🔖 Save To Your Account