SARA is a derived work of the Security Administrator Tool for Analyzing
Networks (SATAN) (http://www.porcupine.org/satan).  SATAN was developed
by Dan Farmer and Wietse Venema.  

  o For a copyright notice of SARA and SATAN, refer to COPYING

  o For configuration information on SARA's daemon mode, please refer
    to the comments in the config/sara.cf file.

  o For operational information on SARA Reporter (SARA report writer), 
    look for information on the initial SARA page.

  o For information on SARA and SANS Top 10 Vulnerability Certification,
    check out the initial SARA page.

  o For CVE compliance, review the initial SARA page.

  o For SARA Self Scan, read sss/README.

Check the INSTALL for details on installing, building, and running SARA.

-------------------------------------------------------------------------
3 March 2007

SARA 7.1.3a introduces a change in how SARA resolves hostnames.  Previous 
versions would force hostname resolution to the real (IN) name even if the 
alias (CNAME) name was supplied as an argument.  This method was good for 
providing a one-to-one mapping of name to IP.  However, it did not fully 
address the scanning issues associated with virtual hosting (2 or more names
mapped to an IP).  In this case each unique hostname could be responsible 
for an entirely different web site. To fully view the unique web sites, the 
proper hostname had to be used. For instance, a DNS entry of could be 
hypothesized:

		origin.domain.com		IN	192.168.0.100
		myweb.domain.com		CNAME	origin
		yourweb.domain.com		CNAME	origin

If previous version of sara was asked to scan myweb.domain.com, it would 
determine the IP then lookup the IN record and change the target name to 
origin. (This is the way most vulnerability scanners work)

Starting with SARA 7.1.3a, the inputted hostname is preserved.  This will
improve the accuracy of web scans (http.sara) and is essential for web
crawling for SQL injection testing. 



13 February 2007

SARA 7.1.1 now has an optional SQL injection module (SQLiX from
www.osawp.org/index.php/Category:OWASP_SQLiX_Project) which performs
injection on port 80 servers.  As it takes 15 to 30 minutes to 'crawl'
through a typical web server, it is not enabled by default.  There are
two ways to enable (not recommended for large scans):

a.  Command line mode:
     Add -c "sql_inject=1" to the command line

b.  config/sara.cf mode:
     Change the $sql_inject variable to "1"

The results will be published in the report.html(.csv)(.xml) files.

If you need more details on detected vulnerabilities, use

      bin/inject.sara -v <hostname>

You may have to wait up to 15 minutes for results

-------------------------------------------------------------------------
15 November 2004

SARA 5.3.0 includes an optional, offline package, called rdesktop which
will test user accounts previously found by SARA over the remote desktop
protocol (rdp).  It is not built by default as it can be difficult to 
operate.  Check the INSTALL document for pre-requisites.

-------------------------------------------------------------------------  
15 October 2004

Starting with SARA 5.2.0, SARA will discover hosts in a variety of ways.
They include:

1.  Normal ping:  Using the standard bin/fping, SARA will continue to
    to test for host presence.

2.  Firewall ping:  Using bin/fwping, SARA will test the response to a tcp
    probe of several ports (looking for any type of response)

3.  ARP search:  Checking the local arp cache, SARA will determine if there
    is a MAC address for the target IP.  Also, if you developed an interface
    to ip2mac, then a valid response from your arp agent will be collected.

Based on these tests, SARA will assign (in the all_hosts file) one of the 
following values:

	a. alive: if (1) and (2) are true
        b. fw-0:  if (1) fails but (2) is true
        c. fw-1:  if (1) is true but (2) fails
        d. fw-2:  if (2) reports open, closed, AND filtered ports
        e. fw-3:  if (1) and (2) fail but there is a valid arp response.

Special reduced port scanning (IAW config/sara.cf) will be performed for fw-1, 
fw-2, or fw-3 responses.

All of the reporting products (report.xml, csv,html) have new fields 
installed to record the firewall data.   

The -f flag no longer has any significance.

------------------------------------------------------------------------------     

15 December 2003

Many changes were made to the report generation process.  The report.xml
becomes the focal point for the csv and html reports.  The html and csv
reports have been changed significantly to improve readability and
consistency with CVE and SANS20.

We are headed more towards a rule based architecture where several functions
have ben migrated to rules/<service>.rules.  More to come in the future.

We are about 40 % towards migrating our tutorials to the standard Cert
advisories.  More to come here also.

We are current with the CVE and the SANS/20-4 specifications.

We have been reminded about some of the security issues with SARA.  For
enterprise level SARA scans, it is advisable that the SARA host(s) only
allow trusted users.  Though difficult, any legitimate user on the SARA
system, could access the SARA server while it is running.

We have dropped all reportwriter support for SAINT (as it now proprietary)
and SATAN (as it is obsolete).  Reportwriter is now integrated into the
SARA report process.  Note that the operation of the -r switch has changed
check ./sara -h or man sara.8 for details.

Users are encouraged to join the sara-l list at www-arc.com/sara.
-------------------------------------------------------------------------
2 October 2002

The Advanced Research Corporation (r), supporting the FBI/SANS Vulnerability
Consensus, is releasing SARA-4.1.1 which fully incorporates the new
Top 20 list and the industry consensus of relevant vulnerabilities
(as referenced by Common Vulnerabilities and Exposures (CVE) items).
This feature will be available in the SARA ReportWriter and will be
migrated into the XML report in future releases.

SARA will be available from the Advanced Research Corporation (ARC) web site
at:

      http://www-arc.com/sara/downloads/sara-4.1.1.tgz

General information on SARA and the ARC can be found at:

      http://www-arc.com

Contact Bob Todd (toddr@arc.com) for details.


19 September 2002

One of customers asked for a method to insert the MAC address into
the SARA reports.  The customer agreed to build the MAC proxy server
for their enterprise.   SARA would query the MAC server, add the MAC to
the all-hosts file, and insert it into the appropriate csv and xml files.
SARA users are invited to build their own MAC servers and use the 
ip2mac() function in perl/misc.pl to access it.  This facility is 
deactivated by default.  To enable it, uncoment the $mac_proxy line in
config/sara.cf and add the appropriate server address.

01 February 2002

We added the SARA Self Scan (SSS) facility.  Details on SSS can be found
in the file sss/README.

02 August 2001

Several of our customers have requested a facility to associate hosts
with the system administrator in the ReportWriter outputs (html and csv
formats).  Starting with SARA-3.4.8, a beta version has been introduced.
A new directory (administrators) has been added to the sara directory
structure.  For each administrator, a file should be created that
contains one or more lines, each containing an IP or IP range (Class C
limit).  I am using the email address for the filename for each 
administrator.  You can use any legal Unix file name scheme.  A sample
file is provide under the administators directory.  To activiate
this feature, set the $get_admins to "1" in config/sara.cf. That should
do it. 


17 July 2001

During our enterprise scans, we determined that we were missing many
hosts during the night hours.  Many foks turned of their systems at
night.  In order to maximize coverage, SARA has an option of running
during periods.  The file rules/timing contains smaples of how to 
restrict SARA scanning periods.
 

Many SARA tests cannot determine with absolute certainty if
the service is vulnerable.  In these cases, it makes a best
guess.  The guess may not always be correct which could 
result in an unfair assessment.  As a result, we have
added a facility to cancel possible incorrect assesssments.

What to do?

1. Define the file rules/correct_report with the following
   format:

   host|keyword|Certifier|Date

   Where

	host:       The name/IP as represented in the SARA report

	keywordx:   Word in the SARA report that identifies the
                    improperly detected vulnerability (e.g., RDS,
		    printer, etc)

	Certifier:  Name of person who certifies that the keyword
                    services are not vulnerable

	Date:       Date of certification


2.  When running sara, add the -C argument to enable manual correction
    or change the $correction variable in config/sara.cf

3.  Run SARA Reporter.  The corrections will be applied to the report.

4.  Note that this correction table only functions with SARA Reporter
    at this time.



