Original 2

Traffic-aware Design of a High Speed FPGA Network Intrusion Detection System
CHAPTER 1
INTRODUCTION
A NETWORK INTRUSION DETECTION SYSTEM (NIDS) is a system that
analyzes the traffic crossing the network, classifies packets according to header, content, or
pattern matching, and further inspects payload information with respect to content/regular-
expression matching rules for detecting the occurrence of anomalies or attacks. The demand
for network security and protection against network threats and attacks is ever increasing, due
to the widespread diffusion of network connectivity and the higher risks brought about by a
new generation of Internet threats.
NIDS rely on exact string matching of packet payloads to detect hostile packets and
string matching operation of the packets in NIDS is the most computationally expensive step.
Accordingly, NIDS typically apply string matching only to those packets that are most
suspects, and only to those sections of the packet most likely to contain the offending data.
like, Snort (a popular NIDS found at www.snort.org) [4] checks port numbers, packet headers
and flags, etc., to ensure a given packet has a high likelihood of containing hostile data before
performing string matching on the packet data.
Intrusion detection systems (IDS) collect data from the network interface and analyze
it to identify ongoing attacks. This system has provided a way in minimizing network threats
and has given uninterrupted operations, by collecting datagram from the network and
conducting matching operations based on pre defined set of rules.
Various IDS types have been proposed in the past two decades and commercial on
the-shelf (COTS) IDS products have found their way into Security Operations Centers (SOC)
of many large organizations. Nonetheless, the usefulness of single-source IDS has remained
relatively limited due to two main factors: their inability to detect new types of attacks (for
which new detection rules or training data are unavailable) and the often very high rate of
false positives.
Network intrusion detection systems (NIDS) monitor was used to implement the
module generator. Network traffic for predefined suspicious activity or data patterns and
notify system administrators when malicious traffic is detected so that appropriate action may
be taken.
DEPT. OF E&C. ENGG. , SIT, MANGLORE

Page1
Snort NIDS is the software based implementation of NIDS, and it cannot sustain the
multi Gbits/sec traffic rates typical of network backbones, and thus is confined to be used in
relatively small scale (edge) networks [4]. For high speed network links, hardware-based
NIDS solutions appear to be a more realistic choice, but the hardware implementation needs
to permit the frequent update of the supported rule set, so as to cope with the continuous
emergence of new different types of network intrusion threats and attacks.
Field Programmable Gate Arrays are thus appealing candidates. Indeed, a FPGA-
based NIDS can be easily and dynamically reprogrammed when the content-matching rules
change. Moreover, current FPGA devices are capable to provide a very high processing
capability, and support high speed interfaces.
FPGA for 100 Gbits/sec processing are available and for 400 Gbits/sec are
forthcoming [8]. However, such an increase in the traffic collection ability is not matched
with a comparable scaling of the device frequency. Indeed, logic resources still operate with
frequencies in the order of “just” hundreds of MHz; for instance a frequency of 500 MHz,
that is achievable only by last generation FPGA devices, can process 8-bit characters at
“only” 4 Gbits/sec.
It is thus straightforward to consider that, similar to the multi-core parallelization
trend in microprocessors; parallelization in FPGA-based NIDS traffic analysis appears to be a
mandatory approach to sustain the increased network throughput.
1.1 Motivation for the project

Network intrusion detection systems (NIDS) are critical network security tools that
help protect distributed computer installations from malicious users. Traditional software-
based NIDS architectures are becoming strained as network data rates increase and attacks
intensify in volume and complexity. In recent years, researchers have proposed using FPGAs
to perform the computationally-intensive components of a NIDS.
Here it presents the next logical step in NIDS architecture: the integration of network
interface hardware and packet analysis hardware into a single FPGA chip. This integration
allows for better customization of the NIDS as well as a more flexible foundation for network
security operations. To demonstrate the benefits of this technique, Complete and functional
NIDS in a Xilinx Vertex II/Pro FPGA that performs in-line packet filtering on multiple
Gigabit Ethernet links using rules from the Snort attack database is implemented.

Page2
1.2 Objectives
The study had focused on these specific objectives
i. To conduct experimental studies for an uninterrupted traffic due to different types of
network intrusion.
ii. To defend from specific type of malicious threats and to have flexible operation.
iii. To validate the developed models with the simulation result obtained to observe
traffic data.
iv. To implement the design with least resource utilisation and maximum throughput of
frequency.
1.3 Organization of Thesis

The main body of the thesis is preceded by detailed table of contents including lists
of figures, tables, and glossary used in the report which is followed by appendices which
contains the screen shots and explains some of the key technology elements and off the shelf
components used in the project. The body of the thesis contains the Introduction, literature
survey done at the early stages of the project to collect the requirements and product use
cases followed by high level design which focuses on developing the system architecture
followed by detailed design where the system is broken down into modules, testing and
drawing conclusion.
Chapter 1: Gives the introduction to the traffic awareness caused by the network
intrusion.NIDS implementation using FPGA for the network security, against the network
threats and its motivation for the project.
Chapter 2: Gives the literature survey done at the early stages of the project to collect the
requirements and product use cases.
Chapter 3: Gives the approach towards awareness of project, giving the idea about snort rules
and relevant classification policies for the detection of network threats and its hardware
module and relevant trade off.
Chapter 4: Explains the type of network intrusion threats
Chapter 5: It is based on overall system architecture which is the major part of this project by
depicting the system architecture, explaining its main blocks and its working
Chapter 6: Explains about implementation of string matching circuit’s namely basic string
matching engine and discrete finite automata and its scalability issues

Page3
Chapter 7: it is the overall system implementation giving the explanation about snort rule set
subdivision string matching engine synthesis. And its dimensioning.
Chapter 8: Software and hardware Requirement Specification, which explains the overall
description, functional and non-functional requirements of the system and interface
description.
Chapter 9: Implementation and result, which shows the FPGA implementation by giving
brief explanation about FPGA kit which is being used and experimental simulation result
showing the outcome of overall design.
Chapter 10: Gives some of advantages and disadvantages of the proposed design.
Chapter 11: Conclusion, which gives the outcome of the work carried out and also brings out
the future enhancements.

Page4
CHAPTER 2
LITERATURE REVIEW
Securities against malicious threats, which intrude in to the network are detected by
using Network Intrusion Detection System. The relative information is collected and design
is implemented by studying various researches carried out by the various researchers.
2.1 Evolution of Internet Traffic [1]

The Internet is a fast evolving world, or beast, an implicit corollary often stated being
that its robust and sustainable analysis and modeling are impossible and that obtained results
may prove to be outdated before being published. Some of the realities beyond this statement
and propose both methodological tools and objective elements of answers to shed light on
these issues.
2.1.1 Analysis of Internet Traffic

According to the authors P. Borgnat, G. Dewaele, K. Fukuda, P. Abry, K. Cho[1];
Study aims at performing a longitudinal study of the evolution of the traffic collected every
day for seven years on a trans-Pacific backbone link (the MAWI dataset). Long term
characteristics are investigated both at TCP/IP layers (packet and flow attributes) and
application usages. The analysis of this unique dataset provides new insights into changes in
traffic statistics, notably on the persistence of Long Range Dependence, induced by the on-
going increase in link bandwidth. Traffic in the MAWI dataset is subject to bandwidth
changes, to congestions, and to a variety of anomalies. This allows the comparison of their
impacts on the traffic statistics but at the same time significantly impairs long term evolution
characterizations.
To account for this difficulty, It is explained how and why random projection (sketch)
based analysis procedures provide practitioners with an efficient and robust tool to
disentangle actual long term evolutions from time localized events such as anomalies and link
congestions. Central results consist in showing a strong and persistent long range dependence
controlling jointly byte and packet counts. An additional study of a 24-hour trace
complements the long-term results with the analysis of intraday variability.

Page5
First major observation is that packet and protocol characteristics remain stable along
the years; on the application side, the changes of the applications used on the Internet do not
seem to have a major impact on those characteristics. The statistics of aggregated packet or
byte count time series at the TCP/IP layer are then analyzed, with focus on the evolutions
with time of their marginal distributions (MDs) and of long range dependence (LRD).
One key difficulty in performing statistical longitudinal analysis is to disentangle
smooth long term evolution features from day-to-day fluctuations, as there is no single day
without anomalies or specific events. Therefore, First contribution consists of proposing a
robust estimation method based on sketches (random projections), that enables long term
analyses without being affected by specific traffic conditions or anomalies. Applied to the 7-
year long datasets, this robust estimation procedure brings new insights into the on-going
debate related to bandwidth increase and statistical multiplexing causing the disappearance
of long range dependence.
The second contribution lies in finding that, once the impacts of local events such as
anomalies and congestions are filtered out, the traffic statistics remain stable along years with
persistent LRD and MDs being well modeled with Gamma laws. A concern with this
longitudinal study is that data last only 15 min., starting systematically at 2:00 pm. One may
question the representatively w.r.t. both the natural intra-day variability and short duration
observations. To address this, 24-hour traces were analyzed. We report results for data
collected on March 19th 2008.
2.1.2 Longitudinal studies

