![]() | ![]() |
| ||||||||||
![]() |
![]() |
![]() | |||||
| |||||
![]() |
No matter what type of honeypot system you deploy or where you place it, some common principles apply. Chapter 1 talked about the importance of data control and data capture. Data control is making sure the compromised honeypot is not used to attack other legitimate resources. Data capture is recording everything the hacker does. In these definitions are other implicit objectives:
Store collected data remotely. You want to store as much evidence as you can remotely. If it is stored locally, the hacker can find it and erase it.
Don’t let hackers discover your monitoring devices. If your monitoring tools are discovered, the hackers could disable them, delete the collected data, or just avoid the honeypot.
A honeypot should strive to look like a production asset.
Your honeypot system should be designed to prevent a compromise to the production network. This means that the hacker should never have access to legitimate data, systems, or user accounts.
Remember these underlying honeypot system tenets when designing your solution.
![]() | |||||
| |||||
![]() |