3.7 SKONI_IDS ARCHITECTURE The architecture of the immune inspired network intrusion detection system is shown in figure 3.

1 below.

NETWORK INTERFACE

PREPROCESSOR ENGINE 2

ANOMALY FILTERED PACKET STREAM ENGINE

NETWORK TRAFFIC

SYSTEM RESPONSE

MEMORY

BLOCKER (IPFW)
ALERT MECHANISM

ADAPTIVE DETECTION

PREPROCESSOR ENGINE 1

MYSQL
INNATE
ENGINE INNATE

ALERT STORAGE LOG STORAGE

Figure 3.1 Architecture of the Computer Immune System (SKONI_IDS)

There are basically five major parts to the (CIS) architecture as shown above: 1. The Preprocessor Engines 2. Innate detection Engine 3. Adaptive Detection Engine (new) 4. System Response (Windows IP Firewall and the Alert Mechanisms) (new) 5. MySQL Database 6. Graphic User Interface (New) The adaptive detection Engine, System response using IP firewall and the alert mechanism and also the 1

graphic user interfaces were the added components to Snort IDS framework. The functions of the different components in SKONI_IDS architecture are as follows: 3.7.1 PRE-PROCESSING ENGINE (PPE1 and PPE2) There are two pre-processing engines in the architecture. Data to be analyzed is processed into a format that is compatible with the analysis engines for each part of the architecture- PPE1 for the innate analysis engine and PPE2 for the adaptive analysis engine. 3.7.2 INNATE DETECTION (Signature Detection) The innate analysis engine is an implementation of misuse detection which is a standard technique used in intrusion detection system. Snort rules were used in the innate analysis engine. The data to be analysed was matched against the rule. Once there is a match, the system provides an alarm response. This technique can provide a high level of detection accuracy and a low level of false positive responses if the rules are tuned correctly. If the system does not provide an alarm response at this point, it could either be that the data analysed is normal, or it could be an attack that does not have a similar or matching rule in the rule base. To determine which situation it is, if no alarm is raised, the data is simply logged into the database. The general form of a Snort rule is given as: <action> <proto> <src_ip> <src_port> <direction> <dst_ip> <dst_port> <options> A Snort rule is composed of two major parts: rule headers and rule options. Within the rule options are a number of subsets of options. Some of these are metadata options, payload detection options, non payload detection options, and post detection options. 3.7.2.1 Snort Rule Headers The rule header contains the information that defines the rule action, protocols, IP addresses, port numbers, and direction operator. This portion of the rule must be structured exactly as it is, and must contain all elements. Without this, the rule will not be valid and Snort will exit upon loading it. Eight rule action options are possible as at Snort 2.9.0. They are log, alert, dynamic, activate, pass They are named snort_alerts and snort29. Snort_alerts is used for storing alerts, while snort29 is used for storing logs. Structure and descriptions of the database tables are included in this report. 3.8 Database Model for the IDS 2

The object oriented approach was used in the design of the database model for the system. Object orientation is a modeling and development methodology based on object oriented (OO) concepts. It uses a set of design and development principle based on conceptually autonomous computer structures know as objects. OO database design allows data models semantics to be captured and represented in the real world more accurately while decreasing development time by reducing the amount of code (Peter and Carloc, 2007). Objects are described by their attributes known as instance variables. The variables in the database are descriptive of the IDS process. The objects and their associated attributes supported in the database are shown below: Table 3.8.1 Acid_event
Field sid cid signature sig_name sig_class_id sig_priority timestamp ip_src Type int(10) int(10) int(10) varchar(255) int(10) int(10) Datetime int(10) Attributes UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED Null No No No Yes Yes Yes No Yes Default Extra

NULL NULL NULL NULL

Table 3.8.2: Acid_ag

Field ag_id ag_name ag_desc ag_ctime ag_ltime Field Type int(10) varchar(40) Text Datetime Datetime Type Attributes UNSIGNED Null No Yes Yes Yes Yes Collation NULL NULL NULL NULL Attributes Null Default Default Extra Auto_incremen t

Table 3.8.3: Acid_ip_cache

Eipc_ip ipc_fqdn ipc_dns_timestamp ipc_whois ipc_whois_timestamp

int(10) varchar(50) Datetime Text Datetime

