CC BY
45Central Asian Research Journal For Interdisciplinary Studies (CARJIS)
ISSN (online): 2181-2454
Volume 2 | Issue 5 | May, 2022 | SJIF: 5,965 | UIF: 7,6 | ISRA: JIF 1.947 | Google Scholar |
www.carjis.org DOI: 10.24412/2181-2454-2022-5-479-486
A VIRTUAL HONEYPOT FRAMEWORK
Husniya Rustamovna Salimova
Master's degree, specialty "Information Security", Tashkent University of Information Technologies named after Muhammad al-Khwarizmi, Uzbekistan
ABSTRACT
A honeypot is a closely monitored network decoy serving several purposes: it can distract adversaries from more valuable machines on a network, provide early warning about new attack and exploitation trends, or allow in-depth examination of adversaries during and after exploitation of a honeypot. Deploying a physical honeypot is often time intensive and expensive as different operating systems require specialized hardware and every honeypot requires its own physical system. This paper presents Honeyd, a framework for virtual honeypots that simulates virtual computer systems at the network level. The simulated computer systems appear to run on unallocated network addresses. To deceive network fingerprinting tools, Honeyd simulates the networking stack of different operating systems and can provide arbitrary routing topologies and services for an arbitrary number of virtual systems. This paper discusses Honeyd's design and shows how the Honeyd framework helps in many areas of system security, e.g. detecting and disabling worms, distracting adversaries, or preventing the spread of spam email.
Keywords: Honeypot, honeyd, Network data, routing topology
INTRODUCTION
Internet security is increasing in importance as more and more business is conducted there. Yet, despite decades of research and experience, we are still unable to make secure computer systems or even measure their security. As a result, exploitation of newly discovered vulnerabilities often catches us by surprise. Exploit automation and massive global scanning for vulnerabilities enable adversaries to compromise computer systems shortly after vulnerabilities become known. *This research was conducted by the author while at the Center for Information Technology Integration of the University of Michigan. One way to get early warnings of new vulnerabilities is to install and monitor computer systems on a network that we expect to be broken into. Every attempt to contact these systems via the network is suspect. We call such a system a honeypot. If a honeypot is compromised, we study the
Central Asian Research Journal For Interdisciplinary Studies (CARJIS)
ISSN (online): 2181-2454 Volume 2 | Issue 5 | May, 2022 | SJIF: 5,965 | UIF: 7,6 | ISRA: JIF 1.947 | Google Scholar |
www.carjis.org DOI: 10.24412/2181-2454-2022-5-479-486
vulnerability that was used to compromise it. A honeypot may run any operating system and any number of services. The configured services determine the vectors an adversary may choose to compromise the system. A physical honeypot is a real machine with its own IP address. A virtual honeypot is a simulated machine with modeled behaviors, one of which is the ability to respond to network traffic. Multiple virtual honeypots can be simulated on a single system. Virtual honeypots are attractive because they requirer fewer computer systems, which reduces maintenance costs. Using virtual honeypots, it is possible to populate a network with hosts running numerous operating systems. To convince adversaries that a virtual honeypot is running a given operating system, we need to simulate the TCP/IP stack of the target operating system carefully, in order to deceive TCP/IP stack fingerprinting tools like Xprobe or Nmap. This paper describes the design and implementation of Honeyd, a framework for virtual honeypots that simulates computer systems at the network level. Honeyd supports the IP protocol suites and responds to network requests for its virtual honeypots according to the services that are configured for each virtual honeypot. When sending a response packet, Honeyd's personality engine makes it match the network behavior of the configured operating system personality. To simulate real networks, Honeyd creates virtual networks that consist of arbitrary routing topologies with configurable link characteristics such as latency and packet loss. When networking mapping tools like traceroute are used to probe the virtual network, they discover only the topologies simulated by Honeyd. Our performance evaluation of Honeyd shows that a 1.1 GHz Pentium III can support 30 MBit/s aggregate bandwidth and that it can sustain over two thousand TCP transactions per second. The experimental evaluation of Honeyd verifies that fingerprinting tools are deceived by the simulated systems and shows that our virtual network topologies seem realistic to network mapping tools. To demonstrate the power of the Honeyd framework, we show how it can be used in many areas of system security. For example, Honeyd can help with detecting and disabling worms, distracting adversaries, or preventing the spread of spam email.
First of all, honeypot forensics is used to study and understand a hacker strategy and his tools but not to prosecute him. This science is very time consuming and according to honeynet project members, one hour of hacker activity can lead to more than 40h of forensic work. The suggested approach is to work on a copy of the original victim, that way the analysis process can be repeated from the beginning without losing any important data. Forensic in computer science require a perfect
Central Asian Research Journal For Interdisciplinary Studies (CARJIS)
ISSN (online): 2181-2454 Volume 2 | Issue 5 | May, 2022 | SJIF: 5,965 | UIF: 7,6 | ISRA: JIF 1.947 | Google Scholar |
www.carjis.org DOI: 10.24412/2181-2454-2022-5-479-486
knowledge of hacker techniques as well as how different software works in general. Forensic science is to find evidences to make researches on it and trying to find some details and answers from it. The forensic science branch that we are interested in our thesis is computer forensics which is the same definition of forensic science but this time electronic devices are involved with our researches. The necessary data is obtained from the devices, and forensic investigators make deeper examination on them. There are several roles and responsibilities for forensic investigation. Forensic investigation is done with first responders, investigators, technicians, evidence custodians, forensic examiners and forensic analysts. (Kipper G., (2007)). The different honeypots we studied offered us several log files that a forensic party can analyze. The most common file to study when we talk about network security is the .pcap file that most honeypots are generating. This file contains all the packets exchanged between the attacker and its target. It can be opened with Wireshark and allow the forensic to see what communication happened. This file can be huge in size but contains very important information. The difficulty here is to sort the relevant information. In the case of a honeypot, we assume that all traffic is suspicious thus any IP address not within our network must be analyzed. This make the sorting easier than on a production network where the attack is harder to detect. Another part of the forensic work is called reverse engineering. When a hacker successfully compromises a system, he will most likely upload one or more malware. Reverse engineering take a closer look at these malware by decompiling it and trying to understand what are their purposes and how they work. Again this technique is very time consuming but can allow the forensics team to identify new threats. Honeypot system In the computer network is very important for network security, especially related to applications involving various interests, there will be many things that can disrupt the stability of the computer network connection, whether related to hardware (physical security, power resources) and related to software (System, configuration, access system, etc.). Disruption of the system can occur due to accidental factors performed by the manager (human error), but not least also caused by a third party. Disturbances can include destruction, infiltration, theft of access rights, misuse of data or systems, to criminal acts through computer network applications. Security of the system should be done before the system is enabled. The use of the system should be done before the actual system is enabled.
Central Asian Research Journal For Interdisciplinary Studies (CARJIS)
ISSN (online): 2181-2454
Volume 2 | Issue 5 | May, 2022 | SJIF: 5,965 | UIF: 7,6 | ISRA: JIF 1.947 | Google Scholar |
www.carjis.org DOI: 10.24412/2181-2454-2022-5-479-486
MATERIALS
Honeypots do not face the problem of resource exhaustion unlike other security mechanisms. This is so because they capture data directed to them only. Thereby, less money needs to be spent on hardware for installing Honeypots. They are much cheaper as they do not require current technologies, RAM with huge capacity or disk drives.
METHODS
Honeypot can literally be a computer which can act as a source for attacks. It attracts the hackers to try hacking it which in turn may log the techniques used by the attackers. This log is useful to prevent such attacks to the legitimate network. Honeypot computer usually do not have any important data or information to be secured. It only has fake services running on its ports to attract the attackers.
RESULTS
Honeyd simulates arbitrary virtual routing topologies to deceive adversaries and network mapping tools. This goal is different from NS-based simulators which try to faithfully reproduce network behavior in order to understand it. We simulate just enough to deceive adversaries. When simulating routing topologies, it is not possible to employ Proxy ARP to direct the packets to the Honeyd host. Instead, we need to configure routers to delegate network address space to our host. Normally, the virtual routing topology is a tree rooted where packets enter the virtual routing topology. Each interior node of the tree represents a router and each edge a link that contains latency and packet loss characteristics. Terminal nodes of the tree correspond to networks. The framework supports multiple entry points that can exit in parallel. An entry router is chosen by the network space for which it is responsible. To simulate an asymmetric network topology, we consult the routing tables when a packet enters the framework and again when it leaves the framework; see Figure 2. In this case, the network topology resembles a directed acyclic graph1 . When the framework receives a packet, it finds the correct entry routing tree and traverses it, starting at the root until it finds a node that contains the destination IP address of the packet. Packet loss and latency of all edges on the path are accumulated to determine if the packet is dropped and how long its delivery should be delayed. The framework also decrements the time to live (TTL) field of the packet for each traversed router. If the TTL reaches zero, the framework sends an ICMP time exceeded message with the
Central Asian Research Journal For Interdisciplinary Studies (CARJIS)
ISSN (online): 2181-2454 Volume 2 | Issue 5 | May, 2022 | SJIF: 5,965 | UIF: 7,6 | ISRA: JIF 1.947 | Google Scholar |
www.carjis.org DOI: 10.24412/2181-2454-2022-5-479-486
source IP address of the router that causes the TTL to reach zero. For network simulations, it is possible to integrate real systems into the virtual routing topology. When the framework receives a packet for a real system, it traverses the topology until it finds a virtual router that is directly responsible for the network space that the real machine belongs to. The framework sends an ARP request if necessary to discover the hardware address of the system, then encapsulates the packet in an Ethernet frame. Similarly, the framework responds with ARP replies from the corresponding virtual router when the real system sends ARP requests.
We studied all level of interaction honeypots and configured them. As first level of interaction honeypot, we deployed Honeyd. We explained the logic behind it and installed it correctly. Our findings about Honeyd are; Honeyd is the most popular low interaction honeypot but its problem is its age. The project is opensource but part of it is outdated and nobody seems to upgrade it. On the other hand hacker tools are evolving, so identifying this honeypot is not hard. Honeyd is using an old version on Nmap fingerprint to create fake virtual operating systems so by using a newer version of Nmap, the fake operating systems will not be recognized and Nmap will detect that there is a problem. Another limitation of Honeyd is the scripts bound to the different ports. With a basic scan it is possible to find which ports are open but as soon as the attacker tries to actually connect on a port, he will realize the service is fake. For example the script used for a Web server, by connecting it using telnet, thew server should send back replies but nothing is happening. Another problem is one cannot understand if there is an incoming attack to the system or not. Because there is no such alarm system that can make you understand that there is an attack. Information gathering is not very smart either. As a result the hacker can understand quickly that there is something wrong with the target and will abort his attack. Even unprofessional intruders can compromise the honeypot without spending too much time on it. Because it is very popular and easy to use well known techniques such as Nmap. There is no additional approach needed for it. Our second step was to configure medium level interaction honeypot Nepenthes. We explained how it works and how we studied on it in implementation part. However, we found some problems with Nepenthes too. First of all, Nepenthes is for capturing malware over internet. It is mostly used for this aim. Thus, it must be implemented very rapidly since threats for users over internet are increasing dramatically day by day. Nepenthes could not keep up with new threats. As new threats are arriving and Nepenthes is not up to date, it will not be able to capture malware. Another problem comes from the shellcode.
Central Asian Research Journal For Interdisciplinary Studies (CARJIS)
ISSN (online): 2181-2454
Volume 2 | Issue 5 | May, 2022 | SJIF: 5,965 | UIF: 7,6 | ISRA: JIF 1.947 | Google Scholar |
www.carjis.org DOI: 10.24412/2181-2454-2022-5-479-486
Shellcode manager should consider about shellcode and understand it. As new threats cannot be captured, new exploits cannot be captured either. Furthermore, as we are investigating the problems and security flaws in our experiment, there is an important security flaw in Nepenthes structure. Nepenthes do not have transport layer security. Transport layer security is a protocol that gives security for communications throughout the internet. We think it is a real problem for honeypot deployment.
CONCLUSION
Honeyd is a framework for creating virtual honeypots. Honeyd mimics the network stack behavior of operating systems to deceive fingerprinting tools like Nmap and Xprobe. We gave an overview of Honeyd's design and architecture and showed how Honeyd's personality engine can modify packets to match the fingerprints of other operating systems and how it is possible to create arbitrary virtual routing topologies. Our performance measurements showed that a single 1.1 GHz Pentium III can simulate thousands of virtual honeypots with an aggregate bandwidths of over 30 MBit/s and that it can sustain over two thousand TCP transactions per second. Our experimental evaluation showed that Honeyd is effective in creating virtual routing topologies and successfully fools fingerprinting tools. We showed how the Honeyd framework can be deployed to help in different areas of system security, e.g., worm detection, worm countermeasures, or spam prevention. Honeyd is freely available as source code and can be downloaded from http://www.citi.umich.edu/ u/provos/honeyd/.
At the time of this est the author get the conclusion that the honeypot and firewall can cooperate in restraining the incident that occurred so the attacker can't enter easily because the attacker into the trap honeypot that has been made, so the server can work safely, and honeypot is successful in Detects suspicious activity and captures the attacker's IP and is stored in a separate folder on the server trap honeypot.
Like all technologies, honeypots have their drawbacks, the greatest one being their limited field of view. Honeypots capture only activity that's directed against them and will miss attacks against other systems.
For that reason, security experts don't recommend that these systems replace existing security technologies. Instead, they see honeypots as a complementary technology to network- and host-based intrusion protection.
The advantages that honeypots bring to intrusion-protection solutions are hard
Central Asian Research Journal For Interdisciplinary Studies (CARJIS)
ISSN (online): 2181-2454 Volume 2 | Issue 5 | May, 2022 | SJIF: 5,965 | UIF: 7,6 | ISRA: JIF 1.947 | Google Scholar |
www.carjis.org DOI: 10.24412/2181-2454-2022-5-479-486
to ignore, especially now as production honeypots are beginning to be deployed. In time, as deployments proliferate, honeypots could become an essential ingredient in an enterprise-level security operation.
REFERENCES
[1] Ofir Arkin and Fyodor Yarochkin. Xprobe v2.0: A "Fuzzy" Approach to Remote Active Operating System Fingerprinting. www.xprobe2.org, August 2002.
[2] Steven M. Bellovin. Security problems in the TCP/IP protocol suite. Computer Communications Review, 19:2:32-48, 1989.
[3] Smoot Carl-Mitchell and John S. Quarterman. Using ARP to Implement Transparent Subnet Gateways. RFC 1027, October 1987.
[4] CERT. Cert advisory ca-2001-26 nimda worm. www.cert.org/advisories/CA-2001-26.html, September 2001.
[5] CERT. Cert advisory ca-2003-20 w32/blaster worm. www.cert.org/advisories/CA-2003-20.html, August 2003.
[6] Fred Cohen. The Deception Toolkit. http://all. net/dtk.html, March 1998. Viewed on May 12th, 2004.
[7] George W. Dunlap, Samuel T. King, Sukru Cinar, Murtaza Basrai, and Peter M. Chen. ReVirt: Enabling Intrusion Analysis through Virtual-Machine Logging and Replay. In Proceedings of the 2002 Symposium on Operating Systems Design and Implementation, December 2002.
[8] Kevin Fall. Network Emulation in the VINT/NS Simulator. In Proceedings of the fourth IEEE Symposium on Computers and Communications, July 1999.
[9] Fyodor. Remote OS Detection via TCP/IP Stack Fingerprinting. www.nmap.org/nmap/ nmap-fingerprinting-article.html, October 1998.
[10] S. Glassman. A Caching Relay for the World Wide Web. In Proceedings of the First International World Wide Web Conference, pages 69-76, May 1994.
[11] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing Encapsulation (GRE). RFC 1701, October 1994.
[12] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing Encapsulation over IPv4 networks. RFC 1702, October 1994.
[13] Herbert W. Hethcote. The Mathematics of Infectious Diseases. SIAM Review, 42(4):599-653, 2000.
[14] C. Kreibich and J. Crowcroft. Automated NIDS Signature Generation using Honeypots. Poster paper, ACM SIGCOMM 2003, August 2003.
Central Asian Research Journal For Interdisciplinary Studies (CARJIS)
ISSN (online): 2181-2454 Volume 2 | Issue 5 | May, 2022 | SJIF: 5,965 | UIF: 7,6 | ISRA: JIF 1.947 | Google Scholar |
www.carjis.org DOI: 10.24412/2181-2454-2022-5-479-486
[15] D. Moore, C. Shannon, and J. Brown. Code-Red: A Case Study on The Spread and Victims of an Internet Worm. In Proceedings of the 2nd ACM Internet Measurement Workshop, pages 273-284. ACM Press, November 2002.
[16] David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford, and Nicholas Weaver. Inside the Slammer Worm. IEEE Security and Privacy, 1(4):33-39, July 2003.
[17] David Moore, Colleen Shannon, Geoffrey Voelker, and Stefan Savage. Internet Quarantine: Requirements for Containing Self-Propagating Code. In Proceedings of the 2003 IEEE Infocom Conference, April 2003.
[18] Laurent Oudot. Fighting worms with honeypots: honeyd vs msblast.exe. lists.insecure.org/ lists/honeypots/2003/Jul-Sep/0071.html, August 2003. Honeypots mailinglist.
[19] Vern Paxson. Bro: A System for Detecting Network Intruders in Real-Time. In Proceedings of the 7th USENIX Security Symposium, January 1998.
[20] Jon Postel. Transmission Control Protocol. RFC 793, September 1981.
