A honeynet is a nifty way of collecting malware from the Internet, and consists of a network of one or more honeypots together with the supporting network infrastructure. If this sounds like something that you’ve been dying to do, or you are simply interested in what I’m using to capture malware samples, then grab yourself a cuppa (after last night, I’d suggest something other than two cups of Chai Vanilla tea if you are planning on getting some sleep anytime soon) and let’s begin.
Honeynets consist of three main components:
- Network infrastructure
- Honeypot host(s)
- Management host(s)
which this ‘Building a Honeynet on Linux’ series will cover in three parts. It will take you through my process of building a honeynet environment on a Linux platform, using KVM to run the virtual hosts, and using (virtual/software) network bridges to create the virtual honeynet network.
The focus will be on the methods and configurations that I used to build my lab, however it will also describe my understanding of honeynets, for the benefit of any readers not familiar with them, and if I don’t start getting more sleep than I did last night, it might also be largely incomprehensible.
As I haven’t been keeping up to date with honeynet technologies, it won’t offend me if readers not familiar with honeynets want to read more definitive documentation from someone actively involved in the research and/or the development thereof. The Honeynet Project is a good source of honeynet related documentation and projects.
There are two main concepts in the design of honeynets:
- Data Control
- Data Capture
Data control is all about controlling the flow of data both in and out of the honeynet. As a honeynet’s main goal is to capture malicious and/or suspicious files, we obviously need to take certain precautions. This controlling of the flow of data both in and out is to make sure that we are not only protecting our own internal systems, but that we are also protecting other Internet users, as we certainly don’t want our own systems being used to attack others.
Data capture is about capturing as much data as we can. Some of the most important data being the inbound network traffic, any outbound network traffic, log files containing timestamps (for log file/data correlation) and artifact (changes, basically) information from the honeypot, and, of course, any malicious/suspicious files. Basically we want to know as much as we can about what happened.
A honeynet also needs a way of being restored to a known clean state after a potential infection. If a honeypot is using software to emulate vulnerable services, then this step is generally not required as nothing, other than what we want to have changed, should have changed on the honeypot host(s).
However, if a honeypot is using real vulnerabilities in an operating system installed in a virtual machine (or on a physical host for that matter), then it will be necessary to restore that operating system to a known clean state after each infection. This is typically achieved using snapshots (for virtual machines) or re-imaging software (for physical machines).
To be continued…
There’s more musing to be done, so don’t miss ‘Building a Honeynet on Linux: Network Infrastructure’.