1. On Analyzing a Layered Defense System
Andrew Anderson
Caine Copsey II
Alexandra Hidalgo
Florida State University
Florida State University
Florida State University
aja12d@my.fsu.edu
ccc10@my.fsu.edu
ah11aa@my.fsu.edu
Marquel Nakashima
Sarah Rudd
Florida State University
Florida State University
mnn09c@my.fsu.edu
snr11@my.fsu.edu
Abstract
The following research will cover the purpose of a layered defense system in a
controlled environment, and analyze its benefits within a modern information system.
This paper includes information on the network’s firewalls and their limitations.
Though firewalls provide resistance to attackers, hackers are always developing new
methods of maliciously accessing secure systems. This paper will discuss and examine
the importance of penetration ‘pen’ testing when securing a network. The experiment
was conducted within a virtual lab, in order to present an adequate control
environment. Within the virtual setting, honeypots, pfsense firewall, and other forms of
security were used in conjunction with each other to form the foundation of the layered
defense model. In order to better secure the system, an intrusion detection system was
installed within the network, as part of the layered defense suite. The team will be
utilizing various tools within the Kali Linux operating system to simulate malicious
users. This research will then analyze the vulnerabilities within the defensive systems,
and provide appropriate responses for potential threats.
Keywords: Security, analysis, cyber security, hacking, penetration testing, Kali Linux, intrusion detection
systems, graphic user interface, virtual machines
Introduction
All information systems contain valuable information that needs to be secured under lock and key. If a
company’s file system was left wide open on an unprotected network, attackers and unauthorized personnel
could gain access to confidential information that could devastate a company’s private assets such as
patents, blueprints, secret documents and more. With more people gaining access to the Internet and with
more companies transitioning from paper to digital, we need to develop secure infrastructures to protect
ourselves from attacks. In other words, information technology administrators must have the ability to
protect the information system. Recognizing this inherent need of securing one’s assets, Plan C was given
access to a virtual machine with the authorization to manage it. By utilizing software to ensure our servers
confidentiality, integrity, and availability, the team worked to make our server an impenetrable fortress. In
order to maintain the server’s strength in defense, the team noted the importance of setting up a layered
defense for the system, as well as executing penetration tests.
A layered defense system is one that has multiple means of defending itself from internal and external
attacks by utilizing firewalls, encrypted passwords, secured ports, hiding the server’s IP address and more.
In further sections, the paper discusses the software used to secure our servers from multiple threats, as well
as the significance of essential programs that keep our server safely protected from potential attackers.
Alternatively, not all defenses are perfect especially if they can’t be tested out in a practical setting. The
most practical execution to prove the security of a server is to attempt to attack hence an experimental
2. penetration test is required. A penetration test goes above and beyond finding vulnerabilities. What
penetration testing does is show you if you can hack into your own server and break the defenses set up.
Penetration testing is a method of discovering vulnerabilities within the information system. The
significance of this practice is that it shows administrators how weak their security is, and lets them figure
out what they can do to patch vulnerabilities in the system. For example, the team focused on the threat of
traffic overflow. If all your firewalls on your server are up and you are hiding all server components behind
software like pfSense, then if an attacker with a network of zombie bots floods the network the entire server
will go down because all the incoming traffic is being pushed through one channel. Alternatively, the team
analyzed the potential vulnerability of using a honey pot or software that attempts to lure hackers with open
ports and lure them away from the actual server.
Additionally, the paper will cover the steps taken to secure our server as well as testing done to attack our
own server to see how vulnerable it may be. Moreover, the team focuses on explaining our approach
towards the experimental penetration testing and how our steps can be reciprocated in a real world
environment. As hackers get craftier in devising alternative methods in compromising company data and
availability of services, network administrators and management must focus on maintaining and testing the
security of their own firewalls and security software.
Literature Review
Reviewing Literature: What is a honeypot? Introduction to Intrusion Detection with honeypots
Before we go into explaining our methodology for utilizing HoneyBot, we must first explore what a
honeypot is. To investigate this concept, we utilized the articles “Honeypot Security,” “Honeyd: A Virtual
honeypot Daemon,” “Leurre.com: On the Advantages of Deploying a Large Scale Distributed honeypot
Platform,” “Improving Exposure of Intrusion Deception System through Implementation of Hybrid
honeypot,” “A Guide to Different Kinds of honeypots,” and “Hands in the honeypot.” Despite having a
name reminiscent of Winnie the Poo, a honeypot is serious extra line of defense utilized to further harden
networks. A honeypot is designed to work in tandem with an IDS, or Intrusion Detection System. The
purpose behind honeypots is that they are supposed to attract malicious users to enter the machine they are
installed in. Just like Winnie the Poo did anything in his power to get to the source of the honey, malicious
users are supposed to think their target lies within the honeypot. Thus, honeypots are supposed to look like
they contain sensitive information. In reality, at its most basic level, honeypots work with an IDS to
observe and log information on any suspicious activity that may be occurring. The IDS has separate rules
that allow it to respond the traffic that is logged. Commonly, an IDS can also send alerts to the security
analyst as well as react defensively to the traffic that the honeypot logs. Honeypots can log packet data and
can even track the malicious user’s keystrokes. They often send alerts to somewhere else on the network.
Thus, they are supposed to be an extra line of defense in the event that a malicious user somehow breaches
the main firewall (Pouget, Dacier, & Pham, n.d.).
Reviewing Literature: Kali Linux and The Network Scanner
The official Kali Linux tools page describes Nmap or Network Mapper as a useful tool to explore a
network. Essentially, Nmap allows users to fingerprint remote operating systems, find open ports and
basically give a “pen-tester” flexibility. What was realized, learning more about the tools of Kali is that not
every tool is specifically designed to attack. Nmap allows a user to check their ports and close then
accordingly or change firewall settings per port. Alternatively, Nmap is an awesome tool for knowing your
network and seeing where its weaknesses are. By looking through a network a user can analyze the parts
that need protection. “Kali Linux – Assuring Security By Penetration Testing” emphasizes the need for
novice security professionals to understand networks and encourage the use of Nmap for defensive
3. purposes. However there is more to this network scanner than meets the eye. The Nmap scripting engine
builds incredible depth to Nmap. Therefore Nmap isn’t just a network detection tool; it’s also effective
when a user writes scripts or uses scripts within the package. A certain script allows a user to perform
fuzzing to a target system. Alternatively, a user can also use the safe script and attempt to ‘DoS’ a target or
if a user wants to be thorough he/ or she can use ‘vuln’ to check for security vulnerabilities on the target
system. Of course there are other programs to utilize on Kali Linux other than Nmap, however, Nmap is a
good place to start when practicing penetration testing. Nmap allowed the group to get used to the type of
environment that information security professionals are familiar with. (Allen, L. and Heriyanto, T. and Ali,
S., 2014)
Reviewing Literature: What is pfSense?
PfSense is a firewall that is utilized within the lab environment. One of the many functionalities of pfSense
is the ability to control and audit traffic on multiple layers of the OSI model. Primarily, identifying
malicious traffic on the application layer, which can be inconspicuously sent through a network through use
of dynamic ports, spoofing, and other vulnerabilities. The University of Minho, Department of Informatics
developed this research paper to explore the various uses of pfSense within filtering layer 7 traffic. By
using pfSense, and managing the application layer traffic, the firewall can simulate a stateful packet
inspector. This includes logging the traffic of different ports, and controlling the extent in which certain
applications can access your network. The flexibility of pfSense makes it ideal to perform this function, and
is only limited by the administrator’s ability to configure pfSense.
There is a long list of functions that pfSense can perform, including VPNs, projected DHCP services, and
even as a secure Wireless Access Point. PfSense can be used to prioritize certain forms of traffic over
others, and do this function securely by hiding the mechanism that performs this, creating a dummy
channel to prevent an attacker from accessing the configuration of QoS (Quality of Service).
The versatility of pfSense allows it to perform multiple functions with the network, including analysis for
traffic data. To test the verifiability of each pfSense function, Amity University performed an experiment to
test multiple forms of scanners, among multiple platforms with different protocols on pfSense. This
experiment pushes pfSense to its limits, testing the limits of the network security infrastructure. By
analyzing the way that pfSense secures the network perimeter, we have a better understanding of how it
will interact with potential vulnerabilities.
Firewall Technology
Firewalls are intended to protect a network from any malicious users and associated untrusted networks. To
do so, firewalls must filter traffic. This traffic is filtered in accordance to firewall rules. These rules
examine packets that attempt to pass through it and determine if the packet is admitted through to the rest
of the network. Firewall rules compare each packet that attempts to pass through with each rule until it
decides if it matches the rules or not. If a packet does not satisfy at least one of the rules, it is dropped. The
most common firewall to fit this description is a network firewall. These are firewalls that aim to protect an
entire network and encompass the entirety of an information system. In this lab, Plan C utilized pfSense,
UFW, and the Comodo firewalls.
However, there is more than one type of firewall. Personal firewalls operate in a little bit different fashion.
Instead of existing to harden and protect the entire network, they are installed onto a single device. They
4. often consist of a program that offers services such as anti-virus capabilities. An operating system is
typically required before installation of a personal firewall. Instead of protecting an entire network, a
personal firewall aims to protect a single user’s system. They protect their user’s individual system from
what they perceive to be malicious packets by performing host packet filtering. This can include, but is not
limited to, a laptop of cellular phone. In many cases, this personal firewall is the only line of security for a
mobile phone device.
While it may seem redundant to have multiple firewalls, it is actually an important feature. Personal
firewalls allow an extra layered defense against malicious packets that may slip through the main network
firewall. Plan C utilized Comodo and UFW on their individual Window’s 7 and Linux machines as their
personal firewalls. The main network firewall was pfSense.
Lab Firewall Technology: Comodo and UFW
Comodo is a personal firewall for Windows 7. It offers a customizable rule set with a graphical interface
for an easy user experience. It also offers behavior blocking and threat analysis scanning capabilities. It
provides virus protection and anti-phishing protection as well. UFW, or the Uncomplicated Firewall, was
utilized by the group in order to create a layered firewall defense system. UFW is a Linux based personal
firewall that allows the user to configure firewall rules for that machine. It utilizes a command-line
interface. Unlike Comodo, UFW is more customizable and offers more flexibility and freedom in designing
its firewall rules. It provides a kernel log and allows the user to create a ruleset as in depth as desired down
to various subnet capabilities. Each member of Plan C put Comodo and UFW on their respective Windows
7 and Linux machines.
Lab Firewall Technology: PfSense
The firewall being used in this exercise is called pfSense. This software is remarkably versatile in that it
can be deployed in almost every network environment regardless of type or size. The inventors of pfSense
based the name on the basic function of a firewall: packet filtering. It is being used as perimeter firewall
with the external network on the WAN (Wide Area Network) side; the internal configured network lies in
the LAN (Local Area Network) side with rules written having maximum-security goals in mind. When
configuring the firewall, the WAN was set up using DHCP with a host address found with pfSense’s shell
command line. The LAN, being the private network, was configured using private, static IP addresses. The
virtual machines lie within the network on the LAN side and use the private IP address scheme inside the
network. These private IP addresses ideally should never be seen, since all outgoing traffic travels outside
the network with the WAN’s IP address. On the outside of the network, the WAN receives all requests
from the exterior of the firewall. The WAN accepts connection requests from the Internet and outside
sources to be routed through the firewall, and if the firewall permits, into the LAN.
PfSense runs on FreeBSD, a free general-purpose operating system similar to UNIX and is therefore,
compatible with all hardware supported by FreeBSD. FreeBSD has a reputation for being secure and
reliable. The pfSense firewall, partially because of its underlying software, is incredibly stable ensuring
availability to the users. Though Intel Pro/100 is recommended, almost all network interface cards are
supported by pfSense. Another reason for its efficiency is that pfSense only requires 128MB of RAM and
100 MHz of CPU so it can run smoothly on any modern machine.
Best Practice Strategy: pfSense
The inventors of pfSense have a best practice strategy that both the firewall and the user can follow. The
firewall rules are based on a default deny strategy. This means they permit only what is absolutely required.
A few tips to keep in mind when configuring firewall; keep a short rule set, review the rules before
implementation, backup and document your progress, and utilize the logs. By default settings, pfSense
5. enables logging but rules can be set to only log specific, important passing traffic. Log noise, referring to a
large amount of incoming traffic logs, should be reduced wherever possible. The ability to control the logs
displayed decreases log noise so the user can view logs of interest. PfSense, like most firewalls, logs only
dropped traffic rather than passing traffic by default. This is done to automatically reduce some log noise
for the user. Viewing all passing traffic is excessive and could prevent the user from properly analyzing
their network traffic. It is important to keep track of logs in case of unusual trends in traffic. This can
indicate abnormalities in the network.
Firewall Rules
Making firewall rules involves a dynamic methodology tailored to the network’s purpose. When making
rules, the order of the rules are important, as it is the order in which the firewall will read them. Typically,
the administrators will want to make rules allowing traffic before making rules rejecting or blocking traffic.
PfSense has a few default firewall rules that are already in place when pfSense is installed. The anti-lockout
rule is in case an administrator is ever locked out of their pfSense environment. While the anti-lockout rule
is useful, the purpose of this exercise is defense security, so in this case it is a threat that must be removed
to secure the network. The firewall includes an anti-spoofing feature, and a rule that blocks all private
networks on the WAN interface. In addition to these is the “Block Bogon Networks” rule, which is a
different type of anti-spoofing. Bogon networks are reserved and unassigned IP addresses on the Internet
that try to pass as source IP’s. The firewall blocks these using a known, and consistently updated list of
bogon networks. Under the best practice rules for pfSense firewall, all requests unspecified by rules are, by
default, denied and silently blocked by the firewall. The interface allows for some rules to remain inactive
if needed, without having to delete the rule from the entire rule set. Because of the default deny practice, all
traffic to and from the WAN and LAN must be expressed in the rule set. PfSense only filters traffic from
where the traffic is initiated, so rules for both the WAN and the LAN interfaces must be carefully
configured with a working methodology strategy suitable for securing the network.
When creating firewall rules, it is vital to understand how the network actually works, and the associated
terminology. The rule being made must specify a protocol so the firewall knows what kind of traffic to
filter. The source and destination addresses for the rule may also be specified, but can be left open to any
host or port (the * symbol). PfSense is unique in that it is able to detect and filter requests by the source’s
operating system; this function works by effectively filtering out any traffic coming from a particular
operating system regardless of the host address. This kind of filtering encompasses significantly more
traffic security than a specified host IP address or port number.
PfSense also includes the ability to use aliases to group together multiple IP addresses and port numbers.
This simplifies the structure of the rule set by granting the ability to group several hosts, networks, or ports
together when deciding how the traffic will be handled. Naming conventions used with aliases can also be
utilized to simplify the rule set. PfSense offers the option to either block or reject traffic. Blocking traffic
means the firewall simply drops the packet. Because of the default deny rule, this is actually the default
action for all traffic unless rules are made to indicate otherwise. Reject only truly works with TCP/UDP
protocols due to a lack of standard with other protocol rejections. Outside of TCP/UDP, all packets are
silently dropped. However, if a reject rule was used with an incoming TCP/UDP protocol request, a
response is sent back to the denied traffic, telling the host that the connection was refused. The most
significant difference between the two is with block, the network is invisible to the system that sent the
denied request; with reject, the network sends back a response, revealing its existence. Best practice
methods would have the block action used on the WAN and the reject action used internally on the LAN.
This way, if a request is denied within the network, internal users don’t have to wait for a time-out on their
denied requests. When preventing attacks, a blocked request is much more time consuming to the attacker.
Their packets are dropped and they have to wait for the request to timeout, or simply cancel it. Rejected
requests give a swift response, which is good for internal users, but externally rejected requests give the
attacker knowledge of the private network, which could potentially lead to more attempted attacks on the
network.
6. Another interesting property of pfSense is egress filtering. Egress filtering isn’t common practice, as it is
extremely secure to the point of not being work-friendly for most enterprise networks. Alternatively, when
the goal is to try to achieve maximum security on a private network, egress filtering should be applied.
Egress filtering is filtering traffic sourced from within the network and destined to the Internet. While LAN
rules commonly get overlooked, they can be extremely useful in both preventing vulnerabilities and
lessening the severity of an attack. Egress filtering can essentially stop an attack in its tracks and render it
non-functional to the internal network. Egress is extremely restrictive and not efficient for the average user,
but when trying to thwart all attacks and prevent compromise, it is a practical and effective security
method. It can prevent sensitive information from being disclosed; prevent DDOS attacks, worms, IP
spoofing attacks, and a variety of attacks that could compromise not only the system, but also the whole
network. When attempting to achieve maximum security within a network, it is best to only allow the
traffic that is absolutely required.
Vulnerability of the Firewall: Single point of Failure
While a firewall provides a very powerful shield, protecting everything through the network by checking
all traffic that enters through the network, its strength can also be its greatest weakness. The basic
infrastructure of a firewall is that all internal network traffic must go through it, making it serve as the
default gateway and DNS for all internal devices. This structure, while defensible, also creates a single
point of failure within the network. [SH2] In network design. A single point of failure is an instance within
a network where the shutdown of a single device or interface will cause the failure of the entire network.
In small office and home office (SOHO) networks. A single point of failure is often impossible to avoid.
However in an enterprise network, single points of failure can be accounted for with redundancy. By using
redundant devices, with multiple connections between each device allows for a network where even if one
router or switch fails, the networks is still functional, even if not necessarily optimal. Since all traffic must
go through the firewall, in a condition where the firewall were to fail, the network would also fail. The
firewall can be incredibly powerful, however it creates this vulnerability through the networks reliance on
the firewall. As a firewall, pfSense has these same vulnerabilities.
Plan C proposed the installation of Comodo and UFW on their Windows 7 and Linux virtual machines in
order to combat this single point of failure vulnerability. The idea was that if the malicious packet slipped
through the first layer of defense, the network firewall, the personal firewalls would be able to catch it.
However, Team Plan C recognizes that there is still a chance that this layered defense could fail. In that
event, the vulnerability of a malicious packet failing to be properly filtered through the firewall still exists.
However, the introduction of layered firewalls greatly decreases this.
The most recent pfSense specific vulnerabilities include a vulnerability to cross-site scripting attacks on the
pfSense web interface. Due to the versatile nature of pfSense, some knowledge of access-control lists and
firewalls is required for a user to configure it. Inexperienced users may not be as well versed, and thus may
not recognize when an attacker could control a particular instance of the web interface. By manipulating
user input, or copying what the user has inputted to have a copy of the configuration, pfSense becomes not
only vulnerability, but also a liability.
There is a current update for pfSense, which reduces any potential chance of key logging or cross-site
scripting that can occur on pfSense, however the point is still valid. No matter how secure pfSense is, as
long as it acts as the default gateway for the internal network, it acts as a single point of failure. This
becomes even more of an issue the more functions that you enable within pfSense (such as: DHCP, DNS,
QoS, and VPN.)
7. Intrusion Detection with Honeypots
As explained in the literature review, honeypots are decoy systems that are created to collect information
about a malicious user. It is important to note that they are not intended to be the sole method of security.
Instead, they are created to enhance an already hardened system. They work in tandem with a firewall, an
IDS, and any other layers of security utilized to support a secure network. Honeypots are designed to work
even more closely with an IDS. The IDS provides the honeypot with the functionality to record the
behavioral patterns of a malicious user. While the IDS can technically log user behavior without the
honeypot, the honeypot serves as a safe environment for this to take place. After all, it is more desirable for
the malicious activity to take place in an environment in which the integrity of the information is not a
concern. Sometimes, a honeypot is placed outside of the network to log outside activity with the IDS and to
detract malicious users from even attempting to enter the network in the first place. For example, a
malicious user can enter a honeypot environment. Once the malicious user is in the honeypot environment,
an IDS can log the behavior of the malicious user while they interact with it. Depending on the IDS, this
can mean keylogging, packet sniffing, or a vast multitude of other behavior logging techniques. Figure A
illustrates a typical network layout utilizing honeypots:
Figure A. Honeypot Topography Example (2000)
Honeypot Usage
If desired, a user can configure multiple honeypots on a machine to create a honeynet. Each individual
honeypot can vary in type and mirror a wide variety of applications or environments found within the main
network. Honeypots can be used for research purposes or in an actual production environment. They can
be used for defense against a wide variety of malicious attack. This includes, but is not limited to, malware,
spam, and database attacks. Honeypots can be distributed on virtual or physical environments. Honeypots,
such as Honeyd, can also be utilized to actively search out malicious activity on the Internet. These
honeypots are called “client honeypots.” Client honeypots monitor their system in order to make sure that
they have not been altered by malicious activity. Client honeypots are typically located on virtual machines
with controls set to restart to a clean state if it detects that something has been altered. Before the clean
state is restored the client honeypot will send a report to SecurityOnion which will log and block the
malicious IP. Many client honeypots utilize a combination of link scoring, search engine integration,
crawling, and filtering in order to try to discover malicious servers. Some of them mine malicious links
from phishing emails (“A Guide to Different Kinds of honeypots,” n.d.). There is always a risk of further
infection on the network the client honeypot is linked to, so low-interaction client honeypots exist as well
(Mansoori, Zakaria, & Gani, 2012).
8. Types of Honeypots
There are three different types of honeypots: low-interaction and high-interaction honeypots. Low-
interaction honeypots have limited interaction with the malicious user, typically attempt to emulate
common services, and can emulate an operating system environment. Low-interaction honeypots are very
user friendly and straightforward which tend to make them easier to deploy. However, because they
provide less functionality, very experienced malicious users may be able to discover them quickly. Some
low-interaction honeypots emulate an existing application found on the network or provide a malicious user
with a false image of their target, called a facade. Once attacked, the malicious user cannot use the
honeypot to their advantage, as they are not considered real systems. However, this also makes them easier
to spot for an experienced hacker. Finally, medium-interaction honeypots are similar to high-interaction
honeypots in that they are not just facades. Both require an actual existing operating system installed on a
machine within the network. Instead of just an image of an OS or imitation of a commonly used
application, it requires a real environment. However, medium-interaction honeypots don’t contain key
applications or services that a production machine on the network would contain. High-interaction
honeypots are an almost exact replication of a production machine. Both medium and high-interaction
machines could potentially be used as a starting off point for a malicious user if an attack is not handled
appropriately. Clearly, the high-interaction machine is the most risky. However, both will ultimately
generate more detailed data on both the behavior and network traffic patterns of a malicious user. Some
users use a high-interaction honeypot, called a “sacrificial lamb,” and leave it vulnerable purposefully.
Coupled with a powerful IDS, it can effectively provide accurate behavioral patterns, such as key logger
and packet sniffing functionality. However, as stated previously, careful consideration for other network
security, such as properly configured firewall rules, must be considered or attackers can use this as a
powerful tool to observe the network and further attack the system. Both the conventional honeypot and
client honeypots could be combined to create hybrid honeypots. We will talk more about client honeypots
in the next section (“honeypot SECURITY,” 2008).
Using HoneyBot
HoneyBot, a honeypot created by Atomic Software Solutions, was utilized in our network. Plan C’s
HoneyBot is on a virtual machine. It runs on an existing machine with Windows 7 installed within the
network of Team Plan C. It is behind the pfSense firewall. As it does not contain any identifying services of
the protected Window’s 7 machines, such as each team member’s individual IIS server, it is a medium-
interaction honeypot. Thus, it provides a brief layer of social engineering functionality, as it is located on
live operating system on Plan C’s network. The IDS utilized is SecurityOnion. Onion utilizes SNORT rules
in order to log network traffic. SecurityOnion is on a separate Ubuntu machine with an additional UFW
firewall for additional security. By working with SecurityOnion, HoneyBot creates a log of packet history.
This log includes the time, direction bytes, and data of each IP packet that was recorded. HoneyBot also
allows the user to capture binaries, which will effectively save malicious malware to a separate directory.
With this functionality combined with SecurityOnion’s provided defense functionality, Plan C’s network
will be more secure. This is important, as HoneyBot is a medium-interaction honeypot within the network
of Plan C. Thus, it is already behind the pfSense firewall. If a malicious user were to theoretically get to our
HoneyBot, they would be able to utilize Internet Explorer and access any malicious site or download any
malicious content because HoneyBot is a full distribution of Window’s 7. They will have access to
information about our network. Furthermore, HoneyBot has over 6000 ports open by default. However, if a
malicious user were to utilize Plan C’s HoneyBot machine to implement an XSS or SQL Injection attack on
the network, it would be blocked by SecurityOnion. HoneyBot is configured to send alerts to
SecurityOnion. Plan C can opt to block IP addresses of perceived malicious users by either specific IP,
range, or country after analyzing this data. Thus, both tools work together to provide an additional layer of
security.
HoneyBot: Weaknesses and Solutions
9. However, HoneyBot is not perfect. As stated previously, its status as a medium-interaction level honeypot
allows malicious users to have a potential platform to gain information on the network. This platform can
be used to launch potential attacks. While Plan C plans to utilize SecurityOnion to combat these attacks
through blocking various malicious activity and monitoring network activity, there is always a possibility
of an attack that it will not block. Furthermore, HoneyBot has over 6000 ports open by default. While this
may seem great for the functionality of a HoneyBot on the surface, a careful hacker will be able to use
various scanners and see this as a red flag. Typically, a non-HoneyBot production machine on a network
does not have this many ports open (Gubbels, 2002). This theoretical careful hacker could simply choose to
ignore our HoneyBot in search of a machine target that contains the information they desire. Our
distribution of HoneyBot does not provide any tools that may hide this like other types of honeypots, such
as Honeyd, provides (Niels, n.d.). The only way Plan C can see to solve this weakness would simply to
utilize a honeypot with more functionality. Thus, HoneyBot’s major selling point is that it is a simple, easy
to use tool. However, that is also one of its greatest weaknesses.
The team decided to solve this by putting HoneyBot outside of the pfSense firewall in order to combat this
vulnerability. By doing so, we will log traffic through an IDS and be able to log the behavioral patterns of
users. Furthermore, because most of the other teams will have HoneyBot within the firewall in their
network configurations, Plan C hopes to throw the other teams off that discover the HoneyBot server. Plan
C hopes to attract the other teams to investigate the HoneyBot in order to be able to log their data and use it
to strengthen their defenses. By doing so, we will safely be able to ensure HoneyBot cannot be utilized as a
starting point for a malicious attack against our network. In its place, we will be utilizing the honeypot
Honeyd. Honeyd is a low interaction honeypot. As stated previously, it does not carry the same risk of
being utilized as a starting point for an attack. Honeyd creates an image of an operating system and
associated device and maps it to an IP address. Because these images are not actual operating systems, they
cannot be utilized to attack the network. If our Honeyd server is scanned by any of the popular Kali Linux
tools, such as nmap, it will show the malicious user information on the generated images as if they were
tangible systems. This is because Honeyd utilizes the nmap database in order to generate its honeypots.
Because we are creating multiple images through Honeyd, we are effectively creating a honeynet. This will
help to combat the vulnerabilities presented by HoneyBot.
Lab Computing Environment
Figure B. Network Topography
Using Windows 7 and implementing Internet Information Services (IIS) the team used a hyper
management virtual machine to remotely access all virtual machines that work together on our network.
There is a separate virtual machine for each part of the server that collaborates together to attack and
defend the server. Using software such as Comodo firewall, HoneyBot, Kali Linux’s Ubuntu, and Internet
Information Services, we put together a functional environment in which we experiment with assessing the
practicality of implementing defensive features, as well as executing our own penetration testing. However,
10. using the virtual machines has its issues to consider. For example, each member of the team has access
remotely (off campus) to our designated machines. But if two people from the same team attempt to log on
to the same virtual machine, the first user will be timed out to make room for the new user. This causes
confusion, and the problem lies within the amount of RAM the team’s virtual machine was allotted.
Additionally, when the virtual machines are all connected and working, it makes testing easier but still
painfully slow as users within the group may get lag from other users on the same network.
We chose to implement the HoneyBot windows honeypot service because of the services it offers in
assisting us with implementing an intrusion detection system. Because our firewall configuration may not
be completely perfect, HoneyBot will allow us time to respond to attacks by making ourselves appear
vulnerable. HoneyBot emulates a wide variety of services by listening to sockets purposefully left open.
Once the HoneyBot is attacked, HoneyBot logs the malicious intent the offender attempted to complete.
However, these open ports and utilization of an actual OS made HoneyBot a point of vulnerability.
Because HoneyBot could be used as a starting off point for an attack and was very easy to spot, Plan C
decided to move it outside of the pfSense firewall. Plan C utilized Honeybot as a decoy to track user’s
actions within it and study their behavioral patterns to block them accordingly. Plan C’s plan was to attract
the other team to HoneyBot and trick them into thinking that by accessing HoneyBot, they had successfully
penetrated our network. Plan C then planned to study their behavior in HoneyBot and log it accordingly.
Thus, over the course of a few attacks, we can use the data gathered from HoneyBot to further improve our
defense as we begin to see a pattern in how the attacks are conducted. Using that information, we can patch
up holes in our pfSense firewall, close ports we may have left open, or other matters. Furthermore, Plan C
choice to install Honeyd on some of the members’ Linux Machines. Virtual Machine 11 contained Honeyd,
which then replicated an image of extra operating systems and various devices on Plan C’s network.
Honeyd is a Linux based honeypot. It is low interaction and did not offer the same security threat of
utilizing an actual operating system on the network that could be interacted with. HoneyD's library of
available operating systems and devices that were then mapped to a free IP address on the network are
generated from nmap’s database. Thus, because Plan C knew that the other teams were utilizing Kali Linux
tools, we decided to utilize Honeyd. Plan C’s aim was to confuse the other teams into thinking that other
devices and OS were being utilized and wanted them to attempt to attack them so data could be logged
through the IDS. Plan C planned to utilize this logged data to further strengthen their network.
We chose to implement the pfSense firewall because of the features it includes as an open source firewall
compared to commercial firewalls. We also used the routing capabilities that are packaged with it. The first
feature is the firewall itself, which includes filters to help in the prevention of intrusions. The firewall
contains the given standards of filtering packets based upon their source and destination IP address. When
pfSense is fully configured and operational, we will only allow our traffic though. Additionally, the firewall
also includes the ability to log traffic that does match a rule we have implemented, meaning in the event
that an intrusion does occur, we are able to check our logs and see where the user came from and determine
how to modify our rule set to better protect us from intrusions in the future. For routing, we implement its
built-in routing functionality for the machines on our network, so that when they pass through the router,
they are also passing through our firewall. Comodo and UFW were also installed onto each member’s
Windows 7 and Linux machines for an additional layer of firewall defense.
Furthermore, members chose to install keyloggers onto their Windows 7 device. The keyloggers contained
a graphical interface that could be accessed remotely through a browser. They were set to send alerts if
certain events, such as password changes or login attempts, were attempted. All the activity that occurred
within the environment was logged and immediately displayed through the graphical interface. This
allowed the team members to be alerted if these events were triggered. The keylogger tracked the
keystrokes of all activity on the machine, which allowed for a quick diagnosis for potential attacks. It saved
time in analyzing potential problems and threats and allowed for a quick solution to all attempts made at
attacking each Windows 7 machine.
We chose to utilize Kali Linux because of the wide variety of features available when it is time for us to go
on the attack. Kali contains a great number of programs. The programs run from exploitation tools such as
Armitage to information gathering tools like Nmap. We can use the Nmap service to see how our network
11. can be mapped out. More so, in using Nmap we can gather information about the network so that when we
attempt to penetrate the system, we can plan out a method of attack. Using services such as Armitage, we
can select from a large number of exploits available to us, and use them in an attempt to gain access.
The Windows 7 machines on our network have the Internet Information Service (ISS) installed upon them
so we can host our individual websites on them. IIS includes features such as HTTP and HTTPS.
Additionally, IIS is a modular system, which allows us to pick and choose which features we desire.
Finally, IIS is incredibly simple and is easy to set up, which allowed us time to continue working on the
rest of our network.
The Comodo antivirus program was installed on our IIS servers for a few reasons. The main reason being it
was free and it is a trusted certification authority. Additionally it is a simple antivirus program that we will
be using to protect our IIS servers from malicious programs instead of leaving them completely bare and
vulnerable.
Defense-in-Depth Methodology
Shown below are the steps the group took in setting up the software on the virtual machines.
1. Log into Windows 7
2. Enable IIS within Windows 7
3. Command line input the configuration of pfSense
4. Change IP address from default to new IP address
5. Within pfSense, we set firewall rules set for the group
6. Set firewalls for Windows 7 (Comodo) and Linux (UFW) VMs
7. Configure and enable Security Onion
8. Install keyloggers onto Windows 7 Virtual Machines
9. Install and update HoneyBot (honeypot)
10. Install Honeyd into VM #11 (Linux)
11. Configured Honeyd to emulate images of OS and devices and mapped them to unused IP
addresses
12. Moved HoneyBot outside of pfSense firewall
13. Attack and test out the defense using Kali Linux
14. Append security onion accordingly
15. Use lazy kali to download all hacking tools especially hack pack
Working with the virtual machine environment the initial process involved installing and configuring the
IIS on our individual virtual machine. By enabling IIS on Windows 7 this allowed the team to set IIS
firewalls on individual machines but this alone isn’t enough protection. The team took it a step further by
editing the individual windows and Linux machines and changing the IP address from the default router on
IPV4 and moved the network behind pfSense. PfSense can be seen as the primary shield of defense. By
configuring pfSense to be moved to a modified IP address this allowed us to temporarily hide away and
protect ourselves from attacks that would utilize the default. Default IPs are easier to spot and thus are more
vulnerable. Grabbing this manually set IP and changing the network of the IPV4 on both windows and
Linux individual machines this allowed us some protection. PfSense utilizes firewall protection that had to
be manually configured by altering and setting firewall rules. These rules aid in some attacks caused by
outsiders and insiders navigating around that might because drive by downloads of malicious software. But
it still wasn’t enough. We had to go on to set more firewall rules for Comodo on both Linux and windows
systems.
Comodo works in such a way in which you search through the rules and add, edit or remove depending on
how you want your rule list to work.
12. The security Onion had to be enabled and running to make a difference in defense and detection. The
security onion setup took only a few minutes to set up but involved a series of decisions on what the team
needs in order to detect intrusions or attacks from outsiders and the virtual machines vulnerabilities. In the
initial setup process we figured that network configuration processes would have been done but advanced
settings was something that needed tailoring. An integral step in this setup process was choosing a
standalone environment since it offered both server and sensor. After inputting an email and password the
next step was to enable snorts GUI, which is a dashboard setup that allows a user to visually understand
what is going on with the systems. Hence, snort monitors activities on the machines and reports
vulnerabilities and potential attacks. So users can view reports on breaches as well as monitoring the
system and more. With the Snorby password set in place (Snorby is the application that primarily deals
with a GUI of monitoring and detection we went with the default 30 days to keep Sguil database. And the
additional 7 default days to keep data repair going. This is how the security onion functions. It houses
information, reports, scans, and alerts on intrusions. This layer is more for detection and aids in know what
the attacker is doing and how to formulate a recovery plan. And is essentially and intrusion detection
system, snort. Additionally, the team chose to keep emerging threats up on the GUI so the team can see
what they are up against and how to better counter security breaches and threats.
While keeping an eye on security onion’s IDS and feeling relatively secure we knew it was time to start
poking around the virtual machines using Kali Linux. Kali Linux is an operating system designed for
penetration testing, snooping, spoofing and essentially any possible form of hacking and spying on other
systems. To stress the danger of this system, it is important to note the system and applications simple
usability. Simply put, Kali Linux is easy to use. It’s designed for simplicity. Which is frightening for the
average user that is blind to the threats the online world has. The first thing that had been done with Kali
was to download Lazy Kali. This suite of hacking tools is its literal name. A lazy way to download all the
tools you’ll ever need to spy, creep, take over, and destroy a user’s connections, systems, applications, etc.
The first action the group decided to take was to snoop around and bypass users behind pfSense’s firewall.
Using Nmap terminal commands I could see which hosts were online, their IP addresses identify names of
the groups and more. Honestly, looking back on the nature of Kali and maintaining our layered defense
system the first thing the team should have done was to attempt to render Kali unusable. Or attack Kali so
other teams wouldn’t be able to penetrate our lines of defense.
Conclusion
By examining our system’s interface and the functionality of all defense programs used, it is important to
note that putting together a layered defense system takes a lot of patience, trial and error and most of all;
research. Through tinkering with programs like HoneyBot, Comodo, and digging deeper on the firewall
functionality within pfSense, the team has realized that it is impossible to have a fully secure network
because there will always be vulnerabilities, but it is possible to work towards mastery. By working
towards mastery we strive with bettering systems security programs and firewalls. It also makes a
significant difference to keep up with security updates and keeping secured personnel working on what
they are allowed to work. As a group, we learned that it would cause a lot of confusion to allow everyone
access to the same virtual machine, since we could either step on each other’s toes or accidentally append
something that we have no knowledge on. There is more to the defense of a system than just enabling a few
programs and letting them do all the work. It requires a well-informed team that is willing to manage key
components and assist one another to better the system. Consistent and frequent clear communication
between team members was the only way to succeed in this defensive security exercise. Additionally, a
major disturbance that caused a lot of contention with in the execution of our project was the abuse of
authority and students not following rules by abusing their privileges of using Hyper-V management. By
turning off someone’s virtual machine and by stalking who is online from the management application you
can create a huge annoyance by throwing someone off his or her virtual machine. Additionally, password
cracking was one form of hacking that was prohibited by our instructor. A certain team went ahead and
used an outside source password cracker that took all our accounts and removed the SMHO account that
belongs to our instructor. That makes it difficult for our instructor to keep tabs on our accounts and monitor
our progress; hence, the project faced impediments in a virtual network. In a controlled network, not
following the rules and ‘doing what you want’ is fine because the only thing that is on the line is your
13. grade. Had anyone deleted a virtual machine off the network this would have caused legal issues since the
virtual machine network and each individual virtual machine belongs to the Florida State University. We
learned it is imperative to set up some sort of layered defense to protect not only your files integrity but
ensure the availability and confidentiality of personal and private information.
Future Implications
This exercise has taught Plan C that no one measure of defense is secure enough to defend against all
common attacks. Best security practices involve having a layered network security configuration. It is
important to note that many of the tools that are utilized within this project have been deployed within
professional computer security production and research environments. Theoretically, if Plan C were within
an actual company, many of the steps taken within the lab environment and previously stated research
would still be relevant. The major difference is that the scope would expand to meet the needs of the
company. A larger company might want to utilize extra security elements, such as a Honeynet with
multiple types of honeypots, in order to ensure optimal security. A smaller company may not have the same
resources and could potentially provide a similar environment as presented by Plan C. Each company
would have to calculate their budgets and adjust their security needs accordingly. Plan C has presented the
basic framework of a relatively secure network that could potentially be reproduced in a real world
environment. Later on in the project, Plan C put their hardening to the test, as other teams were attempting
to penetrate the network. Plan C hopes to evolve from this experience and use it as a stepping-stone to
continue future research on the subject of layered security.
Another topic of future lessons learned, and what to consider for future would involve trustworthiness in a
virtual community. All teams were put through this stress test of understanding the network topography,
figuring our how to set up their defenses, how to attack using Kali and at the end a lot of students found it
easier to use Hyper-V management. Trust was definitely lost in other teams, friends, peers caused by a
virtual network that had turned into a community. It was four communities, four teams fighting the keep
their virtual machines alive and able to counter attacks.
Works Cited
Admin. (n.d.). A Guide to Different Kinds of Honeypots. Retrieved February 24, 2015, from
http://www.symantec.com/connect/articles/guide-different-kinds-
honeypotshttp://www.symantec.com/connect/articles/guide-different-kinds-honeypots
http://www.symantec.com/connect/articles/guide-different-kinds-honeypots
Buechler, C., & Pingle, J. (2009). PfSense: The Definitive Guide to the pfSense Open Source Firewall and
Router Distribution. Reed Media Services.
Gubbels, K. (2002). Hands in the Honeypot. SANS Institute InfoSec Reading Room, 1-17. Retrieved
February 24, 2015, from http://www.sans.org/reading-room/whitepapers/detection/hands-honeypot-
365http://www.sans.org/reading-room/whitepapers/detection/hands-honeypot-365
http://www.sans.org/reading-room/whitepapers/detection/hands-honeypot-365
HONEYPOT SECURITY. (2008). Infosec, 1-12. Retrieved February 24, 2015, from
http://www.infosec.gov.hk/english/technical/files/honeypots.pdfhttp://www.infosec.gov.hk/english/technica
l/files/honeypots.pdf
http://www.infosec.gov.hk/english/technical/files/honeypots.pdf
Horng, S., Fan, P., Chou, Y., Chang, Y., & Pan, Y. (2008). A feasible intrusion detector for recognizing IIS
attacks based on neural networks. Computers & Security, 27(3-4), 84-100.
doi:http://dx.doi.org/10.1016/j.cose.2008.04.004
Mansoori, M., Zakaria, O., & Gani, A. (2012). Improving Exposure of Intrusion Deception System through
Implementation of Hybrid Honeypot . The International Arab Journal of Information Technology, 9(5),
436-444. Retrieved February 24, 2015, from
