Morales-Capstone-IDS.IPS Deployment_revision1

Capstone Project Cover Sheet
Capstone Project Name: Suricata IDS/IPS Deployment to Business X
Student Name:Jeremy Morales
Degree Program:Bachelors of IT : Security
Student Mentor Name:Joyce Dahlhauser
Capstone Project Waiver/Release Statement Acknowledgement
It is the policy of Western Governors University (“WGU”) that student Capstone projects
should not be based upon, and should not include, any proprietary or classified information or
material belonging to your employer or any other organization (“Restricted Information”)
without appropriate authorization.
Please confirm (by signing below) that you will complete (and upload into TaskStream)
the IT Capstone Waiver Release form (verbiage is available in Appendix 2 of this document)
indicating that your project does not include any restricted content. If you have included
restricted content, please confirm that, in addition to the IT Capstone Waiver Release form, you
will upload a suitable release letter giving you permission to use restricted information (A
sample release letter is available in Appendix 3 of this document).
Student’s Ink or Electronic Signature Date Signed

Table of Contents
Capstone Project Report ............................................................................................................. 1
Review of Other Work ............................................................................................................... 3
Project Rationale ........................................................................................................................ 5
Systems Analysis and Methodology .......................................................................................... 8
Goals and Objectives.................................................................................................................. 9
Project Deliverables.................................................................................................................. 13
Project Plan and Timelines....................................................................................................... 18
Project Development ................................................................................................................ 23
Conclusion................................................................................................................................ 27
Appendix I: Network diagram.................................................................................................. 28
Appendix II: Tuning Suricata................................................................................................... 29
References ................................................................................................................................ 30

Suricata IDS/IPS Deployment to Business X Page 1
Capstone Project Report
Business X has recently had been growing in their field of expertise. Along with this
growth is a larger market awareness of their company, which had increased their exposure to
possible network, attacks, from both external sources and possibly internal threats such as
disgruntle employees. CEO Bob has expressed this concern to the current information security
department and it had decided that an Intrusion Detection System or an Intrusion Prevention
System would be an ideal upgrade to the network infrastructure. The purpose of this device was
to provide real-time monitoring and alerts of active threats against the integrity of the network
and the data that resides on it.
There was no current solution in place at that time that matched the needs requested by
Business X. It was then determined, through discussions between the finance department and the
information security department that an open source solution running on current virtual server
infrastructure would provide the necessary requirements and constraints. This product must not
cost anything, have some level of support, and provided regular updates to its core capabilities in
order to stay ahead of any future threats and provide a way for acceptable risk mitigation.
Requirements requested include a Network Intrusion Detection System (NIDS) engine,
Network Intrusion Prevention System (NIPS) engine, and a Network Security Monitoring (NSM)
engine. Offline analysis of PCAP network traffic capture files and possible integration with
current network firewalls were also requested features. It must also have a broad operating
system support as it is yet to be determined which operating system it would lie on, but the IT
department was leaning toward a Linux deployment.
In order to prepare for the future growth of the company, IPv6 support was needed along
with current protocols including IPv4, IPv6, TCP, and UDP. It must be able to monitor HTTP

traffic along with SSL/TLS, SMB file transfer protocol, SMTP/POP email protocols, along with
FTP and DNS.
Suricata meet nearly all the requested features from the provided list. As an open source
solution, it is a well-maintained protection engine and current staff will deploy it. This is to be
deployed with a new virtual server, using provided documentation from the Suricata website, and
with support on hand. Training was available from the Suricata staff through conferences as well
as on-site training upon request. This will be a later consideration if it is determined it would be a
necessity.
Suricata hardware requirements match with current virtualization setup. Two 1GB/s LAN
connections will provide for an inline deployment method. Other requirements were a dual CPU
setup in order to assist in traffic analysis. 2GB of RAM was the starting point in the
virtualization with the option of upgrading in the future to 8GB as the company grew. Hard drive
space requirements were little; therefor 20GB of hard drive space would suffice. The above
requirements match current VMware deployment solution and no other hardware requirements
were going to be added to the current systems.
The Suricata PPA bundle had the necessary packages and library dependencies included
with the installation for functionality. This would shorten deployment time and easy complexity
with mismatching library versions. Ease of deployment was the primary goal, as a junior
information security engineer was to be the primary personal assigned.
The implementation of Suricata on Business X’s computer network was done
with no major issues. The issues that were present were minor and easily correctable. Several
dependencies for the program itself needed to be correct as the guide used on the developers’
website had not been maintained. Additional time had to be allocated for the development of the

