TNE30009 Case Study Project

Organisation analysed: EZNet

Name: ABHISHEK KIZHAKKEPUTHANMADAM SABARINATH

(101213731)
Name: DENNIS LIM CHIA YIN (101209934)
Name: BAEK SUNMU (101213650)
Name: DARREL LAI VUI KIAT (101209714)
Table of Contents
Executive Summary ........................................................................................................................... 3
Introduction ...................................................................................................................................... 3
Risk Analysis ...................................................................................................................................... 3
Delphi Method Risk Assessment .................................................................................................... 4
EZNet ISP ................................................................................................................................... 4
Security Programme .......................................................................................................................... 5
Policy 1 – IP Prefix Filtering ............................................................................................................ 5
Policy 2 – ARTEMIS System ............................................................................................................ 5
Policy 3 – Pretty Good BGP ............................................................................................................ 6
Implementation of security programme ............................................................................................ 7
Implementation of IP Prefix Filtering.............................................................................................. 7
Artemis System ............................................................................................................................. 8
Pretty Good BGP .......................................................................................................................... 12
Executive Summary
This paper is intended to provide the reader with an overview of BGP hijacking, some of the
recent and notable ones and the damage(s) they caused different ISPs. This paper also
provides EZNet, a newcomer in the industry with a section focusing on which assets are at
stake in case of a BGP hijack and the recommended solution as well the implementations of
the policies mentioned.

Introduction
Every organization regardless of size faces issues with security, both in the form of natural
(like fire or landslides) and man-made (like a disgruntled employee or a hacker). This
assignment will focus on the BGP or Border Gateway Protocol vulnerabilities faced by
EZNet ISP, a newcomer to the industry promising high speeds and coverage. A BGP works
by selecting the path the data can travel through and also selecting the best or shortest route.
A BGP makes the internet work by hopping data between different Autonomous System (AS)
to reach the recipient. The internet is a network of networks which are broken up into smaller
networks: the autonomous system. These networks are controlled by single organization or
ISP. Therefore, if BGP is the postal service, AS would be the individual post office branch.
Routers in the autonomous system collect data acting as mailboxes and sends it to the
autonomous systems which act as the postal office branches and finally routes the packet with
the help of BGP transmission. Since ‘EZNet’ is a new ISP we assume it to be relatively
inexperienced with implementation of security policies and the threat of BGP hijacking
attributed to a lack of authorization and authentication mechanisms in the inter-domain
routing system (Dainotti et al 2020).

Risk Analysis
According to (Gill et al 2019), BGP is based on trust model where the AS is supposed to
announce only its own IP prefixes and the correct path to the destinations. However, it is
taken as an advantage by the hacker forging the AS paths or announce incorrect or its own IP
prefixes. BGP vulnerabilities are hard to fix as to fix its vulnerabilities, the whole concept or
idea of BGP has to be changed. BGP hijacking is dangerous and it could lead to serious
damages towards the victims. For example, hijacked BGP routes could lead to blackhole or
the hacker could impersonate itself as the legitimate destinations of the traffic. One of the
most notable BGP hijackings happened on February of 2014 where Canadian ISP got hacked
and the hackers redirected data from several ISP to steal Bitcoin. Other crypto-currency
mining ops were also targeted by the hacker. Thus, we can see that in-case a similar attack
was to happen to EZNet the main asset at stake would be the actual server/data centre
hardware. A massive route leak that impacted several companies such as Cloudflare, Amazon
and Google was caused by Verizon and another ISP in Pennsylvania, DQE communications.
The cause of this route leak was due to a product from Noction, the “BGP optimizer”. This
‘product’ splits up IP prefixes into smaller parts like for example an IPv4 address such as
104.20.0.0/20 received will be turned into 104.20.0.0/21 and 104.20.8.1/21. This incident
happened due to DQE communications announcing specific routes or IPv4 splits to their
customer Allegheny Technologies INC and all the route information was sent to the transit
provider Verizon which then tell the whole internet about a “better route”. These routes are
them selected and eventually more specific routes will take over the more ‘general route’.
Therefore, any user who tried to access Cloudflare, Amazon or Google will access them
through Verizon, Allegheny Technologies as well as DQE. Great losses were suffered not
only by Verizon and DQE, but also impacted 15% of the global traffic. This incident again if
it were to happen to EZNet would mean a loss in traffic for EZNet but also for partnering
ISPs thereby putting the hardware at stake again. The Amazon Route 53 incident enabled
attackers to steal cryptocurrency from unwitting victims who were trying to log into their
exchange accounts. In that attack, hackers stole approximately $150,000 worth of
cryptocurrency from MyEtherWallet.com customers (Loshin 2020).
Thus, we can say that if in case a BGP hijack occurs the following assets at EZNet would be
at stake:
a) The server/data centre hardware in case the intent is mining or other hardware
intensive tasks.
b) Rerouted traffic might contain information or data that might be illegal in another
country and hence must be prevented.
c) Monetary losses

