services

The services file classifies hosts by services, to make reports more suitable for reading. The file is broken into two parts: SERVERS and CLIENTS. Each rule consists of a PERL matching condition that has access to the facts database and can reference each part of a fact using the variable names such as $service or $text. If that rule evaluates to true, the second field is assumed to be provided (if under SERVER) or used (if under CLIENT). A third field can specify a hostname; if not specified, SATAN assumes that the $target of the current fact record is the hostname.

Here is an example from the satan-1.1.1/rules/services file:

/offers gopher/                         Gopher
/offers http/                           WWW

Notice that this services file is used by SATAN when generating a Results screen or a report. The output from the conclusions drawn by these rules is not stored in any file.

todo

The todo file specifies probes to try based on existing facts. Each rule consists of a condition, once again a PERL matching statement, a target to probe, the tool to use in the probe, and any arguments needed for that tool.

Here is an example from the satan-1.1.1/rules/todo file:

$service eq “ypserv”          $target “ypbind.satan”
$service eq “rexd”            $target “rex.satan”

The rules indicate that if the $service field of a record in the SATAN facts database is either “ypserv” or “rexd”, SATAN should run either “ypbind.satan” or “rex.satan” against the $target indicated in that record.

This file can be used for expansion of SATAN. If, for example, a user would find a vulnerability against the echo service, the user could create an echo.satan tool and add an entry such as this:

$service eq “echo”         $target “echo.satan”

trust

The trust file contains rules that are used by SATAN to classify hosts on the basis of trust. The first field is a PERL matching condition that is applied against each fact record, whereas the second field is the conclusion drawn if the first field evaluates to true.

Here is an example from the satan-1.1.1/rules/trust file:

$text =~/ mounts \S+/      NFS export
/serves nis domain/        NIS client

The first entry indicates that if the $text field of a fact contains the word “mounts” followed by a string, this system is exporting NFS file systems. The second entry indicates that if the fact contains the text “serves nis domain,” this system trusts NIS clients.

Extending SATAN

A new probe can be added to SATAN by creating a new .satan tool and putting it into the bin/ directory. Then the tool name must be explicitly added to the satan.cf file under a scan level. The tool can be conditionally invoked using the rulesets, if so desired, as discussed previously, by adding it to the satan.cf using a trailing “?”. Finally, ruleset changes can be added, if so desired, and new documentation describing the vulnerability and how to deal with it is a worthwhile addition.

You might extend SATAN to search for the FTP server bounce problem described earlier in this chapter. The goal of ftpbounce.satan is to see if the remote ftpd server permits a client to specify any remote client IP address and TCP port to receive a file transfer. If the remote ftpd permits a PORT command with an IP address that is different from the originating source, and a TCP port that is reserved, the ftpd is open to this problem.

The quickest way to make ftpbounce.satan is to copy ftp.satan to ftpbounce.satan and make appropriate modifications. (Each .satan tool must output fact records, and using the existing approach from current .satan tools makes this quite easy.) Here is a clip from ftp.satan:

open(FTP, “$FTP -nv <<EOF
open $target
quote user anonymous
quote pass -satan\@
cd /
put /etc/group $$.foo
dele $$.foo
quit
>EOF /”) // die “cannot run $FTP”;
while(<FTP>) {
    if (defined($opt_v)) {
        print;
    }
    if (/^230/) {

This just needs to be modified to look for a 200 reply to an attempt to send a PORT command, as shown in this clip:

open(FTP, “$FTP -nv <<EOF
open $target
quote user ftp
quote pass -satan\@
quote port 1,2,3,4,0,25
quit
EOF /”) // die “cannot run $FTP”;
while(<FTP>) {
    if (defined($opt_v)) {
        print;
    }
    if (/^200 PORT command successful/) {
        $status = “a”;
        $severity = “x”;
        $trustee = “”;
        $trusted = “”;
        $service_output = “BOUNCE”;
        $text = “offers ftp server bounce”;

Now the ftpbounce.satan script is ready to be listed in the heavy scan listing in satan.cf. At this point, an HTML document describing the fix (“Get the patch from a vendor, or the latest wu-ftpd”) should be added into the links available on the tutorials web page. Lastly, the ftpbounce.satan tool and the new web pages should be sent to the creators of SATAN for inclusion into new versions of the program. (Send the changes to satan@fish.com.)

The tool does not have to be written in PERL. It can be written in any language as long it takes an argument specifying the target name and emits records that comply to the facts database format. It is possible to use hybrid tools, and SATAN does this: many of the .satan tools are written in PERL but call compiled programs, such as nfs-chk (which is written in C).