test network, as unplanned operating system updates arose. Additional delays occurred with the
technical documentation of the IT staff due to family emergencies but did not provide any
significant delays as the Chief Information Officer made a speedy signing off of the project,
resulting in the Suricata development being well ahead of schedule.
Review of Other Work
One of the primary concerns and issues was accuracy of detection by Suricata and its
level of performance on the current virtualization hardware. Business X wanted to be sure that on
later date, Suricata would not need to be replaced. Day and Burns stated in "A Performance
Analysis of Snort and Suricata Network Intrusion Detection and Prevention Engines" (2011)
that:
...the amount of packets dropped by Snort and Suricata as the CPU availability drops.
While Snorts percentage drop is largely linear, Suricata’s performance diminishes
significantly, once the CPU availability reduces below one core...reducing the number of
cores, and stressing the CPU, effects false negatives on both systems.
From this, it was determined that a minimum of dual core processor setup was best for
the proper functionality and accuracy of Suricata detection engine. Consideration was also taken
for the increase of cores available to the server instance for future growth. Business X had also
planned for additional resources to be allocated to the virtualization as the company grew and as
such, the amount of network traffic would grow.
Suricata's ability to handle multiple core processor was one of the primary reasons it was
chosen as it has the ability to properly handle multi-threading, resulting in greater performance, a

feature that was not common in most IDS/IPS engines available as open source and free. Snort
was the baseline of free IDS and to which Suricata got its parentage. As such, most analysis
includes Snort as their comparative factor.
When going from one core to four cores, Day and Burns had provided this fact:
Additional cores did not improve Snorts processing time, although Suricata’s
performance increased by 220%, when using four cores, compared to one. Again,
this is expected, considering Suricata’s multithreaded design.
It was concerning that as system resource demands went up, accuracy of detection would
have a significant drop, but this was not a concern by ensuring multiple cores were available to
the Suricata processes. This issue was primarily a concern in Snort, but a short falling that
Suricata did not seem to have.
White, J., Fitzsimmons, T., & Matthews, J. in "Quantitative Analysis of Intrusion
Detection Systems: Snort and Suricata" (2013) stated little performance issues as they used a
large server to host the application consisting of a total of 24 cores, spread across two processors,
and 64GB of RAM available. They go on to add:
With these changes, at 24 cores, Suricata performance increases from 12,871 PPS to
258,912 PPS; an almost 20X improvement. In addition, our work spurred the OISF
developers to add lock profiling code to the Suricata codebase which will allow for easier
future profiling of the engine. While these changes were put initially in a beta version for
our testing, they are now incorporated into mainline Suricata as of version 1.3.6.

From this we concluded that we needed to have at least version 1.3.6 or greater to
maximize multicore functionality. Current available stable version was 2.0.08, so this issue is
well in the past and should not be any concern. The most recent version includes quite a few
stability and performance fixes that should address most concerns brought up in the provided
analyses.
Albin, E used a program called Pytbull in his thesis, "A COMPARATIVE ANALYSIS
OF THE SNORT AND SURICATA INTRUSION-DETECTION SYSTEMS" (2011) to
determine the effectiveness of the Suricata IDS/IPS. We considered that this tool be was to be
used to test for the performance of Suricata in our environment. It provided an automated testing
solution by flooding a test network with packets that would trigger alerts in the Suricata engine,
as long as the proper rules have been set.
Albin, E. also concludes that Suricata had a significantly higher detection rate as
compared to other free sources such as Snort. Also false positives were higher in Snort than in
Suricata, in both fragmented packets and standard. However, while providing a significant
increase in detection of malicious traffic, Suricata came with higher system requirements due to
the nature of its programming.
Project Rationale
When computers began to be networked together, network security became an issue,
which was an issue that needed to be address by IT staff. As the internet has evolved, the need
had become even greater.
Intrusion detection and prevention systems were the attempt to monitor and possibly
prevent attempts to intrude into your systems and network resources. The reason for and IDS/IPS

system is straightforward: You wanted to protect the confidentiality and integrity of your data
and your systems. You cannot always protect your system with just a firewall on the outside line.
A firewall is merely the first line of defense, the wall of your defense, hence its name. The
IDS/IPS was the guard at the gate checking for passports, papers, and reason for entry into your
network. It examined each entry and did its best to ensure that the network traffic was authorized
and checks the contents of the network traffic to ensure that dangerous items do not attempt to
enter. This guard also had monitored what is going on inside and tried to prevent any internal
threats.
By installing an intrusion detection and prevention system, Business X mitigated the
known risk of malicious activity on its network from both internal and external threats. Data loss
and public confidence were the primary reason for the system to go into place. If data loss had
occurred, breaches of contract and loss of revenue were the most likely outcome. Public
confidence in the company could falter, resulting in further financial loss by loss of stock market
holdings by current shareholders. The importance of this system could not be stressed enough.
Installation was the first step and it had needed to be done in anticipation of any future
growth in the company, which would result in increased stress on the system. A virtualization
system was the ideal way to install as future resources can be easily allocated to accommodate
additional growth. Currently, the system was to be used in the inline promiscuous setup, with all
network traffic passing through as the IDS/IPS listened and examined. By setting the server up
this way, monitoring ensures that no malicious activity was being missed.
Configuring rules and alerts was the most critical of steps as this was to be what the
system primary function was to dependent on. Traffic analysis was needed by turning on all the
rules, but not enabled any blocking. This allowed the IT staff to see what was passing through

