In my last post, Getting Started With HoneyPy — Part 1, I covered getting HoneyPy up and running with the very basic default configuration. In this post, I’ll provide additional thoughts on HoneyPy services and service profiles.
The services.cfg file is what drives how your HoneyPy honeypot appears on the network. By that I mean it defines what services are enabled, and what port and plugin to use for each service. As a recap, this is what makes up a service entry:
[<My_service_name>]plugin = <Plugin to use>
low_port = <Protocol>:<Port number>
port = <Protocol>:<Port number>
description = <Text description>
enabled = <Yes/No>
and here is an example:
[Echo]plugin = Echo
low_port = tcp:7
port = tcp:10007
description = Echo back data received via tcp.
enabled = Yes
Don’t forget, the list of default plugins that come with HoneyPy are listed here https://github.com/foospidy/HoneyPy/wiki.
Choosing what services to enable is entirely up to you and the type of honeypot you want to run. There really is no right or wrong way to configure your services. However, here are a few scenarios to consider as you think about how to configure your honeypot’s services:
In some cases, attackers or malware are only looking for specific services. If the service port they are looking for is open then they’ll start launching their attacks. A good example of this is Telnet and SSH, which are commonly targeted services for brute force attacks on the Internet. In recent years, home routers, and even more recently IoT devices, are constantly targeted. In this scenario, the source of the attacks are typically automated and don’t care about any other service running on the host.
In other cases, an attacker may probe or scan the host to identify all listening services. This could be an effort to fingerprint the host and determine if it is a Windows or Linux operating system based on what services are available. Or perhaps, they have exploits for multiple services and are casting a wide net to increase their chances of compromising the host. For this scenario, it’s a good idea to run services that are consistent with a given operating system.
You could configure your honeypot to run both Linux and Windows services, which may be confusing to anyone that scans it. However, while the automated attacks won’t be phased by it, this may be a clear indication to a human that they’ve stumbled onto a honeypot.
Research vs Production
The type of honeypot you plan to run can have an impact on the services you want to run. Choosing to run a research honeypot versus a production honeypot should be pretty straight forward. If you are running a honeypot on the Internet, consider it research. If you are running a honeypot on a company’s internal network, consider it production.
Deciding what services to run for research honeypots is entirely up to what you are interested in researching. It can be as broad as capturing events from numerous known malware service ports. As an example, HoneyPy has a service profile for a larger set of known malware here (more on service profiles later). Or a research honeypot can be focused on just capturing brute force login attempts against Telnet.
Production honeypots should align more with services you are already running on your network. In other words, it should look just like any other server on your network. If you have Windows file servers, web servers, or even domain controllers then you’ll want to run honeypots that look like those. The same applies for any Linux web servers, database servers, or LDAP servers. Additional service profile examples are Linux services and Windows IIS services.
In the previous section, I referenced a few service profiles, so you may have figured them out by now. These are simply service configuration files with service entries that fit a specific “profile”, like a Linux server or a Windows server. You can see the current service profiles here. To use one of these profiles you can copy a service profile file over the service.cfg file (be sure to make a backup copy of service.cfg if you previously made changes you wish to save).
cp etc/profiles/services.linux.profile etc/services.cfg
Alternatively, in the HoneyPy console, you can use the list profiles command to view available service profiles.
HoneyPy> list profiles
Then use the set profile command to enable a profile.
HoneyPy> set profile linux
Profile changed to linux
Quit and restart HoneyPy for profile change to take effect!
You can create your own service profile files by simply adding them to the etc/profiles directory, and follow the naming scheme of:
If you come up with interesting service profiles and want to share it with others, please feel free to add your service profile to the HoneyPy project by submitting pull request on Github.
HoneyPy can be easily configured to listen on any number of service ports you choose. As a result, you can decide what you want your HoneyPy honeypot to look like, whether it be a research or production honeypot. Also, it is easy to create, maintain, share various honeypot profiles with HoneyPy’s service profiles feature. I hope this post has helped you learn more about HoneyPy, and has you thinking up great honeypot scenarios, and implementing them!
In the next post, I’ll go over creating HoneyPy plugins, which are the engines behind services. As well as creating HoneyPy loggers.
Thanks for reading
We wrote a short book on The Roadmap for DevOps and Security that outlines the 4 key areas Security can provide value in a DevOps organization. You can get it for free below.