Delphi Method Risk Assessment

EZNet ISP

Risk Assessment Scale Justification

Severity of threat
Likelihood of threat
Cost of Countermeasure
2/5 Moderate damage to
certain individuals.
1/5 Very low
5/5 Very cheap
It is not as severe even
though it is a large-scale
attack on bitcoin miners.
The affected are mostly
bitcoin miners who did not
monitor their bitcoin setup.
The threat can happen
within the internal network
of the ISP like if staff
account is taken over by
hackers.
The proposed
countermeasure which is to
configure the BGP sessions
to have a maximum received
prefix is not only cheap, it
can be easily done by
configuration on the BGP
deployment part. If all ISPs
were to use this
countermeasure, the
effectiveness of this
 countermeasures would
increase significantly.
Effectiveness of 4/5 Would prevent most This countermeasure is
countermeasure attacks good to ensure that the
company would not receive
BGP route leaks from other
ISP by limiting its prefix
received. It could prevent
most attacks by other ISPs
but it could not prevent itself
from hijacking BGP of other
ISP. Hence, the scale of 4/5
is given due to its inability
to do so.
Risk on scale of 1 to 25= 2 Effectiveness of countermeasures 1 to 25 =12

Security Programme
As mentioned previously, the threats faced by EZNet are mostly on the BGP hijacking side
and below are some of the policies recommended to address the risks:

Policy 1 – IP Prefix Filtering

IP prefix declaration should only be accepted by networks and not declare it to all networks
but only to certain networks. IP prefix filtering can help prevent any bogus IP prefix
declaration being accepted by the Autonomous System (AS) and also prevent accidental route
hijacking (Noction, 2018).

- Limit AS_PATH in the announced prefixes where the prefixes that send to the ISP
can only be locally announced prefixes.
- Limit the Maximum prefixes that can be received where this can help to avoid the
flooding of BGP advertisements.

Policy 2 – ARTEMIS System

According to Vasileios (2018), ARTEMIS is a system that can help protect organization from
BGP hijacking. The software will be running on VM or container in Network Operation
Center and therefore can be operated in-house. To use this system, the user will only need to
configure the ARTEMIS by providing details about the announced prefixes and its neighbors.
The system will protect the prefixes by using AS. Below are the services that the system
provides:

- Monitoring: information can be taken from public monitors and local routers.
 - Detection: this can help to detect if there is any hijacking events happening through
comparing the configuration file with the information that is being monitored.
- Mitigation: through the custom in-house mechanisms, it can react automatically to a
detected hijacking event.

Figure 1 - example of ARTEMIS system

Policy 3 – Pretty Good BGP

According to Karlin et al. (2007), Pretty Good BGP (PGBGP) is used while there is any
forwarding data traffic, any unfamiliar routes will be treated with caution. Problems that are
caused by configuration errors can be mitigated temporarily through this approach. In Pretty
Good BGP, it can identify anomalous routes and also avoid bogus routes.

Identify anomalous routes

- In identifying these anomalous routes, the Pretty Good BGP can determine whether a
routed can be trusted or not.

Avoid bogus routes

- Pretty Good BGP, can help avoid selecting any anomalous routes. The router will
select the trusted route that is the best when there are any alternative routes for the
prefix.
Implementation of security programme
In the Security Programme, 3 policies are introduced meant to protect EZNet from threats
namely IP Prefix Filtering, Artemis System and Pretty Good BGP. In this section the details
of the implementation of these policies will be introduced.

Implementation of IP Prefix Filtering

The AS Path can be limited by applying BGP AS Path Filter. For example, If the customer
router is AS64502 and its IP address is 200.1.1.2. and then ISP is AS64500 and its IP address
is 2001.1.1, we can apply the BGP AS Path Filter on both side of router. The commands will
be:
ip as-path access-list 1 permit ^$

router bgp 64502

neighbor 200.1.1.1 filter-list 1 out

The above commands need to be applied on Customer’s Router toward ISP as well to prevent
the traffic sent from another autonomous system to customers.
ip as-path access-list 1 permit ^64502$

router bgp 64500

neighbor 200.1.1.2 filter-list 1 in

The above commands need to be applied on ISP Router toward Customer Router to prevent
traffic sent from another AS.

If the filter is set, we can configure the prefixes into the routers so that users with the given IP
address pool can join the system (and also prevent another autonomous system interfering
with the system).

For the customer routers toward ISP, the following command can be configured:
ip prefix-list filter_out seq 10 permit 199.1.1.0/24
 router bgp 64502

neighbor 200.1.1.1 prefix-list filter_out out

For ISP toward Customer Router, the command will be:

ip prefix-list as64502in seq 10 permit 199.1.1.0/24

router bgp 64500

neighbor 200.1.1.2 prefix-list as64502in in

For instance, IP address 199.1.1.0/24 is used however this can be changed if the organization
uses a different IP address pool.