the network and what the next steps were to be. After analysis, primary threats were addressed
by setting those rules to blocking mode. Next level threats were balanced, based off of demand
on the server's resources, as each rule took CPU cycle time and the extent of which would be the
result of the threat actually occurring. This could be done by examining US-CERT (United
States Computer Emergency Readiness Team) reports and the OSVDB (Open Source
Vulnerability Database) reports, which were the primary way new threats, were reported and
disseminated. Minor threats were to be logged only and if the rule did not match any current
network traffic, that rule would be turned off as to not put any increased demand on the server
and network resources.
As new attack methods are in development daily, updates to the systems rules and
configurations would be an ongoing task. It was up to the staff to ensure that updates to the
system were pulling from EmergingThreats.net, a free source for rules for Suricata. These rules
were needed to go through the same cycle of monitoring and then implementing blocking on
major threat sources. This was to be done on a weekly and as an ongoing basis. This would
ensure that being blindsided by known threats did not occur to Business X.
It is not possible, using the most up to date tools that are available, to protect against
virtually every type of threat. Unfortunately, new threats and security holes in some software
package or another are being discovered on a daily basis.
It was important in Business X's environment to know what types of threats that were
being faced. Monitoring is to be needed to be aware of any potential security holes in the system,
and care will be taken to prevent attacks against these. For example, the web server that is
connected to the internet and placed behind a firewall may be reasonably secure against most
packet-based attacks, but a CGI program on the server might expose vulnerability.

Systems Analysis and Methodology
Business X had no network device capable of monitoring internal and external network
traffic. Since the inception of the company, this was thought to be unnecessary due to the
obscurity of the company. Recent shifts in the market had brought welcome traffic to the
company's website and other servers. As exposure had increased, so had security threats to
Business X’s systems, to remedy this predicament, the IDS/IPS software Suricata was deployed
inline to pick up the pace of auditing network traffic.
A few years ago, Business X had made the switch to a virtualized server setup, with three
Dell PowerEdge R220 Server blades. Each of this server’s consists of Intel Xeon E3-1286
processor, 3 terabytes of hard drive space, and 32 gigabytes of RAM. As of today, Business X is
operating a VMWare ESXi setup with a Microsoft Server 2012 R2 active directory domain
controller and a file server on one of the blades. The second blade is currently consists of a
backup domain controller, a backup location for the file server and hosting the company's web
application server. The third blade sits in reserve status for potential future growth.
As no setup was available for the Suricata, it was deployed on the first blade, as it was the
least taxed server with daily operations. Two threads from a single core of the processor were
assigned along with 40GB of hard drive space for operating system and logging. 2GB of RAM
was assigned with a possible increase to 4GB after initial testing concludes.
Before any production environment deployment began, Suricata was deployed on the
third blade along with copies of the active directory server, the web server, two Windows 7 user
machines, a Ubuntu user machine, and a reduced size file server as a testing setup. The
virtualization of all these machines allowed a closed loop test to be performed without any

negative impact on the live systems. This was done by specifying the network cards to use a
virtual network, keeping all network traffic contained within the respected test environment.
After initial setup was performed for all involved machines, multiple tests were ran
including typical user usage of internal and external web traffic, access to file servers, and
logging in and out of the active directory domain. The PytBull IDS/IPS testing software was also
deployed from the Ubuntu user machine to test rules and logging of the Suricata server. This was
a daily test performed as configuration was tweaked on the IDS/IPS.
Goals and Objectives
External network access auditing
Recent high exposure on the internet and news had greatly grown Business X to
the world and external threats were of a higher concern to the executives of the company. This
was the primary goal that Business X had been concerned about and had needed immediate
addressing. Often attacks come from skilled and sophisticated external hackers and these
attackers would attempt to find network vulnerabilities or even socially manipulate Business X's
users to bypass any outer facing network defenses. Since Business X's software applications
maintain open connections to IT databases, hackers may seek to take control of these
applications after they get inside, often by seeking application passwords set to their defaults.
Intentional attacks on Business X's databases would receive much press and attention and could
influence stock prices and future growth of the company.
With new vulnerabilities continuously detected in Web applications and database
platforms and exploits to access the vulnerabilities that are being constantly written, it was
essential for Business X to protect its assets against possible exploitation. By using a
combination of signature-based attack rules and white listing normal application and database

