It seems to me that any reference to honey pots requires a reference to Winnie the Pooh, so I'll get that out of the way, and we'll all have that song going through our heads all day. A network honey pot works just like the kitchen honey pot. You open one up and the honey pot attracts flys. In networking the flies are hackers or malicious bots. Honey pots operate by appearing to a hacker to be an attractive hacking target. The honey pot emulates a full production network or network device so a hacker snoops around while the honey pot captures information about the hacker's attack and the hacker. Network Security Engineers respond to the attack and change firewall rules to prevent further atack.
I have seen two implementations of honey pots, a DMZ implementation and a production server implementation. Here is an illustration of each type:
The DMZ implementation has an obvious advantage; that the hacker can be tracked before they get into the production network. The server implementation also has an advantage; it detects and traps hackers that have made their way into the production network.So, which one should you use? Both. Implementing one type does not eliminate the ability to implement the other type. Most companies have multiple honey pots in multiple locations. Once an intrusion has been detected it has to be eliminated as fast as possible and the firewalls all should be updated to exclude that attack.
Centralized firewall security management and device configuration management are crucial at this point. As your network grows, the number of firewalls grows. If you have to manually push new rules out to a few firewalls, that can take a lot of time. During this time the attack is probably still active. Time saved in this process by bringing all of your firewalls into a multi-vendor management platform reduces this time, lessening the threat.