|
|
So far we have seen how Honeyd can be used to simulate a bunch of virtual honeypots that were all living on their own dedicated network or were mixed into existing production networks. Instead of just simulating hosts, Honeyd can also simulate arbitrary routing topologies. This feature can be used not only to deceive adversaries but also to fool network mapping tools:
Code View: route := "route" "entry" ipaddr |
"route" "entry" ipaddr "network" ipnetwork |
"route" ipaddr "link" ipnetwork |
"route" ipaddr "unreach" ipnetwork |
"route" ipaddr "add" "net" ipnetwork "tunnel" ipaddr(src) ipaddr(dst)|
"route" ipaddr "add" "net" ipnetwork ipaddr ["latency" number"ms"]
["loss" percent] ["bandwidth" number["Mbps"|"Kbps"]
["drop" "between" number "ms" "-" number "ms" ]
|
Honeyd does not completely emulate all aspects of a network like NS-based simulators [23], which try to faithfully reproduce network behavior to understand it. Instead, it simulates just enough to deceive adversaries and the common network mapping tools that they might use. When simulating routing topologies, techniques like Proxy ARP no longer work to direct the packets to the Honeyd host. Instead, we need to configure a router to delegate network address space to the host on which Honeyd is running.
To create a virtual routing topology with Honeyd, the configuration file has to start with a route entry line that specifies the IP address of the first router in the topology and tells Honeyd where the routing should start. Usually, a virtual routing topology can be visualized as a tree rooted at the entry node. Each interior node of the tree represents a router, and each edge represents a link that contains latency and packet loss characteristics. Leave nodes correspond to networks. Honeyd supports multiple entry points that can exit in parallel if each entry router is configured with a network space for which it is responsible.
After you have specified a route entry, each router can be configured individually with networks that are reachable directly with the link statement and networks for which another router is responsible via the add net statement, for example:
route entry 192.168.1.1 route 192.168.1.1 link 192.168.1.0/24 route add net 192.168.2.0/24 192.168.2.1 latency 10ms |
In this particular case, the entry router 192.168.1.1 can talk to its own network (192.168.1.0/24) directly but needs to forward packets for 192.168.2.0/24 to the router 192.168.2.0. Any machine that should be reachable in a routing topology should be in a network contained in a link statement, including the routers themselves.
route entry 10.0.0.1 route 10.0.0.1 link 10.0.0.0/24 route 10.0.0.1 add net 10.1.0.0/16 10.1.0.1 latency 55ms loss 0.1 route 10.0.0.1 add net 10.2.0.0/16 10.2.0.1 latency 20ms loss 0.1 route 10.1.0.1 link 10.1.0.0/24 route 10.2.0.1 link 10.2.0.0/24 bind 10.1.0.3 to fxp0 |
To simulate an asymmetric network topology, we consult the routing tables when a packet enters the framework and again when it leaves the framework. In this case, the network topology resembles a directed acyclic graph.[2] In the preceding example, the router 192.168.1.1 would reply to ping statements because it is reachable via the link statement. If your link statement had been link 192.168.1.128/23, the router would have been considered unreachable.
[2] Although it is possible to configure routing loops, this is normally undesirable and should be avoided.
When the framework receives a packet, it finds the correct entry routing tree and traverses it, starting at the root and proceeding until it finds a node that contains the destination IP address of the packet. Packet loss and latency of all edges on the path are accumulated to determine if the packet is dropped and how long its delivery should be delayed.
The framework also decrements the time to live (TTL) field of the packet for each traversed router. If the TTL reaches zero, the framework sends an ICMP time exceeded message with the source IP address of the router that causes the TTL to reach zero.
For network simulations, it is possible to integrate real systems into the virtual routing topology. When the framework receives a packet for a real system, it traverses the topology until it finds a virtual router that is directly responsible for the network space to which the real machine belongs. The framework sends an ARP request, if necessary, to discover the hardware address of the system, and then encapsulates the packet in an Ethernet frame. Similarly, the framework responds with ARP replies from the corresponding virtual router when the real system sends ARP requests.
We can split the routing topology using GRE to tunnel networks. This allows us to load balance across several Honeyd installations by delegating parts of the address space to different Honeyd hosts. Using GRE tunnels, it is also possible to delegate networks that belong to separate parts of the address space to a single Honeyd host. For the reverse route, an outgoing tunnel is selected based both on the source and the destination IP address.
The configuration in Figure 5.8 is a little bit difficult to understand, but it illustrates how a router can delegate traffic via GRE to a Honeyd installation. In this case, router 224.200.0.3 delegates the address space 10.1.4.0/24 to a Honeyd machine running at 192.168.1.6. This means that whenever the router receives a packet for an IP address within 10.1.4.0/24, it encapsulates it via GRE and forwards it to 192.168.1.6. When Honeyd receives the packet, it decapsulates it and finds the correct entry point in its virtual routing topology. At some point, a virtual honeypot gets to answer to the packet. The honeypot creates a response packet that sets the original source IP address as the destination IP addresses and uses the IP address of the honeypot as the source. The reply is then propagated up the routing tree. However, here is where the tricky part begins: Instead of leaving the virtual routing topology, the packet on its reverse path hits the entry
route 10.1.4.1 add net 0.0.0.0/0 tunnel 192.168.1.6 224.200.0.3
route entry 10.1.4.1 network 10.1.4.0/24 route 10.1.4.1 add net 0.0.0.0/0 tunnel 192.168.1.6 224.200.0.3 route 10.1.4.1 link 10.1.4.0/24 create cisco-net2 set cisco-net2 default tcp action reset set cisco-net2 personality "CISCO 4500 running IOS 11.2(2)" add cisco-net2 tcp port 23 "scripts/router-telnet.pl" bind 10.1.4.1 cisco-net2 include hosts-10.1.4.0 |
When Honeyd propagates a packet up the routing topology to find the proper exit, the 0.0.0.0/0 entry lets Honeyd know that the packet originally came from the router at 224.200.0.3. So it encapsulates the packet via GRE and sends it off. The router at 224.200.0.3 receives it and injects the traffic into the real Internet. Besides latency, there is no way for an adversary to tell that his packet was handled somewhere else completely. Clever usage of GRE can also be used to balance loads between multiple Honeyd instances.
|
|