Reference no: EM132178430

Goal

In this project, using an interactive Mininet demo [1], we will explore some of the vulnerabilities of Border Gateway Protocol (BGP). In particular, we will see how BGP is vulnerable to abuse and manipulation through a class of attacks called BGP hijacking attacks. A malicious Autonomous System (AS) can mount these attacks through false BGP announcements from a rogue AS, causing victim ASes to route their traffic bound for another AS through the malicious AS. This attack succeeds because the false advertisement exploits BGP routing behavior by advertising a shorter path to reach a particular prefix, which causes victim ASes to attempt to use the newly advertised (and seemingly better!) route.

Instructions

RUN THIS PROJECT ON THE OLD VM(as your part3 submission will be autograded in that VM), BUT PLEASE USE THE EXTRA CREDIT OPPORTUNITY BY RUNNING THIS PROJECT ON THE NEW VM. THERE WILL BE A PIAZZA THREAD ABOUT THIS PROJECT AND THE NEW VM.

Part 1: Background reading, resources and example BGP router configurations

A.Browse this paper as a reference for subsequent tasks and for some important background on Prefix Hijack Attacks.
B.Refer to this resource on configuring a BGP router with Quagga.
C.Check out the following example configurations: Example 1 and Example 2

Part 2: Interactive Demonstration using a Mininet Topology and simulated prefixes/paths

The demo creates the network topology shown below, consisting of four ASes and their peering relationships. AS4 is the malicious AS that will mount the attack. Once again, we will be simulating this network in Mininet, however there are some important distinctions to make from our previous projects. In this set up, each container is not a host, but an entire autonomous system. Each host runs a routing daemon (quagga), communicates with other ASes using BGP (bgpd), and configures its own isolated set of routing entries in the kernel (zebra). Each AS has an IP address, which is the IP address of its border router.

NOTE: In this topology solid lines indicate peering relationships and the dotted boxes indicate the prefix advertised by that AS.
1. First, download and unzip the Project-7 files (modify permissions if necessary).
2. Next, in the Project-7 directory, start the demo using the following command:
o sudo python bgp.py
3. After loading the topology, the Mininet CLI should be visible. Keep this terminal open throughout the experiment.
4. Start another terminal and navigate to the Project-7 directory. We will use this terminal to start a remote session with AS1's routing daemon:
o ./connect.sh
5. This script will start quagga, which will require access verification. The password is:
o en
6. Next, use the following commands to start the admin shell and view the routing table entries for AS1:
o en
o You will be prompted for the password again, retype en
o sh ip bgp
7. You should see output very much like the screen grab below. In particular, notice that
AS1 has chosen the path via AS2 and AS3 to reach the prefix 13.0.0.0/8:

9. Next, let's verify that network traffic is traversing this path. Open a third terminal and navigate to the Project-7 directory. In this terminal you will start a script that continuously makes web requests from a host within AS1 to a web server in AS3:
./website.sh

10. Leave this terminal running as well, and open a fourth terminal, also in the Project-7 directory. Now, we will start a rogue AS (AS4) that will connect directly to AS1 and advertise the same 13.0.0.0/8 prefix. This will allow AS4 to hijack the prefix due to the shorter AS Path Length:
./start_rogue.sh

11. Return to the third terminal window and observe the continuous web requests. After the BGP routing tables converge on this simple network, you should eventually see the attacker start responding to requests from AS1, rather than AS3.

12. Additionally, return to the second terminal and rerun the command to print the routing table. You may need to repeat the steps to establish the remote session if it closes due to inactivity. You should now see the fraudulent advertisement for the 13.0.0.0/8 prefix in the routing table, in addition to the longer unused path to the legitimate owner.

13. Finally, let's stop the attack by switching to the fourth terminal and using the following command:
./stop_rogue.sh

14. You should notice a fairly quick re-convergence to the original legitimate route in the third terminal window, which should now be delivering the original traffic. Additionally, you can check the BGP routing table again to see the original path is being traversed.

Part 3: Creating a more complex topology and attack scenario

As demonstrated in Part 2, network virtualization can be very useful in demonstrating and analyzing network attacks that would otherwise require a large amount of physical hardware to accomplish. In Part 3, you are tasked with replicating a different topology and attack scenario to demonstrate the effects of a different instance of a Prefix Hijack Attack.

1. To start, we recommend making a working copy of the code provided to you in the Project-7 directory. Next, refer to the referenced paper in Part 1A, and locate Figure 1. Edit the working copy of the demo code you just made to reconstruct the topology in Figure 1. When complete,

you should be able to use the commands from Part 2 to explore the routing tables generated by each border router. For our purposes, you can assume:
a) All links to be bidirectional peering links.
b) Each AS advertises a single prefix: AS1: 1.0.0.0/8, AS2: 2.0.0.0/8, AS3: 3.0.0.0/8, AS4: 4.0.0.0/8, AS5: 5.0.0.0/8, AS6: 1.0.0.0/8
c) The number of hosts in each AS is the same as in the provided code.

NOTE: You will likely find this project to be more approachable if you spend time exploring the demo code and fully understanding how each part works rather than immediately trying to edit the code.
Also make sure you don't change passwords in zebra and conf files. If you change the passwords, autograders will fail resulting in 0 for the assignment.

2. Next, locate Figure 2 in the referenced paper. Continue to adapt the code in your working copy to simulate this hijack scenario. When complete, you should be able to use the commands from Part 2 to start a Rogue AS and demonstrate a similar change in routing table information as was shown in Part 2.

3. Finally, create a compressed file (zip format) named Part3.zip containing your entire attack demonstration. You must include all of the files necessary to run your demo in an empty directory - do NOT assume that we will provide any of the files necessary to run your demonstration for grading purposes.

Part 4 - Design and implement a countermeasure to the attack from Part 3

This part of the project is optional, but it is worth extra credit if you complete it. Your task here is to design and implement a countermeasure to the attack demonstrated in Part 3. We recommend you start by creating a complete copy of the code you produced in Part 3, and paste it to a fresh working directory. Next, design and implement a countermeasure to the attack from Part 3. When complete, you should be able to use the commands from Part 2 to launch the simulation, and start a Rogue AS that mounts a Prefix Hijack attack as in Part 3. In this case, the attack should fail and you should be able to observe the victim AS routing table maintain (or revert back to) it's original state before the attack commences.

As was done in Part 3, create a compressed file (zip format) named Part4.zip containing your entire countermeasure demonstration. You must include all of the files necessary to run your demo in an empty directory - do NOT assume that we will provide any of the files necessary to run your demonstration for grading purposes. Additionally, you should provide a supplementary document (PDF format) named Countermeasure.pdf. This document should provide the following:

1. A brief summary of how your solution counters the attack

2. A list of files you modified from Part 3 or created in order to implement the countermeasure

3. A brief description of what is changed in each file, (or the purpose of newly created files) including how it functions as a part of the larger system.

4. Instructions for demonstrating the countermeasure, including instructions for installing required software / libraries.

5. A brief closing containing any additional information the grader may need to reproduce your countermeasure and contact information (if different than your GT studensmt email address) in case the grade has questions.

Attachment:- Project Description.rar