About InterSect Alliance0
Intersect Alliance, part of the Prophecy International Holdings Group, is a team of leading information technology security specialists. In particular, Intersect Alliance are noted leaders in key aspects of IT Security, including host intrusion detection. Our solutions have and continue to be used in the most sensitive areas of Government and business sectors.
Intersect Alliance intend to continue releasing tools that enable users, administrators and clients worldwide to achieve a greater level of productivity and effectiveness in the area of IT Security, by simplifying, abstracting and/or solving complex security problems.
Intersect Alliance welcomes and values your support, comments, and contributions.
For more information on the Enterprise Agents, Snare Server and other Snare products and licensing options, please contact us as follows:
The Americas +1 (800) 834 1060 Toll Free | +1 (303) 771 2666 Denver
Asia Pacific +61 8 8213 1200 Adelaide Australia
Europe and the UK +44 (797) 090 5011
Email intersect@intersectalliance.com
Visit www.intersectalliance.com
- Configuration File Description
The purpose of this section is to discuss the parameter settings of the Snare configuration file located at /etc/security/snare.conf, and this location may not be changed. If the configuration file does not exist, the audit daemon will not actively audit events until a correctly formatted configuration file is present.
Snare can be configured in several different ways, namely:
a. Via the Remote Control Interface (recommended), or b. By manually editing the configuration file (advanced users only).
The format of the audit configuration file is discussed below. Any line beginning with "#" will be treated as a comment line and ignored. Any number of tabs or spaces can be used. Major tokens such as [Config] must be surrounded by the square brackets.
[Config] |
This section allows you to specify settings relating to the operation of the Snare agent. |
|
set_audit=[1 |
0] |
This value determines if Snare should set the auditing configuration for the local machine. |
clientname=override |
The hostname of the client. If no hostname is set, the value of "hostname --fqdn" will be used |
|
cache_size=(0 - 100000) |
This value determines the size of the event cache,ie; the number of events, that Snare should keep if it cannot reach at least one of the hosts. The value must be between 0 and 100000. This feature only appears in Enterprise Agents only. |
|
use_utc=[1 |
0] |
Enable UTC (Universal Coordinated Time). This feature only appears in Enterprise Agents only. |
syslog_facility=facility |
The SYSLOG facility used when sending to a SYSLOG server. |
|
syslog_priority=priority |
The SYSLOG priority used when sending to a SYSLOG server. |
|
AgentLog=0 |
To be added to the Remote Control Interface as a setting in the future release of version 5.0 of the Snare for Solaris agent. |
|
HeartBeat=0 |
To be added to the Remote Control Interface as a setting in the future release of version 5.0 of the Snare for Solaris agent. |
[Remote] |
This section allows you to specify settings relating to the Remote Control Interface used to control Snare. |
|
allow=[1 |
0] |
Turn the Remote Control Interface on or off. |
listen_port=6161 |
Set a port that the Snare for Solaris agent should listen on. |
|
accesskey_enabled=[1 |
0] |
Password is required to be set |
accesskey=md5password |
Md5 checksum of the password used to protect the embedded web server |
|
restrict_ip_enabled=0 |
Restrict the Remote Control Interface to an IP. |
|
restrict_ip=1.2.3.4 |
IP address of a system that is used to remotely control the agent. All requests from other systems will be dropped. |
[Output] |
By default, if no output section exists within the configuration file, the audit daemon will not send any data to anywhere. Otherwise, audit events will be sent to all valid destinations specified in the Output section. As such, events can be sent to one or all of a file, or to a remote network destination |
network=hostname:port:protocol:format |
Data will be sent to the remote host, and network port specified here. Audit data can be sent to a remote system using the UDP or TCP protocol. SSL may also be used to indicate an encrypted TCP connection. Format may be either SNARE or SYSLOG. E.g networkOutput0=10.1.1.30:6161:TCP:SNARE |
file=/fully/qualified/file/name |
The audit daemon will send data to the fully qualified filename. The directory must exist. The file will be created if it doesn't exist. E.g file=/var/log/filewatch.log |
[Objectives] |
This section describes the format of the objectives. Objectives are composed of:
|
criticality=1 event=execve return=Success user=maria match=/sbin |
Report at criticality level 1, whenever the user 'maria', attempts to execute a binary within /sbin, |
Shown below is an example /etc/security/snare.conf file. It is an example file only, and should NOT be used for operational purposes. It has been included to demonstrate the key concepts of formulating a snare.conf file, as discussed above.
Example snare.conf file
#This is a comment line with no leading spaces
[Config]
use_criticality=1
set_audit=1
encrypt_msg=0
AgentLog=0
HeartBeat=0
clientname=
cache_size=1000
use_utc=0
syslog_facility=1
syslog_priority=6
[Output]
networkOutput0=10.1.7.12:6161:TCP:SNARE
fileOutput0=/var/audit/snare.log
fileOutput1=/root/v4test/sol11.log
[Remote]
accesskey_enabled=1
restrict_ip_enabled=0
allow=1
listen_port=6161
accesskey=snare
[Objectives]
criticality=4 match=^/etc/(passwd|shadow)$ user!=root event=open_rc,open_rt,open_rtc,open_rw,open_rwc,open_rwt,open_rwtc,creat,mkdir,mknod,link,symlink return=success
criticality=4 match=^/etc/shadow$ user!=root event=open_r return=success
criticality=3 match=^/etc/(passwd|shadow)$ user!=root event=open_rc,open_rt,open_rtc,open_rw,open_rwc,open_rwt,open_rwtc,creat,mkdir,mknod,link,symlink return=failure
criticality=3 match=^/etc/shadow$ user!=root event=open_r return=failure
criticality=3 match=^(/var/audit|/etc/security)/.* user=.* event=open_rc,open_rt,open_rtc,open_rw,open_rwc,open_rwt,open_rwtc,creat,mkdir,mknod,link,symlink return=success
criticality=2 match=^(/var/audit|/etc/security)/.* user=.* event=open_rc,open_rt,open_rtc,open_rw,open_rwc,open_rwt,open_rwtc,creat,mkdir,mknod,link,symlink return=failure
criticality=1 match=.* user=.* event=exec,execve return=*
criticality=1 match=.* user=.* event=login,logout,telnet,rlogin,rshd,rexecd,ftpd,su,ssh return=*
criticality=1 match=.* user=.* event=passwd return=*
criticality=2 match=.* user=.* event=mountd_mount,mountd_umount,umount return=*
criticality=2 match=.* user=.* event=systemboot,halt_solaris,reboot_solaris,shutdown_solaris,poweroff_solaris return=*
criticality=2 match=.* user=.* event=audit,auditon_stermid,auditon_setstat,auditon_setstat,auditon_setumask,auditon_setsmask,auditon_setcond,auditon_setclass return=*
criticality=0 match=.* user=.* event=open_r,readlink return=*
criticality=0 match=.* user=.* event=open_rc,open_rt,open_rtc,open_w,open_wc,open_wt,open_wtc,open_rw,open_rwc,open_rwt,open_rwtc,creat,mkdir,mknod,xmknod,link,symlink,rmdir,unlink,rename,truncate,ftruncate return=*
criticality=0 match=.* user=.* event=connect,shutdown,setsockopt return=*
- Event Output Format
The audit_snare plugin reads data from the Solaris kernel, via auditd. It converts the binary audit data into text format, and separates information out into a series of token/data groups. Three different field separators are used in order to facilitate follow-on processing - TABS separate 'tokens', COMMAS separate data within each token, and SPACES separate elements within data.
A 'Token' is a group of related data, comprising a 'header', and a series of comma separated fields which make up data that relates to the header.
Examples of tokens:
- process,1628,gcc
- return,0
- path,/etc/audit/audit.conf
- arguments,ls -al
Groups of tab separated tokens make up an audit event, which may look something like this, depending on whether the audit daemon has been set to 'objective' or 'event' reporting mode (see the configuration section for more information):
phoenix SolarisBSM1header,146,2,execve(2),,Mon Dec 9 22:23:42 2002, + 140001416 msec path,/usr/bin/grepattribute,100555,root,bin,136,379861,0exec_args,2,grep,snaresubject,red,root,other,root,other,12228,12212,8236 131095 10.0.1.1return,success,0sequence,65941
A simple example PERL script for extracting data from a raw Snare log is as follows:
#!/usr/bin/perl
- Usage: cat /var/log/audit/audit.log | ./extract.pl
- Creates an associative array containing the elements of the event record, and prints the data.
while($input=<STDIN>) {
chomp($input);
%Record=();
@tokens=split(/\t/,$input); # Split the line into TAB delimited tokens.
foreach $token (@tokens) {
@elements=split(/,/,$token); # Pick out the elements within each token.
$header=$elements[0];
if($header eq "objective") {
$Record{$header}{"criticality"} = $elements[1];
$Record{$header}{"datetime"} = $elements[2];
$Record{$header}{"description"} = $elements[3];
} elsif ($header eq "event") {
$Record{$header}{"eventid"} = $elements[1];
$Record{$header}{"datetime"} = $elements[2];
} elsif ($header eq "user") {
$Record{$header}{"uid"} = $elements[1]; # User ID
$Record{$header}{"gid"} = $elements[2]; # Group ID
$Record{$header}{"euid"} = $elements[3]; # Effective User ID
$Record{$header}{"egid"} = $elements[4]; # Effective Group ID
} elsif ($header eq "process") {
$Record{$header}{"pid"} = $elements[1]; # Process ID
$Record{$header}{"name"} = $elements[2]; # Process Name (max 16 chars)
} elsif ($header eq "path") {
$Record{$header}{"path"} = $elements[1];
} elsif ($header eq "destpath") {
$Record{$header}{"destpath"} = $elements[1]; # Destination path
} elsif ($header eq "arguments") {
$Record{$header}{"args"} = $elements[1];
} elsif ($header eq "attributes") {
$Record{$header}{"attrib"} = $elements[1];
} elsif ($header eq "return") {
$Record{$header}{"code"} = $elements[1];
} elsif ($header eq "target") {
$Record{$header}{"user"} = $elements[1];
} elsif ($header eq "owner") {
$Record{$header}{"user"} = $elements[1];
$Record{$header}{"group"} = $elements[2];
} elsif ($header eq "socket") {
$Record{$header}{"sourceip"} = $elements[1];
$Record{$header}{"destip"} = $elements[2];
$Record{$header}{"sourceport"} = $elements[3];
$Record{$header}{"destport"} = $elements[4];
} elsif ($header eq "sequence") {
$Record{$header}{"number"} = $elements[1];
}
} - We now have the data in an associative array.
- Roll through the array, and print the data in token groups.
foreach $header (keys(%Record)) {
print "Header: $header\n";
foreach $element (keys(%{$Record{$header}})) {
print "$element = " . $Record{$header}{$element} . "\n";
}
} - In addition, if the event is execve, the effective user ID
- is 'root', but the real user ID is NOT, then display an alert.
if($Record{"event"}{"eventid"} eq "execve" && $Record{"user"}{"euid"} eq "root" && $Record{"user"}{"uid"} ne "root") {
print "Danger: SetUID program " . $Record{"arguments"}{"args"} . " has been run by the user " . $Record{"user"}{"uid"} . " .\n";
}
print "\n";
}
print "----- Done -----\n"; - Known BSM 'bugs'
The Solaris BSM subsystem has a number of 'bugs' (or 'features') which have been identified and
documented in the course of the Snare for Solaris development process. These are detailed
below:
•The 'auditon' system call ONLY turns on system-related audit events (ie. events with
an ID less than 512).(Solaris 10)
•Forked processes do NOT inherit audit settings. Each process is re-applied with the
contents of /etc/security/audit* at startup.(Solaris 10)
•auditconfig -conf makes a range of decisions w.r.t the processes that need to have
auditing applied, but it's decision making process is opaque, and some processes
(including nscd, thankfully), are missed out. This leads to some reasonably important
processes (such as the mount daemon, and openssh) being ignored by the Solaris BSM
subsystem.(Solaris 10 and Solaris 11)
- Configuring Solaris Plugins
With the installation of the Snare Enterprise Agent for Solaris, the auditing subsystem is enabled. This may enable plugins that require configuring to suit your organization. Solaris 10 and 11 both use plugins.
With Solaris 10, when we install the audit_control file we indicate to use the Snare plugin by default:
- #ident @(#)audit_control.txt 1.4 2005/11/24 LJP # # audit_control file for snare # dir:/var/audit flags:ia minfree:20 naflags:ia plugin:name=/usr/lib/security/audit_snare.so
If logging to local disk is also required, either Snare can be used to log to file in Syslog or Snare format, or the standard Solaris audit logs can be logged by using the binfile plugin, like so: # #ident @(#)audit_control.txt 1.4 2005/11/24 LJP # # audit_control file for snare # dir:/var/audit flags:ia minfree:20 naflags:ia plugin:name=/usr/lib/security/audit_snare.so plugin: name=audit_binfile.so;\ p_minfree=20;\ pdir=/var/audit/
This particular setup will put the standard Solaris audit logs into the /var/audit directory, limiting to 20MB free.
Solaris 11 uses the Service Manager to handle the plugins rather than the audit_control file. The auditconfig command can be used to configure this:
#auditconfig -getplugin Plugin: audit_binfile (active) Attributes: p_dir=/var/audit;p_fsize=0;p_minfree=1 Plugin: audit_snare (active) Attributes: Queue size: 1
Further details for configuring Solaris 11 plugins can be found in the Solaris 11 documentation. - Disable audit_binfile
The bin format plugin is responsible for writing log files, and it is enabled by default, when installing Snare Enterprise Agent for Solaris. This log file (20160731135700.20160810191133.hostname ) can rapidly fill disk space.
To disable the audit_binfile plugin which creates the binary files in /var/audit execute:
auditconfig -setplugin audit_binfile inactive
To check your active/inactive plugins execute:
auditconfig -getplugin
Your result may be similar to the following:
Plugin: audit_binfile (inactive)
Attributes: p_dir=/var/audit;p_fsize=0;p_minfree=1
Plugin: audit_snare (active)
Attributes:
Queue size: 1
Large snare.log file
The default install for the Solaris agent does not have a destination so it just logs to a log file, in Network Configuration screen | File Output | FileName.
After you have set a destination IP address or hostname you can delete the snare.log file option, if required. Just delete the text in the FileName field then save the configuration, so it does not log locally anymore, and therefore your disk will not fill.
If you do want to keep a local log file then you will need to implement your own cron job to cycle the log file and restart the agent each day or at a frequency to suit.
- Filter on special or specific event
The following filter, filter on special, event-specific fields, can be applied to incoming audit events only available via the configuration file.
Some events, including open() and socketcall(), allow additional filters to be specified, to provide more flexible search criteria.
- open()
The open event provides the additional capability to filter on open-flags. The flags are specified in regular expression format, and can include (in the following order):
O_WRONLY O_RDWR O_RDONLY O_CREAT O_EXCL O_NOCTTY O_TRUNC O_APPEND O_NONBLOCK O_SYNC O_NOFOLLOW O_DIRECTORY O_LARGEFILE
For example, the following flags can be logically 'or'ed together (in regular expression form) to specify an objective that translates to 'Let me know whenever a file is opened in WRITE mode':
- open(O_WRONLY|O_RDWR|O_CREAT|O_TRUNC|O_APPEND)
Whereas the following three examples all specify 'Read or Write':
- open(.*)
- open(O_.*)
- open(O_WRONLY|O_RDWR|O_RDONLY|O_CREAT|O_EXCL|O_NOCTTY|O_TRUNC|O_APPEND|O_NONBLOCK|O_SYNC|O_NOFOLLOW|O_DIRECTORY|O_LARGEFILE)
More information on the flags associated with the open() system call are available from the Solaris manual pages (see 'man open').
- socketcall()
The Solaris kernel uses the 'socketcall' system call to serve the requirements of the 'connect', 'accept' and related system calls. In order to monitor 'connect' and 'accept' calls only, the system call 'type' can be included within the objective.
For example, socketcall(ACCEPT) only monitors accept() calls. socketcall(CONNECT) only monitors connect() calls. socketcall(.*) or socketcall(CONNECT|ACCEPT) monitor both accept and connect.