Keywords: Big Sister, Bigsister, Network Monitor, Network Monitoring, Perl, GPL, Big Brother, manual, SNMP

Chapter 3. Server Configuration
Prev |  | Next

## Chapter 3. Server Configuration

## Server security

When talking about server security we need tonsider 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 serverprotocol is rather limitted

| 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
`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

Keyword | Function
--- | ---
all | all operations
authenticate | client is permitted to send user authentication
status | client is authorized to send status messages
page | client is authorized to send page commands
grouping | client is permitted to send group join/leave and name commands
archiving | log file archiving operations
alarm_acking | alarm acknowledging operations
perf | performance data transmission
remove | removal 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
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 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
Actually Big Sister tries to mangle IP addresses, so that 001.002.003.004 works equally well as 1.2.3.4

### 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

Prev | Up | Next
Using self contained healthcheks: testers | Home | Configure Alarming