Just as bears are always on the lookout for sweet treats like honey, so too do hackers find them­selves drooling over the thought of an in­ad­equately protected server. While a hacker and its mammalian cousin, the bear, may not appear to have much in common, both are often equated with the image of a honeypot. In the IT world, honeypots are security mech­an­isms that ad­min­is­trat­ors use in order to bait hackers, making them run their attacks on pre­de­ter­mined decoy sites or servers, hopefully identi­fy­ing the culprits in the process. Honeypots simulate network services or ap­plic­a­tion programs in order to attract hackers and protect from system damage. Generally, both client-side and server-based tech­no­lo­gies can be used to set up honeypots.

  • Server-side hon­ey­pot­ting: the basic idea behind server-side honeypots is to isolate attackers in isolated areas of an IT system and, in the process, keep them away from critical network com­pon­ents. Fur­ther­more, honeypots offer the pos­sib­il­ity to track hackers’ actions. To this end, honeypots are able to simulate sever ap­plic­a­tions that host one or multiple services (e.g. a web server) within the targeted network. If the hacker is fooled by the dis­trac­tion and attempts to breaking into your system, the activity will draw attention to the honeypot and set off an alarm or counter measures. In the most ideal case, server honeypots deliver in­form­a­tion as to how automated or manual attacks proceed, so that ad­min­is­trat­ors receive data enabling them to defend their systems against future attacks.
  • Client-side hon­ey­pot­ting: A client-side honeypot imitates ap­plic­a­tion software that uses server services. A prime example of this tech­no­logy is the sim­u­la­tion of a browser that seeks out and visits dubious websites in order to collect in­form­a­tion on security risks. Should an attack on the browser or browser plugin result from this page, then the process is noted. An eval­u­ation of the detected data helps improve the simulated software.

Research in­sti­tutes, public au­thor­it­ies, and the military use so-called research honeypots in order to find out in­form­a­tion regarding new attack patterns and then make this in­form­a­tion pub­lic­ally available online for the benefit of the internet community. In companies, this type of security mechanism is used first and foremost to protect the company network. To this end, ad­min­is­trat­ors install so-called pro­duc­tion honeypots in network areas usually not addressed during normal op­er­a­tions, available to neither employees nor customers. The goal here is steer attackers into more harmless areas by at­tract­ing them to simulated security gaps. Every attack on these normally-inactive systems is then re­gistered, monitored, and analysed.

If multiple honeypots are combined in order to simulate an entire network, offering hackers a par­tic­u­larly at­tract­ive target, then this tactic refers to what is known as a ‘honeynet’.

How are honeypots im­ple­men­ted

There are generally two different pos­sib­il­it­ies at ad­min­is­trat­ors’ disposal for setting up honeypots: honeypots are either realised as physical systems or im­ple­men­ted on the basis of real­isa­tion software:

  • Physical honeypot: physical honeypots involve in­de­pend­ent computers that are connected to a network with their own addresses
  • Virtual honeypot: a virtual honeypot is a logical system that is assigned the physical resources of a computer through vir­tu­al­isa­tion software

In both cases, the honeypot is isolated, meaning that attackers cannot attack the pro­duct­ive system from the decoy system.

Clas­si­fy­ing honeypots

The goal of honeypots is to remain un­detec­ted. The longer an attacker can be deceived, the more in­form­a­tion the system is able to ac­cu­mu­late on their strategy and methods. An important criterion used for clas­si­fy­ing honeypots is assessing the extent of in­ter­activ­ity with the attacker. In this context, one dif­fer­en­ti­ates between server-side and client-side, as well as low-in­ter­ac­tion and high-in­ter­ac­tion honeypots.

  • Low-in­ter­ac­tion honeypots: honeypots with lower levels of in­ter­ac­tion are based on im­it­a­tions of real systems or ap­plic­a­tions. Here, services and functions are only simulated to the extent that an attack can be carried out on them
  • High-in­ter­ac­tion honeypots: honeypots with a high level of in­ter­activ­ity generally involve real systems that offer server services that must be well guarded and secured. If a high-in­ter­ac­tion honeypot is not properly protected by the pro­duc­tion system, then the system you are aiming to protect may be in­filt­rated. Another po­ten­tially hazardous pos­sib­il­ity involves attacks being launched from the protected server onto other online servers.

Low-in­ter­ac­tion server honeypot

