13.6. Controlling Unsafe ConfigurationsAs we've discussed in earlier sections, your ability to trust a protocol often depends on your ability to control what it's talking to. It's not unusual to have a protocol that can be perfectly safe, as long as you know that it's going to specific clients with specific configurations, or otherwise horribly unsafe. For instance, the Simple Mail Transport Protocol (SMTP) is considered acceptable at most sites, as long as it's going to a machine with a reliable and well-configured server on it. On the other hand, it's extremely dangerous when talking to a badly configured server.
Normally, if you want to use a protocol like this, you will use bastion hosts, and you will allow the protocol to come into your site only when it is destined for a carefully controlled and configured machine that is administered by your trusted security staff. Sometimes you may not be able to do this, however; you may find that you need to allow a large number of machines, or machines that are not directly controlled by the staff responsible for the firewall. What do you do then?
The first thing to be aware of is that you cannot protect yourself from hostile insiders in this situation. If you allow a protocol to come to machines, and the people who control those machines are actively trying to subvert your security, they will succeed in doing so. Your ability to control hostile insiders is fairly minimal in the first place, but the more protocols you allow, the more vulnerable you are.
Supposing that the people controlling the machines are not hostile but aren't security experts either, there are measures you can take to help the situation. One option is to attempt to increase your control over the machines to the point where they can't get things wrong; this means forcing them to run an operating system like Windows NT or Unix where you can centralize account administration and remove access to globally powerful accounts (root or Administrator). This is rarely possible, and when it is possible, it sometimes doesn't help much. This approach will generally allow you to forcibly configure web browsers into safe configurations, for instance, but it won't do much for web servers. Enough access to administer a web server in any useful way is enough access to make it insecure.
Another option is to attempt to increase your control over the protocol until you're certain that it can't be used to attack a machine even it's misconfigured. For instance, if you can't turn off support for scripting languages in web browsers, you can filter scripting languages out of incoming HTTP. This is at best an ongoing war -- it's usually impossible to find a safe but useful subset of the protocol, so you end up removing unsafe things as they become known. At worst, it may be impossible to do this sort of control.
If you can't actually control either the clients or the protocol, you can at least provide peer pressure and social support to get programs safely configured. You can use local installations under Unix or profiles under Windows NT to supply defaults that you find acceptable (this will work best if you also provide localizations that are useful to the user). For instance, you can supply configuration information for web browsers that turns off scripting languages and that also correctly sets proxying information and provides bookmarks of local interest. You want to make it easier and more pleasant to do things securely than insecurely.
You can also provide a security policy that makes clear what you want people to do and why. In particular, it should explain to people why it matters to them, since few people are motivated to go to any trouble at all to achieve some abstract notion of security. (See Chapter 25, "Security Policies", for more information on security policies.)
No matter how you end up trying to manage these configuration issues, you will want to be sure that you are monitoring for vulnerabilities. Don't fool yourself; you will never get perfect compliance using policies and defaults. (You'll be very lucky to get perfect compliance even when you're using force, since it requires perfect enforcement!)
Copyright © 2002 O'Reilly & Associates. All rights reserved.