Traffic analyses often consist of snapshot studies of application behaviors, for
instance, focused on the impact of the latest killer application, likely to cause changes in
traffic statistical characteristics, e.g., web, P2P, video streaming. There have been fewer
studies quantifying the long term evolution of Internet traffic (statistics and applications).
One of them is based on NSFNET traces (1988-1993). At that time, FTP and Mail accounted
for about half of the growing traffic volume, until web traffic becomes majority. More
recently, relations between packet rate, bit rate, and traffic statistics are investigated based on
more than 4000 traces collected from 1998 to 2003. Traffic correlation structures before and
after the web emergence are compared, showing that web traffic affects at least the finest
time scales.

Page6
2.1.3Long Range Dependence

The discovery of LRD in Internet traffic was epoch-making and raised fundamental
issues. Specifically, a characteristic related to LRD is the high variability of traffic
fluctuations, yielding degradations of queuing performance.
However, stability (or even existence) of LRD traffic is an ongoing debate and claims
were made predicting its disappearance on backbone or when loads increase. A number of
authors discussed the fact that LRD in Internet traffic can be induced by higher layer
protocol, as well as related to the heavy tail natures of the distributions of the file size to be
transferred. The (heavy)-tail behaviors of IP flow size have been continuously investigated.
However, the practical validity of the control of LRD of heavy-tail in actual traffic has only
been assessed in recent studies as (heavy) - tail behaviors of IP flow size are an elusive
characteristic to estimate.
2.1.4 MAWI Data set

The MAWI traffic repository archives traffic data collected from the WIDE backbone
networks. The WIDE network (AS2500) is a Japanese academic network connecting
universities and research institutes. The MAWI repository has been providing anonym zed
packet traces since 1999 (total volume of available data exceeds 1TB as of April 2008, cf.
http://mawi.wide.ad.jp/.A specific note here is that the data used here are all publicly
available on the website.
2.2 NETWORK INTRUSION DETECTION SYSTEMS ON

FPGAS WITH ON-CHIP NETWORK INTERFACES [7]
2.2.1 Network Intrusion Detection Systems
A network intrusion detection system (NIDS) is a combination of hardware and
software that monitors a computer network for attempts to violate a security policy. In
addition to simply observing network operations, a NIDS can also be designed to react to
assaults, either by filtering attack packets from the network or by initiating appropriate
countermeasures.
Christopher R, Clark, Craig D, Ulmer, according to the authors [7]; over the years, a
number of NIDS architectures have been discussed in the literature. At a fundamental level,
these architectures are all based on two primary components: a network interface (NI) that
interacts with the physical network and intrusion detection (ID) unit that examines and reacts

Page7
to packets captured by the NI. Early network intrusion detection systems consisted of
application software running on commodity servers equipped with high-speed network-
interface cards. While economical and easy to program, this approach is limited in terms of
performance because
(1) There is a significant amount of I/O overhead associated with data transfers
between the NI and the host CPU, and
(2) General purpose CPUs are not optimized for the large pattern-matching operations
that are commonly used in ID operations. As such, software-based NIDS are often unable to
keep up with the data rates of modern high-speed networks.
2.2.2 Modern Field-Programmable Gate Arrays

Field-programmable gate arrays (FPGAs) are reconfigurable hardware devices that
can be programmed to emulate custom application-specific circuitry. Recent commercial
FPGAs have evolved into more than just simple arrays of reconfigurable logic. These
“platform FPGAs” are essentially system-on-a-chip (SOC) devices that contain complex
components, such as embedded SRAM, digital signal processing blocks, high speed
transceivers, and embedded CPU cores, in addition to large amounts of reconfigurable logic.
The Xilinx Virtex family FPGA is an example of a modern platform FPGA architecture that
includes these new components
2.2.3 An Integrated NIDS in FPGA

The fact that modern FPGAs are capable of interacting directly with a physical
network enables us to propose the next natural step in the evolution of NIDS architecture: the
integration of network interface and intrusion detection circuitry in a single platform FPGA.
It’s been argued that there are multiple advantages to consolidating NIDS components
into a single FPGA. From a physical design perspective, integration simplifies board layout
and reduces the overall chip count for a NIDS. Integration also removes the need for off-chip
data transfers, which can be a performance bottleneck in multi-chip systems. However, the
main benefit for an integrated system is the increased level of customization that is made
available to system designers. FPGAs are flexible architectures that can be reconfigured after
fabrication time to meet new application demands. In order to maximize this opportunity, it is
desirable to place as much of the NIDS architecture as possible in reconfigurable logic.

Page8
There are a variety of means by which an FPGA-based NIDS can be customized. At

the component level, individual units can be tuned to meet the needs of the application. For
example, the NI units in many NIDS applications blindly transfer data into and out of the
network in an unsophisticated manner. This knowledge can be used to simplify the NI
implementation in order to conserve FPGA resources and decrease processing overhead.
Customization can also be applied to higher levels in the system architecture. By
implementing the NIDS inside the FPGA, designers are free to implement a variety of data
flow architectures and processing topologies. If the NI cores were not implemented in the
FPGA, we would have had to fabricate multiple reference boards.
2.2.4 FPGA network interface

The first component of an integrated, FPGA-based NIDS is the network interface
(NI), which is responsible for coherently exchanging packets between the FPGA and the
physical network. Given the nature of the work performed by the NIDS, it is possible to
simplify the functionality of the NI to a minimum. Simplifying the NI reduces the overall size
of the unit, which allows more detection rules to be instantiated in the system. The main
components of this unit are transmit and receive controllers for the Rocket I/O core and
packet FIFOs for in flight messages.
2.2.5 Rocket I/O Controllers

The Rocket I/O module provides low-level services for interactions with physical
network standards such as Gigabit Ethernet (GigE). A Rocket I/O module effectively
provides a raw byte stream interface to the network. Users must insert and extract data in
lockstep with the Rocket I/O in order to prevent data from being corrupted or lost. Because of
the clock-by clock operations that must take place at the interface of a Rocket I/O module, it
is useful to construct wrappers around the hardware to present a more user-friendly interface
to other circuits that need to interact with the network. Transmit and receive engines were
constructed to provide a more usable interface to the network.
The receive engine de-frames and extracts Ethernet packets from the incoming
network stream. Conversely, the transmit engine frames and transmits outgoing messages.
When the transmit engine does not have data to send, it transmits idle channel sequences to
maintain clock synchronicity on the link. The receive and transmit engines strip and generate
CRCs for incoming and outgoing messages, in order to prevent the ID unit from generating

Page9
false positive matches. Additional circuitry monitors the physical layer’s status in the Rocket
I/O module, and automatically resets the unit as needed.
2.2.6 Packet FIFOs

The final component of the NI unit is a pair of packet FIFOs for buffering incoming
and outgoing packets. These units are implemented out of a small number of dual-ported
SRAM banks that are available within the FPGA. While internal SRAM is limited in the V2P
architecture, there is still enough memory available to support 2 KB - 16 KB of messages for
a packet FIFO in the smallest V2P part. The dual-ported nature of the SRAM allows the
producer to operate at a different rate and data width than the consumer.
The packet FIFOs are also designed to allow an optional pass/fail flag to be asserted
after an injection, in order to force the last inserted message to be ignored by the consumer.
This feature is useful in a NIDS, where the ID unit’s assessment of whether a packet should
be dropped can be delayed by a small number of clock cycles. While packet buffering is not
strictly necessary in an FPGA-based NIDS, doing so adds a great deal of design freedom to
the architecture because it decouples the NI units from the ID unit. This decoupling allows
the ID unit to operate at a higher clock rate and with wider data streams. These factors enable
the NIDS to share an ID unit among multiple NI cores.
2.3 Intrusion Detection System

An FPGA intrusion detection (ID) core has been developed that inspects packets on
high-speed networks in real-time. The design compares each packet against a large number of
detection rules simultaneously. Each rule specifies multiple packet properties that together
identify an interesting event. The open-source rule language and rule set from were chosen
because of their availability and quality.
The rule language supports Boolean expressions on the packet header fields, as well
as complex regular expressions on the packet payload. The ID core will detect network
packets that meet all the criteria of any rule. Even with a small FPGA, hundreds of rules can
be programmed into a single chip. The core's input data width is configurable to be two, four,
or eight bytes.

Page10
2.3.1 Header Decoder

The header decoder accepts frames from an Ethernet interface and extracts header
fields from the data-link, network, and transport layers of the protocol stack. The supported
protocols include Ethernet, IP, ARP, ICMP, TCP, and UDP. All of the relevant header fields
are stored in registers and made available to the field analyzer. Also, for each packet, the
decoder determines the end of the transport layer header and produces a signal for the
payload processor indicating that the payload data will begin on the next clock cycle.
However, due to variable header lengths and the configurable input data width of the core,
the start of the payload data does not always occur on an input word boundary.
It is important for the payload processor to analyze every byte of the payload to avoid
missing a potential match. Therefore, the header decoder includes a small buffer of the input
data and outputs a data stream with the payload aligned to the configured input data width.
2.3.2 Header Field Analyzer

The header field analyzer consists of circuits that compare the fields of the incoming
packet with each of the rule specifications. Only the fields with values defined in a rule are
checked; all other fields are ignored. The supported comparison operations on each field
include checking for specific values, ranges of values, and negated values or ranges. In order
to save hardware resources, the circuit generator avoids creating duplicate circuitry for
common comparison operations. For example, if there are multiple rules that trigger on traffic
from web servers, the field analyzer would include only one comparison circuit to detect
packets with a TCP source port of 80. There is a separate match output bit for each rule,
which is true only when the entire field comparisons specified in the rule is true for the
current packet.
2.3.3 Payload Processor

The payload processor searches each packet payload for the occurrence of patterns
specified by the detection rules. The input data is compared against all patterns in parallel at
the rate of two, four, or eight bytes per clock cycle. The supported patterns include simple
text or binary strings, as well as more complex expressions with wildcards. The pattern
location within the payload can be left unspecified, specified relative to the beginning of the
data, or specified relative to another pattern. For 8-bit characters there are 28, or 256, output
wires from the decoder. Only one of these wires will be asserted for each input character—
the wire corresponding to the value of the current character. The match indicator wires are

Page11
distributed to the DFA pipelines created for each pattern. Each stage of the pipeline outputs
true if the output of the previous stage was true and the current stage’s match indicator wire is
true. If there is a character sequence in the input that matches one of the stored patterns, a true
value will propagate through the pipeline and the match output bit will be asserted for the
corresponding pattern.

Page12
CHAPTER 3
TRAFFIC AWARE APPROACH
Traffic-aware approach is proposed as a solution for better ways to parallelize NIDS

architecture, other than the obvious approach of balancing the collected traffic across
multiple (equivalent) hardware modules devised to inspect packets using the same set of
rules. The idea is to first process packets via Dispatcher which i) uses elementary header
information (Protocol, port, etc) to classify traffic flows into different categories, and ii)
accordingly routes packets towards distinct content matching engines (hereafter also referred
as String Matching Engines), namely hardware modules in charge of supporting the subset of
rules devised for the specific category at hand.
Even if the basic idea is very simple, turning it into practice is not nearly
straightforward for several reasons. First, traffic classification rules used by the dispatcher
must be extremely simple, and in any case they must be purely based on header information.
This restricts the type of classification that can be enforced. Second, such classification
approaches yield categories of uneven size in terms of traffic volume, so that dimensioning of
the content matching modules cannot be anymore based on the nominal link speed, but must
rely on the actual per-category traffic load. Third, and most important, the type of
classification enforced should attempt to group traffic so that the actual NIDS rules to be
enforced in the dedicated hardware modules are as most disjoint as possible, thus minimizing
the usage of logic resources. The application of the traffic-aware approach to the hardware
domain therefore requires a detailed analysis of aspect that is not covered by previous works.
3.1 Snort rules analysis and relevant classification policies

