Summary

  • Dan Farmer and Wietse Venema’s 1993 paper proposed turning an attacker’s view of network services into a repeatable audit for system administrators; SATAN later made that approach easier to run and interpret.
  • CERT described SATAN as a testing and reporting tool, but warned that its exploratory mode could probe hosts outside an administrator’s domain. Ease of use widened both defensive reach and the chance of unintended traffic.
  • A scan reports what its checks observed within a defined run. It does not, by itself, identify an actor’s intent, prove compromise, establish authorization, or show that untested systems are secure.

Making the outside view usable

Security advice often asks administrators to think like an intruder. Farmer and Venema’s contribution was to make that instruction operational. Their 1993 paper, “Improving the Security of Your Site by Breaking Into It,” argued that defenders needed to examine their own systems using methods that exposed weaknesses from the network. Rather than treating security as a checklist completed from inside each host, the paper described a way to inspect connected services and look for weaknesses an outsider could encounter.

The naming in the record reflects the tool’s development. The 1993 paper called SATAN the “Security Analysis Tool for Auditing Networks.” The CERT Coordination Center’s 1995 advisory used the longer name “Security Administrator Tool for Analyzing Networks.” The paper was co-authored by Farmer and Wietse Venema; the later product and public debate should not erase that shared authorship. In a 2014 USENIX interview, Farmer recalled that the paper’s mention of SATAN drew more interest than the pair expected, prompting them to think more seriously about building it.

That is his retrospective account, not evidence of deployment or a particular use.

CERT’s description helps explain why the tool mattered. SATAN collected information about networked hosts by examining services such as finger, NFS, NIS, FTP and rexd. It could summarize what it found and use simple rules to investigate potential security problems, with brief explanations and pointers to patches or workarounds. It also gathered broader facts such as network topology and the hardware and software in use. The practical shift was from “someone should inspect the network” to a repeatable process that could assemble a view across many machines.

That made security work more legible. A system administrator could compare observed services with intended configuration, find known weaknesses, and decide where to apply fixes. But the report remained an inspection result, not an adjudication. A listed condition was something to investigate and address; it was not proof that an attacker had exploited it. Nor did a clean report prove safety: a scanner only speaks to the services, checks, hosts and moment included in that run.

The boundary was part of the instrument

CERT’s 3 April 1995 advisory, initially based on beta 0.51 and later updated after the official 1.1.1 release, described an exploratory mode that could probe hosts not explicitly specified. Those hosts might sit outside the operator’s administrative domain. CERT noted both malicious use and the possibility that a legitimate administrator could accidentally scan another site while exploring.

This was not merely a question of whether a user had good intentions. A tool’s scope depends on what its operator names, what the tool discovers from those starting points, and where follow-on checks are allowed to travel. The advisory’s warning means that “I started with my network” did not necessarily mean every resulting probe stayed inside it. Shared infrastructure and neighboring systems could experience traffic without being part of the operator’s intended test.

CERT also treated a separate issue separately. Its general SATAN advisory points readers to CA-95.07a, which covered a vulnerability in SATAN after release 1.0. That software vulnerability is not the same as exploratory scanning beyond a specified target. Keeping the two records distinct matters: one concerns the scope of a scan; the other concerns a flaw in the scanning tool itself.

The historical record supports a careful conclusion. SATAN made network auditing more accessible and reportable, while exposing how automation could blur the line between a chosen target and a discovered neighbor. It does not support claims that a particular scan was unauthorized, that SATAN compromised a host, or that the tool caused a specific incident. The advisory describes a capability and a risk, not a case file about an identified victim.

For a modern reader, the durable question is what a test actually establishes. Heng Lu’s Note 65, “Running-Code Primacy,” is used here only as an editorial lens on evidence from operating systems: a live observation should be bounded by what the running system actually did. It is not evidence about Farmer, Venema or SATAN. Under that lens, a scan is useful precisely when its target list, discovery behavior, observation window and exclusions are visible.

Sources