If you’ve ever had an ant problem in your home, it’s likely that you’ve used ant traps. Ants are attracted to food high in carbohydrates, especially sugary stuff. Ant traps work because they contain bait that lures ants in. So, they might go for your ant trap rather than the cookie crumbs you dropped on the kitchen floor. When used properly, the trap allows you to kill ants before they infest your home.
Honeypots in computer networks use the same concept. Cyber attacks travel through the internet to private computer networks constantly. What if you could put something in your network that will attract attacks so you can catch them before they hit your important server and client machines?
How do you use the honeypot concept for your network? So, you want to set up something on your network that looks like an attractive computer to attack. Should you just install Windows 3.1 on a legacy machine, make sure its TCP/IP interface has basic functionality, and plug an Ethernet cable into it? No, that would be a terrible idea. Ideally, a honeypot should resemble a computer on your production network, but with weaker security. In the long run, it’s probably better to make your honeypot a virtual machine. These are easier to maintain and are more scalable. You can tinker around with the virtual hardware specs more easily, and experiment with different amounts of memory and CPU cores. Plus, because virtualization sandboxes your honeypot OS from its host machine, allowing you to contain the effects of cyber attacks more effectively. Did your virtual machine honeypot get infected with ransomware? Just delete it and its virtual disk from your VM client and make a new one!
Install your honeypot virtual machines from the same disc images you use to install operating systems in your production network. Configure them in much the same way, with the same drivers and applications. Just make the security a bit weaker than your information security policy requires. Make fake accounts that are local to your honeypot, and create weak passwords. Be sure that your honeypot doesn’t automatically install security patches, and make the most recently installed patches a few months old. Configure its local firewall to have more open TCP/IP ports, and fewer filtered ports altogether. Leave more of the default OS and application settings. That way, if an attacker OS fingerprints your honeypot, they can try exploiting some vulnerabilities that have been known for a long time. Or not.
The basic principle of making your honeypot like your production machines, but less security hardened, should be maintained in most situations. But all the other details may be tweaked and modified according to your specific needs. Whatever configuration and set up is best may take some experimentation to determine. A good honeypot will allow you to understand what sort of cyber attacks your production machines may face. Having a honeypot that teaches you about malicious network activity will likely take you some trial and error.
Your honeypot must also be set up so that it constantly generates logs on every applicable function. At the very least you should make sure that its OS system logging works and there should be constant logging on its built-in software firewall. If you use some sort of antivirus software in your honeypot, its logs are important as well. You can then run all those logs through a SIEM, just like all of the other logs your network generates.
The next question is, where should you put your honeypots? Putting a honeypot outside of your DMZ and toward the internet is a popular option. That’s an excellent location for watching external cyber attacks on your network. You probably don’t want to put a honeypot inside your DMZ, because attacks to your DMZ can have terrible consequences. You should also consider putting a honeypot on the other side of your DMZ, in a location that’s accessible to users in your private network. As long as you make sure as few employees and contractors know about the internal honeypot as possible, it can be an effective way to catch and analyze internal as well as external attacks. Internal attacks are a big deal. According to IBM”s 2016 Cyber Security Intelligence Survey, about 60% of cyber attacks are done by insiders.