Honeypot Farms using Ethernet Bridging over a TCP Connection
- 1. Honeypot Farms Using Ethernet Bridging over a TCP Connection Bruno Morisson <[email protected]> Marco Vaz <[email protected]> Pedro Inácio <[email protected]> The Honeynet Project - Portugal http://www.honeynet-pt.org March 2005 Abstract This paper describes a methodology and a prototype tool based on libpcap, libnet, mini-lzo and openssl, with the main objective of mitigating honeypot farm deployment complexity. Ethernet bridging over a TCP connection and vlan tagging are used as the way to simplify the deployment of the remote honeypots and achieve better overall results. Keywords Honeypot, honeynet, ethernet bridging, vlan, snort-inline, TCP
- 2. Introduction • Honeypot farms use routing rather than bridge, so they are As already presented by Edward Balas in complex to configure and chapter 7 of “Know Your Enemy, 2nd require good network Edition”, Honeypot Farms are used as a knowledge to operate properly. way of virtually distributing honeypots, • This technology is fair new, transporting IP packets from remote there are no tools to help locations to the physical honeypots. It aims automate the configuration and to reduce cost, deployment time and operation of the analysis time. infrastructures. We decided to embrace and simplify this concept of traffic tunneling because it The Portugal Honeynet Project developed gives us the ability to optimize our its own prototype tool, Kangaroo, to help methodology of analysis. Our aim was to us with those tasks. With this tool, it is use bridging rather than routing for possible to tunnel ethernet traffic from transporting the traffic from remote remote locations to the farm on a TCP locations to our honeypots on the farm. connection, injecting it in the physical Bridging provides the simplicity of traffic honeypot Ethernet card/switch. transportation. Since Kangaroo relies on libpcap and libnet for capturing and injecting packets, it This approach enables: doesn't require any kernel patches/modules, and it should be simple • Quickly access to the compromised to port it to most modern operating equipments. systems. • Reduce the physical space required in ISP housing. • Decrease the number of control Architecture equipments (bridge, firewall and database) The topology deployed is based on a Gen II • Transparency honeynet. The big difference is that we are isolating the honeypots using 802.1q, creating virtual interfaces on our bridge As Edward Balas puts it: server. The bridge server has one virtual interface per network segment. Advantages of honeypot farms All traffic to and from the honeypots will • Honeynets can be deployed be bridged by the central server and the with in a very short amount of remote servers. The remote servers will time. create TCP connections to the central • Forensic analysis can be done server, through which interesting traffic faster. will be tunneled both ways. • Honeypot farms can be used to protect production servers (hot-zoning). • Participant networks don’t need to configure or monitor the honeypots. Disadvantages of honeypot farms • Geographic unrelated positions cause anomalies in network latency.
- 3. operational needs. Filtering rules can also be applied via BPF on both ends of the tunnel. Another important advantage is that libpcap makes Kangaroo a truly platform- independent application. Transparency This approach to traffic tunneling can be described as medium-independent and inherently protocol-independent. Any LAN medium that can be captured with libpcap and injected with libnet can be tunneled with Kangaroo. Contrary to routing, using bridging there is no way for an attacker to detect that the machine is not physically located next to the others on the same subnet, except for the added latency. Performance Latency: There is, obviously, added latency to the connection. To reduce it, Kangaroo Traffic to the honeypot: offers the ability to compress the packets. The remote client captures the Ethernet Scalability: For now, one instance of frames sent to the honeypot's IP address (as Kangaroo is required for each tunnel well as relevant ARP requests/answers), an created, so for now scalability is an issue at sends the frames through the TCP that level. It is also an issue with the connection to the central server. The bridge, since there is only one snort inline central server receives the frames from the instance which must process every packet TCP connection, and injects them in the for every honeypot. desired interface. Traffic from the honeypot: Example Setup The central server captures the Ethernet frames sent from the honeypot's IP address In the example setup there are two remote (as well as relevant ARP requests/answers), sensors with Kangaroo that will forward and and sends the frames through the TCP receive the traffic to and from the connection to the remote client. The honeynet Firewall. remote client receives the frames from the TCP connection, and injects them on the The firewall will encapsulate each stream local network. into dot1q and send the trunk back to the Bridge. BPF – BSD Packet Filter The SnortInline bridge has several virtual bridges and each one is composed by pairs Using libpcap to capture the packets gives of dot1q interfaces. One SnortInline process the possibility to create a set off powerful is enough to process all bridges. filtering rules that will reduce the transported traffic to the minimal
- 4. The switch located behind the SnortInline • ./kangaroo -C -u user -g group -p 4791 -l Bridge will split the trunk traffic, putting 80.x.y.z -i eth1.2 -f 'src host 100.x.y.z' each VLAN in a separate port. Kangaroo will inject traffic coming from RemoteSensor to the VLAN 2 There are two honeypots, one on VLAN 2 interface on the firewall and other on VLAN 3. • ./kangaroo -C -u user -g group -p 4792 -l 80.x.y.z -i eth1.3 -f 'src host 99.x.y.z' Kangaroo will inject traffic coming Honeypot1 will have the (public) IP address from RemoteSensor to the VLAN 3 99.x.y.z and honeypot2 will have the (also interface on the firewall public) IP address 100.x.y.z. The IP address for the firewall’s outside interface (public) will be 80.x.y.z Configuration on the SnortInline Bridge • vconfig add eth0 2 Creation of the VLAN 2 interface on the inside Ethernet NIC. • vconfig add eth1 2 Creation of the VLAN 2 interface on the outside Ethernet NIC. • vconfig add eth0 3 Creation of the VLAN 3 interface on the inside Ethernet NIC. • vconfig add eth1 3 Creation of the VLAN 3 interface on the outside Ethernet NIC. • Creation of the brctl add eth0.2 br2 VLAN 2 interface on the inside Ethernet NIC. • Creation of the brctl add eth1.2 br2 VLAN 2 interface on the outside Ethernet NIC. Configuration on the remote sensors • ./kangaroo -C -u user -g group -p 4791 -c • Creation of the brctl add eth0.3 br3 80.x.y.z -i eth0 -f 'dst host 99.x.y.z' VLAN 2 interface on the inside Kangaroo will capture and inject Ethernet NIC. traffic from and to RemoteSensor1 • Creation of the brctl add eth1.3 br3 • ./kangaroo -C -u user -g group -p 4792 -c VLAN 2 interface on the inside 80.x.y.z -i eth0 -f 'dst host 100.x.y.z' Ethernet NIC. Kangaroo will capture and inject traffic from and to RemoteSensor2 • iptables –A FORWARD –s 99.x.y.z –j ACCEPT Firewall rule to permit Configuration on the Firewall inbound traffic to the honeypot1. • vconfig add eth1 2 Creation of the • iptables –A FORWARD –d 99.x.y.z –j VLAN 2 interface on the inside QUEUE Firewall rule to queue Ethernet NIC. outbound traffic from the • vconfig add eth1 3 Creation of the honeypot1. VLAN 3 interface on the inside Ethernet NIC.
- 5. • iptables –A FORWARD –s 100.x.y.z –j ACCEPT Firewall rule to permit Libnet inbound traffic to the honeypot2. http://www.packetfactory.net • iptables –A FORWARD –d 100.x.y.z –j Mini-LZO QUEUE Firewall rule to queue http://www.oberhumer.com outbound traffic from the honeypot2. Openssl http://www.openssl.org The Honeynet Project http://www.honeynet.org TODO Book – Know Your Enemy, 2nd Edition • The prototype code is being http://www.honeynet.org/book completely re-written. • Multiplexing - One central Kangaroo daemon for several remote servers. • Direct integration with snort-inline • Performance enhancements • SSL enhancements(Certificates for authentication, stream encryption for performance) Conclusions Using the methods described, with the aid of Kangaroo, Linux bridging, VLAN tagging, and snort inline, is is possible to truly decentralize honeynets, deploying honeypots remotely, while keeping all the hardware centralized at a close location. This also allows for costs reduction on hardware: there is no need to replicate honeynets in every participating network. We need can use the same firewall, bridge, log server, etc., for every honeypot deployed. With Kangaroo routing configuration troubles can be avoided, and network transparency obtained. Since Kangaroo was specifically thought for this application, its configuration is also simple and straightforward. References Kangaroo http://www.honeynet- pt.org/research/kangaroo-0.5.0a.tar.gz Libpcap http://www.tcpdump.org