Per-Analysis Network Routing¶

Simple Global Routing¶

Before delving into the more complex and feature-rich per-analysis network routing we’ll first cover the older approach, which is based on global iptables rules that are, once set, not changed anymore.

In the following setup we’re assuming that the interface assigned to our VirtualBox VM is vboxnet0, the IP address of our VM is 192.168.56.101 (in a /24 subnet), and that the outgoing interface connected to the internet is eth0. With such a setup, the following iptables rules will allow the VMs access to the Cuckoo host machine (192.168.56.1 in this setup) as well as the entire internet as you would expect from any application connecting to the internet.

$ sudo iptables -t nat -A POSTROUTING -o eth0 -s 192.168.56.0/24 -j MASQUERADE

# Default drop.
$ sudo iptables -P FORWARD DROP

# Existing connections.
$ sudo iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# Accept connections from vboxnet to the whole internet.
$ sudo iptables -A FORWARD -s 192.168.56.0/24 -j ACCEPT

# Internal traffic.
$ sudo iptables -A FORWARD -s 192.168.56.0/24 -d 192.168.56.0/24 -j ACCEPT

# Log stuff that reaches this point (could be noisy).
$ sudo iptables -A FORWARD -j LOG

And that’s pretty much it, with these rules set we’re almost good to go. However, these rules won’t be doing any packet forwarding unless IP forwarding is explicitly enabled in the kernel. To do so, there is a temporary method that survives until a shutdown or reboot, and a permanent method that is taken into account when booting the machine. Simply put, generally speaking you’ll want to run both commands:

$ echo 1 | sudo tee -a /proc/sys/net/ipv4/ip_forward
$ sudo sysctl -w net.ipv4.ip_forward=1

Iptables rules are not persistent between reboots, so if want to keep them you should use a script or just install iptables-persistent.

Newer Linux distributions have adopted udev’s interface-naming scheme. It’s important to note that this means eth0 may no longer be your primary interface. Possible interface names include ensXX, enp0sXX, and emXX, where the XX part identifies a number. This is particularly important to note for the NAT statement above.

Per-Analysis Network Routing Options¶

Having discussed the old school method for routing analyses through a network interface we will now walk through the dynamic network routing components that allow for much more granular network routing.

As outlined in the introduction for this chapter of the documentation it has been possible since Cuckoo 2.0-rc1, when we introduced the Cuckoo Rooter, to do per-analysis network routing. Since then various bugs have been resolved and more network routing options have been added.

Following is the list of available routing options.

Using Per-Analysis Network Routing¶

Having knowledge about the available network routing options it is time to actually use it in practice. Assuming Cuckoo has been configured properly taking advantage of its features is really as simple as starting the Cuckoo Rooter and choosing a network routing option for your analysis.

Documentation on starting the Cuckoo Rooter may be found in the Cuckoo Rooter Usage document.

Both global routing and per-analysis routing require ip forwarding to be enabled:

$ echo 1 | sudo tee -a /proc/sys/net/ipv4/ip_forward $ sudo sysctl -w net.ipv4.ip_forward=1

Configuring iproute2¶

For Linux kernel TCP/IP source routing reasons it is required to register each of the network interfaces that we use with iproute2. This is trivial, but necessary.

As an example we’ll be configuring Internet Routing (aka the dirty line) for which we’ll be using the eth0 network interface - reverting back to Ubuntu 14.04 and older terminology here for a second (Ubuntu 16.04 uses network interface names based on the hardware manufacturer, as you will likely have seen happen on BSD-based systems since forever).

To configure iproute2 with eth0 we’re going to open the /etc/iproute2/rt_tables file which will look roughly as follows:

#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#

Now roll a random number that is not yet present in this file with your dice of choice and use it to craft a new line at the end of the file. As an example, registering eth0 with iproute2 could look as follows:

#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#

400     eth0

And that’s really all there is to it. You will have to do this for each network interface you intend to use for network routing.

[inetsim]
enabled = yes
server = 192.168.56.1

TransPort 192.168.56.1:9040
DNSPort 192.168.56.1:5353

[tor]
enabled = yes
dnsport = 5353
proxyport = 9040

[vpn]
# Are VPNs enabled?
enabled = yes

# Comma-separated list of the available VPNs.
vpns = vpn0

[vpn0]
# Name of this VPN. The name is represented by the filepath to the
# configuration file, e.g., cuckoo would represent /etc/openvpn/cuckoo.conf
# Note that you can't assign the names "none" and "internet" as those would
# conflict with the routing section in cuckoo.conf.
name = vpn0

# The description of this VPN which will be displayed in the web interface.
# Can be used to for example describe the country where this VPN ends up.
description = Spain, Europe

# The tun device hardcoded for this VPN. Each VPN *must* be configured to use
# a hardcoded/persistent tun device by explicitly adding the line "dev tunX"
# to its configuration (e.g., /etc/openvpn/vpn1.conf) where X in tunX is a
# unique number between 0 and your lucky number of choice.
interface = tun0

# Routing table name/id for this VPN. If table name is used it *must* be
# added to /etc/iproute2/rt_tables as "<id> <name>" line (e.g., "201 tun0").
# ID and name must be unique across the system (refer /etc/iproute2/rt_tables
# for existing names and IDs).
rt_table = tun0