SNORT is an open source network intrusion prevention system capable of performing
real-time traffic analysis and packet logging on IP networks. Snort can perform protocol
analysis, content searching/matching and can be used to detect a variety of attacks and
probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS
fingerprinting attempts, and much more. Snort is comprised of two major components: (i) a
detection engine that utilizes a modular plug-in architecture (the “Snort Engine”) and (ii) a
flexible rule language to describe traffic to be collected (the “Snort Rules”).

Page13
It’s important to note that the Snort Engine and Snort Rules are distributed separately, but
should be used together.
In order to organize set of rules into disjoint subsets, it should be identified by

suitable combinations of packet header fields, the rule subset in charge of detecting possible
exploits against http servers (protocol=TCP, destination port = 80) obviously differs from the
set of rules to be employed by another protocol such as FTP or SMTP; but, perhaps less
obviously, also differs from the subset dedicated to analyze threats still for the http protocol,
but against web clients (protocol=TCP, source port = 80). Such an analysis yields the
classification policies exploited in the dispatching of traffic towards the hardware modules,
each supporting one or more subsets.
The software implementation of Snort rules are grouped by port/protocol and, for
each packet, only the group of rules corresponding to the port/protocol of the packet is
checked. This rule partitioning help to reduce memory consumption and CPU usage of Snort.
Differently from the software implementation,
3.2 Real world traffic analysis for HW module sizing

Real world traffic is analyzed offline, provided by an Internet Service Provider, to
quantitatively assess how traffic splits according to the envisioned classification policies,
determine the expected worst case per-class throughput, and thus set forth the relevant input
rate requirements for dimensioning each content matching HW module. In essence, for an
HW-based development, a methodology similar to the one proposed in, where an adaptive
algorithm depending on the traffic mix is used to optimize a software-based IDS. The goal of
such an analysis is not to provide a once-for-all system dimensioning, but, rather, to suggest a
methodological approach. Indeed, variations in the traffic mix do occur during the operating
lifetime of the NIDS, and may also depend on the specific operator’s deployment. This does
not appear to be a practical concern, as in any case the synthesis of the content matching
engine must be rerun at every rule set update (order of once per week) whereas variations in
the traffic mix are shown to be much slower, in the order of several weeks. And when
significant variations in the traffic mix are detected, the resulting system re-design can be
conveniently accounted for, while performing the synthesis associated to the periodic rule
update.

Page14
3.3 HW module implementation and relevant trade-offs

Several constrained syntheses (with respect to speed and area) of the different string
matching engines are performed, to gather insights in the emerging area/speed trade-offs for
the specific NIDS rule set synthesis scenario. It’s been seen that if multiple copies of the
same string matching engine are used to achieve a higher throughput, the choice between area
or speed optimization of the engine is not unique, but strictly depends on the circuits to be
implemented and, in some cases, the emerging area-delay trade-offs are quite unexpected.
The use of multiple copies of low speed string matching engines allows making an
optimization between the area of the single engine, its maximum operating frequency and the
overall throughput.
3.4 Connecting an IDS Device

There are multiple methods one can use to connect IDS to capture and monitor traffic.
In any case, the IDS need to gather network traffic to be analyzed. Three methods and the
benefits of each are briefly discussed here as depicted in Fig 3.1
Figure 3.1: IDS on the edge of a network or zone.

Each part in this illustration consists of two servers, a workstation and an IDS all
connected to a piece of network equipment attached to an uplink. The servers and
workstation are considered internal assets and the uplink leads to an external network. The
red lines represent connections being utilized to monitor traffic, while the black dashed line
represents a connection that may be used to manage the IDS Network IDS remotely from a
system in the internal network.

Page15
CHAPTER 4
NETWORK INTRUSION ATTACKS

4.1. DOS
A Denial of Service (DoS) attack is a type of attack focused on disrupting availability. Such
an attack can take many shapes, ranging from an attack on the physical IT environment to the
overloading of network connection capacity, or through exploiting applications weaknesses.
A DoS attack involves, using one computer or internet connection to flood a server with
packets (TCP/UDP). The objective of this attack is to overload the servers’ bandwidth, and
other resources, so that anyone who may be trying to get access to the server is not served,
hence the term denial of service. Software Vulnerability: Attacks attempt to exploit a
software program design aw (i.e., Land attack, Ping of Death, and Fragmentation).
Some of the common attacks are discussed below:
4.1.1 SYN Flood Attack

A SYN flood occurs when a host sends a flood of TCP/SYN packets, often with a
fake sender address. Each of these packets is handled like a connection request, causing the
server to spawn a half-open connection, by sending back a TCP/SYN-ACK packet
(Acknowledge) and waiting for a packet in response from the sender address (response to the
ACK Packet). However, because the sender address is fake and the responses never come.
These half-open connections saturate the number of available connections that the server is
able to make keeping it from responding to legitimate requests until after the attack ends
.
4.1.2 Smurf Attack
A Smurf attack is one particular variant of a flooding DoS attack on the public
Internet. It relies on erratically configured network devices that allow packets to be sent to all
computer hosts on a particular network via the broadcast address of the network, rather than a
specific machine. The network then serves as a Smurf amplifier. In such an attack, the
perpetrators will send large numbers of IP packets with the source address faked to appear to
be the address of the victim. The network’s bandwidth is quickly used up, preventing
legitimate packets from getting through to their destination.

Page16
4.1.3 ICMP Flood

Like the other flooding attacks, this one is accomplished by broadcasting a bunch of
ICMP packets, usually the ping packets. The idea is to send large amount of data to the
system, so that it slows down so much and gets disconnected due to timeouts. Particularly,
Ping flood attacks attempt to saturate a network by sending a continuous series of ICMP echo
requests over a high-bandwidth connection to a target host on a lower bandwidth connection.
The receiver must send back an ICMP echo reply for each request.
4.1.4 Ping of Death

A ping of death involves sending a malformed or otherwise malicious ping to a
computer. A ping is normally 32 bytes in size. Ping of death attack is caused by an attacker
deliberately sending an IP packet larger than the 65,536 bytes allowed by the IP protocol.
Many operating systems don’t know what to do when they receive an oversized packet, so
they freeze, crash or reboot. Ping of death attacks were particularly nasty because the identity
of the attacker sending the oversized packet could be easily spoofed and because the attacker
didn’t need to know anything about the machine they were attacking except for its IP address.
4.1.5 Teardrop
The Teardrop, though, is an old attack that relies on poor TCP/IP implementation
that is still around. It works by interfering with how stacks reassemble IP packet fragments.
The trick here is that as IP packets are sometimes broken up into smaller chunks, each
fragment still has the original IP packet’s header, and field that tell the TCP/IP stack what
bytes it contains. When it works right, this information is used to put the packet back together
again. What happens with Teardrop though is that your stack is buried with IP fragments that
have overlapping fields. When the stack tries to reassemble them, it cannot do it, and if it
does not know to toss these trash packet fragments out, it can quickly fail. Most systems
know how to deal with Teardrops and a firewall can block Teardrop packets in return for a bit
more latency on network connections since this makes it disregard all broken packets. Of
course, if you throw a ton of Teardrop busted packets at a system, it can still crash.

