The dangers of writing SATAN are tangible as well. One of the authors lost his job because of it; there has been a letter writing campaign to stop the release of the program. People accuse us of writing it for noterieties sake and pure personal gain. And the newspaper reports of the mission of the program have not been, as they say, wholly favorable.
Controlling SATAN
SATAN has three main safeguards built into the program. First, it will
never venture further than the proximity level number of
hosts away from the original target or subnet. Each host or ring of
hosts that is/are adjacent to the original target is one proximity level
further away. So if the proximity level is set to two, SATAN will never
attack more than two hops away from the original target. This can still
be a very sizable number of hosts, because it can progress
exponentially! See the config/satan.cf
documentation for more on this topic. In addition to proximity levels,
it has two other methods to restrict SATAN's wanderings - the two
targeting exception variables "$only_attack_these" and
"$dont_attack_these". The first can limit SATAN to probe only
hosts in a specified set of hosts, governed by their FQDN (such as
"berkeley.edu", "sun.com", or whatever), and the second
can inform SATAN that it shouldn't probe any hosts of a specific name -
for instance, all military (".mil") or government (".gov")
sites. See the config/satan.cf
documentation for more on this topic.
Boundary issues - keeping track of where it
is
When SATAN probes hosts, it updates a status file (called
status_file by default) with a time stamp and with the last
executed action.
Setting the verbose/debug flag (the "-v" option) will output the
current host on the command line, but with quite a bit of other output
as well, and it can be difficult to keep track of things.
Being a very unfriendly neighbor
It is generally considered to be very rude and anti-social behavior to
scan someone else's hosts or networks without the explicit permission of
the owner. Always ask if it'd be ok to scan outside of
your own networks. If you're unsure about where SATAN will go, set the
proximity levels to be very low
(start at zero!) and set the
$only_attack_these variable to disallow SATAN from scanning anything
but your own hosts.
Please be considerate and smart; unauthorized scanning of your Internet neighbors, even if you think you're doing them a favor, can be seen as a serious transgression on your part, and could engender not only ill will or bad feelings, but legal problems as well.
Attacking vs. probing vs. scanning
What is an attack, or a probe, or a scan? It's not always clear,
especially as system administrators are getting more savy and aware of
the enormous amount of traffic present on the Internet (see Steve
Bellovin's
paper on this topic for more information about this). For instance,
is a finger from a remote site an attack? Without knowing any of the
motivations involved, it can't be ascertained. "Finger wars", or two
sites that use the "tcp wrappers" or similar software that will
automatically finger a remote site that connects to it can bring down
hosts inadvertently.
Certainly SATAN could be used to attack systems, but just as certainly, it wasn't designed for that. In the documentation we use scanning and probing fairly interchangeably, and as long as SATAN is used properly, that's all it will ever do. Be aware that many of the probes will generate messages on the console or set off various alarms on the remote target, however, so you should be aware of the potential for false alarms and accusations that might be leveled against you.
Legal problems with running SATAN
Not only is it an unfriendly idea to run SATAN against a remote site
without permission, it is probably illegal as well. Do yourself and the
rest of the Internet a favor and don't do it! While we don't know of
anyone being charged with a crime or sued because they ran a security
tool against someone else, SATAN could change that. Heed the warnings,
limit your scans to authorized hosts, and all should be well.