UNSIGNED latin1_swedish_ci

No Yes Yes Yes Yes

NULL NULL NULL NULL

latin1_swedish_ci

Table 3.8.4: Acid_event

Field sid cid signature sig_name sig_class_id sig_priority timestamp ip_src ip_dst ip_proto layer4_sport layer4_dport Type int(10) int(10) int(10) varchar(255) int(10) int(10) Datetime int(10) int(10) int(11) int(10) int(10) Collation Attributes UNSIGNED UNSIGNED UNSIGNED latin1_swedish_ci UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED Null No No No Yes Yes Yes No Yes Yes Yes Yes Yes Default Extra

NULL NULL NULL NULL NULL NULL NULL NULL

Table 3.8.5: Base_role

F i e l d role_id role_name rol e _d es c T y p e int(11) varchar(20) varchar(75) Attributes N ul l N o N o N o Default E x t r a

Table 3.8.6: Base_users

Field usr_id usr_login usr_pwd usr_name role_id usr_enabled Type int(11) varchar(25) varchar(32) varchar(75) int(11) int(11) Attributes Null No No No No No No

Table 3.8.7: Tcphdr

Field Type Collation Attributes Null Default Extra sid cid tcp_sport tcp_dport tcp_seq tcp_ack tcp_off tcp_res tcp_flags tcp_win tcp_csum tcp_urp Field sid cid udp_sport udp_dport udp_len udp_csum int(10) int(10) smallint(5) smallint(5) int(10) int(10) tinyint(3) tinyint(3) tinyint(3) smallint(5) smallint(5) smallint(5) Type int(10) int(10) smallint(5) smallint(5) smallint(5) smallint(5) Collation UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED Attributes UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED No No No No Yes Yes Yes Yes No Yes Yes Yes Null No No No No Yes Yes

NULL NULL NULL NULL NULL NULL NULL Default Extra

Table 3.8.8: Udphdr

NULL NULL

Table 3.8.9: Icmphdr

Field sid cid icmp_type icmp_code icmp_csum icmp_id icmp_seq Type int(10) int(10) tinyint(3) tinyint(3) smallint(5) smallint(5) smallint(5) Collation Attributes UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED UNSIGNED Null No No No No Yes Yes Yes Default Extra

NULL NULL NULL

Table 3.8.10: Packets

Field dest dest_port mean standard_dev additional number Type varchar(100) int(11) Double Double int(11) int(11) Attributes Null No No Yes Yes Yes Yes NULL NULL NULL NULL Default Extra

Table 3.8.11: Stats

Field time_in_mills source dest protocol source_port D_TYPE dest_port Type bigint(20) varchar(100) varchar(100) char(10) int(11) varchar(100) int(11) Attribut es Null No Yes Yes Yes Yes Yes Yes Default Extra

NULL NULL NULL NULL NULL NULL

3.9 System specification Having examined the various components of the system at the design stage, we develop the functionalities of the system in this section. The class diagram for the system is given in figure 3.4 to figure 3.7 while the sequence diagrams are given in figures 3.8 to 3.10

Figure 3.4

Class diagram for Facades

Figure 3.5

Class diagram for Entities

Figure 3.6

Class diagram for Bos package

Figure 3.7

Main Thread Sequence

Figure 3.8

Detector Thread Sequence

10

Figure 3.9.

PacketReceiver Thread Sequence

Figure 3.10 AlertChecker Thread Sequence

11

5.5 Further Work We have used negative selection approach in this research work as described by Forrest (1999) however other approaches exist like the danger theory and clonal selection algorithms. Further work may therefore be done in this area for developing a more sensitive system using an optimal combination of these approaches. This work may also be extended to developing distributed intrusion detection systems, that is, to study systems that will simultaneously monitor other layers of the OSI model in order to detect other application specific attacks. The system may further be developed for management of multiple sensor deployments using a suitable GUI. It can also be extended for use in forensic analysis, which is a promising area for research too. Although the system can be replicated for use on Linux like systems, it will need different components and configuration since Linux systems do not require editing of the registry while windows based systems requires this feature. A promising area of research for future work would also be to implement the system on cross platform using Java programming language by incorporating Java virtual machine for every OS that requires the system.

12