usage, also known as anomaly-based signature, Business X could create an effective way to
reduce the risk against the leading attack vectors.
Business X intended to inspect outbound traffic from applications and databases to block
accidental leakage of sensitive data from internal users. These had included such things as credit
card numbers, program code, accounting records, and intellectual property.
The general rule of network communications was that it can occur in an unsecured or
"cleartext" manner, which allowed an attacker who had gained access to the network to perform
man-in-the-middle attacks by listening into the data traffic and or modifying it to fit their desires.
The ability of a hacker to eavesdrop on the network was considered one of the greatest security
issues that the administrators addressed in the organization. Without strong cryptology services,
Business X's data could be read by malicious hackers as it traverses through the network.
Suricata was to inspect traffic to ensure that HTTPs is being enforced as much as possible.
Most networks use the IP address of a system to help identify if it is a valid source of
traffic. However, certain cases, it was possible for an IP address to be falsely assumed by a
method called spoofing. An attacker used special programs to create packets that appear to
originate from valid internal addresses from inside the corporate intranet. Suricata was to block
traffic that was coming from the inbound network line with an internal IP address, which maked
it appear as if it is a trusted traffic source.
A Denial-of-Service (DoS) attack is an attack meant to shut down a system, service, or
network, by making it inaccessible to its valid users or guests. DoS attacks are accomplished by
flooding the target with traffic coming from its inbound line, or by sending it specialized
information that triggers a crash of the service or program. In both cases, the DoS attack deprives
legitimate users the ability to use services or resources they expect. Suricata was to inspect traffic

to ensure packet sizes do not exceed a recommend limit size and malicious buffer overflows did
not occur. It was also to ensure that no more than a few connections were made to Business X
from the same location, reducing the exposure to a DDoS attack.
The goal of monitoring the network for external access was achieved by ensuring that the
Suricata deployment was between the main network connection node and the firewall. This
resulted in all inbound traffic being routed through the Suricata IDS/IPS, allowing monitoring
and logging to occur.
Internal network use auditing
An internal threat to Business X was any current or former employee who has or had
authorized access to Business X's data or network and maliciously used that access in a manner
that affected confidentiality, integrity, or availability of the information systems.
Part of the difficulty in detecting an internal attack was in creating a good rule set for the
internal IDS. The reason being was that the rule set different users need different rules bases off
what they were accessing including services, servers and systems, based off their work. The rule
set was to be set on the IDS to ignore daily user activates such that it does not trigger attack
warnings, but only notifies on important notifications. This was typically when a user exceeds
their typical access, for example, when a user in financial started looking at human resources
files or when a user had made use of "hacking" tools.
Logging and reporting of attacks or misuse by the internal IDS were used to determine if
an attack was a pattern or if it was even an unrelated attack. Once a trend or pattern were
identified, the administrators of the network were able to identify any users who had posed a
threat to the network security, having shown signs of malicious computer use, or even just
violating general acceptable computer usage.

Furthermore, logging by the IDS on the internal system allowed the administrators to
create an audit trail in case there were any successful intrusions by internal users. Identifying
these trends allowed not only a paperwork trail for human resources to handle but also allowed
the system administrator to see where policies were weak or where security holes needed to be
closed to prevent further issues.
The goal of internal auditing was achieved with this project as all outbound and internal
network communication was routed through the Suricata IDS/IPS through network
configuration. All internal sources of traffic were required to route their traffic to the Suricata
IDS/IPS through a promiscuous deployment of the software, which allowed Suricata to monitor
and log all internal threats and malicious activities.
Confidentiality, Integrity, Availability
Confidentiality, integrity and availability, also known as the CIA triad, is a model
designed to guide policies for information security within an organization. The model is also
referred to as the AIC triad (availability, integrity and confidentiality) to avoid confusion with
the Central Intelligence Agency. The elements of the triad are considered the three most crucial
components of security.
In this context, confidentiality is a set of rules that limits access to information,
integrity is the assurance that the information is trustworthy and accurate, and availability is a
guarantee of reliable access to the information by authorized people.
Confidentiality was affirmed by providing rules to the IDS policy within Suricata by
limiting the flow of information so that certain IP address ranges could only reach access to key
resources, such as databases and file servers. This had ensured that only internal and authorized
sources were allowed to access vital information to Business X.

Integrity was reached by verifying that only authorized personal were allowed to
modify those resources on Business X's servers and network devices such as computers, routers,
switches, servers, and network storage resources.
Suricata ensured availability by stopping malicious network attacks before they
could cause interruptions in service to Business X's network, such as denial of service attacks
and virus infections. Suricata accomplished this by whitelisting common traffic to the network
and blocking all other traffic. This ensured only authorized and preapproved traffic was allowed
to move forth on the internal network.
Project Deliverables
Virtual Testing Environment
The first phase of the integration of the Suricata IDS/IPS had involved developing an
internal test network to deploy the software on, consisting of virtualized computer that matched
the typical network at Business X. This had consisted of our usual end user computers, which
consisted of Windows 7 and Ubuntu 14 desktops. Also deployed was one instance of Windows
2008 R2 running Active Directory and another instance of Server 2008 R2 running a MySQL
server database and a webpage which was a direct copy of our external website at that time as
seen by the customers on the web server.
Windows 7 was the most common end user operating system in the internal network of
Business X. The majority of our users were daily using software such as Office 2007, Google
Chrome, and accessing shares on the network for internal documentation. The Ubuntu Linux
distro's were the common operating system used by our development team for product
development, web application development, and website administration. The intent was to place
a copy of each on two separate virtual machines to replicate common use in the network.

