Intrusion Detection Systems
Policy
For this project, the policies and signatures identified are:
Possible Signatures
The initial plan was to use a “suspicious signatures” file to identify combinations of data in the Ethernet traffic file that are associated with known suspicious behaviour. However, the time and resources available for the project did not allow for the development of an adequate heuristics file.
Hence, it was decided to hard code the program to detect a limited number of possibly intrusive activities, and code their signatures in separate function modules. This will allow for expansion of the program by adding further modules to identify other activities as required.
The sample code seeks to identify traffic showing the following signatures:
- Broadcast packets looking for ff: ff: ff: ff: ff: ff where the destination IP;
- Address violations, looking for combinations of IP addresses that are suspicious or invalid on a public network, such as those coming from the range 192.x.x.x;
- Port violations – such as a port with 0 value; or repeated calls to port 80 with same size packet length;
- Specific exploits, such as Code Red and Sub Seven, by coding in their characteristics.
- Potential SYN floods.
- Protos SNMP attacks
- Blind connection reset over ICMP
Some of these identified features may be harmless. However, it was considered that this was no problem for an IDS that analyses a record of traffic (as opposed to a real-time IDS that might stop legitimate activities), as the administrator should be aware of such activities that were legitimate and could ignore them.
There were several other modules which should have been added, but I was unable to complete them. These included
- Search for TTL values below a minimum length (the supplied file did not show TTL values)
- Identify TCP headers that were too short (lack of programming skill to deal with the complexities of reading in detail from the Ethernet traffic file and processing it)
- Most crucially – very good evidence of attempted intrusions are the repeated sending of packages of equal length to different target ports; and the repeated sending of packages without waiting for acknowledgement. As the time and record number fields were omitted in the initial processing of the ethereal output to text (to prevent the file being too unwieldy to use) these procedures could not be carried out. It was decided to add a second program to identify these specific intrusions from a separate subset of the Ethernet traffic file but time did not allow.
The identification of normal traffic patterns was considered to be inappropriate, given that initial test analysis of the data using Etherreal’s own statistics seemed more than capable of identifying traffic patterns, without however, identifying normal usage. There was no way of guaranteeing that any of the traffic was normal, and good evidence from visual inspection that the file included some attempted intrusions.
