Ethical › Module 12 › Lesson 3
Honeypots as Tripwires
Decoy systems defenders use — you will not attack someone else’s honey.
Visual · honeypot_tripwire
A honeypot is a decoy the defender placed so a touch becomes a ticket. You may design one on a network YOU own. You do not hunt or poke someone else's honey.
Opening
A honeypot is a tripwire with an address. Stepping on someone else’s wire is not research. Building a labeled decoy on a net you own is defense.
Lessons 1–2 named the wall and the camera: firewall policy you write, IDS/IPS you tune. This lesson names a third defender object: a system that should never see honest users. In Cyberlium wording, a honeypot is a decoy — a host, a service, or a file — placed so that any connection is a clue. Production traffic has no business there. A hit means someone is enumerating, wandering, or worse. That is why operators deploy honey: early warning, and a place to watch techniques without handing over the real database. It is not a CTF box the internet left out for you. It is not extra credit to “find the honey on campus.” You will not attack someone else’s honeypot. This is original Cyberlium teaching mapped to the CEH v13 IDS/firewall/honeypot domain — not official EC-Council training, not a cert, not exam dumps. You will not get a “how to fingerprint and raid honey” cookbook. You will not get a Shodan homework of random honey. You will write what a tripwire is, low versus high interaction as names so you could BUILD one later under RoE, and a refuse line. Next is the firewall lab on a VM you own. Here you lock honeypot-notes.txt.
1. A honeypot is a tripwire the defender placed — not a leftover toy
Honest services exist because someone needs them: SSH for an admin, HTTPS for customers, DNS for resolvers you run. A honeypot exists because nobody honest should need it. The “user” who connects was not invited. That inversion is the whole idea. On a network you own, you might run a decoy listener on an unused address in YOUR lab VLAN so that a scan of YOUR range lights a ticket before it reaches the real app. The ticket is the product. The decoy is not a prize. If you do not own the network, you do not go looking for decoys to touch. Touching is still a connection to a computer you were not authorized to use — Module 1 again, with a prettier name.
Honeytokens are the cousin that is not always a host: a fake credential, a canary file, a DNS name that should never resolve in production. If it is used, someone read a place they should not have. Those objects are defender instrumentation. Planting them in a classmate’s repo “to catch them” without a contract is still a people/systems test you do not have. Reading about canary tokens as a concept so you might deploy one in YOUR gitignore on a private project you own is in scope as literacy. Stealing someone else’s canary to see what happens is not a lab.
Command guide
Honeypot is a tripwire YOU placed — WHAT/WHY
═══ COMMANDS ═══
Command — copy this
cat >> "$NOTES" << 'EOF' honeypot_means: a decoy I placed so a touch is a clue refuse: raiding public honeypots as homework EOF
2. Low vs high interaction — named so you can BUILD, not so you can raid
Low-interaction honey emulates a service just enough to log a connect, a banner grab, maybe a fake login prompt — then stops. It is cheaper and safer for the operator: less real OS to patch, less chance the decoy becomes a pivot. High-interaction honey is a more complete system (a real VM with a real stack) so the defender can watch what a trespasser tries next. That richness is also risk: a real OS can be abused if the operator failed to isolate it. Those sentences exist so a future you, with written RoE and a lab net you own, can choose isolation, snapshots, and no-route-to-production. They do not exist so you can hunt high-interaction boxes on the internet and “practice.”
This course will not walk you through installing a public honey framework against a stranger’s IP, and it will not walk you through fingerprinting tricks that tell you “this banner is fake, smash it harder.” Fingerprinting someone else’s decoy is still reconnaissance of a system you do not own (Module 2–4 ethics). If you ever deploy honey on YOUR hypervisor, you will bind it to a lab network that cannot reach the café, you will log connects, and you will treat every hit as a ticket — including hits from you while testing YOUR own decoy. Testing YOUR decoy is allowed because you own both ends. Testing theirs is not.
3. What a hit means: someone touched the decoy — investigate, do not trophy
On a honey you own, a SYN to the decoy port is already a finding: inventory who should have been scanning YOUR lab (you, a scheduled check you wrote) versus who should not. Copy the source address you are allowed to see into YOUR ticket, not into a public gist. Do not “return fire.” Do not scan back the source /24. Do not DDoS the scanner (Module 10). The tripwire did its job when it logged. The next job is the same as Module 7 detection: isolate if needed, review YOUR real hosts for the same source, patch leftovers. A screenshot of a stranger’s nmap against your honey is not a portfolio piece you publish with their IP.
On honey you do not own, there is no authorized “hit.” You should not be there. Research papers and public postmortems you read in a browser are literacy, like NVD in Module 5. Replaying their topology against a university decoy, a vendor cloud honey, or a random RFC1918 host you guessed is not literacy. “I thought it was a honeypot so it was fair game” is not a defense. Operators deploy honey precisely because trespass is the signal. You do not get to be the signal as homework.
4. You will not attack someone else’s honey — including “just to see”
Refusal list, write it into the notes: no scanning campus or café for decoys; no Shodan of random honey; no poking a cloud honey program you did not enroll in; no attacking a classmate’s “trap VM”; no using a discovered honeypot as a C2 or a pivot (that is both unauthorized access and often a crime). Authorized honey research, if it ever exists for you, is a program with terms — a vendor’s research net you joined in writing, or a lab net whose owner is you. This Cyberlium path does not assign that program. Recognition and refusal are the assignment, same as Module 9 did for humans.
Legal refrain again because the catalog title tempts people: original Cyberlium teaching mapped to the CEH v13 IDS/firewall/honeypot domain — not official EC-Council training, not a cert, not exam dumps. Completing this lesson does not grant CEH and does not authorize interacting with third-party decoys. A cert-shaped blog that says “enumerate the honey then exploit it” is not this course. If a sentence would help someone raid a tripwire they do not own, delete it from your notes.
5. What you record: tripwire definition, interaction names, refuse line
A honeypot note is boring on purpose. Date (UTC). Legal line. Honeypot means a decoy that honest users should never need; a touch is a clue. Honeytoken as optional cousin. Low vs high interaction in one sentence each — BUILD vocabulary, not a raid plan. Isolation: if I ever deploy one, it lives on a net I own with no path to production or the café. Ethics: I will not attack someone else’s honey. Path: $HOME/cyberlium-lab/honeypot-notes.txt, chmod 600. Empty files fail. Files that list IPs of decoys you found on campus fail even if you “only pinged.” World-readable 777 fails.
A useful feeling: the lesson is small because you did not pop a decoy. That feeling is the course working. Lesson 4 will not raid honey either. It will document inbound firewall policy for a VM you own. Keep honeypot-notes.txt free of target lists. Do not paste “how to detect honeypots” cheat sheets that are really “how to keep scanning after you notice a trap.”
6. Wrong vs right: raiding someone else’s decoy vs naming a tripwire you might BUILD
Worked failure — same word “honeypot,” opposite owner. Right never treats a stranger’s tripwire as a CTF.
Wrong
Scan campus/café for decoys. Shodan random honey. Fingerprint and smash a trap VM. Enroll a classmate's host as a target because it “looked unused.” Publish hit IPs. Call it CEH homework. This course is not official CEH training and does not give you that hunt.
Right
Define a honeypot as a defender tripwire. Name low vs high interaction as BUILD vocabulary. Refuse attacking someone else's honey. Write honeypot-notes.txt under $HOME/cyberlium-lab, chmod 600. Next: Lab — Write Firewall Rules for YOUR Lab VM — inbound allow you need, default deny, no needless 0.0.0.0.
7. Hands-on: lock honeypot-notes.txt — tripwire literacy, not a raid kit
On a computer you own, create cyberlium-lab if needed. Fill the template in YOUR words. Run the checker; it only reads YOUR file. chmod 600. Do not add a found decoy IP because the file felt short.
Command guide
A hit means investigate — WHAT/WHY then lock
═══ COMMANDS ═══
Command — copy this
cat >> "$NOTES" << 'EOF' hit_means: someone touched a decoy I placed next: investigate on MY logs — do not trophy, do not hack-back EOF
Mission: honeypot-notes.txt in cyberlium-lab (mode 600)
1) In your own words, define a honeypot as a defender tripwire and name low vs high interaction as BUILD vocabulary — not a raid plan. 2) Fill $HOME/cyberlium-lab/honeypot-notes.txt; run the checker; chmod 600. 3) Ethics: you will not attack someone else’s honey. No Shodan-of-random. No campus decoy hunt.
Stuck? Ask Cyberlium AI Mentor
If “honey only makes sense if I poke a real one” still feels true, ask for a hint — not a target. Try: "Hint only: why a honeypot is a decoy honest users should never need, why low vs high interaction is BUILD vocabulary, why notes live at $HOME/cyberlium-lab chmod 600, and why someone else's honey is out?" You still fill honeypot-notes.txt. No Shodan. No campus trap VM.
You now treat a honeypot as a tripwire a defender placed — a decoy honest users should never need — and you treat raiding someone else’s honey as out of this course. Low vs high interaction are names for isolation you would design, not a loot table. Notes are locked in cyberlium-lab. This is original Cyberlium teaching mapped to the CEH v13 IDS/firewall/honeypot domain — not official EC-Council training, not a cert, not exam dumps. Next — Lab — Write Firewall Rules for YOUR Lab VM — document inbound allow for SSH/HTTP you need, default deny, no needless 0.0.0.0, chmod 600.
Knowledge Check
APPLY: A classmate found an unused-looking SSH on campus and wants to “check if it is a honeypot” with nmap then a login try as CEH homework. What is a honeypot here, and what do you do?
Multiple choice
Knowledge Check
APPLY: True or False: High-interaction honey is fair game on the internet because the operator wanted to be attacked.
True or False
Knowledge Check
APPLY: You are filling honeypot-notes.txt. Which pairing matches ethics and hygiene?
Multiple choice
Knowledge Check
APPLY: curl of http://192.168.0.1/ shows a home router login (TP-Link / Netgear / Huawei / "Router Admin"). Is that DEMO in scope as a hacking target?
Multiple choice