Windows Server 2008 R2 was the currently used active directory domain controller, file
server, web server, and database server. Its versatility in the production environment allowed the
purchasing of limited amounts of product licensing, easing management headaches. It was
intended to run two separate instances of this, to mimic what was currently in the production
environment. Active Directory with a limited number of users was deployed and the desktop
computers had joined the test domain to replicate domain level activity such as accessing file
shares. Another instance of Server 2008 R2 had replicated a web server with a database backend
and a web application. This was intended to show what Business X's current outward facing web
server had looked like.
Deployment of Suricata
The second phase was the deployment of Suricata in the virtualized environment. The
steps to do this had mimicked exactly what was to be done in the production network. The
greatest importance was placed here, as these steps would be needed to be reproduced to ensure
that there were no issues once the switch from testing to production had taken place.
Deployment had consisted of setting up an instance of Ubuntu Desktop and ensuring that
all necessary dependent packages and libraries were in place. This was to be done using apt-get
to ensure that requirements were met. Ubuntu Desktop was chosen in order to allow the greatest
number of administrators to functional fluidly on it without it being necessary to know all the
required command line functions. The GUI interface would also make sure that the management
of Suricata was easy for all to use.
After full installation, patching, and updating was completed, a clone was done of the virtual
server. This was to allow the ability to recover if the next step of installing Suricata had hit any
bumps along the installation path.

After initial installation, Suricata was to be downloaded and installed, making sure that
no dependencies were missed and installation was smooth with no errors. If errors had appeared,
the server was to be deleted and recovered from the clone. This was to be sure that the process is
done correctly and had no broken packages, libraries, or dependencies left behind. This also
eased early management as less time was to be wasted trying to diagnose any errors that had
arise. Upon successful completion of installation, a separate clone was made, signifying another
completed step and allowing future recovery.
The final step was the downloading of rules and installing them into the correct locations.
This was to be affirmed by starting up Suricata and ensuring that the software can see the rules.
As previous, any errors were to be met by wiping the server and stepping back to the previously
done clone to minimize downtime. After successful completion of the final step of phase two, a
third clone had taken place, ensuring that a quick recovery can take place in case of emergency.
Testing
Third phase consisted of the network and IDS/IPS testing steps. This was to be simulated
using pytbull, an application specifically developed to test IDS/IPS capabilities, and also using
packeth, a network traffic simulator tool to mimic common network traffic, to ensure that
Suricata examines typical daily network usage.
Pytbull is an Intrusion Detection/Prevention System (IDS/IPS) Testing program that is
typically used for Snort and Suricata auditing. It was used to test the capabilities of the Suricata
deployment and allowed Business X to compare configuration and rule sets to validate the most
successful setup
Over 300 tests in 8 categories were used. These include the following:

 The ClientSideAttacks module used a reverse shell to provide the server with instructions
to download remote malicious files. This module gauged the IDS ability to prevent client-
side attacks.
 TestRules was the most common rule tests, as these were supposed to be detected by the
rule sets shipped with an IDS. These typically cover common misuse of computer assets.
 The BadTraffic module consisted of non-RFC compliant packets to test how packets
were being handled by the IDS.
 FragmentedPackets module was set up to send a variety of fragmented payloads that were
then sent to the server to test the ability of the IDS to recompile the packets and then
prevent attacks.
 MultipleFailedLogins tested the ability of the server to track failed logins on program or
services such as FTP or HTTPS.
 EvasionTechniques module used various evasion methods commonly used to avoid and
IDS/IPS and ensures the ability to detect them.
 ShellCodes module sent various shell codes to the server on port 21 to test the capability
of the IDS to detect and then reject shell code.
 DenialofService tested the ability of the IDS/IPS to stop DoS attempts.
Packeth is a program designed to simulate network traffic by creating packets on many
different protocols and ports. It also allowed the ability to manipulate the delay between packets,
the number of packets, and the frequency in which to send them. The purpose of this was to be to
test Suricata's ability to catch it and to log and then tune the amount of resources Suricata had
needed to function. Suricata was subjected to a stream of packets, while the security staff

