Network-based Moving Target Defense

Background

• Software Defined Network

Motivation

• Scanning Worms
• [3] Scanning tools and worms usually send probes to random IP addresses in the network in order to discover their targets. 
• When a target responds, it can then be identified and attacked. Otherwise, the probed addresses will be considered unused.
• Despite firewall deployment, most enterprise networks have many public and private hosts accessible from outside. 
• The IP address assignment scheme can become more dynamic by using approaches based on DHCP or NAT, but they are insufficient to provide proactive countermeasure because the IP mutation is infrequent and traceable.
• Network mapping threat

Previous Work

• DHCP
• Prior work focused on defending hit-list scanning malware utilized DHCP to change the IP address of the host over time
• However, this change can disrupt existing connections.
• This can be solved by placing an intermediate NAT-like box in the network and transparently transition to the new address over time.
• The NAT-like device provided similar address translating behavior, with additional logic to preserve old addresses while they are still in use by previously established connections. 
• IP address randomization [4]
• Rather than changing out the DHCP lease to achieve randomization, they randomly rotate the IP address contained in the DNS reply and notified the NAT device.
• The NAT device then allows new connections with that IP to reach the requested host by mapping it to the host's fixed internal address.
• NAT
• Using NAT to hide the real IP address of the server will make it difficult to reach legitimate hosts remotely. [8]

• Network Address Space Randomization (NASR) [7]
• It was proposed to offer an IP hopping approach that can defend against hitlist worms.
• NASR is a LAN-level network address randomization scheme based on DHCP updates.
• Cons
• Not transparent
• NASR is not transparent to end-hosts because DHCP changes are applied to the end-host itself which results in disruption of active connections during address translation.
• Expensive to deploy
• Moreover, it requires changes to the end-host operating system which makes its deployment very costly.
• Limited unpredictability
• Also, NASR provides very limited unpredictability and mutation speed because its IP mutation is limited on the LAN address space and will require DHCP and host to be reconfigured for this purpose (the maximum IP mutation speed in once very 15 minutes). 

Network Address Randomization

• IP address randomization [5]
• Requires the DNS gateway in both the clients and servers to do the translation

DNS Capability Approach

• Ref [6][2]
• The mapping system was implemented using two components
• A DNS server
• Provide clients with the destination IP address of a targeted server at that moment
• A NAT mapping device
• Grant the client access to the server when a destination mapping is used.
• It stores the state for each established flow, allowing the DNS server to change addresses and providing a unique response to each new client without disrupting the established flow. 
• My questions
• As the NAT needs to maintain so many states, will it result in DDoS attack?

OpenFlow Mutation Approach

• Ref [6] [3]
• Similar to DNS Capability approach.
• The network switches plays the role of NAT devices.
• When the switch receives a packet and does not known how to forward the packet, it can ask for instructions (called elevation) from a specific machine, called the OpenFlow controller.
• The OpenFlow mutation approach uses this elevation mechanism to alter the NDS records and to change packet address in flight. 
• When a client performs a DNS lookup, the DNS server will provide the client with a virtual IP address for a target. 
• When the client attempts to access the target, the packet is forwarded using the virtual IP address until it reaches the destination switch, at which point it is translated to the destination host's real IP address. The network switches essentially act as NAT devices, performing translations between virtual and real IP addresses. 

Communication via Name

• Steps 1-3
• When a DNS query is sent to resolve the name of a host
• The DNS response is updated by the NOX controller to replace the rIP of the server with its active vIP
• The NOX controller also sets the TTL value in the DNS response to a small value. 

• Step 4
• The source host can then initiate the connection using the vIP of the destination
• The OF-switch encapsulates and sends the initial packet to the controller, because there is no matching flow for it.
• Step 5
• The NOX controller installs relevant flows in OF-switches in the route.
• These flows are associated with relevant required Set-Field actions which determine the translation of source/destination rIP addresses to/from vIP addresses
• Relevant flows are installed in destination OF-switch as well. Any other switches in the path are only configured (i.e., flows with no actions) to route the traffic based on vIP. 
• Future packets will be matches and forward by OF-switches (without being sent to controller) according to the installed flows in the flow table.
• The vIP-rIP translation actions will be applied to packets by OF-switches. 

Communication via rIP address

Figure 3 shows how authorized users (e.g., administrator) can reach hosts using rIPs. In this case, the source host initiates a connection with the destination using its rIP. 

• Step 1
• Similar to DNS scenario, the OF-switch will fail to match the new packet with any flow and sends it to NOX controller
• Step 2
• The NOX controller authorizes the access request
• Step 3
• If granted, the controller installs appropriate flows in OF-switches in the route with appropriate vIP-rIp translation actions according to Figure 3

If the source host is internal, NOX controller installs two inbound and outbound flows in source OF-switch, same to DNS scenario. 

Two flows are also inserted in the flow table of destination OF-switch.

However, destination flows require no translation, because the destination host is being reached via its rIP. 

MT6D Approach

• Ref [6][1]
• The client and the server share a symmetric key out-of-band and use these keys to determine the IPv6 addresses the hosts will use.
• To construct their IPv6 address
•  the hosts construct a hash using the shared key, a value derived from the host's MAC address, and a timestamp. The approach extracts 64 bits from the hash output to encode the lower 64 bits of the host's IPv6 address.
• To perform uniform communication between the host applications, the operating system on each host uses a tunneling approach and rotates the addresses of the tunnel end-points. 
• Cons
• Organizations cannot protect public-facing server infrastructure without requiring clients to install software
• The MT6D approach is only effective when both the client and the server can be modified, which prevents its use when protecting public infrastructure for legacy clients. 

Reference

[1] MT6D: A moving target IPv6 defense, by M. Dunlop et al, in Military Communications Conference 2011.

[2] On building inexpensive network capabilities. by C. A. Shue et al, in SIGCOMM 2012

[3] OpenFlow random host mutation: Transparent moving target defense using software defined networking, by J. H. Jafarian, in HotSDN 2012
[4] The SDN Shuffle: Creating a Moving-Target Defense using Host-based Software-Defined Networking, by Douglas C. Macfarland, in MTD15
[5] Adversary-aware IP Address Randomization for Proactive Agility against Sophisticated Attackers, by Jafar Haadi Jafarian, in INFOCOM 2015
[6] Characterizing Network-Based Moving Target Defense, by Douglas C. MacFarland, in MTD15
[7] Defending against Hitlist Worms using Network Address Space Randomization, by S. Antonatos, in Computer Network 2007
[8] Random Host Mutation for Moving Target Defense, by Ehab Al-Shaer, Qi Duan, and Jafar Haadi Jafarian, in Securecomm 2012