Thwarting the System Cracker
- Adventures in System Administration
- Making Your System More Secure
- Getting to Know Your Enemy
- Verifying the Integrity of Your Files
- Looking for the Invisible
- Intro to Network Sniffers
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Adventures in System Administration
In the last few months, I’ve answered an increasing number of calls from people whose systems have been cracked. Usually they’re not aware of this, and the call starts out more like: "There seems to be something wrong with my email. Could you have a look at it?" I log on, do a quick look around and see his footprints everywhere. A wily cracker has struck again.
When you set up your Linux system, you brought up a powerful, high-level, multi-tasking network operating system—one that was maybe a little too powerful. Out of the box, some distributions start a large number of services (rlogind, inetd, httpd, innd, fingerd, timed, rhsd, and others). Do you know what they all are? I do. As sys admin, you’ve got enough things to worry about, such as that hung printer, but if your machine is exposed to the Internet, you should pay particular attention.
Most crackers don’t tend to be innovators. They use the latest distributed exploits (programs and techniques) to break through a well-known or recently uncovered security hole in your system. The good news is that you, as a security administrator, are just as capable of becoming aware of these exploits. Regular visits to your Linux distribution Web site such as Red Hat or Caldera Systems are a good way to stay on top of the latest patches to stop those exploits. While you’re at it, find out about the exploits themselves by checking out the bugtraq forum or CERT, to name just a couple. Innovators or not, cracking a system is made so much easier if the door to your server is left wide open.
The simplest means of controlling access (short of turning off your machine) is through a program called a TCP wrapper. Odds are, you loaded it as part of your system install. Using the wrapper, we can restrict access to some of those services I mentioned earlier. Best of all, the wrapper logs attempts to gain entry to your system, so you can track who is testing the locks on your virtual doors. If you do not need to have people logging in to your system (using telnet or rlogin), then you should close the door to remote access by adding this line to your /etc/hosts.deny file:
ALL:ALL
The first ALL refers to all services. The second ALL refers to everybody. Nobody gets in. Y’hear?
Now, we should probably let the people on your internal network have access (no?). I’ll pretend you’ve set up your LAN with the approved internal network addressing scheme as detailed in RFC 1918. (What’s an RFC? Hmm, we do have a lot to cover.) I’ll use a Class C network at 192.168.1x for our example. We’ll also add your localhost (127.0.0.1) network. Here’s the hosts.allow entry:
ALL: 127.0.0.1 ALL: 192.168.1.
Yes, that’s right. There’s a dot after the one and nothing else. Now everyone in the 192.168.1.whatever network can get into your system. Now, restart your inetd process.
/etc/rc.d/init.d/inet restart
Safe, right? Not exactly. The hosts.deny file controls access only to services listed in /etc/inetd.conf and wrapped by /usr/bin/tcpd, your TCP wrapper. The wrapper looks at incoming network requests, compares them to what is in your hosts.allow and hosts.deny files, and makes a yes or no decision on what to allow through. You could be running services not covered by the wrapper, or you may not have had the wrapper configured and our cracker has already gotten through. How can you tell? How can you make your system even more secure?