monitored system resource usage to see if recommended system resources were sufficient to
handle attacks.
Documentation
The fourth phase of the project was the documentation phase. During this phase, all
previous phases had their formal documentation drafted and finalized. In addition, this was to be
an ongoing phase as new rules and procedures were added to the Suricata configuration.
Documentation is the phase of telling what was done and involves all staff and everyone
who touched the project. Project Management Officers (PMO) primarily worked in this area in
documenting all steps, goals, deliverables, and completion of each step of the way.
However, technical writing was needed to be completed as well, which delves into the
more IT side of the project, including installation process and procedures, configuration steps,
and ongoing update to rules and configuration. Responsibilities and chain of command were also
designated here, as the maintenance is continuous, along with procedures for handling incidents
and violations of the IDS policy.
Deployment
The final and fifth stage was the deployment into the production systems network. This
consisted of final testing, approval and write off, final cloning and switching the Suricata
virtualization over to the live network.
A final test with pytbull had taken place after a final update took place of the Suricata
software. This had ensured that the system when transferred to the live environment was ready to
handle the traffic that was currently in place.
Before the switch could take place, management needed to provide final approval of the
project, including understanding what the Surciata server would provide for the company. It was

up to the management to inform current users that the system was being deployed and the impact
it would have on network activities, both positive and negative. Management of each department
agreed to procedures on how to handle complaints and steps needed to address them with the IT
department.
Final cloning occurred after the final test had been completed. This step involved the
virtualization software making a copy of the system as-is in order make recover steps easier on
the IT staff. If something had occurred on the server instance, it could easily be switched off, a
copy of the clone would occur, and then be turned on, reverting any issues that had arisen during
the time it was on the live network.
Switching of the Suricata instance over to the network was just a matter of powering off
the server, making the necessary changes in the virtualization configuration and pointing it to the
live network. After booting up the server, monitoring was needed for twenty-four hours to ensure
that it is actually handling live traffic and not interfering beyond what was expected.
Project Plan and Timelines
The project deployment of Suricata IDS/IPS came in well ahead of schedule due to the
quick sign off the CIO. However, several times during installation and configuration stages the
timeline fell behind due to unanticipated updates. A decision was made by the project
management team to give these phases more consideration for future endeavors and to anticipate
more time than what is actually requested.
Deliverable or Milestone Actual Start Date Actual End Date Actual Duration
Phase 1: Virtual Setup
Inventory current virtual setup 4/1/2015 4/1/2015 1 day

The inventory of current virtual system setup was completed successfully and on
time. It was reported that current setup would be sufficient to provide all necessary resources and
support for the planned test network and Suricata setup.
Create Windows 7 clients 4/2/2015 4/7/2015 6 days
The installation of Windows 7 clients met expectations for installation process
and setup. However, installation time took one day longer than anticipated because Microsoft
had pushed out more patches than was originally anticipated, which increased installation time.
Create Ubuntu clients 4/7/2015 4/9/2015 3 days
The installation of the Ubuntu clients met no delays and was on schedule. As
there was no delays in the installation process, completion time was actually one day earlier.
Create Windows Server 2008 clients 4/10/2015 4/20/2015 10 days
The installation of the Microsoft Server 2008 R2 clients met no major issues with
the installation and setup process. However, a two day delay occurred, similar to the Windows 7
client installation issues of unanticipated patch installation delays.
Phase 2: Suricata Installation
Create Ubuntu desktop client 4/21/2015 4/21/2015 1 day
The creation of another Ubuntu client to serve the purpose a Suricata server met
no anticipated delays in the installation process, resulting in an on time completion date.
Apply all current upgrades and patches 4/22/2015 4/23/2015 2 days
Installation of all current Ubuntu, Linux, and kernel patches were completed on
time. There were not any unanticipated issues with the patching process. Anticipated time was
correct and no installation issues needed to be addressed.

Installation of Suricata 4/24/2015 4/27/2015 4 days
The installation of the Suricata IDS/IPS software did not come without a few
issues. The guide used was out of date and several new steps had to be taken in response to these
undocumented changes to the installation guide. Several packages, such as with ruby and python,
were not listed and resulted in installation failure of Suricata. After correcting these, the
installation proceeded without any other issues.
Rule download and configuration 4/28/2015 5/3/2015 6 days
The installation of the rules did not match the installation guide resulting in a one-
day delay. This was corrected by looking at the rule creator website with new installation
documentation. Basic configuration of rules, after network traffic analysis, also proceeded with
no delay.
Phase 3: Testing
Pytbull testing 5/4/2015 5/8/2015 5 days
The pytbull installation and testing proceeded with no issues. All tests were run
multiple times and failures were documented in anticipation of the configuration adjustment
stage.
Packeth testing 5/9/2015 5/11/2015 3 days
The packeth testing phase proceeded with no issues that needed to be addressed.
Multiple tests were done to match typical network traffic and as if a denial of service attack was

