Lab #3: Blue Team Exercise - ackSec/DC26 GitHub Wiki

In this portion of the lab, we'll be looking at some of the ways an SDN can defend itself against attacks. If you remember we briefly discussed the active defense honeypot network, well in the following exercise we will get to build it and see it in action. This is a fairly complex and detailed lab, so please follow the instructions carefully.

Navigate to the blue-team-exercises folder with the following command:

cd ~/DC26/blue-team-exercises/blue-team-workstation

Run the below command to build the topology for this lab.

./runBlueTeam.sh

This will provide output similar to the below:

We just deployed three switches in a loop topology with three docker hosts connected. An attacker, a victim, and a "honeyhost". As you can see flows were already pushed to the switches which represent the normal flows in a network.

Run a pingall command to show that the attacker and victim machines can communicate.

pingall

You'll see the below in your terminal:

In the controller things will be a bit interesting. Due to spanning tree, the switches may appear to not be connected in the looping fashion, as one of the links is being blocked to prevent broadcast storms. With the free SDN controllers we don't always get all the fancy features! It's still worthwhile to check out the flow tables, however.

Go to the switches menu as shown below, and click one of the switches to view the flows:

As you can see there are 7 flows that do a number of different things, but they don't show up very well in the controller. Let's run the command

dpctl dump-flows

At the "containernet>" prompt in the workstation

As you can see, this gives a much better view of the flows in each of the switches.

Now let's set up the environment so that it is actively monitoring for an attack. We have written some custom proof of concept code that will change the network topology in response to an attack. Heads up, it's a bit buggy, and has very limited use cases, but hey, that's why it's a demo.

Our attacker today will be attempting to contact our victim, who happens to be a Snort sensor. (Attackers aren't always the smartest). Our Snort sensor will detect the contact and immediately fire an alert to our security appliance which will alter the flows in the controller to respond to the attack.

Let's get the code started.

Hop into the victim docker image by opening a new tab and pasting the URL from your workstation tab into it to start a new shell. Then type the following command to enter the docker image.

sudo docker attach mn.victim

You may have to hit enter once or twice, but you should be greeted by a screen that looks like this:

Navigate to the blue team docker folder by typing the below command:

cd /opt/DC26/blue-team-exercises/blue-team-docker/

We're always making last minute changes so run a git pull to make sure the repo has the latest code:

git pull

Now because neither of us are coders, we had to do a very hokey workaround for a variable problem we were having, so bear with us on this step. Using your favorite editor, open the "runBlueTeamDocker.sh" file for editing:

nano runBlueTeamDocker.sh

In the spot where it says "Add IP HERE" replace that with your controller IP that you can obtain from your other workstation tab.

Here's the controller IP on the other workstation tab (obviously yours will be different):

And here's where it goes:

So at the end your script should look like this:

Type ctrl + o then enter to save your work, and then ctrl + x to exit.

We can now start up snort and our appliance to listen for attacks! Type:

./runBlueTeamDocker.sh

Snort will start up and will start listening for attacks and feeding the information to our security appliance. You know it's successful when you see the little piggy and the words WARNING: Unix socket start listening... at the bottom like this:

Right now, we have our appliance triggering on a ping or ICMP packet, so let's move back to the other workstation tab that has our containernet running in it. At the "containernet>" prompt let's send the evil ping that starts the process. At the prompt, type:

attacker ping victim and then type ctrl + c to stop the continuous ping like this:

if everything was done properly, only one ping should go through and the rest should fail as you can see above. This is because the alert was triggered, and the network topology changed to respond. If you switch back to your victim docker image, you'll see exactly what happened:

The attack was detected, the security appliance received the alert, and cleared out flows connecting the attacker from the victim. Additionally, those flows were redirected to the honeynet host. For the more advanced folks, I recommend installing tshark on your honeynet host and watching the packets come in from the attacker. The attacker should have no idea their traffic is being redirected.

Additionally if you go into the flow table for switch 3 in the controller, you'll see the reactive flows that we just pushed suddenly taking traffic:

and the more detailed dpctl dump-flows at the "containernet>" prompt, also provides the same information:

This is one very small, static example done by someone who doesn't code, just to demonstrate the awesome power of these tools. Whether it's overwriting packets and spoofing them back to the attacker, or standing up a fake network when an attack is detected, there are a multitude of ways the network can respond uniquely to any sort of attack that comes in.