![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.)](https://image.slidesharecdn.com/23024cc9-70d4-47ed-aa8b-6ad9e715392d-150928201856-lva1-app6891/85/On-Analyzing-a-Layered-Defense-System-6-320.jpg)
On-Analyzing-a-Layered-Defense-System
- 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
- 14. http://eprints.um.edu.my/4462/1/2012_Improving_Exposure_of_intrusion_deception_system_through_impl ementation_of_hybrid_honeypot.pdfhttp://eprints.um.edu.my/4462/1/2012_Improving_Exposure_of_intrus ion_deception_system_through_implementation_of_hybrid_honeypot.pdf http://eprints.um.edu.my/4462/1/2012_Improving_Exposure_of_intrusion_deception_system_through_impl ementation_of_hybrid_honeypot.pdf Niels, P. (n.d.). Honeyd: A Virtual Honeypot Daemon (Extended Abstract). Center for Information Technology Integration, 1-7. Retrieved February 24, 2015, from http://ftp.sjtu.edu.cn/sites/ftp.openpkg.org/sources/DST/honeyd/honeyd- eabstract.pdfhttp://ftp.sjtu.edu.cn/sites/ftp.openpkg.org/sources/DST/honeyd/honeyd-eabstract.pdf http://ftp.sjtu.edu.cn/sites/ftp.openpkg.org/sources/DST/honeyd/honeyd-eabstract.pdf Pouget,, F., Pham, V., & Dacier, M. (n.d.). Leurre.com: On the Advantages of Deploying a Large Scale Distributed Honeypot Platform. Institut Eurecom, 1-13. Retrieved February 24, 2015, from ftp://hg.mirror.ac.za/www.honeynet.org/papers/individual/ECCE_pouget_dacier_pham.pdf Even, Loras R. "Intrusion Detection FAQ: What Is a Honeypot?" SANS. N.p., 14 July 2000. Web. 14 Apr. 2015. <http://www.sans.org/security-resources/idfaq/honeypot3.php>.