The honeypot wikipedia article states:

...a honeypot is a computer security mechanism set to detect, deflect, or, in some manner, counteract attempts at unauthorized use of information systems.

Deflect for me implies that the attack is at least party send back to the attacker thus relieving the honey pot of this damage. But as far as I know honeypots are only used to gather information passively.

Is this a language problem, is Wikipedia wrong or am I missing something?

  • 2
    Deflect in my ears sounds more like pushing aside the damages, as a deflector on a shuttle deflect the heat aside the shuttle when it get back inside the atmosphere. Sending back would be more a 'reflect'
    – Tensibai
    Jul 21, 2017 at 9:34

2 Answers 2


Borrowing from the other answers & comments coz I agree with them:

Deflect = Not-the-same-as reflect back to the attacker.

The common practice that comes to mind in this context is this:

Your assets can be protected using deflection to a honeypot.

...the armor is between the targets body and the bullet and the bullet has to go through the armor.

I can't think of many situations where a honeypot sits in between the attacker and the assets under protection. That is usually the role of a firewall (network firewall or a web application firewall of some sort).

Honeypots in practice - how they protect by distracting.

It can be a low interaction honeypot (the most common case because it is easier to setup and maintain) that is placed in such a manner that deflects the attention of the attacker by appearing to be easy to hack and sets up protection for main assets. e.g., To protect x.yourasset.com, you could setup x-be.yourasset.com and x-private.yourasset.com as honeypots where no legit customer should normally connect to. When someone connects to them, you use some form of scripted automation that bans them from reaching *.yourasset.com. Here the ban-trigger is simply connecting to the honeypot. No deep interaction is needed.

An intermediate interaction honeypot (again fairly common) would allow an attacker to connect and give them an infinite-looped path e.g, allow SSH connect with a non-existent account and password; then present a fictional file system with never ending directories to traverse. This wastes attacker time and may or may not directly help your asset-security unless you also use this with some form of banning.

In both the above cases, the honeypot is not "placed in front of" the asset. 

Another possibility is to use high interaction honeypots (uncommon). This takes some effort to setup and manage. Here, you let the user interact with your main asset, but if you see anything unusual at all, switch the session to the honeypot. e.g. Your web-form could have legitimate sounding hidden fields (e.g., spl-discount, secret-auth) that normal flow would never populate. On your server you first check those fields and if they're populated you send a redirect to a honeypot. You could also do this using something like the OWASP AppSensor project.

  • that looks like a normal successful submission - "thank you... processing..."
  • that takes several seconds for each screen update and wastes more time - "thank you for your patience..."
  • that could keep asking for more info - "we only need some more information before we complete processing" "we sent you an additional security code to your email address ... please enter it to verify your account for additional security" (of course you may not have sent any code at all)
  • and finally blows it off with something like "we're sorry, please try again later".

This may or may not be combined with banning but it helps in many ways, including data collection about the attacker and their TTPs (Tools, Techniques and Procedures) - that will come handy in other defensive measures.


Don't confuse deflect and counter-attack.

Merriam-Webster online dictionary:

Deflect: to turn (something) aside especially from a straight course or fixed direction

armor that deflects bullets

In this example the armor will not send the bullets back to the shooter, it will only send them away.

In the case of the honeypot, it will act as a distraction for the attacker, making him loosing time and resources in exploring and attacking a decoy, isolated and controlled environment while the real working environment remains safe.

This is as much time and information gained for the defensive team.

  • OK, in the case of the armor the armor is between the targets body and the bullet and the bullet has to go through the armor. How does one guarantee that the attacker has to go through the honeypot first? As far as I know the honeypot is an independent system that is more exposed to be a more attractive target and gets targeted additionally, but there is nothing to prevent the attacker from going directly to the real system if he chooses to. Jul 21, 2017 at 9:55
  • @problemofficer An attacker does not have your network map (hopefully at least !). Given 4 mail servers, 3 domain controllers, 5 proxy-firewall systems, 10 file servers, etc., how can he tell which ones are genuine and which ones are not? Moreover, at a more advanced level, if the attacker regularly comes from the same IPs, it is possible to actively switch them to the honeypot network. Jul 21, 2017 at 10:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .