HoneySens is an open platform to deploy and manage honeypots on a variety of hardware and software architectures. This page covers primarily the freely available Community Edition. In case you’re interested in professional support, please have a look at the Enterprise Edition.
The following topics are meant to give an introduction into the HoneySens design goals, architecture, setup procedure and operation.
Traditional defenses in IT security try to detect and mitigate threats as fast and efficient as possible in an attempt to reduce damage to infrastructure, assets and confidential data. Anti-virus software and Intrusion Detection Systems are widespread examples for that.
For a first glance on what HoneySens has to offer we prepared a bunch of preconfigured Docker images that can be utilized to quickly set up a demo environment. Please be aware that these images should never be used in production!
When deploying HoneySens, planning ahead can prevent serious headaches later. This document thoroughly explains some of the assumptions HoneySens was built around and the subsequent requirements one has to consider when planning to set up a HoneySens installation.
This section describes the initial steps necessary to deploy HoneySens in your IT infrastructure. We will set up, prepare and configure the server components. Please consult Preparation first as a checklist and to understand how a HoneySens deployment could look like in practice.
This document describes the deployment of both dockerized and “physical” sensors. We assume that the server was set up beforehand and is running properly. Deploying new sensors generally involves the following steps, which will be explained more thoroughly in the following chapters:
A sensor by itself doesn’t perform any tasks other than regularly polling the server for configuration updates. To gain value from a sensor, operators have to deploy services to add custom functionality.
In its primary role HoneySens sensors act as an early-warning system that provide fake honeypot services to attract and report potential network-based attacks, called events. This document will show how collected events can be examined and how the event list can be kept clean by filtering out false positives.