![](bg3.png)
transparent router. The decoy network in this study is
presented as a placeholder and is not detailed. Else, it
is possible to use this network to redirect adversaries
or observe their actions further on a honeynet.
Slowloris and similar DoS attacks harm the avail-
ability of a web server even before connections are es-
tablished. Since the attack traffic will not include the
correct message authentication keys, MaTaDoR for-
wards this traffic into a decoy server. Even if the de-
coy server rendered unavailable, the legitimate users
of the genuine server are not affected. However, from
the adversary’s point of view, disrupting the service of
the website make them think their attack is success-
ful at first sight. Such additional confusion is another
layer of ambiguity for the adversary.
The relaying nature of MaTaDoR is transparent as
seen in Figure 1. The sole functionality of MaTaDoR
is to verify the message authentication header and de-
termine the future flow of the traffic. A realistic sce-
nario is to place MaTaDoR in between two organiza-
tions that share non-public network services without a
dedicated VPN (Virtual Private Network) or a leased-
line. Message authentication key is assumed to be
set up during initialization. Further key management
issues are deliberately keep out of the scope of the
discussion. A second, decoy server is also placed in
Figure 1 to handle attacker attention whenever MaTa-
DoR fails to authenticate the message. Moreover, the
decoy server could be replaced with an honeynet that
logs attacker behavior or non-verified segments could
simply be dropped.
The network topology presented in Figure 1 rep-
resents the aforementioned scenario with two clients,
two web servers and MaTaDoR. One of the clients
(marked red in Figure 1) represent the malicious IP
space where DoS attack is originating from. The
packets from the malicious IP space have missing or
incorrect MAC. The other client (marked blue in Fig-
ure 1) represent the benign users who want to use
the web server. The genuine web server represents
the protected resource. Finally, the decoy web server
is equivalent to the genuine resource, but consists of
mechanisms to distract adversarial efforts. As in ev-
ery other MTD solution, the adversary is hopefully
tricked to think that no defense mechanism exists to
protect the asset.
The flow is shown in Figure 2a when a segment
is authenticated. MaTaDoR verifies the authentica-
tion header, then directs the traffic to the web server
if the MAC verification is successful. The genuine
web server gets the segments and continues by send-
ing an acknowledge message to establish TCP hand-
shake with the authenticated client. The genuine web
server can directly see the initiator IP address of the
client, as MaTaDoR is transparent. Thus, the server
can directly send the response to that client. There-
fore MaTaDoR allows to establish the communication
of legitimate users and the genuine web server.
Whenever a packet authentication fails, MaTaDoR
redirects the packet to the decoy server. The flow of
unauthenticated segments is shown in Figure 2b. De-
coy server can also see the IP address of the initiat-
ing client. Therefore, the adversary might believe as
if they are directly connected to the server, without
any interceptors. Thus, unauthenticated or unwanted
messages are directed to the decoy server and genuine
server can continue its normal operation.
A DoS attack example in which the adversary
never finishes TCP handshake to waste the resources
of benign servers is shown in Figure 2c. In this sce-
nario, like in Slowloris attacks, the adversary sends
only “SYN” packets of the handshake and never re-
sponds to incoming “SYN/ACK” packets. This be-
havior makes serving computers to wait for an incom-
ing connection, by allocating some of its resources
to keep state. The increase of such requests makes a
web server to allocate more resources and eventually
the server becomes unavailable. Since MaTaDoR for-
wards the requests to an actual, yet decoy web server,
the decoy server becomes unavailable. Thus, MaTa-
DoR serves its purpose by confusing the adversary ei-
ther the web server is on or off. Genuine server oper-
ates normally in the meantime.
Note that, both benign and malicious traffic is han-
dled the same from the external network’s point of
view. Therefore, it is not possible to detect either the
genuine or decoy server is active. This attribute al-
lows users to be unaware of that there is a protection
mechanism in place.
4 METHODOLOGY
MaTaDoR’s feasibility is validated by a simulation
setup similar to Figure 1. A real network dump is re-
generated with Scapy (Rohith et al., 2018) to build
experimental traffic. Scapy is a packet manipula-
tion program that enables real time header processing.
Since popular operating systems like GNU/Linux, OS
X and Windows do not support TCP-AO message au-
thentication header is added at the client side with
Scapy. Then, MaTaDoR handles these headers via
custom iptables rules.
The original traffic data is named “SUEE1”
1
, in-
cludes both wireless and wired interfaces, and col-
lected by Lukaseder et al. (Lukaseder et al., 2018).
1
https://github.com/vs-uulm/2017-SUEE-data-set
Moving Target Defense Router: MaTaDoR
651