Sharing between D4 sensor networks - a simple example to share DDoS backscatter traffic while preserving privacy
Table of Contents
D4-core introduced a new feature recently: a default analyzer to write directly to standard output. This allows the piping of D4 output streams into any other UNIX tools, opening the door to more data analyses and data sharing.
We apply this data flow and processing to network captures, but it applies to other type of any data supported by D4 (eg. passive DNS, passive SSL, etc.)
Architecture Overview
In the following, we demonstrate data mixing and sanitization of several network sensors on a D4 server, as well as the forwarding of the result to another D4 server. The typical use-case is the hosting of a D4 server in-premises that strips out the collected data of personal information for privacy reason before sharing with a public DDoS backscatter-traffic analyzer. See the picture below, the green area represents the private perimeter, and the red area the public one.
The area of interest are the following (red circles on the picture above):
| # | Description |
|---|---|
| 1 | network captures: tcpdump pipes its standard output to d4-goclient for streaming to a private D4 server, |
| 2 | data mixing and sanitizing: the private D4 server receives network capture streams and stores these in pcap files in rotation. These files, after compression are marked as ready for analysis in a redis queue (The analysis is detailed below), |
| 3 | result of the analysis (the sanitization) is forwarded to the public D4 server, |
| 4 | the public D4 server mixes data from several sensors / servers and analyze the data for DDoS backscatter traffic. |
Follow along: You can use the passive dns tutorial virtual machine. You need to
update d4-core first:
$ cd ~/d4-core
$ git pull
Network Collection
Let’s first dig into the network collection: we use tcpdump to collect packets,
and the default Clang client or the Golang client to forward packets to the
public D4 server (HOWTO install).
- We use
tcpdumpwith the following parameters:
| parameter | Description |
|---|---|
| -n | no DNS resolution |
| -s0 | set snaplen to default 262144 for compatiblity |
| -w - | write to stdout |
- Clang client:
The Clang client requires to have a relay, here we use socat:
$ sudo tcpdump -n -s0 -w - | ./d4 -c ./conf | socat - OPENSSL-CONNECT:$D4-SERVER-IP-ADDRESS:$PORT,verify=0
Use the command above and in the ./conf folder create the following files:
| parameter | description | value |
|---|---|---|
| destination | address and port of the receiving D4 server | stdout |
| source | where to look for input data | stdin |
| snaplen | D4 packet size | 4096 |
| type | type of D4 packets sent, this is used by d4-server to know how to handle the data received | 1 |
| uuid | sensor's unique identifier | automatically provisioned |
| key | a Pre-Shared Key used to authenticate the sensor to the server | "private key to change" |
| version | D4 protocol version | 1 |
- Golang client:
$ sudo tcpdump -n -s0 -w - | ./d4-goclient -c ./conf
With the Golang client, use the command above and in the ./conf folder create the following files:
| parameter | description | value |
|---|---|---|
| destination | address and port of the receiving D4 server | 127.0.0.1:4443 |
| source | where to look for input data | stdin |
| snaplen | D4 packet size | 4096 |
| type | type of D4 packets sent, this is used by d4-server to know how to handle the data received | 8 |
| uuid | sensor's unique identifier | automatically provisioned |
| key | a Pre-Shared Key used to authenticate the sensor to the server | "private key to change" |
| version | D4 protocol version | 1 |
Preparing the private D4 server
In order to have a analyzer for network captures, the public D4 server needs to
have a redis queue for type 1 data. Once the server is launched, point your browser to
http://127.0.0.1:7000/server_management and create a new queue as follows:
To obtain a new redis queue for your analyzer to consume:
protip: When clicking on the number of item in the queue (in the following screenshot 10001 elements), the webapp display a preview of the elements in the queue:
Analysis
Let’s build the analyzer command from the ground up, keep in mind that:
- it queries the analyzer redis queue (filled with path to files ready for analysis),
- unpacks these files,
- rewrites the content of each file to remove sensitive content,
- forwards the result the public D4 server.
analyzer-d4-stdout
Analyzer-d4-stdout is part of d4-core and allows for popping an analyzer redis
queue and outputting its content on standard output. Used with the - f flag,
it behaves differently: it streams the content of files pointed out by the redis
queue.
$ ./d4-stdout.py -t 1 -u 84723644-0841-4580-97e9-23e98682739c -f
| parameter | description |
|---|---|
| -t | d4 type of data: type 1, pcap |
| -u | uuid of the analyzer redis queue we created: 84723644-0841-4580-97e9-23e98682739c |
| -f | Fetch files instead of reading raw content of the queue |
Then we pipe the result in zcat, for to remove compression:
$ ./d4-stdout.py -t 1 -u 84723644-0841-4580-97e9-23e98682739c -f | zcat
We are now ready to remove sensitive information from these files.
tcprewrite
tcprewrite is part of tcpreplay, and is a tool to rewrite packets stored in pcap files.
In the following we replace private IP addresses with phony ones:
$ ./d4-stdout.py -t 1 -u 84723644-0841-4580-97e9-23e98682739c -f | zcat | tcprewrite --pnat=10.1.0.0/16:192.168.0.0/16 -i - -o -
| parameter | description |
|---|---|
| –pnat=10.1.0.0/16:192.168.0.0/16 | Replace 10.1 by 192.168 |
| -i - | read from stdin |
| -o - | write to stdout |
d4-client
The data is now ready to ship towards the public server. We can now use our favorite client for D4 transmission. For instance:
$ ./d4-stdout.py -t 1 -u 84723644-0841-4580-97e9-23e98682739c -f | zcat | tcprewrite --pnat=10.1.0.0/16:192.168.0.0/16 -i - -o - | d4-goclient -c ~/go/src/github.com/d4-goclient/conf.sample