Page17
CHAPTER -5
OVERALL SYSTEM ARCHITECTURE

System comprises multiple string matching modules. These are further organized into
clusters, suitably sized so as to sustain the expected per-cluster traffic load. Packets are
balanced across clusters on the basis of policies implemented in a block called dispatcher.
Two type of string matching engine (SME) are used as follows-1) Basic string matching
engine and another is 2) Deterministic finite automata (DFA). It is explained in detail in
chapter 6. The overall system architecture is shown in Fig 5.1.
Figure 5.1: Overall system architecture
5.1Main blocks of the system

 Network interface - it collects packets from the network link under monitoring which
is Xin;
 Dispatcher - it provides a header-based packet classification, whose result is used to
determine to which specific string matching cluster the packet is transmitted;
 String matching engines - blocks performing string matching; their design is identical
but the content searching rules synthesized in string matching engines belonging to
different clusters differ and specifically depend on the type of traffic routed to the

Page18
considered cluster; A generic string matching system is composed of n cluster, each

one clocked at a specific frequency fi and composed of Ki identical SMEs.
 Queue manager - this block provides a queue for each SME cluster. The queue
provides the buffering of packets to cope with packet bursts. The queues can be
realized by using external memories to provide enough space. The memory can be
partitioned as a set of circular buffers, each one controlled by two pointers. A control
FSM, realizing a round-robin policy allows using the memory as a set of independent
queues. Since the SME cluster may be clocked with a different frequency, with
respect to each other and to the queue manager, asynchronous FIFOs for clock
decoupling are deployed between the queue and the SMEs.
Since, multi-byte string matching engines do complicate the internal design, the
Queue output uses 8 bits. Conversely, the interfaces between the remaining modules can be
implemented using multiple characters at a time. For example, if the network interface is the
10 Gigabit Ethernet core of Xilinx, that provides a 64 bits interface working at-
 f0=156.25 MHz, the data width will be 64 (N=64 bits), and the operating frequency
of the dispatcher will be f0 [8]. In proposed architecture instead of queue manager
FIFO is used.
The resulting operation in fact depends on a configuration setting which includes the
following decisions and parameters:
• Dispatcher classification policy;
• String matching rules loaded over each cluster of engines;
• Operating frequency of each cluster;
• Number of string matching engines deployed in every cluster.
5.2 Working
Input to the overall system is fed from the network interface in the form of packets.
There will be standard I/O controllers which provide a raw byte stream interface to the
network. These packets are received by the receiver which de-frames and extracts Ethernet
packets from the incoming network stream and are stored in ROM. Packet classification is
done based on Header format as shown in fig 5.2, Homogeneous packets are grouped and
sent to the respective string matching engines.

Page19
5.3 Packet classification flow chart

As shown in the flowchart in fig 5.2. Once the tools are defined and set to high,
packet classification process starts after 63 byte count up to 76 packets based on Ethernet
header and IP header format
Figure 5.2: Packet classification flow chart

Page20
The Packet classification process is structured into a three phases as follows
 Phase-I: The first phase is defining tools. Here values are assigned to the respective
tools
 Phase-II: The second phase is Header based packet classification. Here based on Ether
and IP header format packets are classified.
 Phase-III: The third phase is output. Here packets are transmitted to the respective
string matching’s based on pre-classified packet classification policy.
4.4 OSI layer and functions

The OSI Layer is used because, it divides the network communication process into
smaller and simpler components.OSI provides way for how PC does communicate to the
network.
Communication to the application system from the external network is carried out in
OSI (open system interconnection) format.OSI was created by the ISO (international
organization for standardization).OSI layer and function is shown in fig 5.3.
Figure 5.3: OSI layer and functions

It is also called as seven layer communication. In this upper layer, which is the front
end has Application, Presentation, and Session layer. These layers are not much concerned
because it is just needed to receive data stream.

Page21
Next is the Transport layer and network layer and this is where host to host
communication appear. Transport layer gives end to end communication. Here type of
communication is decided based on two type of connection i.e.
1. Connectionless
E.g. UDP
2. Connection oriented
E.g. TCP/IP
TCP is reliable and is guaranteed where acknowledgement is received. UDP is not reliable,
uses less resource and acknowledgement is not received. The application developer decides
whether to use UDP or TCP. In TCP we need to have larger header compared to UDP i.e.
more resource needed. Two pieces of information segments- destination IP address and
datagram packets Transport layer has and are sent to the Network layer. In Network layer
routing of packet takes place. This will route the packet to the destination.
The bottom layer is concerned with local and physical network. In Data link layer the
packets of data are fragmented in to frames and are linked to the destination. Finally it is sent
to the Physical layer where the data are read. Physical layer is application system.

Page22
CHAPTER - 6
IMPLEMENTATION OF STRING MATCHING

CIRCUITS
The overall system architecture considered in Fig 5.1 has a block called “cluster”,
where string matching operation of packets are carried out. In cluster two types of string
matching engines are being used namely “Basic string matching engine” and “Discrete finite
automata” which are explained in this chapter
6.1 Basic architecture and related extensions

The relevant design depicted in Fig 6.1 of cluster follows the shift-and-compare
architecture. The main input of the circuit is an 8 bit signal that transports the payload under
inspection one character each clock cycle. The only output of the circuit is the “Match”
signal, set to high only if a string is matched. The input is fed into an 8 bits register chain
storing the last M packet’s characters. The outputs of the register chain are provided as input
to a combinatorial network. This latter detects which characters are stored, and performs the
AND operation of the detected characters. This signal indicates that a rule has been matched
without specifying which rule.
Figure 6.1: Basic implementation of the string matching circuit
Fig. 6.1 further illustrates a toy example which consists in the search for two strings: “abc” or
“def”. If the character d is stored in the register labeled x(n−3), e is stored in x(n − 2) and f is

Page23
stored in x(n − 1), all the inputs of the uppermost AND gate are equal to 1 and the circuits
signal the matching by the “Match” output.
If the system is deployed as a snort off loader, devised to forward the malicious
packets to a software IDS implementation, a matching signal is all needed to drive simple
pass/drop packet logic. Indeed, note that the deployment of a full-fledged hardware IDS
requires supplementary features (e.g. alert generation, packet logging and so on), that can be
better performed in software. Besides, if the goal is to further detect which rule has been
matched, a quite straightforward implementation consists in substituting the OR gate with a
priority encoding circuit that takes as input the output of each AND gate and provides as
output the binary representation of the highest input with high Modifier Description offset: N
the search for the content begin after N characters depth: N the search for the content ends
after N characters distance: N the distance between to contents is at least N characters within:
N the distance between to contents is less than N characters value. A rough estimation of the
resource occupation of the encoder is around 15K LUTs3.
Table 6.1 summarizes the most used modifiers.
Table 6.1: Modifier description
A string matching circuit can be implemented using character comparators (realized

with a combinatorial network) and shift registers storing the most recent characters. For
example, a decoded structure, which allows sharing of the comparators in the combinatorial
network? While increasing the number of registers, this structure permits to minimize the
combinatorial network, if the number of string to be search is large enough. Starting from the
basic string matching circuit (Fig 6.1), it is extended with counters and comparators to
support the more specific and complex rules specified by Snort. Specifically, and deployed a
global counter and a number of dedicated registers tracking partial matches. This extension
allows an easy hardware implementation of the typical Snort rules, which usually are
expressed in the form of content + modifiers.

Page24
• Content: fixed pattern to be searched in the packets payload of a flow. If the pattern is
contained anywhere within the packets payload, the test is successful and the other rule
options tests are performed. A content keyword pattern may be composed of a mix of text
and binary data. Most of the rules have multiple contents.
• Modifiers: they identify a location in which content is searched inside the payload. This
location can be absolute (defined with respect to the start of the flow) or relative to the
matching of a previous content.
6.2 Implementation of a rule composed of two contents

Fig. 6.2 shows an example of a rule matched exploiting the extended content
matching approach. The rule to be matched is composed of two contents “ab” and “cde” that
must be at a distance less than 10 bytes. The first part of this rule, i.e. the match of the content
“ab” is performed by the two inputs AND gate. When the content is matched, the value of the
global counter is stored in a register. Now, when the second content is matched, the system
also checks if the difference between the global counter and the value stored in the register is
less than ten bytes. This extension is resource consuming because a register and a comparator
must be instantiated for each part in which the rule is decomposed. The resource occupation
of this block depends on the number of rules implemented.
Figure 6.2: Implementation of a rule composed of two contents: a) first content

Matching b) second content matching and distance check

Page25
6.3 DFA implementation of the string matching circuit

