In the previous section we 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.
You try to find the final portions of possible paths that will get there and how "costly" each of these alternatives are. 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 cost of all the segments for each possible path. These attack paths to root are shown in Figure 2.2.
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 the science 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" 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" 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".
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.
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
Danger Level
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" 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" and in "Limiting Consequences of a Named Compromise".
The best way to make use of "Rings of Security" is to use attack paths to analyze your system, as discussed in "Attack Paths". 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".
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."
[1]
The names Pentacorp and Fly-By-Day Consulting are trademarks of Fly-By-Day Consulting, Inc.
[2]
This environment variable lists what directories should be searched to find a command if there are no slashes in the command name.
[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.
[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.
Book: Real World Linux® Security: Intrusion Prevention, Detection, and Recovery Section: Chapter 2. Quick Fixes for Common Problems