7.1.1 Itinerary Agent and Signatures

The network monitoring environment can be configured to collect signatures of files. These signatures are compared to previous signatures and if there is a change the user is made aware of it. To collect the signatures and store them the network monitoring environment uses two agents: a itinerary agent that collects signatures, and a stationary agent that stores/compares these signatures.

The itinerary agent (from now on we will call it the sign collector) uses the demohostlistfile presented in 2.4 and the demofilestomonitor, also presented in 2.4, to create an itinerary. The sign collector travels to each host in the demohostlistfile, gathering sign information for the files/directories given in the demofilestomonitor file. The sign collector generates NewSignatureEvents which trigger the CheckSignatureEventDetector. The CheckSignatureEventDetector is located in the stationary agent (it will be called the file monitor from now on). The CheckSignatureEventDetector generates CheckSignatureEvents which trigger FileChangedEventDetector, FileDeletedEventDetector, and FileAddedEventDetector. The file's signatures are added to the signature database in the dbConfig file presented in section 2.4 by the file monitor. The file monitors event detectors have access to that database and do comparisons to generate the FileChangedEvents, FileAddedEvents, and FileDeletedEvents. These events are placed in the events database.

7.1.2 Itinerary Agent Example

The example configuration can be found here.

To use this configuration the example trigger file presented in section 2.1 needs to be modified.

DETECTOR:
network.detectors.CheckSignatureEventDetector
LOCAL: 
network.events.NewSignatureEvent

Should be changed to:

DETECTOR:
network.detectors.CheckSignatureEventDetector
REMOTE: 
network.events.NewSignatureEvent

This configuration file can be used along with the example configuration files in section 2.4.

The signature collector has new fields. ITIN_AGENT = true specifies that this is an itinerary agent. The PATTERN field is set to LOOP, this means that the agent will go through the list of hosts in a loop. The INTERVAL specifies how long in minutes the agent should wait between loops. The HOST_LIST should be set to the location of the demohostlistfile and the CONFIG_FILE should be set to the demofilestomonitor file. Examples of both of these files can be found in section 2.4. The MigrationEventDetector works similarly to the TimerEventDetector: it generates events periodically that trigger other events. In this case the NewSignatureEventDetector is triggered. The NewSignatureEventDetector is also passed in an argument. This argument consists of the path to the demofilestomonitor file and a boolean 0 or 1. 0 signifies that in the first round the signature collector should only generate signatures for every file while 1 signifies that the agent should assume the signatures have already been generated once.

AGENT{
    AGENT_NAME = ~/signcollector;
    ITIN_AGENT = true;
    PATTERN = LOOP;
    INTERVAL = 1;
    HOST_LIST = /home/ugrad00/jtucker/konark/demohostlistfile;
    CONFIG_FILE = /home/ugrad00/jtucker/konark/demofilestomonitor;
    TRIGGER_TABLE = /home/ugrad00/jtucker/konark/trigger;
    DETECTOR{
    network.detectors.MigrationEventDetector, network.manager.EventHandler;
    network.detectors.NewSignatureEventDetector, network.manager.EventHandler,
    "/home/ugrad00/jtucker/konark/demofilestomonitor 0";
        /* 0 signifies that in the first round the itinerary agent should just collect sigs */
    }
}

The file monitor agent subscribes to the signature collector for NewSignatureEvents. These events trigger the CheckSignatureEventDetector. This detector takes in a string that has a boolean value, similar to that of the signature collector. 0 signifies that signatures should just be added to the signature database and no CheckSignatureEvents should be generated while 1 signifies that CheckSignatureEvents should be generated. The CheckSignatureEvents trigger the FileDeletedEventDetector, FileAddedEventDetector, and the FileChangedEventDetector. Each of these detectors takes in the demofilestomonitor and dbConfig files as arguments. They use the signature database to look up information on the file and generate their events based on if changes have occurred. The events that they generate are added to the events database specified in the dbConfig file.

AGENT{
  TARGET_HOST = URN:ans:plato.cs.umn.edu/jtucker/filemon;
  AGENT_NAME = ~/filemon;
  dburl = jdbc:mysql://archimedes.cs.umn.edu:10000/test;
  dbuser = mobile_agent;
  dbpasswd = user1000;
  TRIGGER_TABLE = /home/ugrad00/jtucker/konark/trigger;
  DETECTOR
  {
        network.detectors.TimerEventDetector, network.manager.EventHandler;
        network.detectors.CheckSignatureEventDetector, network.manager.EventHandler,
        "/home/ugrad00/jtucker/konark/demofilestomonitor /home/ugrad00/jtucker/konark/dbConfig 1";
                /* 0 means add the events to the database */

        network.detectors.FileDeletedEventDetector, network.manager.EventHandler,
        "/home/ugrad00/jtucker/konark/demofilestomonitor /home/ugrad00/jtucker/konark/dbConfig";
        network.detectors.FileAddedEventDetector, network.manager.EventHandler,
        "/home/ugrad00/jtucker/konark/demofilestomonitor /home/ugrad00/jtucker/konark/dbConfig";
        network.detectors.FileChangedEventDetector, network.manager.EventHandler,
        "/home/ugrad00/jtucker/konark/demofilestomonitor /home/ugrad00/jtucker/konark/dbConfig";
  
  }
  
  SUBSCRIPTION{
    AGENT_NAME = ~/signcollector;
    EVENT{
        network.events.NewSignatureEvent, network.manager.EventHandler;
    }
  }
}

There are three other agents in the example configuration. They are similar to previously discussed agents and will not be discussed here again.

To modify this configuration for your own use you should first modify the demofilestomonitor and demohostlistfile. Using that information (what hosts you will be testing this on) you can modify the example configuration presented above to suit your needs.

7.2.1 SnortEventDetector

This detector generates an event for every log entry in the snort alert file. These events provide a flexible way to perform actions on snort rules. A Snort alert file entry looks like the following:

[**] [1:409:4] Snort message [**]

[Classification: Classification (string)] [Priority: Priority (int)]

date(00/00)-time(00:00:00).010928 fromIp(xxx.xxx.xxx.xxx):port_num -> toIp(xxx.xxx.xxx.xxx):port_num

Type(ICMP, UDP, etc.) TTL:TTL(int) TOS:TOS(hex) ID:SnortId(int) IpLen:IpLen(int) DgmLen:DgmLen(int)

The events generated contain all of the relevant information that the entry does. This allows us to use these events very easily. A detector needs only to be triggered by the SnortEvents, then it can filter or log to the database events that are deemed useful. Another possibility is for a detector triggered by SnortEvents to collect statistic information.