[AUDIO LOGO]
So as we jump in to start talking about BGP security
and securing it in the service provider space,
I want to keep in mind a few things
as we go through this skill.
First, this is not a comprehensive security course.
So this is just an overview of some of the most common things
that we need to secure in regards to BGP.
This is certainly not a complete course
on how to secure a service provider environment.
That said, we are going to jump in here
and look at some of the most common things
that we do need to protect.
And keep in mind that BGP is a very commonly attacked protocol
since it is the protocol that runs the internet.
So we do need to take certain precautions.
We need to, as a service provider,
protect ourselves not only from other service providers,
but also possibly from our customers.
And for that matter, if we can into the extent that we can,
we want to help protect our customers
from the rest of the internet.
Now, ultimately, of course, customers
are going to be responsible for their own security,
but we can certainly provide some tools that
will see throughout this skill that can help them
in protecting their own networks if they choose to use them.
So that said, let's jump in here and take a look
at some of the most common things
that we need to secure BGP against in the service provider
space.
So as we said during the introduction,
keep in mind that BGP is the most attacked routing protocol
just because it's what runs the entire internet.
Now, of course, if an attacker is
trying to come after a particular company,
well, then they might attack the routing protocol
that company is using in their environment.
But BGP, since it's so global, is, of course,
going to be the most attacked.
Now, keep in mind also that as we
go through this entire skill, we're
going to be referring to things as attacks
just because it's an easy way to say things.
However, not all of them are malicious.
Sometimes it's just a mistake.
Maybe a junior admin misconfigures
a router, or maybe even a senior admin misconfigures a router.
So we can see things like just common mistakes, BGP not
being filtered properly.
I actually had a situation one time, where one of my customers
was just flat out redistributing their entire IGP into BGP.
The problem, of course, with that
is, they were using all RFC 1918 address space because it
was inside of their NAT environment,
and they just took all those addresses
and started advertising them into BGP.
Now, of course, the service provider
stopped that, but as the customer,
that's definitely a misconfiguration.
Were they trying to attack the internet
or inject these evil RFC 1918 addresses?
Of course, not.
They just didn't understand that that's not
something you should do.
So again, a lot of times, these things
are just common mistakes, either because
somebody misconfigured something, or maybe
they just didn't know any better,
and they thought that that's how it
was supposed to be configured.
So these are the kind of things that we
want to protect the service provider environment from.
So as we move through this skill,
just keep in mind that the service providers, of course,
need to be concerned about their safety
as well as trying to protect the customers.
Again, we ultimately can't completely protect customers,
but we can give them tools.
So some of the different types of attacks, or like we said,
mistakes that BGP can be vulnerable or susceptible to
would be things like TCP synchronization.
This is also known as SYN flooding.
This is essentially sending a lot of TCP SYN requests
to the device, knowing that they're probably not going
to complete, but trying to overwhelm
either the device itself or the link that these SYN
requests are going over, and that plays
in as well to traffic flooding.
Oftentimes, the SYN flooding is what's
causing the traffic flooding.
However, we could also try to overwhelm a device possibly
even just by pinging it from 100,000 different computers.
So it doesn't have to be the SYN flooding, but that
is a common way that it's done.
And then, of course, there's BGP specific attacks.
These are attacks not on TCP itself but actually on BGP.
These would include things like unwanted neighborships, people
trying to form neighborships that aren't
supposed to be our neighbors.
How about just a neighbor flapping?
Every time a neighbor goes up or down,
it's a new TCP connection.
We have to exchange open messages.
We have to resynchronize the entire BGP table.
So again, this can really cause an issue.
Also, improper route injection.
Now, this is pretty much the one I was just talking about,
where we had a customer injecting all those RFC 1918
addresses that they, of course, shouldn't have been doing,
but it can also be other things.
People could be doing this maliciously,
trying to inject, say, a customer's
prefix from somewhere else in the world,
trying to get the internet to go to them
to reach a customer's prefix rather than to the customer.
So from that perspective, as a service provider,
it would fall on us to, again, attempt customer security here
by allowing our customers to advertise their prefixes,
but nobody else's.
That way, our customers can't try to attack somebody
else because again, we never know
where those malicious parties are going to be.
They very well could be one of our own customers.
So to protect the rest of the internet from our customers,
we should also be monitoring and well,
protecting the internet from what our customers are
attempting to advertise.
So these are all things that we can
control with the tools we're going
to see throughout the rest of this skill.
And of course, last but not least,
would just be improper configuration, which could be,
of course, all sorts of different things.
Again, the redistribution of your IGP
would fall into that, having timers set way too high.
There's other things that can fall into this,
and we'll get into this in more detail as we go.
Now, we've spent quite a bit of time here
talking a little bit about BGP, but let's not
forget that the routers themselves also
need to be protected, and some of the things we've mentioned
would fall into the category of an attack on the router.
So again, these are sort of one and the same.
But keep in mind, the routers are split up
into three sections.
The first of which is the management plane.
And I've just listed a few examples here
because it's not really our main focus in this section,
but things like SSH, Telnet.
Hopefully, nobody's actually using Telnet.
That's how we secure that one.
We just don't use it.
But again, I just put it in as an example, things like SNMP.
An example here would be make sure you're at least using
version 3 if you're using SNMP because it has
a lot more security features.
But again, this isn't really our focus here.
Our focus is mostly going to be on the control
plane and a little bit of the data plane.
So the control plane is, of course,
the second thing we would have to secure, and lots of things
can be affected here.
One of them is an overly large BGP table.
Why?
Well, it's going to take a lot of RAM to store the table,
and it's going to take a lot of CPU to run the BGP scanner
and select the best paths.
All the calculations that need to happen are, of course,
going to be more complicated the bigger the table.
And then of course, there's the data plane itself.
And this is a direct result of a lot
of what's going to happen up here, particularly
the last point here, the overloaded TCAM.
Now, keep in mind, not all Cisco devices have a TCAM.
These are the hardware tables stored in the line cards.
But the ones that do, this is a finite amount of space.
Each different platform has the maximum amount
of routes that it can store in its TCAM tables,
and we need to make sure that we don't overwhelm that.
So all of the routes get stored into the TCAMs
as long as there's room.
And if there's not room, well, that's
where this problem comes in.
And of course, we already mentioned this first point
here, which is the saturated links
or the denial-of-service attacks,
where basically, somebody is just
trying to saturate our connection,
just take up all the bandwidth, and that would be
very detrimental to the router.
And keep in mind, when we're talking
about these potential threats, customers are, of course,
going to be open to the exact same vulnerabilities
as the service provider.
If they're running BGP, bad actors
can attack them just as easily as they can attack the service
provider.
And as I've already mentioned, we cannot fully protect
the customer, but what we can do is implement policies that do
our best to protect the customer.
And I have given a few examples of those,
such as only allowing them to advertise
the prefixes that they own.
We can also implement policies to prevent them
from becoming a transit area or a transit AS.
So these are some things that we can do is a service provider
to protect the customers.
And then we can also provide customers with tools
to help them protect themselves.
One example of this is, we could do remote triggered black hole
filtering.
We'll talk about that in an upcoming video.
And also do things such as support communities
and outbound route filtering.
So there are things that we can do
to give these customers tools that they can
use to help protect themselves.
In this video, we talked about some
of the most common attacks on BGP and to an extent
the router itself, and we just got an introduction to things
that we might be able to do to help circumvent those problems
in our environment.
Over the upcoming videos, we'll be exploring
a lot of this in great detail.
So we'll see you there.
I hope this has been informative for you,
and I'd like to thank you for viewing.