The simplest version of server honeypots involves a single ap­plic­a­tion that emulates (i.e. rep­lic­ates) network services, including the con­nec­tion set-up. Given that those attacking this type of honeypot are only able to interact with the simulated system in a limited way, the type of in­form­a­tion that can be found out about the attackers through low-in­ter­ac­tion honeypots is re­l­at­ively limited. As such, hackers are generally able to expose these server honeypots re­l­at­ively quickly. For this reason, this type of security mechanism is favoured for the rooting-out of malware-based automated attacks. A known open-source solution with which low-in­ter­ac­tion server honeypots can be set up is Honeyd.

  • Honeyd: published under the GPL software, Honeyd allows ad­min­is­trat­ors to create different virtual hosts in a computer network. This can be con­figured in such a way that allows different types of server types to be rep­lic­ated, making it possible for an entire system, including the TCP/IP protocol stack, to be rep­lic­ated. However, the software is still among the low-in­ter­ac­tion honeypots, given that Honeyd doesn’t simulate all system para­met­ers, meaning that hackers are able to quickly look through the system. The software appears to not have been developed since 2008.

Low-in­ter­ac­tion client honeypots

Low-in­ter­ac­tion client honeypots (also known as hon­eyc­li­ents) are programs that enable users to emulate different browser types. Users have the pos­sib­il­ity to visit websites and record attacks to these simulated browsers. Known open-source hon­eyc­li­ents with limited in­ter­activ­ity include HoneyC, Monkey Spider and PhoneyC.

  • HoneyC: the low-in­ter­ac­ton Hon­eyc­li­ent HoneyC enables users to identify malicious servers found online. Instead of a fully-op­er­a­tion­al operating system and a cor­res­pond­ing client software, HoneyC uses an emulated client that inspects server responses for malicious content. The software’s fun­da­ment­al structure is made up of three com­pon­ents: the visitor engine is re­spons­ible for the in­ter­ac­tion with the server and emulates different web browsers through modules. The queue engine creates a list of servers that is processed by the visitor engine. An eval­u­ation of the in­ter­ac­tion with a web-server is carried out through the analysis engine, which checks whether the software’s safety rule was damaged after every visit.
  • Monkey Spider: Monkey Spider is a web crawler that can be used as a low-in­ter­ac­tion hon­eyc­li­ent. To this end, the software crawls the software websites and searches for malicious code that could pose a threat to the web browser.
  • PhoneyC: Written in Python, PhoneyC is a hon­eyc­li­ent with which various web browsers can be imitated in order to inspect websites for malicious content. The software is able to process script languages like JavaS­cript or VB script, and supports de-ob­fus­ca­tion functions, which allow the malicious code to be unraveled. What’s more, PhoneyC supports many different methods for analysing websites, e.g. the open source antivirus engine ClamAV.

High-in­ter­ac­tion client honeypot

Ad­min­is­trat­ors looking to make use of server­side honeypots with lots of pos­sib­il­it­ies for in­ter­ac­tions generally use a fully-func­tion­ing server set up as a decoy system. This can either be set-up on real hardware or in virtual en­vir­on­ments. While low-in­ter­ac­tion honeypots are first and foremost sued for identi­fy­ing and analysing automatic attacks, high-in­ter­ac­tion honeypots aim to tackle manually-executed attacks.

Server-side hon­ey­pot­ting is es­pe­cially promising when the goal is to bait hackers with an es­pe­cially at­tract­ive target with a high degree of in­ter­activ­ity. However, this set-up is much more time consuming than simple software solutions, which merely imitate server functions. When a real server is used as a honeypot, there is always the danger that an attacker could use the in­filt­rated system as a starting point for further online attacks. This could result in further con­sequences, given that server operators are often liable for any of the activ­it­ies carried out with their devices.

Special mon­it­or­ing tools are needed in order to survey servers set up as honeypots. Such tools include the freely-available Sebek. A high-in­ter­ac­tion honeypot en­vir­on­ment can be realised with the software, Argos.

  • Sebek: the data col­lec­tion tool, Sebek, is used for highly-in­ter­act­ive honeypots to monitor hackers and collect data on security-related activ­it­ies. Fun­da­ment­ally, the software is composed of two different com­pon­ents: the client runs on the honeypot and collects all the hacker activ­it­ies, such as entries, data uploads, and passwords, and transfers these to a protocol server that is able to run on an in­de­pend­ent system.
  • Argos: the high-in­ter­ac­tion honeypot en­vir­on­ment, Argos, is based on a modified QEMU hardware emulator. The software supports various guest operating systems that are executed in a virtual machine and represent the honeypot. In order to recognize and record attacks, Argus operates without ad­di­tion­al mon­it­or­ing software. Incoming data traffic that reaches the honeypot via the network card is auto­mat­ic­ally ‘tainted’ and monitored. The same applies to data that has been generated from tainted data. The ad­di­tion­al computing effort required for emulating the operating system, and the data analysis, means that Argos is sig­ni­fic­antly slower than pro­duct­ive systems running on com­par­able hardware.

