Honeypot is a unique security resource which is a part of your overall security mechanism deployed in your organisation. The idea is that you want all the attackers to interact with your honeypots ONLY, not with actual production systems. Honeypots would have little value if attacker doesn’t interact with them.
Honeypot traps lure bad guys into attacking these fake networks, servers, or other devices because they contain applications and data similar to legitimate targets. Once an attacker falls into this trap, the honeypot allows administrators to obtain valuable data about the type of attacker, the activity he was attempting, and in many cases, even identify the attacker.
They can be used as early warning systems, slowing down the automated attacks and capturing new exploits to gathering intelligence on emerging threats, before they actually cause any damage to your networks or critical assets.
The beauty of honeypots is that they can be a real computer, a virtual machine, an entire (dummy) network, even an application. Furthermore, honeypots don’t even have to be computer. They may be credit card numbers, Excel spread sheets or login and passwords (known as honey tokens). Honeypots can take many forms...
What Are the Different Types of Honeypots?
3-Primary Categories of Honeypots
1. Low Interaction Honeypots
Low-interaction honeypots allow partial interaction with systems since they run limited 'emulated' services with restricted functionality as would be typically expected from a server or a production computer. Though these are the easiest to set up and maintain, they are also easier to be detected by potential attackers. These types of honeypots serve as an early detection mechanism, and organizations commonly use them in production environments.
The hallmark of these honeypots is that they don't allow any interaction with the OS at all. They offer a small set of emulated services only to interact with...
2. Medium Interaction Honeypots
These honeypots come with expanded capabilities compared to low interaction honeypots but still have reduced implementation complexities than high interaction honeypots. They imitate the application layer but don’t have their own operating system. Organizations typically deploy these types of honeypots to stall attackers to give them time to respond to attacks.
They offer more services to attackers to interact with. But they still don't allow any interaction with the OS of the machine.
3. High Interaction Honeypots
Here is the game...These honeypots closely imitate your real-world systems and applications with actual services, functions, and operating systems. It is natural that they would be involving high-levels of interactivity from attackers. Setting up high-interaction honeypots is a complex and resource-intensive process. You will need a certain level of skills to design and establish correct level of interactivity...
They give extensive details about how an attack progresses and how payloads execute in a network.
However, since there are actual operating systems and services involved, the chance of infection is higher if the hackers are able to compromise the honeypots and use them gain access to your organization’s real production environment
4. Pure honeypots:
They are FULL production systems, so no other software needs to be installed.
The next question is, where should you put your honeypots?
Honeypot can be deployed in a variety of locations in the network.
1.Putting a honeypot outside of your DMZ or outside of your firewall and toward the internet is a popular option. That’s an excellent location for watching external cyber attacks on your network.
2.You probably don’t want to put a honeypot inside your DMZ, because attacks to your DMZ can have terrible consequences.
3.You should also consider putting a honeypot on the other side of your DMZ, in a location that’s accessible to internal 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.
What would I advise?
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 specifications more easily, and experiment with different amounts of memory and CPU cores.
Virtualization will work as a sandbox to separate your honeypot OS from its host machine, allowing you to contain the effects of cyber attacks more effectively.
Q. 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.
Also ensure 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.
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.
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.
Always remember: a honeypot is, in itself, NOT a network security solution. It is in fact a tool that serves as a means to reach a secure network solution. Learn from it and tighten the screws using other network monitoring and protection solutions.
Please let me know of what do you think about this in the comment section. You can also share with all if the information shared here helps you in some manner.
Kindly write your COMMENT on the posts or topics, because when you do that you help me greatly in designing new quality article/post on cybersecurity.