3 comments on “Building a Honeynet on Linux: Introduction

  1. How do you know when your honeypot has been infected by malware? How long after the event before you know?

    • Hi John,

      Good question, and something which is quite important to know.

      This is something which, when I first started using honeypots, I would do manually by sitting and watching a network capture for tell tale signs such as outbound network connections, in which case you know pretty much instantly.
      Usually, after a successful infection, you will see connection attempts to lots of different IP addresses and to the same destination port that the attack came in on. This is why it is generally not a good idea to allow your public web servers to get out on port 80/tcp, and a good idea to split your inbound and outbound email servers and stop your public inbound mail server from getting out on port 25/tcp — it naturally restricts the ability of a compromised host to compromise other (remote) hosts, but I digress.

      That manual approach was annoyingly arduous and so these days I use some software which emulates vulnerabilities, and it performs what it believes the malware is trying to do. This emulating software (which will be mentioned in the part subtitled ‘Honeypot Host’) is configured to log to a SURFcert IDS database. I notice new malware downloads and attacks by occasionally checking the database using the SURFcert IDS web interface.

      As my honeypot is using software to emulate the vulnerabilities, it doesn’t (unless the emulating software is explicitly targeted) actually get infected, and hence I feel that this is sufficient.

      However, if you are going to be running a live operating system (as opposed to emulating vulnerabilities) on your honeypot, then unless you’ve got nothing better to do you will want to automate the processes of detection, archiving the malware sample and log files, shutting down the honeypot, cleaning up (revert a virtual machine to a snapshot, or re-image a physical machine), and restarting the honeypot. You would include some method of notification as part of the automation, in which case the notification in this case would be close to instantaneous.

      Having said that, if you are just starting out with honeypots then it can be interesting to take the manual approach of sitting and watching the network traffic, as it gives you the opportunity to go back afterwards and watch the attack unfold.

      I started discussing ways in which this automation could be done, but that created a humongous comment reply, so I figured that it would be a good topic for a future blog entry.

      I hope that this has answered your questions.

      Musingly,
      Karl.

      • Thanks Karl. That’s an excellent answer. You obviously know your stuff! And yes, I would use your answer as a blog post in its own right!
        Thanks.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s