An alternative implementation of a string matching engine is to rely on a Deterministic
Finite Automata (DFA), based structure, like the one presented in Fig. 6.3. This structure
shares, with the previous one, the use of a character comparator, followed by some AND
gates. The difference is that here, registers (and therefore the state) do not store the last
transmitted characters, or the result of their decoding, but an intermediate result that tracks
the partial matching of the transmitted characters. In particular, in the example in Fig. 6.3 the
flip-flop labeled F1 stores the matching of a, while F2 stores the matching of “ab”. Note that
the number of register elements grows with the number of strings to be searched for, and with
the number of characters of each string.
Figure 6.3: DFA implementation of the string matching circuit
6.4 Scalability issues

Realistic applications employ several thousand content matching rules (e.g. the Snort
basic rule set includes more than 5700 rules), and strings to be matched can be as long as one
hundred characters. In such practical deployment conditions, the combinatorial network can
become huge, and the number of registers grows linearly with the number of character of the
longest string. The parallel search for different strings corresponds to an increase in the fan-
out of the registers and of the character comparators. Also, the fan-in of the AND gates
increases with the strings size. The other implementation issue that must be faced when the
number of overall character grows is the timing closure problem. This problem is amplified
by the high fan-out and fan-in nodes in the circuit. These fan-out nodes are related both to the
architecture of the circuit and to the logic optimization performed to increase the resource
sharing in the combinatorial network. As expected, timing closure and area occupation are
conflicting issues which require a huge design effort to be solved. The techniques to face

Page26
these problems are widely known, and span from limiting the fan-out and replicate the logic,
to increasing the pipeline and performing speed retiming. In all these cases, when the
requested throughput increases to the Gbits/sec rate, these approaches become unfeasible.
Therefore a scalability issue becomes very important for multi-Gbps networks.
A solution proposed at architectural level consists in using a wide data bus that operates on
multiple characters each clock cycle. With this approach, the data processing rate can be
improved without increasing the operating frequency. For example, an 1-character string
matching circuit operating at 125 MHz provides a throughput of 1Gbit/sec, while a 4-
character based circuit is able to sustain a rate of 4 Gbits/sec. The area required for
implementing a multi character circuit increases at least linearly with the number of
characters. This approach has several drawbacks that limit the usability of such method. First
of all it is not easily scalable since the modification of the number of characters that a content
matching engine checks in a clock cycle requires the complete redesign of the content
matching engine itself. Moreover, the extension of this method to regular expression can be
difficult. Basically the problems related to a multi character approach derive from the nature
of the NIDS rules (and from the nature of the data that are inspected) that are strongly
character dependent. Since the rules often are based on matching strings, counting the
number of characters and so on, it is not trivial to extend these analyses to a multi-character
implementation. Finally, the effort of the logic optimization algorithms for these architectures
is greater than one of single character architecture and also the quality of results in such case
is in doubt. Similar considerations about the limitation of the multi-character approach have
been presented. Moreover it shows that, when number of characters becomes greater than 4,
the performances of this approach, computed as throughput/area (Gbps/#LUTs), decreases.
The approach proposed in what follows alleviate these issues, since the area/speed
optimization constraints are applied to smaller hardware blocks running at lower frequency.

Page27
CHAPTER - 7
OVERALL SYSTEM IMPLEMENTATION
Over all system implementation mainly deals with the performance gains that can be
achieved by dispatching different traffic types to different clusters, consistently distributing
different content matching rules over different engines, independently optimize the area-
frequency tradeoff for each deployed engine, and dimensioning each engine depending on the
traffic-load conditions.
7.1 Design steps

Practical three-steps design are taken, organized as follows-
Step 1: Ruleset distribution and relevant packet dispatching policy.
The first, necessarily heuristic, step is to distribute different content matching rules
across multiple engines. Such distribution is driven by two practical requirements:
i. Permit an elementary dispatching policy, based on simple protocol header
information, meanwhile
ii. Attempt to obtain (as much as possible disjoint) subsets of size smaller than the whole
rule set.
Indeed relies on protocol/port information, thus permitting a straightforward
implementation of the dispatcher. It is worth noting that per-protocol grouping of string
matching rules is the most natural direction, as in practical NIDS such as Snort, rules defined
for a same protocol not rarely share common sub-strings (for instance, the string “HTTP”
requires to be matched by most rules applied to Protocol: TCP and destination port: 80), and
hence may yield savings in the subsequent HW circuit design.
Step 2: Per-engine optimized HW design.

For each specific engine (and its subset of different rules) a large amount of syntheses
in order to identify the best tradeoffs in terms of throughput/area is performed. Quite
surprisingly, such trade-off significantly depends on the specific rule set considered. The
output of this second stage design is the frequency at which each engine is implemented.

Page28
Step 3: Traffic-load-based system dimensioning.

Finally, an experimental analysis of traffic devised to provide information about the
per cluster load, and consequently determine how many copies of each synthesized engine are
needed to sustain the resulting load is performed.
7.2 Snort ruleset subdivision

SNORT is an open source network intrusion prevention system capable of performing
real-time traffic analysis and packet logging on IP networks. In the design and
implementation part only few rules based on TCP, IP and UDP protocols are been used. Real
time implementation accounts for complex design and even difficult to get Real time network
interface but Using Real time data [8] it is implemented as explained below.
The SNORT ruleset are basic ruleset for Internet Traffic analysis which comprises
5567 rules. These are already pre-classified on a per-protocol basis (TCP, UDP, IP including
ICMP etc) [8]. Non overlapping (disjoint) partitioning of the Snort rules is not feasible, as
some rules are exploited. For instance those related to the IP protocol, must be obviously
applied to all the incoming network traffic.
The quantitative results of the analysis are summarized in Table 6.1 [8]. This table
splits the Snort rules on the basis of the type of considered traffic, specified in terms of
protocol (IP, TCP, UDP) and port (HTTP, IANA assigned non HTTP, i.e., smaller than 1024,
and ephemeral i.e., greater or equal than 1024). The direction of the traffic (i.e. source versus
destination port numbers) is further accounted in classification. Such split has the advantage
that a classification policy is trivially supported over the dispatcher.
Table 7.1: SNORT RULES BREAKDOWN

Page29
Table 7.1’s rule breakdown is based on the following considerations:

• Set A (IP rules):
Used for the IP protocol, and hence applied to all TCP and UDP packets and to be
supported on all the string matching engines; note that the number of rules in this set is very
small (only 34).
• Set B (generic TCP rules):
Applied to all TCP traffic, irrespective of the specific application supported (i.e. port
number), and hence to be supported on all the TCP-related string matching engines; although
greater than the previous IP case, the size of such set is still
Relatively small (491 rules) especially if compared with the following sets.
• Set C (UDP rules):
Dedicated to UDP traffic; this set is fully disjoint from the previous set B (TCP
traffic) and hence can be supported over a different string matching cluster dedicated to UDP
traffic analysis.
• Set D (HTTP server rules) and set E (HTTP client rules):
These two set of rules are dedicated to the analysis of Web (HTTP) traffic. The rules
devised to inspect the traffic addressed towards web servers (namely, set D) is fully disjoint
from the rules devised to inspect traffic in the opposite direction (set E); this suggesting the
deployment of two independent string matching clusters for the two cases.
• Set F and G (non web TCP traffic):
These rules, in total 1977, are devised to analyze non web traffic. They can be
conveniently partitioned into two disjoint subsets: set F comprising 1157 rules, dedicated to
inspect non web traffic generated by IANA-registered applications (port number lower than
1024), and set G comprising the 820 rules devised to analyze the remaining traffic.
These considerations suggest deploying 5 different string matching engine designs,
summarized in Table 6.2, along with the relevant number of supported rules. Note that, in the
worst case of the engine to be included in the cluster dedicated to the analysis of traffic
addressed to a web server, only 2394 rules out of the initial set of 5567 shall be implemented,
i.e. about 43%. Finally, we stress that the number of rules supported by each engine is just a
very rough indicator of the expected circuital complexity, as this latter depends on the
specific rules to be deployed, indeed largely differing in terms of size of strings to be
matched, rule modifiers to be accounted, and so on. As a matter of fact, Table IV presented in
the next section highlight that despite the large amount of rules, SMEWEB UPLINK is very
conveniently implemented, especially when compared with SME-NONWEB PORTLOW;

Page30
despite this latter contains a significantly lower number of rules (“only” 1682 versus the 2394
of SME-WEB UPLINK).
TABLE 7.2: MAPPING OF RULE SUBSETS OVER STRING MATCHING ENGINES
7.3 String matching engine synthesis

The five String Matching Engines (SMEs) identified in the previous section are
implemented as independent modules; hence their synthesis can be independently optimized.
Per each SME, a number (between 5 and 10 each) of syntheses with different speed
constrains, so as to identify the one(s) which achieve the best area/speed trade-off.
Specifically, in order to maximize the throughput by using the fewer number of logic
resources; the area-delay product of each implementation should be evaluated, computed as
the ratio between number of LUTs and the maximum operating frequency, and selected the
one with the lowest area-delay product.
Depending on the complexity of the circuit to be synthesized, qualitatively different
results can be obtained. For large circuits, such as the case of SMENONWEB PORTLOW,
optimization criteria are not straightforward as, the best implementation is at an intermediate,
hardly predictable, operating frequency. . Indeed, the plot in Fig. 7.1 a) shows the number of
used FPGA logic elements (y-axis) versus the maximum achievable frequency, for different
implementations of SME-NONWEB PORTLOW [8].
The two most resource consuming implementations require almost 48000 LUTs and
run at 275 and 295 MHz, while the least consuming one requires 32408 LUT and runs at 221
MHz. The solution that maximizes the throughput can be easily identified as the one with the
lowest Area-Delay Product. It can be seen that the best choice is the circuit running at 221
MHz, whereas circuits with less area or higher frequency achieve lower performance.

