Return to Installation

Configuration

The configuration file is /ossonar/etc/config/OSSONAR.conf.

It should be edited by the command /ossonar/bin/editconfig.


First-Time Install (Custom Config)

On a first-time install of OSsonar, i­f /etc/OSSONAR.conf exists,it will be copied as the standard instead of the default one in /ossonar/language.

By  creating an /etc/OSSONAR.conf, you are causing the initial config file to be created with your values.  This is helpful with installs after you have one OSsonar configured the way you want it.  If /etc/OSSONAR.conf is used, the Node Section will be redone and the Ignoredirs Section will be updated by adding the standard entries and deleting any entries that are not directories on this node.


 System


Section language

The varible OSSLANG will be set to the language code.  No spaces around the = sign.

Example:

 

[important]

Section language start

OSSLANG=en

Section language end

[/important]

 


Section date

The varible OSSUSDATE will be set to yes if date is to be displayed in USA  format.  No spaces around the = sign.

Example:

 

[important]

Section date start

OSSUSDATE=yes

Section date end

[/important]

 


Section sshport

The varible SSHPORT will be set to the port other nodes should use to access this node’s ssh.  No spaces around the = sign.

Example:

 

[important]

Section sshport start

SSHPORT=22

Section sshport end

[/important]

 


Section node

If set to “unknown”, the varible OSSNODE will be set to the short host name during first-time installation.  OSSNODE cannot exceed 8 characters.  A host name that doesn’t  begin with an alphabetic can cause problems in some GNU commands.  No spaces around the = sign.

Example:

 

[important]

Section node start

OSSNODE=gamma

Section node end

[/important]

 


Section passwd

How do I get a list of users and their passwords (/etc/passwd format) for this machine?  If you are using network data managers like NIS/NIS+/LDAP, you will need to provide this procedure that outputs 7 colon delimited fields in /etc/passwd format.  The default is /ossonar/bin/getpasswd which outputs 7 colon delimited fields in /etc/passwd format.  (This program adds the encrypted password back into data)

Example:

 

[important]

Section passwd start

/ossonar/bin/getpasswd

Section passwd end

[/important]

 


Section shadow

How do I get a list of passwords (/etc/shadow format) for this machine?  If you are using network data managers like NIS/NIS+/LDAP, you will need to provide this procedure.  The getshadow program will either output /etc/shadow or will make up a shadow file if /etc/shadow does not exist.

Example:

 

[important]

Section shadow start

/ossonar/bin/getshadow

Section shadow end

[/important]

 


Section group

How do I get a group list (/etc/group format) for this machine?  If you are using network data managers like NIS/NIS+/LDAP, you will need to provide this procedure.

Example:

 

[important]

Section group start

cat /etc/group

Section group end

[/important]

 


Section services

How do I get a services list (/etc/services format) for this machine.  If you are using network data managers like NIS/NIS+/LDAP, you will need to provide this procedure.

Example:

 

[important]

Section services start

test -f /etc/services && cat /etc/services

Section services end

[/important]

 


Section ignoredirs

This is a list of directories that should be ignored.  NFS mount directories are automatically ignored.

Example:

 

[important]

Section ignoredirs start

/linux/proc

/mnt /proc

/usr/tmp

/var/named/chroot/proc

/var/tmp

Section ignoredirs end

[/important]

 


Section misc

This is a list of misc. variables.

XFERBACKUP, if set to 1, will copy /ossonar/etc/backup to the “alertxfer” node’s /ossonar/etc/backup.  This then is an off-site backup of the configuration files.

XFERLOGS, if set to 1, will copy /ossonar/etc/logs to the “alertxfer” node’s /ossonar/etc/backup.  This then is an off-site backup of the log files. XFERBACKUP must be set to 1.  You can’t just copy the logs.  The log files are  trimmed to the last XFERTRIM lines.  If XFERTRIM is set to zero, the logs will not be trimmed.

Defaults:

XFERBACKUP=1

XFERLOGS=1

XFERTRIM=10000


Alert Manager


Section alertlevels

No spaces around the = sign.

Alert Rule 1:

When a sensor sends out an alert it is counted.  Until the count reaches LVL1THRESHOLD, lvl1alert is executed.  After this, lvl2alert is executed until the count reaches LVL2THRESHOLD.  lvl3alert is executed until the count reaches LVL3THRESHOLD.  When LVL3THRESHOLD is reached, the count is reset to zero and the levels start over.

Add 1 to count

While count <= LVL1THRESHOLD, lvl1alert is executed

While count > LVL1THRESHOLD and <= LVL2THRESHOLD lvl2alert is executed  While count > LVL2THRESHOLD and <= LVL3THRESHOLD lvl3alert is executed  If count > LVL3THRESHOLD, count = 1 and lvl1alert is executed

Alert Rule 2:

When a sensor sends out an alert it is counted.  Until the count reaches LVL1THRESHOLD, lvl1alert is executed.  After this, lvl2alert is executed until the count reaches LVL2THRESHOLD.  After this, LVL3THRESHOLD is ignored and lvl3alert is executed until the sensor is no longer concerned.

