Table of Contents




2. Configuration Files

      2.1 Trigger File

      2.2 Example Configuration

      2.3 GUI Configuration

      2.4 Other Configuration Files






2.1 Trigger File

The trigger file is used to define the relationship between detectors and events. A detector is triggered by an event, and that event can be local or remote. For instance, suppose we have a detector for new root processes. This detector needs to be triggered by an event to occur. If we have an event called new process, for instance, we may wish to extract further information out of it (i.e. See if the new process is a new root process). In the trigger file we could then specify that we want a new process event to locally trigger the new root process event detector. There is an example trigger file included. It can be found here. The trigger file's location needs to be remembered as you will need to know the location when you are creating your SMS Agent Configuration (see chapter 3 for more details on SMS Agent Configurations).

In general, the format for the trigger file should be as follows:

DETECTOR:
network.detectors.DetectorName
LOCAL:
network.events.EventName
REMOTE: 
network.events.EventName

Where both the local and remote events are optional.




2.2 Example Configuration

SMS Agent Configuration:

This configuration file is used to specify what the SMS (Secure Management Server) Agent (s) should do. An example can be found here.

The file starts off with a SYSTEM_VALUE. This is used to specify the default handler, timer frequency, syslog file, IPE file, arm args file, pattern file, domain hosts file, monitorusers file, rootlogin hosts file valid users file, and disk usage file. Every agent (except the SMS Agent for now) in the system should be defined in the SMS Agent Configuration. The format for defining an agent is as follows:


AGENT{
  TARGET_HOST = URN:agent_server_urn;
  AGENT_NAME = ~/agents_name;
  dburl = url_of_database;
  dbuser = user_name_for_database;
  dbpasswd = user_password_for_database;
  TRIGGER_TABLE = location_of_triggerfile;
  DETECTOR{      
     detectors; or INCLUDE = file_of_detectors
  }
  SUBSCRIPTION{
     AGENT_NAME = name of subscribee;
     EVENT{
        event_names;
     }
      
     AGENT_NAME = name of subscribee
     INCLUDE = file_of_events  
}

The TARGET_HOST should be set to the agent's URN, this can be found by starting up the agent server and writing down the URN. The agent name is the name of the agent, for each agent there should be a directory in ~/.ajanta/servers/. The dburl, dbuser, and dbpasswd are all set using the mysql server info. The TRIGGER_TABLE variable is set to the absolute directory of the trigger file. DETECTORS defines what detectors should be inside of this agent. The SUBSCRIPTION defines what other agents this agent should subscribe to. The INCLUDE works by including a file. For instance, if you wanted 20 agents that all had the same detectors you could make a file that listed all of the detectors and simply include it in each DETECTOR section. The DETECTOR and the SUBSCRIPTION variable are optional and can be left out.

The network monitoring system requires the use of a default subscriber. There should be an agent in the configuration that has the same form as the following:

DEFAULT_SUBSCRIBER{
  TARGET_HOST = URN:agent_server_urn;
  AGENT_NAME = ~/defaultSubscriber;
  dburl = url_of_database;
  dbuser = user_name_for_database;
  dbpasswd = user_password_for_database;
  DETECTOR{
  }
}

We will work more with the SMS Agent Configuration during some examples in chapters 3 and 6.





2.3 GUI Configuration

~/.ajanta/network/color.conf

This file defines the colors that the GUI will use for each group defined in group.conf . An example can be seen here.

~/.ajanta/network/group.conf

Specifies the filter for the console event viewer by Event name. An example can be seen here.

~/.ajanta/network/smsgui.conf

A convenience file. This is what the default SMSAgentServer url will be in the GUI. An example can be seen here.

~/.ajanta/network/consoleEventConfigs/general.conf or system

This specifies what events should be shown on the console if the user so chooses. General.conf will cause the console to have an event be shown earlier but system is probably a more realistic version of the file. Examples for the console event configuration can be seen here and here.




2.4 Other Configuration Files

dbConfig

An example dbConfig can be seen here. dbConfig specifies two databases: the first is an events database, the second a signature database. The events database stores the events generated by the network monitoring environment. It can be the same database used for storing regular events. The signatures database stores file signatures. File signatures consist of file hashes, permissions, directory location, etc. The dbConfig file will be used in section 6.4. The format of the file is to have the events database first. The first line will be the database url (dburl1 = events_database_url), the second line will be the data base user name (dbuser1 = events_database_user_name), and the third will be the data base password (dbpasswd1 = events_database_password). The signature database is constructed similarly except the variable names follow the format of name2 instead of name1.

demohostlistfile

An example demohostlistfile can be seen here. This file specifies what hosts should have files monitored. Its format is a host-machine dns name, one per line. This specifies what hosts the itinerary agent in section 6.4 will go to.

demofilestomonitor

An example demofilestomonitor can be seen here. The format of the configuration file is to have the same hosts as the demohostlistfile, each host with a prefix of host: . Under the host: host_name a list of directories and/or files can be listed. The files/directories can have three possible prefixes: ! means do not monitor this file/directory, = means monitor this file/directory non-recursively, and no prefix means monitor the directory recursively (if it is a directory). These directories/files will have their signatures collected and placed in the signature database. Immediately following the directory/file name there can be multiple options:

-a : Ignore last access time for the file

-m : Ignore last modification time

-c : Ignore file creation time

-i : Ignore change in the i-node information for the file

-u : Ignore change in the user id of the file owner

-g : Ignore change in the group id of the file owner

-s : Ignore change in the file size

-b : Ignore change in the number of disk blocks allocated to the file

-p : Ignore change in the access permissions for the file

-h : Ignore change in the file contents hash value


These options can be combined, thereby providing a robust way to monitor files/directories.




Table of Contents