# Dangers of SARA

How could a friendly program such as SARA be called dangerous? Well, there are two reasons; first, system crackers, potential intruders, or simply random people on the Internet could run the program against hosts that they have no authorization to do so against. This could be a problem especially since some of the probes that SARA uses are very similar to some attack methods used by system crackers (and that's part of the reason that it works so well), and alarms and blood pressures could be raised unnecessarily. The second reason is that even a well-intentioned system administrator could run SARA on her or his system and it could follow lines of trust or potential vulnerability far beyond their authorized e-borders and anger or frustrate their neighbors. The safest way to run SARA is behind a firewall - since SARA will only probe systems that it has IP connectivity to, it will never cross the firewall host (assuming IP_FORWARDING is turned off.) Be VERY careful if you're running SARA behind a firewall that allows inside users to have direct IP connectivity to hosts on the Internet! You are essentially on the Internet as far as SARA is concerned, so follow the above guidelines.

### Controlling SARA

SARA 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, SARA 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/sara.cf documentation for more on this topic. In addition to proximity levels, it has two other methods to restrict SARA's wanderings - the two targeting exception variables "$only_attack_these" and "$dont_attack_these". The first can limit SARA 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 SARA that it shouldn't probe any hosts of a specific name - for instance, all military (".mil") or government (".gov") sites. See the config/sara.cf documentation for more on this topic. We strongly recommend that you leave the proximity level to "0".

### Boundary issues - keeping track of where it is

When SARA 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 SARA will go, set the proximity levels to be very low (start at zero!) and set the $only_attack_these variable to disallow SARA 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 SARA 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 SARA 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 SARA

Not only is it an unfriendly idea to run SARA 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, SARA could change that. Heed the warnings, limit your scans to authorized hosts, and all should be well.

Back to the Introductory TOC/Index