Add 1 to count

While count <= LVL1THRESHOLD, lvl1alert is executed

While count > LVL1THRESHOLD and <= LVL2THRESHOLD lvl2alert is executed  While count > LVL2THRESHOLD lvl3alert is executed

Example:

 

[important]

Section alertlevels start

ALERTRULE=1

LVL1THRESHOLD=3

LVL2THRESHOLD=4

LVL3THRESHOLD=5

Section alertlevels end

[/important]

 


Section alertxfer

If this section contains a node name, the alert is transfered to that node for processing.  The optional port number is defaulted to port 22 if not given.  The following alert level sections are ignored since they only pertain to local processing.  However, if an alert encounters an error trying to transfer, the alert sections will be executed as the backup.

[important]node_name [port_number][/important]

Multiple node names are allowed – one node per line.

alertxfer’s first attempt will be to use ssh’s scp to transfer the alert to the remote using “ossonar” as the regular user.  (Add user ossonar to each machine and restart OSsonar on each.) (Please setup ssh without a passphrase for ossonar and test:

[important]su ossonar -c “scp -P 22 /tmp/junk ossonar@myhost:/tmp/junk”[/important]

alertxfer’s second attempt will be to use AdminUX’s CAP.  (AdminUX is another product by Mason Gibson).  Port number is ignored if given. The node name must be a Sender.

alertxfer’s third attempt will be to use ssh’s scp to transfer the alert to the remote using “root” as the super user.  (Please setup ssh without a passphrase for root and test:

[important]scp -P 22 /tmp/junk root@myhost:/tmp/junk[/important]

Examples:

 

[important]

Section alertxfer start

node2

node3 22

node4 27356

Section alertxfer end

[/important]

 


Section lvl1alert, lvl2alert and lvl3alert

Variables are:

 

[important]

ALERTCNT

ALERTFILE

ALERTNODE

ALERTTITLE

SENSOR

SGRP

[/important]

 

Description:

[important]All lines between start and stop will be put into a script.  The variable SENSOR will be substitued with the sensor’s name.  The variable ALERTCNT will be substitued with the current alert count.  The variable ALERTTITLE will be substituted with the first line outputted from the sensor.  The variable ALERTFILE will be substituted with the file created by the standard error from the sensor.  The variable ALERTNODE will be substitued with the OSsonar name for this node (/ossonar/bin/lsnode).  The variable SGRP will be substituted with the sensor’s group code.  The script will then be executed to do the alert notifications.  The installation default is to mail the alert to root on the local machine; go quiet for a while; and then start over.[/important]

Linux Example:

Section lvl1alert start

if test “SGRP” = “p”

then

mail -s “ALERTNODE OSsonar Alert – ALERTTITLE” root < ALERTFILE

else

mail -s “ALERTNODE OSsonar Alert – ALERTTITLE” support < ALERTFILE

fi

Section lvl1alert end

Unix Example:

Section lvl1alert start

if test “SGRP” = “p”

then

mailx -s “ALERTNODE OSsonar Alert – ALERTTITLE” root < ALERTFILE

else

mailx -s “ALERTNODE OSsonar Alert – ALERTTITLE” support < ALERTFILE

fi

Section lvl1alert end


Schedule Manager


Section sensors

Comments are not allowed in this section.  Every record must have exactly 10 fields.  Example values are in [ ].  The sensors section is patterned after a simple cron entry.

1st field = a minute (0-59) [30]

a range separated by a dash (no spaces) [0-30]

a sequence separated by a comma (no spaces) [0,30,45]

* for always match [*]

2nd field = an hour of the day (0-23) [21]

a range separated by a dash (no spaces) [0-22]

a sequence separated by a comma (no spaces) [0,8,16]

* for always match [*]

3rd field = a day of the month (1-31) [15]

a range separated by a dash (no spaces) [1-15]

a sequence separated by a comma (no spaces) [1,8,15]

* for always match [*]

4th field = a month of the year (1-12) [5]

a range separated by a dash (no spaces) [1-5]

a sequence separated by a comma (no spaces) [1,8,12]

* for always match [*]

5th field = a day of the week (0-6)(Sunday = 0) [5]

a range separated by a dash (no spaces) [1-5]

a sequence separated by a comma (no spaces) [1,3,6]

* for always match [*]

6th field = enabled/disabled code (on|off) [on]

7th field = run/do-not-run countermeasure code (y|n) [y]

8th field = background/foreground code (b|f) [f]

9th field = sensor name [sec_passwd_gid.sh]

10th field = sensor group code [1]

Example:

 

[important]

Run sec_passwd_gid.sh on the hour Monday through Friday

from 8:00 AM until 5:00 PM.

0  8-17  *  *  1-5  on  y  f  sec_passwd_gid.sh

[/important]

 

If you manually change this section, you will need to restart OSsonar. (/ossonar/bin/OSsonar restart)

Permanent link to this article: https://www.ossonar.com/installuninstallupgrade/configuration/