Page31
Figure 7.1: Area and Area/frequency synthesis results for the SME-NONWEB
PORTLOW [8]
Conversely, for small circuits the implementation with the lowest area-delay product
is typically the fastest one. As an example, Fig. 7.2 documents results for the SMEWEB
UPLINK [8] case; the remaining SMEs are qualitatively similar to this and not reported to
save space.
Figure 7.2: Area and Area/frequency synthesis results for the SME-WEB UPLINK [8]
The fact that when circuit complexity increases, limitations in the synthesis process
largely impact results. Indeed, with small SMEs, speed optimization is carried out at cost of a
limited increase in logic resource consumptions (the number of LUTs for the various
implementations differs of just about 5%), thus making the implementation with the highest
speed also the one that provides the best throughput/area trade-off. Instead, when the circuit
size grows, not only the best implementation in terms of throughput/area trade-off is for an
intermediate speed, but the variability in terms of number of LUTs is up to as much as 50%,
being 32408 the smallest one and 47516 the fastest one. It’s been believed that this is caused

Page32
by limitations in the heuristics exploited by the synthesis algorithms. All data presented in
this section are referred to result obtained without enabling the retiming available by the
Xilinx synthesis tools. Enabling retiming, results that are quantitatively different, but very
similar to those presented here.
Table 7.3 summarizes the best throughput/area results achieved for all the 5 SMEs
synthesized. For sake of comparison, the table further reports results obtained by the
synthesis of a single SME supporting all the rules. Note that such a single synthesis uses
more than 8% extra LUTs with respect to the multiple SME case4 and that in all cases but
one the resulting single SME implementation has a lower speed. This is quite remarkable,
since, as discussed in section SNORT RULESET SUBDIVISION, a disjoint partition of rules
was not technically achievable (rules belonging to sets A and B had to be reimplemented in
most of the SMEs - see table 7.2 and the total number of rules implemented is thus 7176).
TABLE 7.3: SYNTHESIS RESULTS FOR THE BEST IMPLEMENTATIONS OF
THE FIVE SME
7.4 Traffic-aware system dimensioning

Initial goal, i.e., how to dimension the entire NIDS, and which savings our approach
may accomplish. Recall that the approach promotes a traffic-aware dimensioning. Dispatcher
routes different traffic types to different string matching clusters on the basis of the enforced
classification policy. As a result, a string matching cluster is not required to support the entire
traffic, but shall sustain only the amount of traffic belonging to the considered type. It follows
that the number Ki of SME replicas to be deployed within each cluster i (refer back to Fig.
5.1) can be adapted to the actual per-cluster traffic load, in turns lower than the network link
throughput.
First, as benchmark, the system sizing in the assumption of a traffic agnostic system where a
single string matching engine is designed including all rules, and it is replicated to sustain a

Page33
total peak load of 10 gbps. From table 7.3, the best throughput/area implementation for the
case of single SME supporting all the IDS ruleset operates at 241 MHz, i.e. it can support up
to about 1.9 gbps can be seen. Therefore a cluster of 6 replicated engines is needed to sustain
a 10 gbps peak load, which in turns implies that a total number of 388206 LUTs are required.
In order to dimension a traffic-aware system, information about the actual traffic
composition is needed. Of course, the overall sizing depends on such a traffic mix, and hence
on the specific deployment case, so that no universally valid dimensioning rules are possible.
Nevertheless, some insights on the extent of such a resource saving may be gathered by
analyzing specific (and realistic) use case deployments
7.5 Queue dimensioning

The choice of the throughput at which each SME shall be operating must be strictly
greater than the average throughput; otherwise loss at the queues would be unavoidable.
Moreover, the larger the SME throughput, the lower the requirements on the queue buffer
sizing. A thorough dimensioning of the queue buffer requires an in depth queuing analysis of
the traffic variations.

Page34
Chapter 8
SOFTWARE & HARWARE REQUIREMENT

Implementation of any software and hardware is always preceded by important
decisions regarding selection of the platform, the language used, etc. These decisions are
often influenced by several factors such as the real environment in which the system works,
the speed that is required, the security concerns, and other implementation specific details.
Type of software and hardware used and its brief explanation is explained in below section.
8.1 ModelSim
ModelSim is a verification and simulation tool for VHDL, Verilog, SystemVerilog,
SystemC, and mixed-language designs.
Figure 8.1: Basic Simulation Flow


Creating the Working Library
In ModelSim, all designs are compiled into a library. Typically start a new simulation
in ModelSim by creating a working library called "work". "Work" is the library name used by
the compiler as the default destination for compiled design units.
Compiling Your Design

Page35
After creating the working library, you compile your design units into it. The
ModelSim library format is compatible across all supported platforms. You can simulate your
design on any platform without having to recompile your design.
Loading the Simulator with Your Design and Running the Simulation
With the design compiled, load the simulator with the design by invoking the
simulator on a top-level module (Verilog) or a configuration or entity/architecture pair
(VHDL). Assuming the design loads successfully, the simulation time is set to zero, and enter
a run command to begin simulation.
Debugging Your Results
If the results expected are not obtained, use ModelSim’s robust debugging
environment to track down the cause of the problem.
8.2 XILINX
Xilinx, Inc. is the world's largest supplier of programmable logic devices, the inventor
of the field programmable gate array (FPGA) and the first semiconductor company with a
fabless manufacturing model. The programmable logic device market has been led by Xilinx
since the late 1990s. Over the years, Xilinx has fuelled an aggressive expansion to India, Asia
and Europe – regions Xilinx representatives have described as high-growth areas for the
business. Xilinx's sales rose from $560 million in 1996 to almost $2 billion by 2007.
The relatively new President and CEO Moshe Gavrielov – an EDA and ASIC
industry veteran appointed in early 2008 – aims to bolster the company's revenue
substantially during his tenure by providing more complete solutions that align FPGAs with
software, IP cores, boards and kits to address focused target applications. The company aims
to use this approach to capture greater market share from application-specific integrated
circuits (ASICs) and application-specific standard products (ASSPs).
8.2.1 Technology
The Spartan-3 platform was the industry’s first 90nm FPGA, delivering more functionality
and bandwidth per dollar than was previously possible, setting new standards in the
programmable logic industry.

Page36
Figure 8.2: Xilinx Spartan 3 IC
Xilinx designs, develops and markets programmable logic products, including integrated
circuits (ICs), software design tools, predefined system functions delivered as intellectual
property (IP) cores, design services, customer training, field engineering and technical
support. Xilinx sells both FPGAs and CPLDs for electronic equipment manufacturers in end
markets such as communications, industrial, consumer, automotive and data processing
8.3VERILOG
Verilog HDL is a hardware description language used to design and document
electronic systems. Verilog HDL allows designers to design at various levels of abstraction. It
is the most widely used HDL with a user community of more than 50,000 active designers.
8.3.1 A brief history
Verilog HDL originated at Automated Integrated Design Systems (later renamed as

Gateway Design Automation) in 1985. The company was privately held at that time by Dr.
Prabhu Goel, the inventor of the PODEM test generation algorithm. Verilog HDL was
designed by Phil Moorby, who was later to become the Chief Designer for Verilog-XL and
the first Corporate Fellow at Cadence Design Systems. Gateway Design Automation grew
rapidly with the success of Verilog-XL and was finally acquired by Cadence Design Systems,
San Jose, CA in 1989.
Verilog was invented as simulation language. Use of Verilog for synthesis was a complete
afterthought. Rumors abound that there were merger discussions between Gateway and
Synopsys in the early days, where neither gave the other much chance of success.

Page37
In the late 1980's it seemed evident that designers were going to be moving away from
proprietary languages like n dot, HiLo and Verilog towards the US Depatment of Defense
standard H.D.L., known as the VHSIC Hardware Description Language. VHSIC it self stands
for "Very High Speed Integrated Circuit" BTW).
Perhaps due to such market pressure, Cadence Design Systems decided to open the Verilog
language to the public in 1990, and thus OVI (Open Verilog International) was born. Until
that time, Verilog HDL was a proprietary language, being the property of Cadence Design
Systems. When OVI was formed in 1991, a number of small companies began working on
Verilog simulators, including Chronologic Simulation, Frontline Design Automation, and
others. The first of these came to market in 1992, and now there are mature Verilog
simulators available from many sources.
As a result, the Verilog market has grown substantially. The market for Verilog related tools
in 1994 was well over $75,000,000, making it the most commercially significant hardware
description language on the market.
An IEEE working group was established in 1993 under the Design Automation Sub-
Committee to produce the IEEE Verilog standard 1364. Verilog became IEEE Standard 1364
in 1995.
As an international standard, the Verilog market continued to grow. In 1998 the market for
Verilog simulators alone was well over $150,000,000; continuing its dominance.
The IEEE working group released a revised standard in March of 2002, known as IEEE
1364-2001. Significant publication errors marred this release, and a revised version was
released in 2003, known as IEEE 1364-2001 Revision C.
.8.4 Tools
VHDL descriptions of hardware design and test benches are portable between design
tools, and portable between design canters and project partners. You can safely invest in
VHDL modelling effort and training, knowing that you will not be tied in to a single tool
vendor, but will be free to preserve your investment across tools and platforms. Also, the

