summarised architecture

7/28/2019 Summarised Architecture

1/12

3.7 SKONI_IDS ARCHITECTURE

The architecture of the immune inspired network intrusion detection system is shown in figure 3.1

below.

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

FILTERED PACKET STREAM

SYSTEM RESPONSE

ADAPTIVEDETECTION

INNATE

MYSQL

PRE-

PROCESSORENGINE 2

MEMORY

ANOMALY

ENGINE

INNATE

ENGINE

PREPROCESSOR

ENGINE 1

BLOCKER(IPFW)

ALERT

STORAGE

LOG

STORAGE

ALERTMECHANISM

NETWORKTRAFFIC

NETWORK

INTERFACE


2/12

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:

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


3/12

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 Type Attributes Null Default Extra

sid int(10) UNSIGNED No

cid int(10) UNSIGNED No

signature int(10) UNSIGNED No

sig_name varchar(255) Yes NULL

sig_class_id int(10) UNSIGNED Yes NULL

sig_priority int(10) UNSIGNED Yes NULL

timestamp Datetime No

ip_src int(10) UNSIGNED Yes NULL

Table 3.8.2: Acid_ag


ag_id int(10) UNSIGNED No Auto_incremen

t

ag_name varchar(40) Yes NULL

ag_desc Text Yes NULL

ag_ctime Datetime Yes NULL

ag_ltime Datetime Yes NULL

Table 3.8.3: Acid_ip_cache

Field Type Collation Attributes Null Default

Eipc_ip int(10) UNSIGNED No

ipc_fqdn varchar(50) latin1_swedish_ci Yes NULL

ipc_dns_timestamp Datetime Yes NULL

ipc_whois Text latin1_swedish_ci Yes NULL

ipc_whois_timestamp Datetime Yes NULL

3


4/12

Table 3.8.4: Acid_event

Field Type Collation Attributes Null Default Extra



signature int(10) UNSIGNED No

sig_name varchar(255) latin1_swedish_ci Yes NULL

sig_class_id int(10) UNSIGNED Yes NULL

sig_priority int(10) UNSIGNED Yes NULL

timestamp Datetime No

ip_src int(10) UNSIGNED Yes NULL

ip_dst int(10) UNSIGNED Yes NULL

ip_proto int(11) Yes NULL

layer4_sport int(10) UNSIGNED Yes NULL

layer4_dport int(10) UNSIGNED Yes NULL

Table 3.8.5: Base_role

F i e l d T y p e Attributes Null Default E x t r a

r o l e _ i d i n t ( 1 1 ) N o

role_name varchar(20) N o

role_desc varchar(75) N o

Table 3.8.6: Base_users

Field Type Attributes Null

usr_id int(11) No

usr_login varchar(25) No

usr_pwd varchar(32) No

usr_name varchar(75) No

role_id int(11) No

usr_enabled int(11) No

4


5/12

Table 3.8.7: Tcphdr

Field Type Collation Attributes Null Default

Extra



tcp_sport smallint(5) UNSIGNED No

tcp_dport smallint(5) UNSIGNED No

tcp_seq int(10) UNSIGNED Yes NULL

tcp_ack int(10) UNSIGNED Yes NULL

tcp_off tinyint(3) UNSIGNED Yes NULL

tcp_res tinyint(3) UNSIGNED Yes NULL

tcp_flags tinyint(3) UNSIGNED No

tcp_win smallint(5) UNSIGNED Yes NULL

tcp_csum smallint(5) UNSIGNED Yes NULL

tcp_urp smallint(5) UNSIGNED Yes NULL

Table 3.8.8: Udphdr




udp_sport smallint(5) UNSIGNED No

udp_dport smallint(5) UNSIGNED No

udp_len smallint(5) UNSIGNED Yes NULL

udp_csum smallint(5) UNSIGNED Yes NULL

Table 3.8.9: Icmphdr




icmp_type tinyint(3) UNSIGNED No

icmp_code tinyint(3) UNSIGNED No

icmp_csum smallint(5) UNSIGNED Yes NULL

icmp_id smallint(5) UNSIGNED Yes NULL

icmp_seq smallint(5) UNSIGNED Yes NULL

Table 3.8.10: Packets


dest varchar(100) No

dest_port int(11) No

mean Double Yes NULL

standard_dev Double Yes NULL

additional int(11) Yes NULL

number int(11) Yes NULL

5


6/12

Table 3.8.11: Stats

Field Type Attribut

es

Null Default Extra

time_in_mills bigint(20) No

source varchar(100) Yes NULL

dest varchar(100) Yes NULL

protocol char(10) Yes NULLsource_port int(11) Yes NULL

D_TYPE varchar(100) Yes NULL

dest_port int(11) Yes 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

6


7/12

Figure 3.4 Class diagram for Facades

7


8/12

Figure 3.5 Class diagram for Entities

8


9/12

Figure 3.6 Class diagram for Bos package

9


10/12


11/12

Figure 3.9. PacketReceiver Thread Sequence

Figure 3.10 AlertChecker Thread Sequence

11


12/12

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

summarised architecture

Documents