Crossfire DDoS Protection - A Moving Target Defense (MTD) Framework For Distributed Systems

1. Crossfire DDoS Protection
A Moving Target Defense (MTD) Framework For
Distributed Systems
Presented By: Muhammad Farjad Noor

2. Introduction
 The most common problem in online hosts & networks are easy targets
of network attacks caused by their static nature. Distributed Denial-of-
Service (DDoS) attacks pose one of the severest security threats to
today’s Internet services.
 Makes an information asymmetry and makes it effortless for the
attackers to attack and hard to defend for the defender .
 To breakdown the asymmetry nature of information, Moving Target
Defense mechanism was proposed to bring uncertainties to computer
systems.

3. Moving Target Defense
 To transform this attack and defense game, Moving Target Defense –
MTD was proposed by the researchers to break the asymmetry among
the attacker and defender.
 There are many methods that have been proposed to mitigate security
threats using this mechanism.
 The existing studies on MTD can be separated into two levels, network
& system level.
 The network level solutions include IP address reshuffling, network
configuration randomization, and so on.
 The system level MTD methods cover software applications, platform,
and runtime environment. All these methods are still in the phase of
prototype and far from mature for deployment.

4. IMPLEMENTATION
 In order to achieve the objective we proposed two approaches. Either
by changing the servers with different IPs or by the changing the
communication port of specific server at regular interval of time.
 The whole project can be divided into four major components.
 Client
 DNS Resolver
 Web Server(s)
 Reverse Proxy Server

5. Cont..
 Client – A client is required to send http(s) request. In our case, Client is our host
machine on which the whole virtualized setup is created using Oracle VirtualBox.
 DNS Resolver – A client does not know the IP behind the website he is requesting. A
DNS resolver is required to resolve the name to IP address. In order to achieve this
objectivity, either you need to setup a DNS service (Bind9 – Famous DNS service for
Linux machine) or you can put a manual entry in local hosts file for DNS resolution.
You can find the file at the following directory if client is using Windows as OS
“C:WindowsSystem32Driversetc”
 Web Server – We created two virtual instances with Ubuntu Server Image (Ubuntu
18.04) on which we installed and configured Apache Server to serve http(s)
requests.
 Reverse Proxy Server – A Reverse Proxy server has been introduced as a middle
layer between Client and Web Server to keep the whole process of re-assignment
and shuffling of IPs or ports transparent to the user. Whenever a client will request,
it will always be redirected to Reverse Proxy server (by the DNS resolver) who will
decide from where the requests can be currently served.

6. First Approach
 These diagrams depict the two topologies at
random intervals of time. The connection
between Reverse Proxy server and Web
Server will keep changing at regular intervals.
The only major change here will be the
server on which Reverse Proxy is forwarding
all Client requests to Web Server. This re-
assignment/shuffle of server will remain
transparent to requesting Client. This
approach can be restricted to choose
between active servers in some order for
communication or can be used to randomly
select any of them. For now, we have
decided to take two active servers operating
at 192.168.56.5 and 192.168.56.6 for
implementation.
 We have implemented a bash script to
switch reverse proxy server configuration
and add it to cron to execute it at decided
regular interval of time.

7. Second Approach
 Below diagrams depict the four different topologies at
random intervals of time. The connection between
Reverse Proxy server and Web Server will keep
changing at regular intervals. The only major change
here will be the port on which Reverse Proxy is
forwarding all Client requests to Web Server. This re-
assignment/shuffle of communication ports will remain
transparent to requesting Client. As a security measure,
whenever a new port is assigned for communication. All
other ports that were previously used for
communication will be disabled. This approach can be
restricted to use specified range of ports for
communication or can be expanded to randomly
selected port(s). For now, we have decided to take four
ports from 8888 to 8891 for implementation.
 We have implemented a bash script to switch reverse
proxy server configuration and add it to cron to execute
it at decided regular interval of time.
 SSH password-less login is also required because we
are enabling/disabling the serving port(s) of webserver
from Nginx Reverse Proxy Server using implemented
script.

8. THANK YOU!