Page38
design automation tool vendors are themselves making a large investment in VHDL, ensuring
a continuing supply of state-of-the-art VHDL tools.
8.5 Technology
VHDL permits technology independent design through support for top down design
and logic synthesis. To move a design to a new technology you need not start from scratch or
reverse-engineer a specification - instead you go back up the design tree to a behavioural
VHDL description, then implement that in the new technology knowing that the correct
functionality will be preserved
8.6 Benefits
 Executable specification
 Validate spec in system context (Subcontract)
 Functionality separated from implementation
 Simulate early and fast (Manage complexity)
 Explore design alternatives
 Get feedback (Produce better designs)
 Automatic synthesis and test generation (ATPG for ASICs)
 Increase productivity (Shorten time-to-market)
 Technology and tool independence (though FPGA features may be unexploited)
8.7 Overview of FPGA

As the FPGA architecture evolves and its complexity increases, CAD software has
become more mature as well. Today, most FPGA vendors provide a fairly complete set of
design tools that allows automatic synthesis and compilation from design specifications in
hardware specification languages, such as Verilog or VHDL, all the way down to a bit stream
to program FPGA chips. A typical FPGA design flow includes the steps and components
shown in Fig. 8.2.
Design constraints typically include the expected operating frequencies of different clocks,
the delay bounds of the signal path delays from input pads to output pads (I/O delay), from
the input pads to registers (setup time), and from registers to output pads (clock-to-output
delay). In some cases, delays between some specific pairs of registers may be constrained.

Page39
The second design input component is the choice of FPGA device. Each FPGA
vendor typically provides a wide range of FPGA devices, with different performance, cost,
and power tradeoffs. The designer may start with a small (low capacity) device with a
nominal speed-grade. But, if synthesis effort fails to map the design into the target device, the
designer has to upgrade to a high-capacity device. Similarly, if the synthesis result fails to
meet the operating frequency, he has to upgrade to a device with higher speed-grade. In both
the cases, the cost of the FPGA device will increase by 50% or even by 100%. Thus better
synthesis tools are required, since their quality directly impacts the performance and cost of
FPGA designs.
Figure 8.3: FPGA Design Flow
8.7.1 Design Entry

The basic architecture of the system is designed in this step which is coded in a Hardware
description Language like Verilog or VHDL. A design is described in Verilog using the concept
of a design module.

Page40
8.7.2 Behavioural Simulation

After the design phase, the code is verified using a simulation software i.e. Modelsim6.1e
for different inputs to generate outputs and if it verifies then we will proceed further otherwise
modifications and necessary corrections will be done in the HDL code. This is called as the
behavioural simulation.
8.7.3 Design Synthesis

After the correct simulations results, the design is then synthesized. During synthesis the
Xilinx ISE tool does the following operations:
1. HDL Compilation: The tool compiles all the sub-modules in the main module if any and
then checks the syntax of the code written for the design.
2. Design Hierarchy Analysis: Analysis the hierarchy of the design.
3. HDL Synthesis: The process which translates VHDL or Verilog code into a device net list
format. i.e. a complete circuit with logical elements such as Multiplexer, Adder/Subtractors,
Counters, Registers, Flip flops, Latches, Comparators, XORs, Tristate Buffers, Decoders, etc.
4. Advanced HDL Synthesis: Low Level synthesis: The blocks synthesized in the HDL
synthesis and the Advanced HDL synthesis are further defined in terms of the low level
blocks such as buffers, lookup tables. It also optimizes the logic entities in the design by
eliminating the redundant logic, if any. The tool then generates a netlist file (NGC file) and
then optimizes it.
8.7.4 Design Implementation

The design implementation process consists of the following sub processes:
1. Translation: The Translate process merges all the input netlists and design constraints
information and outputs a Xilinx NGD (Native Generic Database) file.
2. Mapping: The Map process is run after the Translate process is complete. Mapping maps
the logical design described in the NGD file to the components/primitives (slices/CLBs)
present on the target device. The Map process creates an NCD file.

Page41
3. Place and Route: The place and route (PAR) process is run after the design has been
mapped. PAR uses the NCD file created by the Map process to place and route the design on
the target FPGA design.
4. Bit stream Generation: The collection of binary data used to program reconfigurable
logic device is most commonly referred to as a “bit stream,” although this is somewhat
misleading because the data are no more bit oriented than that of an instruction set processor
and there is generally no “streaming”.
5. Functional Simulation: Post-Translate (functional) simulation can be performed prior to
mapping of the design. This simulation process allows the user to verify that your design has
been synthesized correctly and any differences due to the lower level of abstraction can be
identified.
(a) (b)
Figure 8.4: (a) Design Flow during FPGA Implementation (b) Procedure Followed for
Implementation

Page42
6. Static timing analysis: Three types of static timing analysis are performed that are:
(a) Post-fit Static timing analysis: The Analyze Post-Fit Static timing process opens the
timing Analyzer window, which lets you interactively select timing paths in your design for
tracing the timing results.
(b) Post-Map Static Timing Analysis: You can analyze the timing results of the Map process.
Post-Map timing reports can be very useful in evaluating timing performance (logic delay +
route delay).
(c) Post Place and Route Static Timing Analysis: Post-PAR timing reports incorporate all
delays to provide a comprehensive timing summary. If a placed and routed design has met all
of your timing constraints, then you can proceed by creating configuration data and
downloading a device.
7. Timing Simulation: After your design has been placed and routed, a timing simulation net
list can be created. This simulation process allows you to see how your design will behave in
the circuit.
8.8 Implement Design in FPGA

The Spartan-3E Starter Kit board highlights the unique features of the Spartan-3E
FPGA family and provides a convenient development board for embedded processing
applications. The board implements the design and verifies that it meets the timing
constraints after check syntax and synthesis.

Page43
Chapter 9
IMPLEMENTATION AND RESULT
9.1 FPGA Implementation

The FPGA that is used for the implementation of the circuit is the Xilinx Spartan 3E
(Family), XC3S500 / XC3S1600 (Device), FG320 / FG484 (Package), -5 (Speed Grade). The
working environment/tool for the design is Xilinx ISE 9.2i.
Figure 9.1: FPGA kit
9.2 Simulation Result

NIDS can be used to detect traffic intruding in to the network. To verify the
architecture, the design was coded in verilog Fig 9.9 shows the simulation result of NIDS
architecture.
The detailed RTL schematic of NIDS is as shown below in Fig 9.2. Where the packets
are received from the receiver and stored in ram which are read by the packet classifier.
Packet classification takes place based on respective header format and string matching

Page44
operations is done. OR operation is carried out for the output of packet classification to get
final output
Figure 9.2: RTL schematic of NIDS
9.2.1 Receiver
Figure 9.2 shows RTL schematic of Receiver module. Fig 9.3 shows the Simulation
test result of receiver of NIDS system. Where once the clock cycles begin, reset is made from
high to low and start of packet (SOP) is made high. Output will be the values which are in
temp. Temp values are those which are received from Data in. here input to the system is of 8
bits packets, total 76 packets are received hence 608 bits and input is given as data-in=8’d608

Page45
Figure 9.3: RTL receiver module
Figure 9.4: RTL schematic of Receiver module

Page46
Clock = clock, reset = 0, SOP=0, EOP=1, Valid=1, Error=1, data in = 8’d608
Figure 9.5: Receiver output
9.2.2 RAM
Figure 9.4 shows RTL schematic of Ram module. Here the input to the system will be
the output. Input to the system is from receiver output. Fig 9.5 shows the simulation result of
RAM. Reset will be low and once Write Enable (WE) is made high output will be the input
which are stored in temp.
Figure 9.6: RTL ram module

Page47
Figure 9.7: RTL schematic of Ram module

Clock = clock, reset = 0, data in = 8’habcdefabcdef, WE=1.
Figure 9.8: Ram output

Page48
9.2.3 Packet Classification

Fig 9.6 shows RTL schematic of Packet classification module. Fig 9.7 shows the
simulation result of Packet classification module. Here byte count is set to 63 bytes;
classification process takes place after 63 byte up to 76 byte.
Figure 9.9: RTL Packet classification module
Figure 9.10: RTL schematic of Packet Classification module

Page49
Clock = clock, reset = 0, data in = 8’habcdefabcdefabcdefabcdefabcdefabcdef, lda=1, byte

count=7’d63
Figure 9.11: Packet classification output
9.2.4 Simulation result of NIDS

This is the final Test result of overall NIDS which gives the matched output for the
intrusion for respective string matching engines. As shown in fig 9.8.
Clock = 0,rst = 1, valid = 1, sop = 0, error = 0, eop = 0, data_in =
temp,

Page50
Figure 9.12: NIDS output
9.3 Device utilization

