代写security | Network代写 | 代写network | shell | project | Python代写 | 代写assignment – BGP Hijacking Attacks

2024-04-23

BGP Hijacking Attacks

代写security | Network代写 | 代写network | shell | project | Python代写 | 代写assignment – 这道题目是比较典型的web/security/Network/network/shell/Python等代写方向, 这是值得参考的assignment代写的题目

security代做 网络安全 网安代写 计算机网络安全

OMSCS GEORGIA TECH

BGP Hijacking Attacks

CS 6250
Spring 2023

Copyright 2020- 2023 Georgia Institute of Technology All Rights Reserved. This is solely to be used for current CS6250 students. Any public posting of the material contained within is strictly forbidden by the Honor code.

Table of Contents

  • project INTRO
    • What Is BGP Hijacking?
    • What happens when BGP is hijacked?
    • BGP hijacking in the real world
  • PROJECT GOAL
  • INSTRUCTIONS
    • Part 1: Background reading, resources, and example BGP router configurations………………………………
    • Part 2: Interactive Demonstration using a Mininet Topology and simulated prefixes/paths……………….
      • STEPS TO START DEMO
    • Part 3: Creating a more complex topology and attack scenario
    • STEPS FOR YOUR ATTACK SCENARIO
    • Part 3 Configuration Debugging Tips
  • What to Turn In:………………………………………………………………………………………………………………………….
    • PART
    • WHAT YOU CAN AND CANNOT SHARE
  • RUBRIC

PROJECT INTRO

In this project you will explore the vulnerability of the AS systems and the BGP protocol.

As you recall from Lesson 4, an autonomous system can be any of the tier ISP providers access (tier 3), regional (tier 2), or global (tier 1). An autonomous system can also be an IXP (where ISPs and CDNs exchange local traffic) or CDN (like Netflix and Google). An AS is a group of routers (including the links among them) that operate under the same administrative authority. The border routers of the ASes use the Border Gateway Protocol (BGP) to exchange routing information with one another.

BGP is used to implement routing policies, which makes it important for ASes to cooperate with other ASes. Even though each AS can make internal decisions, they look to each other for routing information provided by BGP. security was not in original design of BGP, but with the internets increasing complexity and size, so is there a need to provide security measures.

What Is BGP Hijacking?

BGP hijacking occurs when a malicious attackers or rogue AS advertises a false IP prefix that it does not own or control to reroute internet traffic. These vulnerabilities still cause routing disruptions and connectivity issues for individual hosts, networks, and sometimes even entire countries. There have been some notable recent hijacking events that we have linked in the slides for this project. BGP favors a shorter route to save money for the providers or just to decrease number of hops to an IP prefix (more specific route).

For a hijack to be successful it must:

A. Advertise a shouter route of a more specific range of IP addresses that another AS already advertised. B. Advertise a shorter route to a block of IP addresses. This can only be made by an operator of a AS, or by a bad actor that takes control of an AS.

(Cloudflare)
What happens when BGP is hijacked?

When an attack is made, it re-routes the traffic to malicious sites to steal credentials, drops traffic to cause disruption, and/or increases latency of pages. Even though the victim AS thinks the route is shorter, the reality is it may be a lot longer than the previous advertised routes. The best-case scenario of an attack is where the route will just increase latency and steer traffic to a much longer route, at worst case the attack may re-route to a malicious site to steal confidential information from the users.

BGP hijacking in the real world

We have linked several of the notable cases of real-world hijacking in the project slides. In 2017 Russian hackers re-routed several Visa and MasterCard IP prefixes hijacking the traffic that routed to those addresses:

https://arstechnica.com/information-technology/2017/04/russian-controlled-telecom-hijacks-
financial-services-internet-traffic/

Additionally, BGP hijacking has occurred when the Pakistan government re-routed YouTube traffic (link in slides) and hackers attempted to steal crypto currency. Aside from constant monitoring of how Internet traffic is routed, users and networks can do very little to prevent BGP hijacks.

A good resource that explains BGP hijacking is linked below:

https://www.cloudflare.com/learning/security/glossary/bgp-hijacking/

PROJECT GOAL

