THE A-TEAM.
1.1 Executive Summary
Dr. Frincke is researching network security concerns. The Hummingbird project deals with detection and distribution of security relevant information between computers in a network. Information is gathered on each host in the network by various tools and then can be acted upon and distributed to other nodes in the network. The Hummingbird project will provide a tool to accomplish the information distribution tasks.
1.2 References
The following documents were used to develop this document:
"Senior Team Design Project: Hummingbird" Deborah A. Frincke, January 15, 1997.
"Senior Team Design Project: Hummingbird Two Page Description" Deborah A. Frincke, January 21, 1997.
1.3 Deliverables and Timeline
Our team will deliver the following to Dr. Frincke at the completion of this project:
The project notebook
Hummer executables
Tool executables
The project will be completed according to the project schedule. It began on January 13, 1997. The initial walkthrough (prototype 0) was completed on January 26, 1997. A mockup of the GUI interface was passed to Dr. Frincke on February 19, 1997. Prototype 1 will be presented to Dr. Frincke on March 26, 1997. Beta testing will take place starting April 1, 1997 and the completed project will be presented May 7, 1997.
1.4 Project Management
The project will be managed by a rotating group leader. Each member of the group will act as group leader at some point in the project. The group leaders will be: Joe Dowding - Jan 20 - Feb 17
Casey Coltrin - Feb 18 - Mar 17
Troy Holmberg - Mar 18 - Apr 14
Peter Neisen - Apr 15 - May 9
2.1 Product Perspective
This product is to be used by system administrators of networked systems. They will use this product in conjunction with a group of data gathering tools to monitor system activity. After this system has been refined, in is envisioned that it will run on many computer systems and will be used in all types of environments. It could be used in educational, industrial, and military environments with networks of all sizes. The system will eventually be ported to many platforms as well.
2.2 Summary of Features
Separate Hummers will run on each host in the network. The Hummers will be configurable using WWW browsers. The Hummers will take data from data gathering tools which are separate from the Hummer. The Hummer will then act on the messages it receives based on how the user has configured the Hummer. It can log the messages to its own log file, it can pass the messages on to other Hummers running on other hosts or it can alert the user's console to notify them of some danger condition.
2.3 User Characteristics
The users of the Hummingbird system will vary. There will be some who are highly technical and will have exact knowledge of how their networks operate. These users will be able to write and integrate new data gathering tools into the Hummingbird system. At the other end of the spectrum will be fairly novice users who wish to use a more basic set of features of the Hummingbird system. They use default, included, data gathering tools and will have to be able to understand the configuration of small networks.
The Hummingbird system will be flexible enough to be usable by both of these sets of users and those users who fall in between those examples. To accomplish this, the Hummers must be very configurable and that configuration must be easy to accomplish and understand.
More experienced users will use this system and add to it. The source code will be distributed with the system and it is expected that some changes will need to be made in the future. Possible additions will include changes to the interface that allow more visibility of the hierarchy structure, more information on statistics of threat type information and fixing any security problems with the system that we may have overlooked or not implemented.2.4 Constraints, Assumptions, and Dependencies
This project is to be used to report security violations and warnings of security breeches. This requires the communications to the Hummers and between the Hummers to be secure. This system assumes that the local file system and its limitations on file accessibility will remain secure and are not at risk. The system will be required to maintain the security of inter-Hummer communications and will have to validate users when they attempt to change the configuration of a Hummer.
The project is dependent on the external data gathering tools for collection of information. If the tools don't function correctly, the Hummer will not be able to report security violations.
The Hummingbird system has some limitations as far as the security data it can provide. First of all, if there is not a data gathering tool that keeps track of security problems that the administrator is interested in, the system won't report those. As with many security relevant systems, if the person who is attempting to break into the system knows enough about what security measures are in place, they will probably be able to find a way to circumvent them. Keeping the details of what is being logged and monitored a secret will help to keep the system more secure.
3.1 Operational Environment
This product will execute on a networked system. The system will use sockets for transferring information between the data gathering tools and the Hummer and from one Hummer to another. The system will run on systems using the UNIX operating system version 9.0 or higher.
3.2 Development Environment
This product was developed on the University of Idaho, Computer Science Departmental Network. It was developed on Hewlett Packard workstations (model 9000 712/80) running HP-UX version 10.10.
The workstations were connected to a local area network. For more details on this network, contact the department listed above.
3.3 File Environment
This product was developed on the departmental computer system listed above. The system uses HP-UX and a shared file system. The files were stored on a central server and were accessed by the workstations the on which the product was developed.
The executables themselves expect all working files to be in a single directory. Since the data gathering tools communicate with the Hummer server through the program TOOLI, the tool scripts must be able to find that program. Since TOOLI communicates with the Hummer server through network socket connections, it does not need to be in the same directory as the Hummer server.
4.1 Input Definitions
The input to the Hummingbird system is the data being analyzed by the tools. Since the tools will be added to as the system operates, the input data definition is open ended and cannot be placed here.
4.2 Output Definitions
The final output from the Hummingbird system consists of alert messages to user consoles.
4.3 Global Data Definitions
The following list of classes are the data major definitions used within the Hummingbird system.
The following class is the internal class of data for messages passed to and from the Server
class Message
{
public:
char Description [256];
char Date[9];
char Time[7];
char Filename[256];
char HostIP[16];
int MessageAge; // This is used to expire messages caught in a loop.
};
Used in TOOLI, and Server
The following class is the internal class of data for message filters.
class MessageFilter
{
public:
char RegExp[256];
char StartDate[7];
char EndDate[7];
char StartTime[7];
char EndTime[7];
char TrustLevel[2];
HostList *FromHostList;
char Log;
char Alert;
HostList *ForwardHostList;
MessageFilter *Next;
MessageFilter *NewNext;
};
The following data class is used for trust filtering.
class Trust
{
public:
char StartHostIP[16];
char EndHostIP[16];
char TrustLevel;
Trust *Next;
};
4.4 File Structures
There are several files used in the Hummingbird System. The file types shown below are used to save the configuration data. The files are used read and written by Web and Server.
Hummer.log - The hummer's log file. This file is read by alert tools
Manag.info - Contains the hummer's manager's IP address
Message.loc - This file stores the message filters for local use. An example is shown below:
129.101|0|0|0|0|0|0|0|1|0
uidaho|0|0|0|0|0|0|0|1|1|129.101.55.82
regexp|date1|date2|time1|time2|trust|#hostpairs|host1|host2|log|alert|#forwards|ipaddress
Field
|
Use
|
| 1
|
Regular
expression being looked for
|
| 2
|
Date1
|
| 3
|
Date
2
|
| 4
|
Time
1
|
| 5
|
Time
2
|
| 6
|
Trust
|
| 7
|
Number
of host pairs followed by IP addresses
|
| 8
|
Log
locally
|
| 9
|
Alert
Console
|
| 10
|
Number
of forwards
|
| 11
|
IP
address of destination being forwarded to
|
Mesage.locinh - This file is in the same format as message.loc but contains the message filters being sent to subordinates.
subord.info - This file contains the IP addresses of the Hummer's subordinates
time.info - This file contains the number of seconds before the subordinate polls its manager to see if its inherited configuration has changed.
trust.loc - This file contains the trust filters used by this Server. Its format is shown below:
Start IP Address | End IP Address | trust level
If the end IP address is 0, it is not a range and assigns that trust level only to the first IP address.
trust.locinh - This file contains the trust filters propogated to the Hummer's subordinates. It is in the same format as the file above.
The list below shows the functional and performance requirements for the Hummingbird system.
1.0 General Requirements
1.1 Must Run on HP/UX
1.2 Must use <10% of CPU while running
1.3 Needs to be highly portable
1.4 Dates should not fail in year 2000
1.5 Tools must be well documented
1.6 Documentation must be included for any undocumented features
1.7 Embedded constants must be removed from code
2.0 Tool Requirements
2.1 Must run with:
2.1.1 TCP Wrapper
2.1.2 login
2.1.3 bad SU/bad login
2.1.4 http access log
2.2 Must be able to add new tools
2.3 Data collected from tools (amount/type) must be configurable
2.4 Data also collected from other Hummers
2.5 A useful set of example tools to be included with Hummer
3.0 Storage
3.1 Must store data collected from tools and other Hummers in its own files
3.2 What is stored is configurable
3.3 Storage method (complete vs statistics only) will change when files too large
4.0 Sending data
4.1 Hummers must send data to other Hummers
4.1.1 What is sent, how often and who to is configurable
4.2 Must send data in encrypted form
4.2.1 Must be strong encryption
4.3 Errors should be logged by Hummer system
4.4 Hummer system messages should die after being passed through the system some # of times
5.0 Configuration
5.1 Trust levels are configurable
5.2 Managing Hummers can designate who to trust
5.2.1 Local Hummer operator can override managing Hummer
5.3 GUI Interface must be used for configuration
5.4 Security risks that will be announced are configurable
5.5 Configuration changes should be logged by Hummer
5.6 Configuration interface should be secure (password)
5.7 Should be able to force configuration down hierarchy
5.8 Must be able to move and remove subordinates
5.9 Should be allowed to use aliases for manager and subordinates
6.0 Hummer Interface
6.1 Security alerts must be announced audibly and written to screen.
6.2 Should be an interface to view Hummer log file
6.3 Configuration interface should show a map of subordinates and managers, possibly peers
Legend:
Trivial: minimal time and effort
Hard: either time or effort intensive
Difficult: time and effort intensive
Severe: unsure how to implement
6.1 Design Description
The Hummingbird System is divided into several parts. Each of the parts of the program listed below will be executing on every host in the Hummingbird network. Data gathering tools will only be executing when that tool is being used to gather data. They will be invoked by the system administrator. The interface program between the data gathering tools and the Hummer will be invoked by the data gathering tools and will only run when the tools are actually sending messages to the Hummer. The Hummer server will be invoked by the system administrator and will remain running as long as the Hummer is in the Hummingbird network. The configuration server will also remain running as long as the Hummer is active in the Hummingbird network. It is invoked by the system administrator. Another part of the Hummingbird system is the alert tools. These tools are not unlike the data gathering tools. They are invoked by the system administrator and remain running as long as the alert condition they pertain to is wanted to be monitored.
The data gathering tools gather security related data on each host system. These tools as developed to this point are small scripts that read log files and format them to be passed into the Hummers. In general, the data gathering tools will send all messages sent to a log file to the Hummer.
A second executable, TOOLI is a small program that is called by the data gathering tools. Its only job is to pass the plain text messages into the Hummer. It passes the messages to the Hummer through network sockets. TOOLI takes the messages as command line parameters.
A third program is the Hummer server. This program is the one that actually receives messages from TOOLI or other Hummers, and takes action depending on its configurations. It may ignore messages, pass messages on to other Hummers, log the messages in its own log, or alert the console. The actions the Hummer takes will depend on its configuration. When Hummers send messages on to other Hummers, the messages will be in the same format as if they were received from TOOLI on their host computer. The messages will be distinguishable by their host names.
Another component of the Hummingbird system is the configuration server that will allow configuration of the Hummer. It will allow WWW browsers to connect to change configuration parameters of the Hummer. The hypertext pages the configuration server displays will be coded into the server for security reasons. Because the server uses html commands it writes the configuration files and they are kept secure from the remote WWW browser. These files are what the Hummer will read from to make its functional decisions.
The last component of the Hummingbird system are the alert tools. The alert tools are like the data gathering tools but they read from the Hummer log rather than system logs. The alert tools will make decisions (such as counting the number of times an event takes place) and pass an alert message back into the Hummer when they reach an alert condition. The alert conditions are programmed into each alert tool. An example would be three failed login attempts for a user. The Hummer will be configured to alert the console of the machine it is running on when the alert messages are received from the alert tools.
6.2 Design Alternatives
The Hummingbird system was designed as a near real-time monitor of system events. Another alternative would be to look at old log files to determine whether or not security violations had occurred. By designing the system as near real-time, it will be possible for system administrators to stop break-ins as they occur rather than finding out about them when the administrator cannot do anything but try to prevent future attacks.
This system also does not have built in alarm conditions for security break-in conditions. This allows the user to set alarm conditions that can be changed easily without having to change the Hummingbird system.
Along with the Alert tools, the data gathering tools are also not built into the Hummingbird system, this is for the same reason, flexibility without having to change the Hummingbird system.
The data that is stored by the Hummingbird system is in the form of a log file. Each Hummer executing on different hosts has the ability to generate a log file. These log files, just like other log files in Unix systems, have the ability to get large. The user will have to delete or archive the files periodically.
6.3 Data Flow Diagram
Notice that the Hummer writes data to its log file, an alert tool looks at this data and when appropriate can generate another message that gets passed into the Hummer. This cycle is intentional.
6.4 Structure Chart
6.5 User Interface Description
The user interface for the Hummingbird system also consists of several parts. The only user interface that generally exists between the data gathering tools and the user is the command line execution of the tools. Some tools may include a message to the console that they have started running, but that may not even exist.
TOOLI will have no interface with the user. It will only invoked when a data gathering tool executes it.
The Hummer will have display messages to the user console. These messages come from any alerts the user configures the Server to display.
The configuration server will be the main user interface for the Hummingbird system. The configuration server will display html pages to a WWW browser and allow the user to change the configuration of a Hummer. The interface will use standard html buttons and text boxes.
The alert tools, like the data gathering tools will only be interfaced by the user when they are executed. The data they display will depend on how they are written.
See code listing - Modules are described in headers of each.
The Hummingbird system is complex and difficult to test. It is not like a Unix utility that can simply be fed files to read and then if it performs correctly passes that test. The WWW configuration interface must be tested manually. Also since the Hummingbird server is event driving, the tester must force these events to occur to test the server.
Each of the data gathering tools that is included in this system is tested by executing it, forcing an addition to the log file it monitors. If it sends the change to the TOOLI program, it is working correctly.
The Hummingbird server is tested by setting up it configuration files properly and sending messages into the Server manually by executing TOOLI. When the actions the Server performs are the same as how it is configured to perform, it will be operating correctly.
The configuration server is tested manually. A user will execute the configuration server (Web) make changes through the WWW browser they are using (Netscape 2.0 or some other browser that supports CGI commands) and check to see if the changes are reflected in the configuration files.
Integration testing will take place next. The Hummingbird server and tools will be executed. Forcing changes to log files the tools monitor and configuring the Hummingbird server to alert on all data from that tool will show when they are working properly together. Next the configuration server can be executed to see if the changes made using the WWW browser actually make changes that are seen in how the server is running.
The final step of testing will be to execute Hummers on several different hosts configure a hierarchy and make sure that messages are passed and acted upon properly between hosts.
9.1 Encryption
Adding encryption to the hummer's message passing structure should not be very hard. My recommendation is to create a new class that inherits from the existing OutSocket class. In the new class overload the Write and Read functions to contain encryption routines. The Server, ConfigServer, and ConfigClient will need to replace the OutSocket instantiations with this new encrypted socket.
9.2 New TOOLS
Hummer Tools
The hummer tools are simply parsing tools which send information to an interface module. The module is called ToolI. It accepts information in the following format.
ToolI -d $yyyymmdd -t $time -h $ipadr -f $logfile -m \"$msngr\"
-d : The date; includes a 4 digit year representation, 2 digit month
rep, and 2 digit day rep. These numbers are run together with no
whitespace.
-t : The time; includes a 2 digit for the hour, 2 for the minutes, and 2 for seconds these are run together with no whitespace.
-h : This is the ip address of the current host machine. NOTE :Sending the name of the host machine will currently cause and error.
-f : The name of the log file the information was taken from.
-m : The message to be sent to the hummer. In most cases, this is the body of the entry entered into the log file. This message may be parsed at the tool level to include as much or as little information as is desired. The \" ensure that the message is surrounded by quotation marks.
The tools emulate the "tail -f <filename" command. That is to say, it opens the log file, finds the end of the file, removes the end of file marker, then waits for information to be appended to the log file. If it finds new information it will parse the information, format the info., then send it to the ToolI interface. Once it finds no more information at the end of the file, it will sleep for 15 seconds then try again.
The suite of tools currently included in the hummer package were written using Perl version 5.002. The Perl language makes the manipulation of files extremely easy. The tools may of course be written in any language. The only requirement for the tools is that they pass information to the hummer in the above format. Information passed in a nonstandard manner will be lost or corrupted.
The system files being parsed by the tools are the :
access_log - where all of the HTTP access attempts for the system are logged.
mail.log - where all of the information about the routing of email messages is stored.
syslog.log - where all of the switch user, inetd, bootpd, sshd, ftpd, telnetd, and xntpd information is logged.
The alert tools parse the local hummer logs for information. The hummer must be set up to save the corresponding data. Currently the designer of the tool hardwires in the threshhold values, time intervals, and the search strings that the toll will look for. Warnings/Alerts to be sent on to the hummer for display must include "ALERT" at the beginning of the message string to be passed.
example: -m "ALERT there have been 12 bad switch user attempts on deb3467 in the last 10 minutes."
Information from prexisting tools may also be used. Simply direct the output of that tool to a file. Parse and format the information and send it to the hummer.
9.3 Hierarchy Diagram
Adding a heriarchy map to the Web Configuration page should be rather straight forward. The first thing that needs to be done is another radio button should be added to the main humer configuration page. After the radio button has been added, you will have to can add an if check in the ProcessRequest function checking for your new file name. When the check matches the name variable call the function where you are going to write the code for the map.
In the new function call the Headers funciton to set up the HTML headers. To set up the map start by getting the current hummers managers and subordinates, then work you way up and down until you reach the top manager and the last subordinates. By doing this you will have a good idea about the form of the heirarcy. The method for the actual implementation of the map will have to be decided by the code.
The Hummingbird system is complex and difficult to test. It is not like a Unix utility that can simply be fed files to read and then if it performs correctly passes that test. The WWW configuration interface must be tested manually. Also since the Hummingbird server is event driving, the tester must force these events to occur to test the server.
Each of the data gathering tools that is included in this system is tested by executing it, forcing an addition to the log file it monitors. If it sends the change to the TOOLI program, it is working correctly.
The Hummingbird server is tested by setting up it configuration files properly and sending messages into the Server manually by executing TOOLI. When the actions the Server performs are the same as how it is configured to perform, it will be operating correctly.
The configuration server is tested manually. A user will execute the configuration server (Web) make changes through the WWW browser they are using (Netscape 2.0 or some other browser that supports CGI commands) and check to see if the changes are reflected in the configuration files.
Integration testing will take place next. The Hummingbird server and tools will be executed. Forcing changes to log files the tools monitor and configuring the Hummingbird server to alert on all data from that tool will show when they are working properly together. Next the configuration server can be executed to see if the changes made using the WWW browser actually make changes that are seen in how the server is running.
The final step of testing will be to execute Hummers on several different hosts configure a hierarchy and make sure that messages are passed and acted upon properly between hosts.
| Degree of Difficulty | Requirements | Code | Tests |
|---|---|---|---|
| 1.0 General Requirements | |||
| Trivial | 1.1 Must Run on HP/UX | ALL | 1 |
| Hard | 1.2 Must use <10% of CPU while running | ALL | 2 |
| Difficult | 1.3 Needs to be highly portable | ALL | n/a |
| Trivial | 1.4 Dates should not fail in year 2000 | ALL | 3 |
| 2.0 Tool Requirements | |||
| Hard | 2.1 Must run with: | ||
| 2.1.1 TCP Wrapper | MAILTOOL | 4 | |
| 2.1.2 login | SYSTOOL | 5 | |
| 2.1.3 bad SU/bad login ***** Lack of log file limited test this tool | SUTOOL | 6 | |
| 2.1.4 http access log | ACSTOOL | 7 | |
| Difficult | 2.2 Must be able to add new tools | N/A | |
| Difficult | 2.3 Data collected from tools (amount/type) TOOLS must be configurable | n/a | |
| Hard | 2.4 Data also collected from other Hummers | SERVERMAIN.C | 8 |
| Trivial | 2.5 A useful set of example tools to be included with Hummer | TOOLS | n/a |
| 3.0 Storage | |||
| Hard | 3.1 Must store data collected from tools and other Hummers in its own files | SERVERMAIN.C | 9 |
| Hard | 3.2 What is stored is configurable | WEBSERVER.C | n/a |
| Hard | 3.3 Storage method (complete vs statistics only) will change when files too large | UNIMPLEMENTED | |
| 4.0 Sending data | |||
| Hard | 4.1 Hummers must send data to other Hummers | SERVERMAIN.C | 8 |
| 4.1.1 What is sent, how often and who to is configurable | WEBSERVER.C | n/a | |
| Difficult | 4.2 Must send data in encrypted form | NOT IMPLEMENTED | |
| 4.2.1 Must be strong encryption | NOT IMPLEMENTED | ||
| Trivial | 4.3 Errors should be logged by Hummer system | SERVERMAIN.C | 10 |
| Hard | 4.4 Hummer system messages should die after being passed through the system some # of times | SERVERMAIN.C | 11 |
| 5.0 Configuration | |||
| Hard | 5.1 Trust levels are configurable | WEBSERVER.C | 12 |
| Hard | 5.2 Managing Hummers can designate who to trust | WEBSERVER.C | 13 |
| Trivial | 5.2.1 Local Hummer operator can override managing Hummer | WEBSERVER.C | 14 |
| Difficult | 5.3 GUI Interface must be used for configuration | WEBSERVER.C | n/a |
| Hard | 5.4 Security risks that will be announced are configurable | WEBSERVER.C | 15 |
| Trivial | 5.5 Configuration changes should be logged by Hummer | WEBSERVER.C | 16 |
| Hard | 5.6 Configuration interface should be secure (password) | WEBSERVER.C | 17 |
| Hard | 5.7 Should be able to force configuration down hierarchy | CONFIGSERVER.C CONFIGCLIENT.C | 18 |
| Hard | 5.8 Must be able to move and remove subordinates | WEBSERVER.C | 19 |
| Hard | 5.9 Should be allowed to use aliases for manager andsubordinates | WEBSERVER.C | 20 |
| 6.0 Hummer Interface | |||
| Hard | 6.1 Security alerts must be announced audibly and written to screen. | INTERFACE.JAVA | 15 |
| Hard | 6.2 Should be an interface to view Hummer log file | NOT IMPLEMENTED | |
| Hard | 6.3 Configuration interface should show a map of subordinates and managers, possibly peers | NOT IMPLEMENTED |
Test 1:
Test purpose: Test to see if project runs on HP-UX
Test instructions:
1) Run hummer on HP-UX platform.
Test criteria:
Pass: Hummer runs
Fail: Hummer does not run.
Test 2:
Test purpose: See if hummer uses < 10% of CPU
Test instructions:
1) Run hummer.
2) Run UNIX top utility to check CPU useage of hummer processes
Test criteria:
Pass: If all processes together use < 10% CPU
Fail: If all processes together use >= 10 % CPU
Test 3:
Test purpose: Dates should not fail at year 2000
Test instructions:
1) Check to see if all dates are entered in yyyymmdd format.
2) Enter in dates in yyyymmdd format and run hummer.
Test criteria:
Pass: Dates are in format and work fine.
Fail: Dates are not in format or don't work fine.
Test 4:
Test purpose: Make sure hummer gets TCP wrapper messages
Test instructions:
1) Run hummer and configure to alert console of TCP wrapper messages
Test criteria:
Pass: Messages show up.
Fail: Messages don't show up.
Test 5:
Test purpose: Make sure hummer gets login messages
Test instructions:
1) Run hummer and configure to alert console of login messages
Test criteria:
Pass: Messages show up.
Fail: Messages don't show up.
Test 6:
Test purpose: Make sure hummer gets su log messages
Test instructions:
1) Run hummer and configure to alert console of su log messages
Test criteria:
Pass: Messages show up.
Fail: Messages don't show up.
Test 7:
Test purpose: Make sure hummer gets http access log messages
Test instructions:
1) Run hummer and configure to alert console of http access log messages
Test criteria:
Pass: Messages show up.
Fail: Messages don't show up.
Test 8:
Test purpose: Make sure hummer messages from other hummer
Test instructions:
1) Run hummer and configure to send messages to other hummer.
2) Run other hummer.
Test criteria:
Pass: Messages show up.
Fail: Messages don't show up.
Test 9:
Test purpose: Make sure hummer logs messages
Test instructions:
1) Run hummer and configure to log messages
Test criteria:
Pass: Messages show up in log.
Fail: Messages don't show up in log.
Test 10:
Test purpose: Make sure hummer generates error messages
Test instructions:
1) Run hummer and configure to log errors.
2) Configure hummer to forward messages to other hummer.
3) Don't start other hummer.
Test criteria:
Pass: Error messages show up in log.
Fail: Error messages don't show up in log.
Test 11:
Test purpose: Make sure hummer messages have a max number of hops.
Test instructions:
1) Configure 2 hummer is a loop.
Test criteria:
Pass: Messages expire.
Fail: Messages don't expire.
Test 12:
Test purpose: Make sure trust levels are configurable
Test instructions:
1) Configure trust levels
Test criteria:
Pass: You can.
Fail: You can't.
Test 13:
Test purpose: Make sure manager's can designate trust.
Test instructions:
1) Configure a manager to propagate trusts down.
Test criteria:
Pass: You can.
Fail: You can't.
Test 14:
Test purpose: Make sure local operator can override manager.
Test instructions:
1) Have local operator change manager.
Test criteria:
Pass: You can.
Fail: You can't.
Test 15:
Test purpose: Alerts are configurable.
Test instructions:
1) Run a hummer and configure it to send alerts.
Test criteria:
Pass: You can.
Fail: You can't.
Test 16:
Test purpose: Make sure hummer generates messages when configuration changes.
Test instructions:
1) Run an hummer and configure it to log internal messages
2) Change the configuration
Test criteria:
Pass: Messages show up.
Fail: Messages don't show up.
Test 17:
Test purpose: Configuration interface is password protected
Test instructions:
1) Connect to configuration interface
Test criteria:
Pass: You had to enter a password
Fail: You didn't have to enter a password.
Test 18:
Test purpose: Make sure manager can force config down hierarchy.
Test instructions:
1) Force configuration from manager down hierarchy
Test criteria:
Pass: It worked.
Fail: It didn't.
Test 19:
Test purpose: Make sure hummer can remove subordinates.
Test instructions:
1) Remove a subordinate on configuration page.
Test criteria:
Pass: You can.
Fail: You can't.
Test 20:
Test purpose: Make sure aliases can be used on configuration page.
Test instructions:
1) Use "manager" and "subordinate" on config page.
Test criteria:
Pass: It works.
Fail: It doesn't.
Test 21:
Test Purpose: Make sure propagated trusts work properly.
Test instructions:
1) Add a new trust to be propagated to subordinates on config page.
2) Push the new configuration to subordinates.
3) Go to subordinate page and make sure trust was added.
Test criteria:
Pass: Web server does not crash and trust was added.
Fail: Web server crashes or trust is not added.
Test 22:
Test Purpose: Make sure Configuration Push sends kill signal to Server.
Test instructions:
1) Go to a Hummer's config page and add a new message filter.
2) Push the configuration to subordinates
3) Check on subordinate's machine that Server process is running.
4) Check on subordinate's config page that configuration change was made.
Test criteria:
Pass: Server continues to run on subordinate and config changes are made
Fail: Server crashes on subordinate or config changes are not made
Test 23:
Test Purpose: Make sure link to "configure manager" button works on webserver
Test instructions:
1) Set up a Hummer with manager.
2) Press "configure manager button"
Test criteria:
Pass: netscape links to manager's page
Fail: Webserver crashes
*****
Defect Number: 1
Date Found: 2/9
Found By: Pete Neisen
Description: Server generates accept error when connected to.
Environment: RCS 1.3 w/ gcc
Assigned to: Pete Neisen
Date Fixed: 2/10
Solution: The server socket was being shutdown by the child process.
Test Case:
*****
*****
Defect Number: 2
Date Found: 2/10
Found By: Pete Neisen
Description: Server will only accept 56 concurrent connections then dies.
Environment: RCS 1.3 w/ gcc
Assigned to: Pete Neisen
Date Fixed: 2/10
Solution: The parent process wasn't closing the file descriptors so the
program was running out of available ones.
Test Case:
*****
*****
Defect Number: 3
Date Found: 2/11
Found By: Pete Neisen
Description: Socket.C will not compile.
Environment: RCS 1.4 w/gcc
Assigned to: Pete Neisen
Date Fixed: 2/11
Solution: Needed to include netinet/in.h
Test Case:
*****
*****
Defect Number: 4
Date Found: 2/12
Found By: Paul Oman
Description: Items on the interface mock-up unclear.
Environment:
Assigned to: Casey Coltrin
Date Fixed: 2/18
Solution: Cleaned up mock-up, by making field names more descriptive and
adding
pages for each potential use.
Test Case: Customer thought our mock-up was clean and on the correct track.
*****
*****
Defect Number: 5
Date Found: 2/25
Found By: Casey Coltrin
Description: Web Browser printing Content-type:text/html on web page, should
not be there.
Environment: RCS 1.1 w/gcc
Assigned to: Casey Coltrin
Date Fixed: 2/27
Solution: Printed out the entire set of headers necessary for the browser.
Test Case: No more Content-type:text/html on page.
*****
*****
Defect Number: 6
Date Found: 3/2
Found By: Casey Coltrin
Description: WebServer not reporting properly if file is found or not.
Environment: RCS 1.1 w/gcc
Assigned to: Casey Coltrin
Date Fixed: 3/2
Solution: Checked fopen for return of NULL, instead of ferror.
Test Case: Check value of file pointer to make sure that the proper file was
found.
*****
*****
Defect Number: 7
Date Found: 3/4
Found By: Troy Holmberg
Description: program doesn't have access to local sulog chunk
Environment: RCS 1.1 perl5.002
Assigned to: Troy Holmberg
Date Fixed: 3/4
Solution: changed location of file to read to /net/dworshak1/classes
Test Case: accesses sulog.old
**********
Defect Number: 8
Date Found: 3/4
Found By: Troy Holmberg
Description: Tool began at beginning of file instead of end.
Environment: RCS 1.1 perl5.002
Assigned to: Troy Holmberg
Date Fixed: 3/4
Solution: Moved file pointer to bottom then removed the EOF marker.
Test Case: Reads in only new entries.
**********
Defect Number: 9
Date Found: 3/4
Found By: Troy Holmberg
Description: Cant parse "[" with split command
Environment: RCS 1.1 perl5.002
Assigned to: Troy Holmberg
Date Fixed: 3/4
Solution: Take substring of the string containing "["
Test Case: Access log entries do not contain [day.
**********
Defect Number: 10
Date Found: 3/4
Found By: Troy Holmberg
Description: split does not work on /
Environment: RCS 1.1 perl5.002
Assigned to: Troy Holmberg
Date Fixed: 3/4
Solution: changed split command to split '/'
Test Case: Date does not include yymm/dd
*****
*****
Defect Number: 11
Date Found: 3/4
Found By: Casey Coltrin
Description: ToolI dies if there are spaces in the message passed from the
tool
Environment: RCS 1.1 w/gcc
Assigned to: Casey Coltrin
Date Fixed: 3/5
Solution: Problem not actually in ToolI, needed " " around passed string if
it
contains blank spaces.
Test Case: Tool1 no longer dies on strings with spaces.
*****
*****
Defect Number: 12
Date Found: 3/10
Found By: Casey Coltrin
Description: WebServer dies when reloading page.
Environment: RCS 1.1 w/gcc
Assigned to: Casey Coltrin
Date Fixed: 3/11
Solution: Was not assigning memory for a char *, added a call to new.
Test Case: Run the webserver, it won't crash when loading configuration page.
*****
*****
Defect Number: 13
Date Found: 3/11
Found By: Casey Coltrin
Description: Will not read in expressions with spaces.
Environment: RCS 1.1 w/gcc
Assigned to: Casey Coltrin
Date Fixed: 4/23
Solution: converted + character sent by the CGI to a space char
Test Case: add expressions with spaces
*****
*****
Defect Number: 14
Date Found: 3/11
Found By: Casey Coltrin
Description: Servers for trusts and messaging must be input by IP address and
not domain name.
Environment: RCS 1.1 w/gcc
Assigned to: Casey Coltrin
Date Fixed: 5/5
Solution: Added code to look up IP when given name
Test Case: Changes names to IPs
*****
*****
Defect Number: 15
Date Found: 3/12
Found By: Casey Coltrin
Description: Web server dies and core dumps when trust level or subordinates
are selected on the config.html
Environment: RCS 1.1 w/gcc
Assigned to: Casey Coltrin
Date Fixed: 3/24
Solution: Memory management, allocated some memory.
Test Case: No more core dump.
*****
*****
Defect Number: 16
Date Found: 3/12
Found By: Pete Neisen
Description: Socket errors are generated when a message server is killed.
Environment: RCS 1.1 w/gcc
Assigned to: Pete Neisen
Date Fixed: 4/29
Solution: Doesn't connect to server if server down
Test Case: Doesn't generate errors
*****
*****
Defect Number: 17
Date Found: 3/12
Found By: Pete Neisen
Description: Hummer needs to inherit messages from it's manager.
Environment: RCS 1.1 w/gcc
Assigned to: Team A
Date Fixed: 3/25/97
Solution: Wrote code to do this.
Test Case: None
*****
*****
Defect Number: 18
Date Found: 3/24
Found By: Casey Coltrin
Description: Server dies if you try to change trust level for a range of IP's
Environment: RCS 1.1 w/gcc
Assigned to: Casey Coltrin
Date Fixed: 3/25
Solution: More memory management.
Test Case: No more server death.
*****
*****
Defect Number: 19
Date Found: 3/24
Found By: Pete Neisen
Description: If the Server or ConfigServer dies the ConfigClient reports
errors
Environment: RCS 1.1 w/gcc
Assigned to: Pete Neisen
Date Fixed: 4/29
Solution: Doesn't connect to servers if servers not up
Test Case: Doesn't generate errors
*****
*****
Defect Number: 20
Date Found: 3/24
Found By: Troy Holmberg
Description: Alert tool resets at midnight. Could hide an attack.
Environment: RCS 1.1 perl5.002
Assigned to: Troy Holmberg
Date Fixed: N/A
Solution: No planned fix.
Test Case: Hits will reset to 0 for the alert tool when a new day is
detected.
*****
*****
Defect Number: 21
Date Found: 3/24
Found By: Troy Holmberg
Description: Alert tool will overwrite any previous log file for the day if
restarted.
Environment: RCS 1.1 perl5.002
Assigned to: Troy Holmberg
Date Fixed: N/A
Solution: N/A
Test Case: N/A
*****
*****
Defect Number: 22
Date Found: 3/25
Found By: Casey Coltrin
Description: If multiple filters with the same regular expression are used
there will be problems when they are deleted
Environment: RCS 1.1/gcc
Assigned to: Casey Coltrin
Date Fixed: 4/17
Solution: Indexed expressions with numbers
Test Case: Made several same regular expressions then deleted just one.
**********
Defect Number: 23
Date Found: 3/26
Found By: Joe Dowding
Description: You can configure the manager of a hummer as itself
Environment: RCS 2.0/gcc
Assigned to: Casey Coltrin
Date Fixed: No planned fixed
Solution:
Test Case:
********
********
Defect Number: 24
Date Found: 3/26
Found By: Joe Dowding
Description: If you leave the change selected trust level box empty and
hit the configure button, it will remove the current trust
level for the selected hummer.
Environment: RCS 2.0/gcc
Assigned to: Casey Coltrin
Date Fixed: 4/9
Solution: If not trust entered, default to 5
Test Case: Works
********
********
Defect Number: 25
Date Found: 3/26
Found By: Peter Neisen
Description: Message filters to be inherited are also assumed at local
level.
Environment: RCS 2.0/gcc
Assigned to: Peter Neisen
Date Fixed: 3/26
Solution: Changed code so it doesn't assume at local level.
Test Case:
********
********
Defect Number: 26
Date Found: 3/26
Found By: Peter Neisen
Description: Trust level filters to be inherited are also assumed at local
level.
Environment: RCS 2.0/gcc
Assigned to: Peter Neisen
Date Fixed: 3/26
Solution: Changed code so that is doesn't assume at local level.
Test Case:
******
********
Defect Number: 27
Date Found: 3/26
Found By: Peter Neisen
Description: Can't add new trust filters if the file is empty
Environment: RCS 2.0/gcc
Assigned to: Casey Coltrin
Date Fixed: 4/13
Solution: If the trusts file is empty or there is no trusts file the
program will display a "-" in the pulldown box. This fixes the
adding problem.
Test Case: Tested configuration, worked fine.
******
********
Defect Number: 28
Date Found: 3/26
Found By: Peter Neisen
Description: If no subordinates exist, changing manager adds manager to
subordinate list.
Environment: RCS 2.0/gcc
Assigned to: Casey Coltrin
Date Fixed: 3/26
Solution: Changed duplicate variable name.
Test Case:
******
********
Defect Number: 29
Date Found: 3/26
Found By: Peter Neisen
Description: Filters that do not exist in filter file show up on
configuration screen.
Environment: RCS 2.0/gcc
Assigned to: Casey Coltrin
Date Fixed: 4/23
Solution: Fixed Memory problem
Test Case: Doesn't show up anymore
******
********
Defect Number: 30
Date Found: 3/25
Found By: Peter Neisen
Description: Wrong trust reported on incoming messages
Environment: RCS 1.2/gcc
Assigned to: Peter Neisen
Date Fixed: 3/25
Solution: Changed code
Test Case:
******
********
Defect Number: 31
Date Found: 3/25
Found By: Peter Neisen
Description: Filter hosts in message file hang server
Environment: RCS 1.2/gcc
Assigned to: Peter Neisen
Date Fixed: 3/25
Solution: Changed Code
Test Case:
******
********
Defect Number: 32
Date Found: 3/25
Found By: Peter Neisen
Description: Filter hosts compare reversed
Environment: RCS 1.2/gcc
Assigned to: Peter Neisen
Date Fixed: 3/25
Solution: Changed order in code
Test Case:
******
********
Defect Number: 33
Date Found: 3/26
Found By: Casey Coltrin
Description: Interface server creating defunct processes
Environment: RCS 1.2/gcc
Assigned to: Pete Neisen
Date Fixed: 3/26
Solution: Signal need to be trapped
Test Case: Ran, no new defunct processes
******
********
Defect Number: 34
Date Found: 3/26
Found By: Troy Holmberg
Description: Alert tool counting hits wrong
Environment: RCS 1.1 perl5.002
Assigned to: Troy Holmberg
Date Fixed: 3/27
Solution: Moved system call out of while loop
Test Case: While logging hits, the count increases steadily rather than
jumping.
******
********
Defect Number: 35
Date Found: 4/7
Found By: Casey Coltrin
Description: If there is a new line at the accept or forward box the filter
will not be stored correctly in the message.* file
Environment: RCS 1.3 gcc 2.7.2
Assigned to: Casey Coltrin
Date Fixed:
Solution:
Test Case:
******
********
Defect Number: 36
Date Found: 4/8
Found By: Joe Dowding
Description: Webserver Crashes when a bad password is entered, then you go
back and enter the right password.
Environment: RCS 1.3 gcc 2.7.2
Assigned to: Casey Coltrin
Date Fixed: 4/8
Solution: Allocated more memory.
Test Case: No longer dies with improper password.
******
********
Defect Number: 37
Date Found: 4/8
Found By: Joe Dowding
Description: Removing a subordinate doesn't work
Environment: RCS 1.3 gcc 2.7.2
Assigned to: Casey Coltrin
Date Fixed: 4/9
Solution: Change filename to correct discrepancy
Test Case: Now can remove a subordinate
******
********
Defect Number: 38
Date Found: 4/8
Found By: Joe Dowding
Description: Passwords not encrypted for config page login
Environment: RCS 1.3 gcc 2.7.2
Assigned to: Casey Coltrin
Date Fixed: No planned fix
Solution:
Test Case:
******
********
Defect Number: 39
Date Found: 4/13
Found By: Casey Coltrin
Description: Web Server dies if any special characters are used
Environment: RCS 1.11 gcc 2.7.2
Assigned to: Casey Coltrin
Date Fixed: 4/13
Solution: removed a delete from the code
Test Case: Works fine now.
******
********
Defect Number: 40
Date Found: 4/13
Found By: Casey Coltrin
Description: Cannot remove, or modify filters that contain special
characters
Environment: RCS 1.11 gcc 2.7.2
Assigned to: Casey Coltrin
Date Fixed: 4/13
Solution: Added code to convert cgi % characters into actual chars
Test Case: input a filter with a ~, can now modify and remove that filter
******
********
Defect Number: 41
Date Found: 4/11
Found By: Ryan Bradetich
Description: won't make without Java in path
Environment: beta testing
Assigned to: Pete Neisen
Date Fixed: 4/18
Solution: Added absolute path to Java
Test Case: Compiles now
******
********
Defect Number: 42
Date Found: 4/11
Found By: Ryan Bradetich
Description: make clean doesn't remove bin directory
Environment: beta testing
Assigned to: Pete Neisen
Date Fixed:
Solution:
Test Case:
******
********
Defect Number: 43
Date Found: 4/11
Found By: Pete Neisen
Description: Mail tool doesn't report year
Environment: beta testing
Assigned to: Troy Holmberg
Date Fixed: 4/25
Solution: took the date/time from the perl function and inserted the correct
year
Test Case: N/A
******
********
Defect Number: 44
Date Found: 4/9
Found By: Jerry Atkinson
Description: warning generated by make file from Filter.C
Environment: beta testing
Assigned to: Casey Coltrin
Date Fixed: 4/29
Solution: Fixed code
Test Case: No more warning
******
********
Defect Number: 45
Date Found: 4/9
Found By: Jerry Atkinson
Description: socket connect errors generated
Environment: beta testing
Assigned to: Pete Neisen
Date Fixed: 4/11
Solution: Checks to make sure interface is running before opening socket
Test Case: no more socket errors generated by tools
******
********
Defect Number: 46
Date Found: 4/15
Found By: Pete Neisen
Description: Server randomly forks new servers, filling up process table
Environment: beta testing
Assigned to: Pete Neisen
Date Fixed: 4/23
Solution: Removed the fork and had server just process message then accept
new.
Test Case:
******
********
Defect Number: 47
Date Found: 4/10
Found By: Jerry Atkinson
Description: No description about connecting to other sockets with web
browsers
Environment: beta testing
Assigned to: Joe Dowding
Date Fixed: 4/10
Solution: Added the appropriate information to the documentation.
Test Case: Now in docs
******
********
Defect Number: 48
Date Found: 4/11
Found By: Jerry Atkinson
Description: g++ only for compiling
Environment: beta testing
Assigned to: Joe Dowding
Date Fixed: 4/11
Solution: Added information to release notes
Test Case: now in notes
******
********
Defect Number: 49
Date Found: 4/18
Found By: Deb Frincke
Description: core dump if trust modify button is not selected but value is
put in the box.
Environment: beta testin
Assigned to: Casey Coltrin
Date Fixed: 4/22
Solution: set the modify button to default on.
Test Case: can now modify trusts levels with no problem
******
********
Defect Number: 50
Date Found: 4/18
Found By: Andy Hopkins
Description: When view button on interface is pressed error generated
Environment: beta testing
Assigned to: Pete Neisen
Date Fixed: 4/25
Solution: Added logic to prevent error
Test Case: No more error
******
********
Defect Number: 51
Date Found: 4/19
Found By: Abe Haight
Description: Hummer dies if go to general configuraiton page
Environment: beta testing
Assigned to: Casey Coltrin
Date Fixed: 4/23
Solution: Fixed memory problem
Test Case: No more death
******
********
Defect Number: 52
Date Found: 4/22
Found By: Pete Neisen
Description: Possible recursion problem with trapping hummer error messages.
Environment: beta testing
Assigned to: Pete Neisen
Date Fixed:
Solution:
Test Case:
*******
*******
Defect Number: 53
Date Found: 4/23
Found By: Pete Neisen
Description: Java interface does not release memory when a message is
deleted.
Environment: beta testing
Assigned to: Pete Neisen
Date Fixed: 4/25
Solution: Added memory release code
Test Case:
*******
*******
Defect Number: 54
Date Found: 4/24
Found By: Pete Neisen
Description: ToolI produces a Broken pipe error when the server is not up.
Environment: beta testing
Assigned to: Pete Neisen
Date Fixed: 4/25
Solution: Doesn't try to connect if server not up
Test Case: No more error
******
********
Defect Number: 55
Date Found: 5/6
Found By: Troy Holmberg
Description: Changing the inherited message filters causes a core dump.
Environment: beta testing
Assigned to: Casey Coltrin
Date Fixed:
Solution:
Test Case: Modify inherited message filter and check for a core dump in the
./bin directory.
******
********
Defect Number: 56
Date Found: 5/7
Found By: Peter Neisen
Description: Editing trusts that propogate causes Webserver crash
Environment: final demo
Assigned to: Casey Coltrin
Date Fixed: 5/8
Solution: fixed typo in filename
Test Case: 21
******
********
Defect Number: 57
Date Found: 5/7
Found By: Peter Neisen
Description: Configuration push didn't send kill signal to Server
Environment: final demo
Assigned to: Peter Neisen
Date Fixed: 5/8
Solution: fixed typo
Test Case: 22
******
********
Defect Number: 58
Date Found: 5/7
Found By: Peter Neisen
Description: Webserver crashed when trying to link to manager
Environment: final demo
Assigned to: Casey Coltrin
Date Fixed: 5/8
Solution: fixed typo in filename
Test Case: 23
******
The Beta testing for the Hummingbird system will be completed by the
following testers:
Customers Testers:
Dr. Deborah Frincke (customer)
Dean Polla
Bill Danielson
Jim Kruchkow
Greg Vert
Jim Kruchcow
Developers Test Team:
Abe Haight
Ryan Bradetich
Chris Neisen
Andy Hopkins
Other Testers:
Dr. Paul Oman
Gerald Atkinson
These testers will receive a Beta test package from the Hummingbird team. The package will include the source code, a make file, and test documentation. The testers will then compile the source into executable programs and follow the instructions to test the product.
These instructions will be included with Beta test packages:
readme2
From: CS 481 Team A
To: Project Beta Testers
Hummingbird Project
Customer: Dr. Deborah Frincke
08 Apr 97
Beta Test Instructions
** Background:
The Hummingbird system is a network security tool that manages security relevant information. The system works with data gathering tools that collect data about individual hosts in the network. These tools pass data into Hummers running on the same host they run on. The Hummers on the
individual hosts can take a variety of actions with the data they
receive. They can ignore messages from the data gathering tools, send the data on to other Hummers, log the data in their own log file, or send an alert to the console of the machine they are running on. The Hummer can also do perform any combination of the above tasks. The hummingbird system will run on the HP machines in the CS department on which NFS mounts the /usr/local/ directory. This is required because the tools read from log files under the /usr/local/ directory.
** Build and Running Instructions:
This section will be easier to understand if you can look at what is being described.
The g++ compiler is NEEDED to compile Hummingbird
-- Type: make install
This will create a ./bin directory off of the working directory. The makefile will copy the necessary configuration files to the ./bin
directory. There will be one warning on the file Filter.C during the compile process.
-- Change directory to the ./bin directory and type: Interface &
to start the alert interface running in the background.
NOTE: If you are running the Interface on a machine other than your console (ie running on Snake while sitting in front of Selway) you will have to export the display from the remote machine so the window pops up on your own console. To do this type: xhost +
in a window on the machine you are in front of. (ie
dowd9241@selway>xhost + ) and then type: export DISPLAY= and then the name of your console followed by :0.0
(ie dowd9241@snake>export DISPLAY=selway:0.0 )
If at some point the Interface is shut down but the server is still trying to send it information, you will see socket connect errors. Restarting the Interface by reissuing the command: Interface & will restart the Interface and will solve that problem.
-- Next type: startup &
to begin execution of the Hummer, the data gathering tools, and configuration server.
NOTE: If you get socket bind errors, it is probably because you are running on the same machine as someone else testing hummingbird and are both trying to use the same socket. Try running on another machine.
-- When you are ready to stop testing the hummer type: shutdown
this script will kill the tools, the hummer and the configuration server.
You will of course have to run this for each host you started hummers on.
To quit the alert interface, press the quit button on the alert interface
window.
-- Start your favorite web browser and connect to port 15000 on the machine you ran the Hummer on. (ie connect to the URL
http://snake.cs.uidaho.edu:15000 if you had the hummer running on snake)
The password to enter the configuration page is 'test'.
NOTE: If you are running Hummers on more than one machine, (for testing the hierarchy as explained below) you will need to copy the files from the ./bin directory to the new directory. Run each machine's hummer from its own copy of the ./bin directory.
** General Hummer Information:
Hummers are configured with a web browser. You connect to the Hummer and follow the on screen instructions to change how the Hummer will work. The configurable sections include the hierarchy, trust levels, and Hummer configuration options.
The hierarchy of Hummers consists of a Hummer's manager, itself and its subordinates. Each Hummer has zero or one managers and zero to many subordinates. A Hummer's manager forces message filter and trust information down to the local hummer. The local Hummer can force its own
message filter and trust information on its subordinates. What is forced down is configurable.
Trust levels are values assigned to messages coming from other Hummers. The trust levels range from 1 to 5. A value of 1 means most trusted and a value of 5 means least trusted. These values can be assigned to a single
ip' address or a range of ip addresses. The trust values are used by message filters. If an incoming message has a trust equal to or greater than the trust level assigned to the filter, and the other message filter parameters are met, it will act on the message.
Message filters are how you configure what a hummer will do with certain messages. All fields are optional except the regular expression. When the regular expression is matched with an incoming message and the message meets the filter parameters, it will be acted on as you select at the
bottom of the configuration screen. Log Locally will add the message to the Hummer log file. Alerting the console will send a message to the alert interface. Adding an ip address to the text box will send the
message to that ip address.
Managers will propagate their configurations that are to be inherited to their subordinates at the interval configured under general setup.
The Hummer itself acts with no interaction to the console. You will only know that it is working by watching how it affects other Hummers and by watching the alert interface window.
The alert interface window shows alerts on the console it is displayed on. You can double click on a message to see the entire contents. You can remove messages when they are no longer necessary.
The data gathering tools that are included with this Beta package are the HTTP access log tool, the mail log tool, and TCP wrapper tool. These tools will send a message to the Hummer every time a new line is added to their respective log files.
** Testing:
If your Hummer and alert interface have been running while playing with the configuration through a web browser your have probably seen an alert from an access to the HTTP access log. This indicates that the Hummer is acting on the configuration data that was sent with it.
The default message filters included with the Beta package will send messages to the alert interface when World Wide Web hits are made to http://www.cs.uidaho.edu/~connie and
http://www.cs.uidaho.edu/~dowd9241/mustang.html.
Hitting these web pages should cause messages to appear on the alert interface and in the Hummer log file. The file is hummer.log .
To start a test, add a part of a title of a web page as a message filter. Have it alert the console. Hit the page with a web browser and the Hummer alert console should report it.
Now it is up to you. Suggested tests:
1. Add message filters for messages coming from the mail log, the system log and the http access log. These messages also include TCP wrapper messages (telnetd, rlogind, fingerd).
2. Try creating a hierarchy by running Hummers on different hosts.
To set up two hummers with one as a manager and the other as a subordinate follow these steps:
- Create two separate directories and copy in the contents of the ./bin directory into each. This has to be done so the two hummers do not share the same configuration files.
- Start two new xterms and log in to the machines you wish to run the hummers on. On one machine change directory into one of the directories you made. On the other change directory into the other directory you created.
- Start the hummers on both machines by following the instructions listed above.
- Using netscape connect to the configuration web page of the hummer you wish to be the manager (instructions above tell you how to do this).
- Click on the radio button labeled "Add a new Subordinate" and click the button at the bottom of the page labeled "Configure". This will take you to a page where you can type in the subordinate.
- Enter in the hostname of the machine the other hummer is running on and click the "Configure" button. Return to the main configuration page. The hostname you entered will appear in the "My Subordinates" pull down. If it does not, you did something wrong.
- Make sure the "My Subordinates" pull down is selected on the hostname you entered as a subordinate, and select the "Configure Selected Subordinate" radio button. Click the "Configure" button.
- Notice the URL in the "Location:" window on netscape. It should show that you are now connected to the subordinate's configuration web page.
- In a similar fashion as adding a subordinate, you want to configure this hummer to have the first hummer as its manager. If the first hummer's hostname appears next to "My Manager:", then you configured the manager correctly.
- Once this is done, you are ready to create a message filter to pass messages to the manager. Scrolling down the main configuration page of the subordinate, click the button that reads "Modify Local Messaging."
- This will bring up the "Current Expressions Available for Modification" page. Select the expression "mustang.html" from the pull down and select the "Modify Selected Expression" radio button. Click the "Configure" button.
- This will bring up a page showing the message configuration for "mustang.html". Whenever a message comes into the hummer that matches the regular expression "mustang.html", it is sent through the filters.
If it passes, the actions configured are performed. Make the check box next to "Alert this Console" NOT be checked. Then add the manager's IP address to the text box labeled "Forward this Message to:". Now when mustang.html is hit the message will be forwarded to the manager. Since the manager is already configured to report this message to the console, you should see it pop up twice on the manager's alert interface.
- You can now play with the filters and actions for messages to test the functionality of the hummer. Also, remember messages and trusts can be inherited from managers above.
** Known Defects:
- Will not read in expressions with spaces.
- Servers for trusts and messaging must be input by IP address and not domain name.
- Alert tool will overwrite any previous log file for the day if restarted.
- If multiple filters with the same regular expression are used there will be problems when they are deleted
- You can configure the manager of a hummer as itself
- If there is a new line at the accept or forward box the filter will not be stored correctly in the message.* file
- Passwords not encrypted for config page login
** Known Limitations:
There is also some requested usability functionality not in place for the Beta release.
- The socket communications are not encrypted.
- There are no aliases for manager and subordinates under message filter configuration for forwarding.
- The password protection on the configuration page is not secure.
** Reporting Instructions:
For each defect found, include as much information as prudent and be specific about the situation where the defect occurs.
Please report any defects you find. This includes instructions that are not clear, errors that cause the Hummer to stop working, misspelled words on the configuration page and anything else that "just isn't right".
Send reports by email to: cs481a@cs.uidaho.edu.
** Please return all comments no later than April 23, 1997 **
Thank you for your time in testing this product we are looking forward to your input.
Team A
The Hummingbird system is a tool to collect and distribute security relevant information for computer networks. The system is for use by system administrators to aid them in monitoring the security of their networks.
Hummers are programs that will execute and remain executing on each individual host in the network. The system will use multiple data gathering tools that will pass information to Hummers. The Hummers will then act on the information depending on how they are configured.
This product requires that the user have a level of understanding of their computer system and network at the level of a system administrator. The Hummingbird system requires data to be passed into in from a system of data gathering tools. A limited set of tools will be included with the Hummingbird system. Some computer systems and some administrators will wish to monitor information these tools do not. Monitoring additional data will require writing additional tools that work with the Hummers.
The Hummingbird system will be distributed in a shell archive (SHAR) file.
Copy the SHAR file to a directory you have made for the Hummingbird system. Use your system's tool to unshar the file. (Typically SH hummer.shar). This will place the Hummingbird files in your directory. You will NEED G++ to compile Hummingbird. Type make install. This will compile the program. It will create a ./bin directory where the executable files will be located. It will also create ./bin/data where a set of default configuration files will be located. Create a new subdirectory under the ./bin directory with the same name as the machine you are running on (ie ./bin/kootenai/) This directory is where the configuration files will be stored for this host. Copy all of the files from ./data directory to this new directory. If you wish to run the Hummingbird system on another server, create a directory for that server and copy the files from ./data to that directory.
The ./src/ directory will contain the source code files for the Hummingbird system.
The file readme2 also contains instructions for installing and running Hummingbird.
Now the system should be ready to run.
To start the Hummingbird system, first make sure there is a data directory for the host you are running on. See above for more detail.
Next change to the ./bin directory and type Starthum &
This will start the Hummingbird executables and place them in the background.
Next type Interface &
This will open the Java windows used for console alerts.
To configure the hummer use a web browser to connect to port 15000 on the machine you are running the hummer. (ie from netscape connect to
http://snake.cs.uidaho.edu:15000
if you were running on snake. Replace snake with your machine name if you are running on another machine.
This will bring up the configuration interface. The password to enter is initially `test'.
The
To set up two hummers with one as a manager and the other as a subordinate follow these steps:
- Create two separate directories and copy in the contents of the ./bin directory into each. This has to be done so the two hummers do not share the same configuration files.
- Start two new xterms and log in to the machines you wish to run the hummers on. On one machine change directory into one of the directories you made. On the other change directory into the other directory you created.
- Start the hummers on both machines by following the instructions listed above.
- Using netscape connect to the configuration web page of the hummer you wish to be the manager (instructions above tell you how to do this).
- Click on the radio button labeled "Add a new Subordinate" and click the button at the bottom of the page labeled "Configure". This will take you to a page where you can type in the subordinate.
- Enter in the hostname of the machine the other hummer is running on and click the "Configure" button. Return to the main configuration page. The hostname you entered will appear in the "My Subordinates" pull down. If it does not, you did something wrong.
- Make sure the "My Subordinates" pull down is selected on the hostname you entered as a subordinate, and select the "Configure Selected Subordinate" radio button. Click the "Configure" button.
- Notice the URL in the "Location:" window on netscape. It should show that you are now connected to the subordinate's configuration web page.
- In a similar fashion as adding a subordinate, you want to configure this hummer to have the first hummer as its manager. If the first hummer's hostname appears next to "My Manager:", then you configured the manager correctly.
- Once this is done, you are ready to create a message filter to pass messages to the manager. Scrolling down the main configuration page of the subordinate, click the button that reads "Modify Local Messaging."
- This will bring up the "Current Expressions Available for Modification" page. Select the expression "mustang.html" from the pull down and select the "Modify Selected Expression" radio button. Click the "Configure" button.
- This will bring up a page showing the message configuration for "mustang.html". Whenever a message comes into the hummer that matches the regular expression "mustang.html", it is sent through the filters.
If it passes, the actions configured are performed. Make the check box next to "Alert this Console" NOT be checked. Then add the manager's IP address to the text box labeled "Forward this Message to:". Now when mustang.html is hit the message will be forwarded to the manager. Since the manager is already configured to report this message to the console, you should see it pop up twice on the manager's alert interface.
- You can now play with the filters and actions for messages to test the functionality of the hummer. Also, remember messages and trusts can be inherited from managers above.
You may also wish to refer to the Hummingbird Project Software Support Document for more information on this product.
The Hummingbird system has two error messages that you might see. First of all, the Hummingbird system uses a dedicated set of network sockets to send and receive information. If another Hummer is running on the system you are on you will see:
Socket Bind Error. Is there a Hummingbird Web Server running on this machine?
The other errors you might see for the Hummingbird system will be messages sent by the hummer server to itself. Setting up a message filter (there will be one by default) to catch the message "Internal hummer message - " will trap these message and you can have them sent to the alert interface and/or to the log file or even to another hummer. These message describe errors that occurred while the hummer was running.
The Hummingbird system will require some maintenance. Each time you wish to monitor different information, that may require installation and integration of a new data gathering tool. This will require you to enter the Hummer configuration through a WWW browser and make the appropriate additions or changes to the incoming message filters.
Other maintenance to be considered is the Hummer log file. The Hummer log has the ability to become large quickly. You may want to archive the log to off-line storage or possibly just deleting the log if you feel the data is no longer needed.