Getting Started With HoneyPy — Part 2

source

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.

Services

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.

Research Honeypot

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 Honeypot

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.

Service Profiles

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
tcp_malware
windows_active_directory
windows_iis
peer_to_peer
udp_malware
default
common
linux
databases
streaming
HoneyPy>

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!
HoneyPy>

Changing HoneyPy Service Profiles

You can create your own service profile files by simply adding them to the etc/profiles directory, and follow the naming scheme of:

services.<service_profile_name>.profile

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.

Conclusion

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.

At Signal Sciences we provide a modern approach to application security and web application firewalls that DevOps shops love. I hope you find it useful.