The world-wide-web is constantly evolving — along with this comes a fair amount of attacks from malicious actors. In order for companies (or individuals) to attempt to detect attacks in advance, they use a technique known as setting up “honeypots.” An analogy might help: imagine if you place a honeypot (or a pot of gold, if you desire) outside. Inevitably, some person comes to grab a taste of your honey: this is what is known as “bait.”
Honeypots are, fundamentally, traps — they are designed to lure, and capture the activities of malicious actors that could potentially attack other critical infrastructure/servers in the future. With that said, there are typically two types of “trap” designs:
There are many variations of a generic “honeypot” — some of which are:
1) Malware Honeypots
Malware honeypots are exactly as they imply — they are designed to “trap” (i.e. detect) malware. For example, a decoy API server could be set up to trick an attacker (or automated bot) such that they attempt to steal information by means of malware.
Fortunately, malware honeypots are never connected to a company’s primary infrastructure; the honeypot is most often placed on an external server, away from any critical servers.
2) Spider Honeypots
While a “spider honeypot” does not necessarily search for bad traffic, it does sit and monitor web trends (from browser types to crawler versions). A side effect, however, is obvious: being able to track and monitor botnets, the general locations of cyberattacks, to attack vectors.
Since the honeypot is merely set up to “listen” for these attacks, there should be no infrastructure to attack; there is only a server forwarding logs and information to the company or individual that runs said honeypot.
High interaction network honeypots aim to waste as much time as possible while low interaction honeypots do the opposite. With a fully fledged high interaction honeypot, an attacker can attack a system that closely resembles that of a production system (which can be placed near production servers), providing valuable information on necessary bug-fixes and patches for live applications (as well as luring attackers; low interaction honeypots are less likely to have a dedicated person attacking the honeypot).
With low interaction honeypots, “bait” is placed away from primary infrastructure. They also capture the most common types of attacks (usually ones sent by automated code/crawlers) and are very easy to manage. Having said that, this form of honeypot is not targeted by “devoted” attackers — they will search for actual vulnerabilities that will grant them access to important infrastructure rather than a bait server.
Honeypots are a useful tool for hacking prevention. They generate valuable data that can be used to patch out emerging viruses and web attacks — they can even monitor for SQL vulnerabilities that applications could potentially be vulnerable to.
From a security perspective, honeypots can also bait attackers away from core applications, which, in a way, is a sort of defence in itself. With that in mind, honeypots do not replace actual security updates and maintenance — they exist to help create said updates.
Honeypots are traps often used for security research. They are designed to attract attackers into discovering or exploiting vulnerabilities.