In this project, using an adaptation of an interactive Mininet project[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

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. Also, the FRR docs for zebra can be helpful as well.

C. The BGP Bible is here https://www.cisco.com/c/en/us/td/docs/ios/iproute_bgp/command/reference/irg_book.html

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

The Part 2 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 setup, each object is not a single host, but an entire autonomous system. In each AS, a router 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 router has multiple IP addresses, to connect to the hosts in the AS and to other routers.

NOTE: In this topology solid lines indicate peering relationships, and the dotted boxes indicate the prefix advertised by that AS.

STEPS TO START DEMO
  1. Download and unzip the Project files. Modify permissions using the command:
sudo chmod -R 777 BGPH
  1. In the Project Directory open a terminal and type the following command:
sudo  Python bgp.py

Then enter the password for VM: mininet
  1. After loading the topology, the Mininet CLI should be visible. Keep this terminal open throughout the experiment.
  2. Open a second terminal in the Project directory. We will use this terminal to start a remote session with AS1s routing daemon. Type in the following command:
./connect.sh

Then enter the password for VM. Enter the password whenever prompted.
  1. This script will start quagga, which will require access verification. The password is: en You will type in en and press enter (a total of 3 times) This will give you access to the administration shell and R1 routing table When you get the bgpd-R1# prompt type the following command:
sh ip bgp
  1. You should see output very much like the screen grab below. Notice that AS1 has chosen the path via AS2 and AS3 to reach the prefix 13.0.0.0/8. NOTE: It may take a minute for the routes to settle. Try the command until you see all three routes.
  2. Next, let us verify that network traffic is traversing this path. While still in the project directory, open a third terminal (keeping all other terminals open). In this terminal you will start a script that continuously makes web requests from a host within AS1 to a web server in AS3. Type in the following:
./website.sh
  1. Leaving all terminals open, open a fourth in the Project 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 type the following:
./start_rogue.sh
  1. 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.
  1. 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.
  2. Finally, lets stop the attack by switching to the fourth terminal and using the following command:
./stop_rogue.sh
  1. You should notice a fast reconvergence 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.

IMPORTANT NOTE: Build your Part 3 Attack Scenario off the demo files used in Part 2. Per step 2 below, make a backup of your demo files so you can refer to them as you modify the files for Part 3.

STEPS FOR YOUR ATTACK SCENARIO
  1. First, locate Figure 2 in the referenced paper. Draw a topology map using any drawing tool of your choice. See Slide 7 of the presentation slides for an example of the level of detail desired in your topology diagram.
You may hand-draw your topology with pencil and paper and scan or photograph your
drawing. All configuration values drawn on the map must be legible! Save your topology
diagram in PDF format with the name fig2_topo.pdf. You must use this filename as part
of your submission to receive credit for your diagram. We find that if you do your
diagram first, it will make the following steps much easier!
  1. Next, we recommend making a copy of the code provided to you in the Project files (the full demo folder). This will make it easier to complete this project and 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.
  2. Next, refer to the referenced paper in Part 1A, and locate Figures 1 and 2
  1. Edit the working copy of the demo code you just made to reconstruct the topology in Figures 1 and 2 When complete, you should be able to use the commands from Part 2 to recreate the attack on the new topology you built in the BGPHijacking directory. For our purposes, you can assume the following:
  • All links to be bidirectional peering links.
  • Each AS advertises a single prefix: AS1: 1 1.0.0.0/8, AS2: 1 2.0.0.0/8, AS3: 1 3.0.0.0/8, AS4: 1 4.0.0.0/8, AS5: 1 5.0.0.0/8, AS6: 1 1.0.0.0/8 (Note: We highly recommend using these prefix values in your configuration to simplify grading and for consistency in communication and discussion in Edstem. However, you may use any valid prefix values in your configuration.)
  • The number of hosts in each AS is the same as in the provided code (the demo).
  1. Do not change passwords in zebra and conf files. If you change the passwords, the auto- grader will fail resulting in 0 for the assignment. All passwords need to follow the demo and be en
  2. Continue to adapt the code in your BGPH directory 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 and see the screen printout (website.sh) as in demo. If this is not seen will result in points lost (see rubric for breakdown of points)
  3. Finally, follow the directions in the What To Turn In section carefully. You must include all of the files necessary to run your demo in the directory – do NOT assume that we will provide any of the files necessary to run your demonstration for grading purposes. Include your fig2_topo.pdf file in your directory.
Part 3 Configuration Debugging Tips
  • When viewing the BGP Tables note the Status codes. Give your topology enough time to converge before recreating the hijack simulation portion. It may take a minute or so for your topology to fully converge. You may continue to check the BGP Tables to determine whether the topology has converged
  • The order that you set up your peering links using addLink() matters. In previous projects, we manually selected which port on the switch to use. There is an optional parameter to the addLink() call which allows you to specify which switch port to use. In this project, you will not use those options. Therefore, the order of the links matters.
  • Some of the commands in the boilerplate code may not be necessary to complete Part
    1. Some of it is there just so that you know it exists.
  • Check for more descriptive errors in the /logs directory. See the zebra files for the location of additional log files.
  • Run "links" on the Mininet CLI terminal to see if all links are connected and OK.
  • Run "net" on the Mininet CLI terminal to see if your ethernet links are connected as you expect.
  • Run "ifconfig -a" on all routers and hosts to ensure that all IP addresses are assigned correctly.
  • Run "sh ip bgp" and "sh ip bgp summary" on all routers.
  • The command pingall may not work and that is fine.
  • The website.sh may sometimes hang intermittently. If this happens restart the simulation. We are aware of this issue, and we keep this in mind as we grade your submission. You will not lose points if website.sh hangs so long as we are eventually able to run the simulation.
  • Watch the Intro presentation and read through the additional debugging tips on the intro slides.

What to Turn In:………………………………………………………………………………………………………………………….

PART

For this project you need to turn in all the files that are necessary for your code to run. Please name the zip file based on your GA Tech username. Be sure to use the -r option so your conf and logs subdirectories are part of the zip file! Use the following command to zip for Part 3:

zip -r gtlogin_bgph.zip BGPHijacking (replace gtlogin with your GT login)

You need to make sure the pdf file fig2_topo.pdf is present inside your BGPHijacking directory along with all files and directories to run the attack scenario you created. Run the above zip command when above your project folder. Zip the directory BGPHijacking. All the files and folders needed must be in the BGPHijacking folder zip the files in the VM using the Linux command, dont zip the files in your host operating system (i.e. No MAC_OSX directory)

Failure to have proper zip organization will result in 10 points loss!

Improper zipping (not following directions) will cause problems with the auto grader so please follow the directions!

gtlogin_bgph.zip should be submitted in the main assignment on canvas which is named:

BGP Hijacking

As with all projects, we highly recommend after submitting that you re-download your submission from Canvas to check that it uploaded correctly and runs properly in the class VM.

WHAT YOU CAN AND CANNOT SHARE

While discussion of the project in general is always permitted on Edstem, you are not permitted to share your code generated for Part 3 or Part 4. You may quote snippets of the unmodified skeleton code provided to you when discussing the project.

  • You may not share your topology diagram you created in Part 3 Step 5. (private post to instructors is always OK)
  • You may not share your IP addresses publicly (private post to instructors is always OK)
  • Sharing of completed code pseudo code is ok but if in doubt please private post to instructors

RUBRIC (out of 150 points)

20 pts Submission For turning in all the correct demo files with the correct names, and
significant effort has been made towards completing the project.

10 for submission and effort

10 for following zip directions

5 pts Fig 2 Topo
Diagram

For turning in the correctly named Topology diagram file: fig2_topo.pdf

Please use legible configuration values!

125 pts Attack Demo For accurately recreating the topology, links, router configuration, and
attack per the instructions. Partial credit is available for this rubric item as
follows:

40 points for accurately recreating the topology, links, router
configuration

40 points for seeing default message when you run website.sh

40 points for seeing attack message after running start_rogue.sh

5 points for seeing default message after stop_rogue.sh is run

[1] This Project inspired by a Mininet Demo originally presented at SIGCOMM 2014.

Bibliography

Cloudflare. (n.d.). Retrieved 2020, from cloudflare.com: https://www.cloudflare.com/learning/security/glossary/bgp-hijacking/