Table 9.1 shows the Device utilization summary, where the overall logic utilization
and overall resource utilization percentage is very less with respect to available logic
resource. This accounts for main aim of project. Total throughput of the system is 3.34GHz
with the frequency of 418.755MHz [8]. Design implemented has the least resource utilization
compared to the earlier approach mentioned in Table 7.3 and even the total throughput of the
system is very much better in terms of GHz comparatively to the approach in Table 7.3 which
had throughput in terms of MHz

Page51
Table 9.1: Device utilization summary (estimated values)

Page52
CHAPTER 9
ADVANTAGES AND DISADVANTAGES
9.1 Advantage
 Network Intrusion Prevention Systems (IPS) is able to use signatures designed to
detect and defend from specific types of attacks such as denial of service attacks
among other.
 A system automatically identifies and responds to intrusion activities.
 Intrusion Prevents the act of dropping detected bad traffic in real-time by not
allowing the traffic to continue to its destination, and is useful against denial of
services floods, brute force attacks, vulnerability detection, protocols anomaly
detection and prevention against unknown exploits. Intrusion Prevention Systems
protect the information systems from unauthorized access, damage or disruption.
 The system support both static and dynamic patterns and can handle multi-pattern
signature matching.
 When the number multi pattern signature increase significantly the resource cost of
the encoders, counters and comparators are not considerable.
 This approach is feasible for the number of signature that has reached thousands.
 Pattern matching on reconfigurable device not only focused on one type of pattern but
also considers the combination of multiple patterns.
 The system when evaluated shows that system can maintain better gigabit line rate
throughput when compared to previous approach without dropping packets.
9.2 Disadvantage
 The risk introduced with placing either an IDS inline is related to the likelihood of the
system failing resulting in the link being brought down.
 System dimensioning is a major issue, several trade off needs to be considered
 String matching engine implementation is costly

Page53
CHAPTER 11
CONCLUSION AND FUTURE WORK
11.1 Conclusion
The integration of network interface hardware and packet analysis hardware into a
single FPGA chip gives best approach for network intrusion attacks caused by various
malicious intrusions in to the network. NIDS gives a flexible way of foundation for network
security operations. It can be concluded that security of today’s system rely on network
intrusion detection system
The overall resource utilization and throughput of frequency is of major concern, and
least resource is utilized and best throughput of frequency is achieved, keeping in concern of
various trade off related to the design
11.2 Future work

There are a variety of opportunities for future work in this area. First, this NIDS work
can be improved upon by considering techniques by which intrusion detection information
captured at one network point can be shared with other interested parties or devices. The
PowerPC processor would serve as a good processing substrate for coordinating the
distribution of this information.
Another avenue of investigation for this work involves an exploration of how high-
capacity FPGAs can be better leveraged in a large-scale NIDS. Experiments indicate that
current FPGAs are large enough to house very large rule sets. However, compiling these
circuits is very time consuming on state-of the workstations. These compilation times and
clock speeds can be improved with better floor-planning. Therefore, the next step in this work
will involve refining how placement information is added to the ID cores when the pattern
matching circuitry is generated.
Finally, this work can be improved upon by considering methods in which an FPGA-
based NIDS is incrementally updated with new patterns over time. In current approach of
NIDS, It must be taken offline briefly and reconfigured whenever rule updates need to be
applied. Because updates are infrequent and require only a few seconds of downtime, this
approach is acceptable for many applications. However, if high availability is required,

Page54
partial reconfiguration techniques are potential solutions. With partial reconfiguration, the NI
units would buffer incoming messages while the ID unit is updated with new circuitry.

Page55
REFERENCES
[1] P. Borgnat, G. Dewaele, K. Fukuda, P. Abry, K. Cho, “Seven years and one day:
Sketching the evolution of internet traffic”, in Proc. Of the Twenty-Eight Annual Joint
Conference of the IEEE Computer and Communications, INFOCOM 2009, pp. 711-719.
[2] A.V. Aho, M.J. Corasick,“Efficient String Matching: An Aid to Bibliographic Search”,
Communications of ACM, Vol. 18 n. 6, June 1975
[3] J. Bispo, I. Sourdis, J. Cardoso, S. Vassiliadis, “Synthesis of Regular Expressions

Targeting FPGAs: Current Status and Open Issues”, in Proc. of the 3rd international
conference on Reconfigurable computing: architectures, tools and applications, ARC 2007,
Springer-Verlag.
[4] Sourcefire, “Snort: The Open Source Network Intrusion Detection System”, available at
http://www.snort.org.
[5] S. Teofili, E. Nobile, S. Pontarelli, G. Bianchi, “IDS Rules Adaptation for Packets Pre-
filtering in Gbps Line Rates”, in Trustworthy Internet, pp. 303–316, Springer, 2011.
[6] Sourdis, V. Dimopoulos, D. Pnevmatikatos and S. Vassiliadis, “Packet Pre-filtering for

Network Intrusion Detection”, in 2nd ACM/IEEE Symposium on Architectures for
Networking and Communications Systems (ANCS), 2006, pp. 183-192.
[7] Christopher R. Clark, Craig D. Ulmer, “Network Intrusion Detection System On FPGAS
with On-Chip Network Interfaces”, In Proceedings of International Workshop on Applied
Reconfigurable Computing (ARC), Algarve, Portugal, February 2005.
[8] Salvatore Pontarelli, Giuseppe Bianchi, Simone Teofili, “Traffic awareness Network
Intrusion Detection System” Consorzio Nazionale InterUniversitario per le
Telecomunicazioni (CNIT) University of Rome “Tor Vergata” Via del Politecnico 1, 00133,
Rome, ITALY.

Page56
PAPER PUBLISHED
SANDEEP NAIK R and PRASHANTH BARLA, “TRAFFIC AWARE DESIGN OF A
HIGH SPEED FPGA NETWORK INTRUSION DETECTION SYSTEM”, International
journal of Research in Information Technology (IJRIT), ISSN:2001-5569, June 2014.

Page57

Page58

Original 2

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Original 2

Загружено:

Авторское право:

Доступные форматы

Traffic-aware Design of a High Speed FPGA Network Intrusion Detection System

DEPT. OF E&C. ENGG. , SIT, MANGLORE

1.1 Motivation for the project

DEPT. OF E&C. ENGG. , SIT, MANGLORE

1.3 Organization of Thesis

Chapter 4: Explains the type of network intrusion threats

DEPT. OF E&C. ENGG. , SIT, MANGLORE

DEPT. OF E&C. ENGG. , SIT, MANGLORE

2.1 Evolution of Internet Traffic [1]

2.1.1 Analysis of Internet Traffic

DEPT. OF E&C. ENGG. , SIT, MANGLORE

2.1.2 Longitudinal studies

DEPT. OF E&C. ENGG. , SIT, MANGLORE

2.1.3Long Range Dependence

2.1.4 MAWI Data set

2.2 NETWORK INTRUSION DETECTION SYSTEMS ON

DEPT. OF E&C. ENGG. , SIT, MANGLORE

2.2.2 Modern Field-Programmable Gate Arrays

2.2.3 An Integrated NIDS in FPGA

DEPT. OF E&C. ENGG. , SIT, MANGLORE

There are a variety of means by which an FPGA-based NIDS can be customized. At

2.2.4 FPGA network interface

2.2.5 Rocket I/O Controllers

DEPT. OF E&C. ENGG. , SIT, MANGLORE

2.2.6 Packet FIFOs

2.3 Intrusion Detection System

DEPT. OF E&C. ENGG. , SIT, MANGLORE

2.3.1 Header Decoder

2.3.2 Header Field Analyzer

2.3.3 Payload Processor

DEPT. OF E&C. ENGG. , SIT, MANGLORE

DEPT. OF E&C. ENGG. , SIT, MANGLORE

TRAFFIC AWARE APPROACH

Traffic-aware approach is proposed as a solution for better ways to parallelize NIDS

3.1 Snort rules analysis and relevant classification policies

DEPT. OF E&C. ENGG. , SIT, MANGLORE

In order to organize set of rules into disjoint subsets, it should be identified by

3.2 Real world traffic analysis for HW module sizing

DEPT. OF E&C. ENGG. , SIT, MANGLORE

3.3 HW module implementation and relevant trade-offs

3.4 Connecting an IDS Device

Figure 3.1: IDS on the edge of a network or zone.

DEPT. OF E&C. ENGG. , SIT, MANGLORE

NETWORK INTRUSION ATTACKS

4.1.1 SYN Flood Attack

DEPT. OF E&C. ENGG. , SIT, MANGLORE

4.1.3 ICMP Flood

4.1.4 Ping of Death

DEPT. OF E&C. ENGG. , SIT, MANGLORE

OVERALL SYSTEM ARCHITECTURE

Figure 5.1: Overall system architecture

5.1Main blocks of the system

DEPT. OF E&C. ENGG. , SIT, MANGLORE

considered cluster; A generic string matching system is composed of n cluster, each

DEPT. OF E&C. ENGG. , SIT, MANGLORE

5.3 Packet classification flow chart

Figure 5.2: Packet classification flow chart

DEPT. OF E&C. ENGG. , SIT, MANGLORE

The Packet classification process is structured into a three phases as follows

4.4 OSI layer and functions

Figure 5.3: OSI layer and functions

DEPT. OF E&C. ENGG. , SIT, MANGLORE

DEPT. OF E&C. ENGG. , SIT, MANGLORE