Chapter 3. Server Configuration

Table of Contents

Server security
Server vulnerability and server access
Server access: /etc/bigsister/permissions
Data integrity and authenticity
Tunneling Big Sister tcp- connections through Secure Shell
Configure Alarming
Rules
Patterns - "when to do things"
Description - "what to do"
PAGER rules: influencing alarm delivery
Definitions and their meaning
Use and configure SLA/Availability management
Setting it up Availability management
Sending server commands
Using the telnet client
Using the bsadmin tool
Configuring the Server and customizing the Display
The main server configuration file: bb-display.cfg
The options section
The names and group section
The Webpages section
Using imagemaps
Deleting unused and stale network objects
Attaching the Big Sister server to a database
Enabling data logging in a database
Data logging in MySQL database
Data logging without a database server: the file database
Database Structure

Server security

When talking about server security we need to consider two issues:

  • server vulnerability

  • integrity and authenticity of the collected data

Server vulnerability and server access

Agent nodes communicate with the Big Sister server via a TCP based protocol (see sections Sending server commands and Server Command Reference). Whenever an agent needs to send status/group updates it connects to a dedicated port (defaults to 1984), sends one or more commands and then disconnects. The server will never acknowledge client commands, the protocol (currently) is one-way only.

Because of using theTCP/IP preotocol stack for agent - server communication, the Big Sister server has some potential to be exploited by a hacker. Overall the server is considered rather secure since

  • it is written in Perl and therefore does not suffer from buffer overrun problems

  • it uses a simple protocol and therefore validity checking on incoming requests is rather trivial

  • the functionality available through the server protocol is rather limitted

[Warning]Warning

Nobody will guarantee that there is absolutely no way of hacking Big Sister! In order to minimze your risk you should harden you server system (uninstalling any unnecessarry software and fancy stuff including all unsed deamons and network services) and limit the remote access to your server to systems who are running Big Sister agents.

Server access: /etc/bigsister/permissions

The permission file tells bbd which clients are allowed to connect and which operations they may perform. The file is read line by line. Each line contains both a pattern and a list of operations accepted or rejected for the matching clients. If a client matches multiple patterns the associated access lists are treated in a cumulative way and applied in the order they appear in the file.

The format of each line is

pattern => access list

accepted patterns are:

name [hostname]client name matches 'name'

ip [ip] client IP address matches 'ip'

anonymous no user is logged on on this connection

[Note]Note

name [name]patterns are ignored if the DNS option in bb-display.cfg (see above) is switched off. This is the default!

The access list is a list of keywords being associated with an operation or a group of client operations. Each keyword is preceded by either a "+" or a "-" character allowing or rejecting corresponding request. Accepted keywords are:

Table 3.1. Accepted keywords and function

KeywordFunction
allall operations
authenticateclient is permitted to send user authentication
statusclient is authorized to send status messages
page client is authorized to send page commands
groupingclient is permitted to send group join/leave and name commands
archivinglog file archiving operations
alarm_ackingalarm acknowledging operations
perfperformance data transmission
removeremoval of staus records

Empty lines and lines starting with '#' are ignored. Example:

                          
name .* => -all 
# default - reject everything 
#
# hosts in mydomain.com may only send status 
# messages 
name .*\.mydomain\.com => +status 
#
# archiver may only do archiving 
name archiver => -all +archiving 
# 
# localhost may do everything 
name localhost => +all 
#
# unauthenticated clients must never page 
anonymous => -page 
# 
# selected hosts may send grouping information 
name group1 => +grouping 
name group2 => +grouping 

Data integrity and authenticity

Data gathered by network monitoring software like Big Sister does not need to be considered sensitive enough for taking the trouble to ensure full integrity, authenticity and maybe even privacy.

Without any means auf authentication, a nasty user can at least annoy you by generating masses of false alarms, faking wrong system status, injecting wrong history data, etc.

A client is identified in two ways:

  • by the host it is running on

  • ∑ by the user it is authenticating asunimplemented yet

[Warning]Warning

The second identification is not implemented yet - this makes less secure but at the same time things get really easy.

There are only a few ways how to identify a host: Either you identify it by its name or by its IP address. To make rules more powerful you can use wildcards in both cases. For instance

 host 192.168..* => +all

will permit access to every host in the 192.168 network, while

 host .*.microsoft.com => +all

will do the same for every host in the microsoft.com domain.

[Note]Note

Note that the strings are perl regular expressions which are slightly different from any other wildcarded patterns!

To clarify if you are trying to match a name or an IP address it is always a good idea to use ip or name instead of host:

 ip 192.168..* => +all name .*.microsoft.com => +all

Example 3.1.  Example of refusing a status from certain machines

 host .* => +all host 192\.168\.0\.88 => -status host
                        192\.168\.0\.89 => -status

[Note]Note

Actually Big Sister tries to mangle IP addresses, so that

001.002.003.004 works equally well as 1.2.3.4

[Tip]Tip

Using host name to address translation via DNS or some other directory service on a monitoring machine is often a bad idea: The monitoring application should especially work when there are problems around - and there is some risk that these problems prevent name resolution from working. Therefore it is a good idea to avoid names in the permissions file and to set %Option -DNS in the server configuration file.

Tunneling Big Sister tcp- connections through Secure Shell

It is very simple to build a secure (encrypted) tunnel for these status connections using Secure Shell (ssh) and thereby adding at least a basic security level to your environment.

Agent to Server

On the host running the agent start up ssh forwarding, e.g.:

ssh -n displaymachine -L 10192:localhost:1984 sleep 600

(This will forward connections to 10192 to displaymachine port 1984 for 10 minutes)

In uxmon-net use the following server entry:

localhost port=10192 bsdisplay

Server to Server

Use ssh the same way as above. In bb-display.cfg use the Rsync statement like e.g.:

 %Rsync mastermachine:10192 prefix GROUP