View
223
Download
0
Category
Preview:
Citation preview
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
7/28/2019 Summarised Architecture
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
7/28/2019 Summarised Architecture
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
Field Type Attributes Null Default Extra
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
7/28/2019 Summarised Architecture
4/12
Table 3.8.4: Acid_event
Field Type Collation Attributes Null Default Extra
sid int(10) UNSIGNED No
cid int(10) UNSIGNED No
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
7/28/2019 Summarised Architecture
5/12
Table 3.8.7: Tcphdr
Field Type Collation Attributes Null Default
Extra
sid int(10) UNSIGNED No
cid int(10) UNSIGNED No
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
Field Type Collation Attributes Null Default Extra
sid int(10) UNSIGNED No
cid int(10) UNSIGNED No
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
Field Type Collation Attributes Null Default Extra
sid int(10) UNSIGNED No
cid int(10) UNSIGNED No
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
Field Type Attributes Null Default Extra
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
7/28/2019 Summarised Architecture
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/28/2019 Summarised Architecture
7/12
Figure 3.4 Class diagram for Facades
7
7/28/2019 Summarised Architecture
8/12
Figure 3.5 Class diagram for Entities
8
7/28/2019 Summarised Architecture
9/12
Figure 3.6 Class diagram for Bos package
9
7/28/2019 Summarised Architecture
10/12
7/28/2019 Summarised Architecture
11/12
Figure 3.9. PacketReceiver Thread Sequence
Figure 3.10 AlertChecker Thread Sequence
11
7/28/2019 Summarised Architecture
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
Recommended