Table of Contents
When talking about server security we need to consider two issues:
server vulnerability
integrity and authenticity of the collected data
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 |
---|---|
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. |
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 |
---|---|
|
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 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 |
![]() | 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. |
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.
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