Artemis System
Artemis is based on Ubuntu and hence Ubuntu must be installed before the implementation of
this step. If Ubuntu is installed, apt package needs to be updated and installed. It can be done
by the following command:

sudo apt-get update

$ sudo apt-get install \

apt-transport-https \
ca-certificates \
curl \
gnupg-agent \
software-properties-common

Once apt is installed, Docker Engine needs to be downloaded. It can be done by typing the
below command in Command Prompt.

$ sudo apt-get update

$ sudo apt-get install docker-ce docker-ce-cli containerd.io

After the above steps are done, we can download ARTEMIS System from Github and install
it. Once ARTEMIS is installed, we can change the directory into backend/config. If the
current directory is at backend/config, “config.yaml” can be found.
From the file we can change the configuration. Examples are:
prefixes:
 # A reference for a single prefix

simple_prefix: &my_prefix

IPv4|IPv6_prefix

# A reference for a list of prefixes

simple_prefix_list: &my_prefixes

- IPv4|IPv6_prefix_1

- ...

- IPv4|IPv6_prefix_N

monitors:

riperis: ['']

bgpstreamlive:

- routeviews

- ris

- caida

exabgp:

- ip: ip_to_exabgp_1

port: port_1
 - ...

- ip: ip_to_exabgp_N

port: port_N

bgpstreamhist: csv_dir_with_formatted_BGP_updates

asns:

my_asn: &my_asn

1234

my_asns: &my_asns

- 321

- 432

my_neighbor: &my_neighbor

222

my_neighbors: &my_neighbors

- 333

- 444
prefixes:

- prefix_A

origin_asns:

- ASN_A

neighbors:

- ASN_B

policies:

- 'no-export'

mitigation: manual
After the configuration is done, we can use Artemis system to monitor, detect and mitigate
BGP hijacking.

Pretty Good BGP

For deploying Pretty Good BGP, two components need to be built. The First component is
“Changes to the BGP protocol need to be implemented in a routing platform”. (Karlin, 2002)
For this step, Quagga, which is an open sourced routing suite can be used to implement
PGBGP algorithm. The Next component is an alert distribution mechanism. This can be
implemented through “Internet Alert Registry” As an example,

Figure 2 - PGBGP update algorithm

Figure 3 - Commands for interactive BGP

After this setting is configured, PGBGP will be activated and it will identify anomalous
routes and help avoid bogus routes.
Summary and Recommendation
From the above few paragraphs, we have seen how a BGP hijack could be potentially
devastating and cause great losses in both traffic and money. The recommended solutions and
the implementation are also outlined, namely:
• IP Prefix Filtering
• ARTEMIS
• Pretty Good BGP

Most BGP attacks are also short lived and do not create disruption on a global level but
strict filtering can reduce further disruption (Siddiqui 2020).

References
Cho, S., Fontugne, R., Cho, K., Dainotti, A., & Gill, P. (2019). BGP hijacking
classification. 2019 Network Traffic Measurement and Analysis Conference (TMA). doi:
10.23919/tma.2019.8784511

GitHub. 2020. FORTH-ICS-INSPIRE/Artemis. [online] Available at:

<https://github.com/FORTH-ICS-INSPIRE/artemis/wiki/Configuration-file> [Accessed 11
June 2020].

Karlin, J., Forrest, S. and Rexford, J., 2007. Pretty Good BGP: Improving BGP By
Cautiously Adopting Routes. [online] Swinburnedb.librarynet.com.my. Available at:
<https://swinburnedb.librarynet.com.my:2081/stamp/stamp.jsp?tp=&arnumber=4110301>
[Accessed 6 June 2020].

Loshin, P., 2020. How Does BGP Hijacking Work And What Are The Risks?. [online]
SearchSecurity. Available at: <https://searchsecurity.techtarget.com/tip/How-does-BGP-
hijacking-work-and-what-are-the-risks> [Accessed 11 June 2020].

Noction. 2018. BGP Hijacking Prevention And Defense Mechanisms | Noction. [online]
Available at: <https://www.noction.com/blog/bgp-
hijacking#:~:text=What%20is%20BGP%20Hijacking%3F,exploiting%20the%20weaknesses
%20of%20BGP.> [Accessed 6 June 2020].
RIPE Labs. 2018. ARTEMIS: Neutralising BGP Hijacking Within A Minute. [online]
Available at: <https://labs.ripe.net/Members/vasileios_kotronis/artemis-neutralising-bgp-
hijacking-within-a-minute> [Accessed 6 June 2020].

Siddiqui, A., 2020. Not Just Another BGP Hijack. [online] MANRS. Available at:
<https://www.manrs.org/2020/04/not-just-another-bgp-hijack/> [Accessed 11 June 2020].

UKNOF45 - ARTEMIS: an Open-source Tool for Detecting BGP Prefix Hijacking in Real
Time. 2020. [video] UKNOFconf.