As
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.
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!)