Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.