being done on the network. Adjustments were documented in preparation of the configuration
adjustment phase.
Configuration adjustments 5/12/2015 5/16/2015 5 days
The IT Security team meetings concerning the testing results was productive. The
meeting resulted in several changes being made to the Suricata rule sets and several rules had
their configuration changed to logging rather than blocking as they were deemed to processor
intensive while the actual exploit was highly unlikely or would not pose a large enough danger to
the network environment.
Re-test 5/17/2015 5/18/2015 2 days
As anticipated, the rule set changes provided a significant reduction in reported
incidents, allowing threats that are of true concerns to be more readily seen.
Phase 4: Documentation
PMO documentation 5/13/2015 5/17/2015 15 days
The project management documentation was completed in a timely manner in
accordance to the plans stated. Changes to timelines were reported and added to the planning
documentation. Due to the changes in dates and length of stages, document completion was
adjusted.
Manager deployment meeting 5/18/2015 5/18/2015 1 day
All current department heads participated in a day meeting in anticipation of the
Suricata deployment. The purpose of this meeting was to anticipate questions and concerns of

the new IDS/IPS system. This was to anticipate also any concern members of each department
bringing their concerns to the department heads. Issues addressed included impact of
productivity, security and privacy concerns, and general IT questions of how the system works.
IT Staff technical manual 5/19/2015 6/3/2015 16 days
The IT staff documented all changes and installation procedures for the Suricata
installation. All current rules and configurations were documented and added to the technical
manual. Sign off the final documentation took one day longer as the IT department head had a
family medical emergency.
Phase 5: Deployment
Final testing 6/4/2015 9/5/2015 2 days
The final testing phase consisted of updating Suricata rule set and running one
more time a pytbull and packeth test to see if any new threats needed to be addressed with new
rules. Several new threats were added but did not have a large enough impact or were not a
factor in the network, and therefore no new rules were applied.
Final approval from CIO 5/6/2015 5/8/2015 2 days
The CIO visited the IT security staff in anticipation to the Suricata deployment
and a pytbull demonstration was performed on request along with a packeth test. Questions and
concerns were addressed in the direction of frequency of updates. Staff informed that weekly
updates will be performed and monthly tests will be conducted as stated in the technical manual.
CIO was satisfied and signed off on project eight days earlier than anticipated.
Switch to production 5/9/2015 5/9/2015 1 day
All test network clients were shut down, and the Suricata installation received one
final cloning and backup, before it was also shutdown. Configuration changes were made to the

network card settings to match production environment settings and the Suricata server was
brought online.
Initial monitoring 5/10/2015 5/10/2015 1 day
A twenty-four hour monitoring station was put in place to address any immediate
concerns to be brought up in the first day of live deployment. A few issues were brought up users
as certain file downloads were blocked. These files were reviewed and the Suricata installation
performed as it should have as the files actually contained malicious content.
Two week review 5/11/2015 5/25/2015 13 days
A two week review of the system was participated by the Chief Information
Officer, IT security Staff, and department heads. In this meeting, reports were handed out to
demonstrate the effectiveness of the Suricata system and questions were addressed in regard to
future adjustments to address any new projects that may come up. The CIO stated that if any new
technical project were to arise they would need to address it then.
Project Development
The purpose of the project was to introduce standardized security practices for the
protection of the network and data held by Business X. This was to ensure that the
confidentiality of the data was maintained, the integrity of the data was not changed, and the
availability of that data was always there. This was done by installing an IDS/IPS with minimum
cost, to which Suricata was chosen to achieve this end goal. Overall, the project came in well
ahead of schedule, but caution should be taken in the future for the testing phases. The creation
of test clients took longer than anticipated due to unexpected patches put forth by Microsoft.

More time to the testing phase should be given to ensure that these unanticipated events do not
occur again. The IT staff did an excellent job of demonstrating the effectiveness of the product
resulting in a quick sign off by the CIO and ensuring that implementation happened earlier than
what was planned.
Problems Encountered
In the first phase of the project, anticipated times for installation of the Windows 7 and
Server 2008 R2 test clients took longer than was originally projected. Microsoft regularly pushes
updates out every Tuesday, on a day commonly known as Patch Tuesday. The IT team did not
project this into their timeline when asked about if they foresaw any unexpected delays. Several
large patches were applied to both these operating system, and while it was good for a real world
example to be given to test the IDS/IPS, delaying these patches, would have provided no
negative consequences. Another option would have been to install the patches during off hours,
which would have increased available bandwidth to the clients to speed up the download and
installation.
In phase two, during the Suricata installation, several packages were not up to date as
needed for the installation of the latest version of the IDS/IPS software. While these packages are
standard ones that are included with most version of Ubuntu Linux, they were not updated as
originally was anticipated to be done in the deliverable stage of updating all software and
dependencies before installing Suricata. It was not until the actual installation was occurring that
Suricata put forth in its logs that a dependency requirement was not met. This was partial at fault
to the guide provided by the software makers, but partially sits on the IT staff not ensuring that
the operating system patching had fully completed. After these dependencies were updated, the
Suricata installation proceeded as expected, however this led to a two day delay.

