Honeypots and honeynets are deception-based security technologies designed to attract, detect, and analyze malicious activity on a network. For the N10-009 exam, this topic appears under Objective 4.2 (Network Security), typically accounting for 5-8% of questions. This chapter provides a deep technical explanation of how honeypots and honeynets function, their deployment architectures, and the critical role they play in threat intelligence and incident response.
Jump to a section
Imagine a police department sets up a 'decoy house' in a high-burglary neighborhood. The house looks completely normal from the outside — curtains, a car in the driveway, even a dog barking occasionally. But inside, every door has a sensor, every window is wired to an alarm, and there are hidden cameras in every room. When a burglar breaks in, the house doesn't stop them. Instead, it lets them roam, triggering different responses: turning on a light in one room, making the TV play in another, all while recording their every move. The system logs which rooms they entered, what they touched, and how long they stayed. Meanwhile, the police monitor everything from a remote command center, gathering evidence about the burglar's methods — do they pick locks, smash windows, or use a crowbar? Do they head straight for the master bedroom or check the kitchen first? The house is expendable; its sole purpose is to learn about the threat. Once the burglar leaves, the police have a complete profile of their techniques, which they share with other precincts. In the same way, a honeypot is a decoy system that appears vulnerable but is actually heavily monitored. Its only job is to attract attackers and record their behavior — what exploits they try, what commands they run, what files they access — without ever compromising real production assets. The honeypot is isolated and expendable, and every interaction is logged for analysis.
What Are Honeypots and Honeynets?
A honeypot is a decoy computer system, service, or network resource intentionally designed to appear vulnerable and attractive to attackers. Its primary purpose is to be probed, attacked, and compromised so that security analysts can observe attacker behavior, capture malware, and identify attack vectors. Honeypots have no production value — any traffic to a honeypot is suspicious by definition.
A honeynet is a network of multiple honeypots, often deployed behind a honeywall (a controlled gateway) to simulate a realistic network environment. Honeynets allow analysts to study multi-stage attacks, lateral movement, and command-and-control (C2) communications.
Types of Honeypots
Honeypots are classified by their level of interaction and purpose:
Low-Interaction Honeypots: Emulate only a limited set of services (e.g., SSH, HTTP, FTP) using scripts or lightweight daemons. They do not provide a full operating system. Examples include honeyd and Dionaea. Low-interaction honeypots are easy to deploy, low-risk, but easily detected by sophisticated attackers.
High-Interaction Honeypots: Use real operating systems and full applications (e.g., a real Windows Server with IIS). Attackers can interact with the system as if it were a real target. High-interaction honeypots capture more detailed data but carry higher risk if not properly isolated.
Medium-Interaction Honeypots: Fall between the two, offering more realistic service emulation than low-interaction but without a full OS. Example: Cowrie (SSH/Telnet honeypot).
Malware Honeypots: Specifically designed to capture malware samples by emulating vulnerable services that malware exploits.
Database Honeypots: Simulate database services (e.g., MySQL, MSSQL) to detect SQL injection attacks.
Client Honeypots: Act as clients that visit malicious websites to detect drive-by downloads and client-side exploits.
How Honeypots Work Internally
When an attacker probes a honeypot, the following occurs:
Traffic Redirection: The honeypot is typically placed in a DMZ or isolated VLAN. Traffic may be redirected to it via DNS poisoning, ARP spoofing, or network taps.
Service Emulation: The honeypot presents fake banners, open ports, and vulnerable services. For example, a low-interaction SSH honeypot might respond with an OpenSSH 5.3 banner (known to have vulnerabilities).
Interaction Logging: Every keystroke, command, file download, and network connection is logged in detail. High-interaction honeypots may use kernel-level monitors to capture system calls.
Alert Generation: The honeypot sends alerts to a SIEM or central management console when specific events occur (e.g., login attempt, file download, privilege escalation).
Data Exfiltration Simulation: Some honeypots include fake sensitive data (e.g., passwords.txt, financials.xlsx) to observe exfiltration patterns.
Key Components and Architecture
A typical honeynet deployment includes:
Honeywall: A gateway device that bridges the honeynet to the production network. It inspects all traffic entering and leaving the honeynet, enforces outbound connection limits (to prevent the honeynet from being used to attack others), and logs all traffic. The honeywall often uses a Layer 2 bridge (transparent) so attackers cannot detect it.
Data Capture: Tools like tcpdump, Wireshark, Sebek (kernel module for high-interaction honeypots), or Argus record network flows.
Data Analysis: Logs are sent to a central analysis platform (e.g., ELK stack, Splunk) for correlation and threat intelligence extraction.
Management Interface: Administrators access the honeypot via a separate, secure out-of-band network to avoid contamination.
Configuration and Verification Commands
While honeypot configuration varies by software, common examples include:
#### Cowrie (SSH/Telnet Honeypot)
Configuration file: cowrie.cfg
[honeypot]
listen_port = 2222
hostname = server01
[ssh]
version = SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.13To start Cowrie:
cd cowrie
bin/cowrie startTo check logs:
tail -f var/log/cowrie/cowrie.log
tail -f var/log/cowrie/audit.log#### Honeyd (Low-Interaction)
Configuration file example:
create windows
set windows personality "Windows 2000 SP4"
set windows default tcp action reset
add windows tcp port 80 open
add windows tcp port 135 open
add windows udp port 137 openRun:
honeyd -d -f honeyd.conf 192.168.1.100#### iptables Integration (Traffic Redirection)
Redirect incoming SSH traffic to honeypot:
iptables -t nat -A PREROUTING -p tcp --dport 22 -j DNAT --to-destination 10.0.0.5:2222Interaction with Related Technologies
SIEM Integration: Honeypot logs are fed into SIEM systems (e.g., Splunk, ELK) for correlation with other alerts.
Threat Intelligence: Attack patterns observed in honeypots are shared via platforms like MISP or STIX/TAXII.
Firewalls and IDS/IPS: Honeypots can trigger firewall rules to block attacker IPs or update IPS signatures.
Network Segmentation: Honeypots are placed in isolated VLANs with strict egress filtering to prevent them from being used as a launchpad for attacks.
Default Values and Timers
Session Timeout: Typically 300 seconds (5 minutes) for idle SSH sessions in Cowrie.
Connection Rate Limiting: Honeyd defaults to 10 connections per second to prevent resource exhaustion.
Log Rotation: Most honeypots log rotate daily or at 100 MB.
Outbound Connection Limit: Honeywall limits outbound connections to 10-20 per hour to prevent abuse.
RFC References
RFC 793: TCP – relevant for service emulation.
RFC 2616: HTTP/1.1 – for web honeypots.
RFC 4251: SSH Protocol Architecture – for SSH honeypots.
Exam Tips
Remember that any traffic to a honeypot is malicious by definition because it has no legitimate use.
Low-interaction honeypots are easier to deploy but easier to detect; high-interaction honeypots provide richer data but require more resources.
Honeynets include a honeywall that controls inbound and outbound traffic.
Honeypots do NOT prevent attacks; they detect and analyze them.
Deploy Honeypot in Isolated Network
The honeypot is placed in a separate VLAN or DMZ with no direct connectivity to production systems. A honeywall (Layer 2 bridge) is inserted between the honeypot and the external network. The honeywall uses iptables or ebtables to control traffic. All inbound traffic to the honeypot is allowed, but outbound traffic is rate-limited (e.g., 20 connections per hour) to prevent the honeypot from being used to attack other systems. The honeywall also logs all packets using tcpdump or netflow.
Configure Service Emulation
The honeypot software is configured to emulate specific services. For a low-interaction honeypot like Honeyd, you define virtual hosts with IP addresses and assign open ports. For a high-interaction honeypot, you install real operating systems and applications, then modify them to look vulnerable (e.g., weak passwords, outdated software). The honeypot's banner strings are set to match known vulnerable versions. For example, Cowrie's SSH banner is set to 'SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.13' to attract attackers targeting that version.
Redirect Traffic to Honeypot
Traffic is redirected to the honeypot using network techniques such as DNS poisoning, ARP spoofing, or iptables DNAT rules. For example, an iptables PREROUTING rule can redirect all incoming traffic on port 22 (SSH) to the honeypot's IP address. Alternatively, a network tap or port mirroring on a switch can copy traffic to the honeypot. The goal is to ensure that attackers scanning the network find the honeypot and attempt to interact with it.
Monitor and Log Attacker Activity
Every interaction is logged in detail. Low-interaction honeypots log connection attempts, commands entered, and files downloaded. High-interaction honeypots use kernel modules (e.g., Sebek) to capture system calls, keystrokes, and file operations. Network traffic is captured using tcpdump. Logs are sent to a central SIEM in real-time via syslog or custom agents. Alerts are generated for specific events, such as a successful login or download of a known malware sample.
Analyze Collected Data and Update Defenses
Security analysts review the logs to identify attack patterns, new malware variants, and attacker TTPs (Tactics, Techniques, and Procedures). Indicators of compromise (IoCs) such as IP addresses, file hashes, and URLs are extracted and shared with threat intelligence platforms. Based on the analysis, firewall rules are updated to block attacker IPs, IPS signatures are created, and system patches are prioritized. The honeypot configuration may also be adjusted to emulate new vulnerabilities.
Enterprise Scenario 1: Detecting Lateral Movement in a Corporate Network
A large enterprise deploys a honeynet consisting of 20 low-interaction honeypots across multiple subnets (HR, Finance, R&D). The honeypots emulate Windows file servers, SQL databases, and domain controllers. They are configured with fake sensitive data (e.g., 'employee_salaries.xlsx', 'source_code_backup.zip'). The honeywall logs all outbound connections. One day, a honeypot in the Finance subnet receives an SMB connection from an internal IP that normally only accesses production SQL servers. The honeypot logs the attacker's attempt to mount a share and copy files. The honeywall blocks the outbound connection when the attacker tries to exfiltrate data via FTP. The SIEM correlates this with a previous IDS alert on a workstation, revealing a ransomware infection that had moved laterally. The incident response team isolates the workstation and blocks the attacker's C2 IP. The honeynet provided early detection of lateral movement that would have otherwise gone unnoticed.
Enterprise Scenario 2: Capturing IoT Malware in a Cloud Environment
A cloud service provider deploys a high-interaction honeypot running a real Linux server with exposed Telnet and SSH services. The honeypot is placed in a public subnet with a public IP. Within hours, it receives thousands of login attempts from Mirai variants. The honeypot records the malware payloads downloaded via wget and tftp. Analysts extract the binary and analyze it in a sandbox, identifying a new variant that targets a vulnerability in a popular IoT device. The threat intelligence team shares the IoCs with customers and updates the WAF rules to block the exploit. The honeypot also reveals that the attackers are using a new C2 server IP, which is added to the blocklist.
Common Misconfigurations
Not isolating the honeypot properly: If the honeypot has outbound connectivity without rate limiting, it can be used to attack external systems, causing legal liability.
Using production data: Honeypots must never contain real sensitive data. Use fake data that appears realistic but has no actual value.
Insufficient logging: Without comprehensive logging, the honeypot provides little value. Ensure all network traffic and system calls are captured.
Detectable honeypots: Sophisticated attackers can detect low-interaction honeypots by sending malformed packets or checking for missing responses. High-interaction honeypots are harder to detect but require more maintenance.
N10-009 Objective 4.2: Network Security
The exam tests your understanding of honeypots and honeynets as security monitoring and threat detection tools. Key points:
Purpose: Honeypots are decoy systems used to attract attackers and analyze their behavior. They have no production value — any traffic to them is malicious.
Types: Low-interaction (emulates services) vs. high-interaction (real OS). The exam expects you to know the trade-offs: low-interaction is safer but less realistic; high-interaction is more realistic but riskier.
Honeynet: A network of honeypots behind a honeywall. The honeywall controls outbound traffic to prevent the honeynet from being used as a launchpad.
Placement: Honeypots are typically placed in a DMZ or isolated VLAN. They should not be directly accessible from the production network.
Common Wrong Answers and Traps
Trap: 'Honeypots prevent attacks' — Wrong. Honeypots do not prevent attacks; they detect and analyze them. Prevention is handled by firewalls, IDS/IPS, etc.
Trap: 'Honeypots are used to store sensitive data' — Wrong. Honeypots contain fake data to entice attackers, never real production data.
Trap: 'Low-interaction honeypots are harder to detect' — Wrong. Low-interaction honeypots are easier to detect because they lack full OS behavior. High-interaction honeypots are more realistic and harder to detect.
Trap: 'Honeynets have no outbound control' — Wrong. Honeynets always have a honeywall that restricts outbound traffic to prevent abuse.
Numbers and Terms to Know
Honeypot: decoy system
Honeynet: network of honeypots
Honeywall: controlled gateway for honeynet
Low-interaction: emulated services
High-interaction: real OS
DMZ: typical placement location
Edge Cases
Client honeypots: These are honeypots that act as clients (e.g., web browsers) to detect malicious servers. They are less common but may appear on the exam.
Malware honeypots: Specifically designed to capture malware samples by emulating vulnerable services.
How to Eliminate Wrong Answers
If a question asks about the purpose of a honeypot, eliminate any answer that mentions prevention, blocking, or storing real data. If it asks about placement, eliminate answers that put honeypots inside the production network without isolation. If it asks about outbound traffic, remember that honeynets restrict outbound connections.
Any traffic to a honeypot is malicious by definition because it has no legitimate production purpose.
Low-interaction honeypots emulate services; high-interaction honeypots use real OS.
Honeynets include a honeywall that controls and logs all traffic, especially outbound connections.
Honeypots are placed in isolated networks (DMZ, VLAN) to prevent lateral movement to production.
Honeypots do not prevent attacks; they detect and analyze them for threat intelligence.
Client honeypots act as clients to detect malicious servers (e.g., drive-by downloads).
Common honeypot software includes Cowrie (SSH/Telnet), Dionaea (malware), and Honeyd (low-interaction).
These come up on the exam all the time. Here's how to tell them apart.
Low-Interaction Honeypot
Emulates only specific services (e.g., SSH, HTTP)
Easy to deploy and maintain
Lower risk of compromise to other systems
Captures limited data (connection attempts, commands)
Easier for attackers to detect
High-Interaction Honeypot
Uses real operating systems and applications
Complex to deploy and maintain
Higher risk if not properly isolated
Captures detailed data (system calls, keystrokes, files)
Harder for attackers to detect
Mistake
Honeypots are used to block attacks in real-time.
Correct
Honeypots are passive decoys designed to detect and analyze attacks, not to block them. Blocking is done by firewalls, IDS/IPS, and other security controls.
Mistake
Low-interaction honeypots provide the same level of detail as high-interaction honeypots.
Correct
Low-interaction honeypots only emulate a limited set of services and capture limited data (e.g., connection attempts, commands). High-interaction honeypots use real OS and capture system calls, keystrokes, and file operations, providing much richer data.
Mistake
Honeypots should contain real sensitive data to attract attackers.
Correct
Honeypots must never contain real sensitive data. They should contain fake data that appears realistic to entice attackers without risking actual data loss.
Mistake
A honeynet is the same as a honeypot.
Correct
A honeynet is a network of multiple honeypots, often with a honeywall that controls traffic. A honeypot is a single decoy system.
Mistake
Honeypots can be placed anywhere on the network without isolation.
Correct
Honeypots must be isolated from production systems, typically in a DMZ or separate VLAN, to prevent attackers from pivoting to real assets.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A honeypot is a single decoy system designed to attract attackers. A honeynet is a network of multiple honeypots, often with a honeywall that controls and monitors traffic between the honeynet and the outside world. The honeywall logs all traffic and restricts outbound connections to prevent the honeynet from being used to attack others.
No, a honeypot does not prevent attacks. It is a detection and analysis tool. It attracts attackers and logs their behavior, which can then be used to improve security measures like firewall rules, IDS signatures, and patch management. Prevention is handled by other security controls such as firewalls, IDS/IPS, and access controls.
A honeypot should be placed in an isolated network segment, such as a DMZ or a separate VLAN, with no direct access to production systems. It should be behind a honeywall that controls inbound and outbound traffic. This isolation prevents an attacker from using the honeypot as a pivot point to attack real assets.
The data captured depends on the type of honeypot. Low-interaction honeypots capture connection attempts, service requests, and commands entered. High-interaction honeypots capture keystrokes, system calls, file operations, network traffic, and sometimes full memory dumps. All data is logged for analysis.
Yes, but with caveats. Honeypots are legal as long as they do not entrap innocent users or cause harm to others. It is important to have clear policies and legal review. Honeypots should not be used to attack others, and any data collected must be handled according to privacy laws. Rate-limiting outbound connections is a best practice to avoid legal liability.
Common tools include: Cowrie (SSH/Telnet medium-interaction honeypot), Dionaea (malware capture), Honeyd (low-interaction honeypot that can emulate multiple OS), Glastopf (web application honeypot), and Kippo (older SSH honeypot, predecessor to Cowrie). For honeynets, the Honeywall CDROM (now deprecated) or custom iptables scripts are used.
A honeywall is a Layer 2 bridge that sits between the honeynet and the external network. It transparently inspects all traffic, logs it, and enforces outbound connection limits (e.g., 20 connections per hour) to prevent the honeynet from being used to attack other systems. It can also perform deep packet inspection and alert on suspicious activity.
You've just covered Honeypots and Honeynets — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?