High-in­ter­ac­tion client honeypots

High-in­ter­ac­tion client honeypots are software solutions that run on real operating systems and use standard web browsers in order to record attacks that ori­gin­ated from online servers. Common tools here include Capture-HPC and mapWOC.

  • Capture HPC: the high-in­ter­ac­tion hon­eyc­li­ent Capture-HPC uses a client server ar­chi­tec­ture. Here, a server de­term­ines which websites are to be visited and checks various clients. These then call up pre­de­ter­mined sites and send the result data back to the server. Possible clients include various web browsers, office ap­plic­a­tions, PDF readers, or media players.
  • mapWOC: Also free of charge, mapWOC (short for massive automated passive Web Ob­ser­va­tion Center) loads websites with real browsers. These run on virtual machines whose data traffic with clients is per­man­ently monitored. This is done in order to record and analyze attacks such as drive-by-downloads. mapWOC’s basic com­pon­ents use the host system Debian Squeeze, KVM for vir­tu­al­isa­tion, and ClamAV for examining malware.

Ad­vant­ages and dis­ad­vant­ages of honeypots

Honeypots are generally used to sup­ple­ment other IT security com­pon­ents, like the intrusion detection system (IDS) and firewalls. One aspect that makes honeypots par­tic­u­larly valuable assets is their ability to collect highly-relevant data that can help ad­min­is­trat­ors find out valuable in­form­a­tion. Given that honeypots don’t actually take on any actual network functions, any activity taking place in this control system poses a potential threat. All data collected by honeypots is relevant to your system’s security. If, on the other hand, pro­duct­ive systems are monitored, then this type of data analysis requires an ad­di­tion­al process step in which data relevant to the attack has to be filtered out of the system’s entire dataset.

One thing to take into con­sid­er­a­tion, however, is that not every honeypot is able to deliver valuable in­form­a­tion. If the offered bait is too un­at­tract­ive or difficult to find, then it could also be the case that no attacks happen. This means that any in­vest­ments made into the security systems were a waste of money.

Honeypots can help reveal crucial data to companies, but they also present ad­di­tion­al risks. Given that the decoy system seeks to actively bait hackers, there’s always the risk that a break-in into the honeypot might lead to further damage in the network. This risk can be reduced by max­im­ising the sep­ar­a­tion between honeypots and pro­duct­ive systems, and by per­man­ently mon­it­or­ing all activ­it­ies within the bait systems. What’s more, it’s also important to take into account that a com­prom­ised system could lead to hackers using this in order to launch external attacks. In order to prevent honeypots from being used as starting points for attacks, it’s crucial to keep outbound con­nec­tions to an absolute minimum.

If a high-in­ter­ac­tion server honeypot is equipped with the same security systems as the pro­duct­ive system, then this can be used for im­ple­ment­ing quality control measures. In this case, the collected data is able to deliver direct feedback on how effective the security system is. If an in­filt­ra­tion is re­gistered in the honeypot, then it’s also important to check whether or not the pro­duct­ive system has been in­filt­rated. What’s more, both systems have to be adjusted in order to defend against future attacks of similar patterns.

Side note: hon­ey­pot­ting and the law

In the past, pro­sec­utors have used hon­ey­pot­ting to catch criminals on the lookout for illegal content. Ad­di­tion­ally, it’s often discussed whether copyright owners are able to use honeypots in order to try and surpass the dis­sem­in­a­tion of copyright-protected content.

According to a report published by CNet, in 2006 the FBI re­portedly placed a link in forums that eluded to leading to content con­tain­ing child por­no­graphy. American citizens that then proceeded to visit these links were later visiting by the au­thor­it­ies.

Honeypots are also used to in­vest­ig­ate illegal file sharing platforms. Given that some of these were taken offline and some were able to stay online, it was assumed that both copyright owners and per­se­cutors were able to use them as honeypots. However, depending on which country you live in, this tactic may have no legal basis.

ENISA (European Union Agency for Network and In­form­a­tion Security) is urging companies to use honeypots in order to get a better un­der­stand­ing of what hackers are capable of and what they’re dealing with. At the same time, companies have to be careful when setting up the honeypot so that it doesn’t 'give itself away', causing hackers to purposely avoid it. Brain Honan, founder of the Irish Reporting and In­form­a­tion Security Service also warned companies to make sure that the honeypot can’t be used by the attacker to attack other systems in case it does get breached.

Go to Main Menu