The rule set installation also encountered issues due to a failure of the software developer
to update their guide. As the rule set was a third party software, this installation issue was
resolved by consulting that third party vendor's website, but also resulted in a delay of one day in
the configuration step.
Creation of the IT technical manual proceeded as normal but a short one-day delay was
resulted of an unexpected family medical emergency of the manager's family, resulting in a delay
of the review and sign off of the manual, however this did not affect the overall timeline as it was
on schedule despite the delay.
Unanticipated Requirements
During phase two of the installation of Suricata it was requested that a GUI (Graphical
User Interface) be provided for the purpose of management by those less technically inclined.
The CIO and the IT staff manager placed the request. The reason given was to ensure that
management and reports could be maintained if IT security staff was unavailable for any given
reason. This request was brought before the IT security team and the project management staff
who determined that a one-week delay would be the result of implementing this request. A
compromise was reached that the dependencies to install a GUI would be installed as providing a
framework to base installation on later. The installation of the GUI was determined to be not
critical to the project but would be implemented later, on a non-project basis but as an upgrade to
the IDS/IPS system to be taken as part of a daily operation.
Reasons for Change
Most of the changes to the original planned laid out were of a positive nature. Anticipated
time needed for several goals were completed earlier than originally planned. For example, the
early sign off by the CIO was largely due to the IT security staff provided a well put together

presentation and demonstration of the capabilities of the Suricata IDS/IPS. All deliverables were
kept with none needing to be removed.
Actual and Potential Effects
By implementing a middle ground processing unit such as the Suricata IDS/IPS, there
was several anticipated effects. The first being an increase in latency due primarily to all traffic
being routed through the IDS/IPS, each packet opened and examined, before encoding and
sending the packet on. This latency also increases as more connections are made. Many
applications actually use multiple requests, for example, opening a web browser page may make
several connections for pictures from one server, data from another, advertisement coming from
another server, times this by hundreds of users, the increase of IDS/IPS server load increases
data connection times. Most users did not see any severely negative impact except during early
morning, as all users came online and began their work at roughly the same time. Typical
webpage load time on the network before the Suricata implementation was on average 3 to 5
seconds, and after the installation, a 4 to 6 second delay was observed. This was anticipated and
was addressed at management deployment meeting and department heads were assured that the
delay was negligible and was not worth being reported.
Several users also reported downloading particular files were not going through at their
request. The logs were examined and it was determined that most of the files requested failed
due to successful rules implementation blocking malicious software. Two users were discovered
to have installed unauthorized games on their computers, and these were address with HR for
violating acceptable use policy of company computer assets.

Conclusion
The overall success of the project was determined by the weekly reports which displayed
a significant reduction in the amount of attacks that were actually aimed at Business X's network.
The reports showed a 30% reduction in inbound network traffic, with 90% of that reduction due
to malicious activates being blocked and reported. The remaining 10% was blocked due to
misconfiguration or misuse of Business X's computer assets. These issues were addressed and
the overall bandwidth was improved, despite the latency added to the network due to packet
inspection. Most of the management staff was glad for the increase in productivity due to
decrease in abuse of computer usage and the reduction in computer down time due to malware
and virus issues needing to be addressed by the IT support staff.
The executive staffs was pleased with the risk reduction in place with the
installation of the Suricata IDS/IPS server and were able to adjust expenses with risk
management and insurance allowing for a reduction in monthly business insurance cost.

Appendix I: Network diagram

Appendix II: Tuning Suricata
Before Suricata configuration tuning:
After Suricata configuration tuning:

References
White, J., Fitzsimmons, T., & Matthews, J. (2013). Quantitative analysis of intrusion
detection systems: Snort and Suricata. Cyber Sensing 2013.
Day, D. & Burns, B. (2011), A Performance Analysis of Snort and Suricata Network
Intrusion Detection and Prevention Engines, University of Derby
Albin, E. (2011), A COMPARATIVE ANALYSIS OF THE SNORT AND SURICATA
INTRUSION-DETECTION SYSTEMS, Naval PostGraduate School
What is pytbull? (n.d.). Retrieved June 19, 2015, from http://pytbull.sourceforge.net/
Packeth. (n.d.). Retrieved June 19, 2015, from http://packeth.sourceforge.net/

Morales-Capstone-IDS.IPS Deployment_revision1

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Morales-Capstone-IDS.IPS Deployment_revision1

Similar to Morales-Capstone-IDS.IPS Deployment_revision1 (20)

Morales-Capstone-IDS.IPS Deployment_revision1