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. This second part will describe how I set up the network infrastructure for my honeynet lab.
My honeynet lab consists of three networks, isolated by a honeywall host:
- External honeynet network
- Internal honeynet network
- Honeynet management network
Software implemented network bridges, on the virtual host machine (the server which is running your virtual machines), will implement each of these networks. A network bridge is a network device which simply copies network frames from one side to the other, or from one of its interfaces to all of its other interfaces.
The names given to the bridges is arbitrary, but I have used names which reflect the bridge’s purpose. They start with ‘br-‘ to distinguish them from other, non-bridge, network interfaces in ‘ifconfig’ output, and then ‘hnet-‘ so that all the honeynet bridges appear together in sorted output.
Note that a bridge does not route the packets, but merely copies them. It is a bit like an Internet ‘chat room’, in that people join the chat room (the ‘bridge’) and then any message that any chat room member (an interface attached to the bridge) sends to the chat room, gets sent to every other member (all the other interfaces) of the chat room.
External Honeynet Network
The external honeynet network is the small network which connects my honeynet network to the Internet. To the honeynet environment, this network is the external (or Internet) network, in that anything out here is probably evil.
A bridge called ‘br-hnet-ext’, will implement this network on the virtual host machine. It will consist of the external network interface on the honeywall host, and a dedicated interface on my firewall. My firewall is then told that my internal honeynet network is directly connected to this dedicated interface.
Note that to the firewall, the internal honeynet network is directly connected and not routed through the honeywall host. This is because the honeywall host acts as a network bridge, and is hence transparent to anything above the data link layer (Ethernet in this case) — it will simply copy the Ethernet frames between its external interface and its internal interface, without them being explicitly addressed to it.
Use the following command, on the virtual host system, to create the ‘br-hnet-ext’ bridge which will bridge Ethernet frames between the firewall and the honeywall host:
brctl addbr br-hnet-ext
Add the virtual, or physical, network interface on the virtual host system, connecting your honeynet to your firewall. Use the following command:
brctl addif br-hnet-ext # for instance 'brctl addif br-hnet-ext eth0', if eth0 is the Ethernet interface used to connect your virtual host to your firewall.
We will add the honeywall host’s external interface after we have built its virtual machine.
Internal Honeynet Network
The internal honeynet network is the honeynet network itself, to which all your honeypot hosts will connect. A bridge called ‘br-hnet-int’ (despite the ambiguity between ‘int’ for internal, and ‘int’ for ‘Internet’ — you might want to pick a better name) on the virtual host machine will implement this network.
Use the following command to create the ‘br-hnet-int’ bridge which will bridge Ethernet frames between the internal interface on the honeywall host, and the network interface’s of the honeypot hosts.
brctl addbr br-hnet-int
We will add the honeywall and honeypot interfaces after we have built those virtual machines.
Honeynet Management Network
The honeynet management network is the network used to connect our management host(s) to the honeynet. The network bridge ‘br-hnet-mgt’ is used to implement this network on the virtual host machine.
In my case, I have one management host, which is the host which receives a copy of the malware collected by the honeypot host, and hosts the SURFcert IDS database and web interface.
It is a good idea to keep this management network separate from the honeynet internal network, where malware is free to infect other systems on that network; and separate from your non-honeynet networks. We don’t want to risk a potential breach of our non-honeynet systems in the event that something goes awry. When dealing with malware, and especially running malware, it is always good to have a ‘careful now’ mentality.
Use the following command to create the ‘br-hnet-mgt’ bridge which will bridge Ethernet frames between the management interface on the honeywall host, and the network interface of any management hosts:
brctl addbr br-hnet-mgt
Again, we shall add the interfaces after we have built the virtual machines.
To be continued…
Stay tuned as, believe it or not, it does get more exciting. The next part of the series will describe the process used to create the KVM virtual machines and attach them to the network bridges that we just created.
A diagram or 2 would assist my small brain in understanding how things are connected from whatever your terminate your public IP onto.
Do you use ebtables or similar to add any additional protection / security for the honeywall host ?
I know — I was thinking as I was writing it, that I really ought to include a diagram to show the network topology. However, I don’t yet know how to do this on Linux. I hope to find out one day and then revisit this post and add a diagram.
The honeywall host is an installation of the Honeynet Project’s Honeywall CDROM. It isn’t using ebtables (bridge firewall).
The two interfaces through which Internet traffic passes do not have an IP address on them.
The management interface has a private IP address on it which cannot be routed over the Internet.
iptables is used to restrict access to the management interface and to other hosts.
This will be discussed in more detail in the post describing the Honeywall virtual machine. I’ll get there eventually!
I hope that this has answered your questions.
Pingback: Building a Honeynet on Linux: Introduction | Malware Musings