Geof f Hust on February 2005 1 Disclaimer This is not a - - PowerPoint PPT Presentation

1

An Operational Perspective on BGP Securit y

Geof f Hust on February 2005

2

Disclaimer

This is not a descript ion of t he approach t aken by any part icular service provider in securing t heir net work. I t is int ended t o illust rat e t he set of t rade-of f s t hat are t ypical in t he I SP environment and t he current st at us of securing int er-domain rout ing in t he I nt ernet .

3

I ts about Management of Risk

• Operat ional securit y is not about being able

t o creat e and maint ain absolut e securit y. I t s about a pragmat ic approach t o risk mit igat ion, using a t rade-of f bet ween cost , complexit y, f lexibilit y and out comes

• Making a reasoned j udgement t o spend a

cert ain amount of resources in order t o achieve an accept able r isk out come

4

Risk Management

Underst and t he t hreat model:

• What might happen?
• What are t he likely consequences?
• How can t he consequences be mit igat ed?
• What is t he cost t r adeof f ?
• Does t he t hreat and it s consequences

j ust if y t he cost of implement ing a specif ic securit y response?

5

Lets talk routing security…

Prot ect ing rout ing prot ocols and t heir operat ion

• What you are at t empt ing t o prot ect against are ef f ort s

int ended t o:

• Compromise t he t opology discovery / reachabilit y operat ion of

t he rout ing prot ocol

• Disrupt t he operat ion of t he rout ing prot ocol

Prot ect ing t he prot ocol payload

• What you are at t empt ing t o prot ect against are ef f ort s

int ended t o:

• I nsert corrupt ed address inf ormat ion int o your net work’s

rout ing t ables

• I nsert corrupt reachabilit y inf ormat ion int o your net work’s

f orwarding t ables

6

The threat

• Corrupt ing t he rout ers’ f orwarding t ables

can result in:

• Misdirect ing t raf f ic (subversion, denial of

service, t hird part y inspect ion, passing of f )

• Dropping t raf f ic (denial of service, compound

at t acks)

• Adding f alse addresses int o t he rout ing syst em

(support compound at t acks)

• I solat ing or removing t he rout er f rom t he

net work

7

Components of the network model

Edge Routers Interior Routers BGP Route Reflectors Upstreams Peers Customers IGP iBGP eBGP

8

The routing model

I GP

• used t o manage int erior t opology
• I GP payload is int erior int erf ace and

loopback addresses

BGP

• Used t o manage ext ernal rout es
• I mplement s local rout ing policies

9

Basic Network design

I solat e your net work at t he edge:

• Rout e all t raf f ic at t he edge
• NO sharing LANs
• NO shared I GPs
• NO inf rast ruct ure t unnels

I solat e your cust omers f rom each ot her:

• NO shared access LANs

I solat e rout ing roles wit hin t he net work:

• Ext erior-f acing int erf ace rout ers
• I nt ernal core rout ers

10

Conf iguration Tasks - Access

• Prot ect ing rout ing conf igur at ion access
• ssh access t o t he rout ers
• f ilt er list s
• user account management
• access log maint enance
• snmp read / writ e access cont rol list s
• prot ect conf igurat ions
• monit or conf igurat ion changes
• Prot ect ing conf igurat ion cont rol of rout ers

is an essent ial part of net work securit y

11

Conf iguration Tasks – I GP

• Prot ect ing t he I GP
• No shared I GP conf igurat ions
• Don’t permit t hird part y managed equipment t o

part icipat e in I GP rout ing

• No I GP across shared LANs!
• shared LANs represent a point of vulnerabilit y

12

Conf iguration Tasks - BGP

• Prot ect ing BGP
• Prot ect t he TCP session f r om int rusion
• Minimize t he impact of session disr upt ion
• n BGP.
• Reduce t hird part y dependencies t o a

minimum (use local next hop t arget s, f or example)

• Monit or and check

13

Conf iguration Tasks - BGP

• Basic BGP conf igurat ion t asks:
• No redist ribut ion f rom iBGP int o t he I GP
• Use session passwords and MD5 checksums t o prot ect all BGP

sessions

• For iBGP use t he local loopback address as t he next hop (next -hop-

self )

• Use f ilt er list s t o prot ect TCP port 179
• Use maximum pr ef ix limit ing (hold mode rat her t han session kill mode

pref erred)

• Use eBGP mult i-hop wit h care (and consider using TTL hack)
• Align rout e ref lect ors wit h t opology t o avoid iBGP t r af f ic f loods
• Operat ing BGP

:

• Use sof t clear t o prevent complet e rout e wit hdrawals
• Use BGP session st at e and BGP updat e monit ors and generat e alarms
• n session inst abilit y and updat e f loods

14

Conf iguration Tasks – BGP

• Check your conf ig wit h a current

conf igurat ion t emplat e

• Rob Thomas’ t emplat e at

ht t p:/ / www.cymru.com/ Document s/ secure- bgp-t emplat e.ht ml is a good st ar t ing point

• Remember t o regularly check t he source

f or updat es if you really want t o using a st at ic bogon list

15

BGP Conf iguration template

• Global set t ings
• Record neighbor st at e changes
• bgp log-neighbor-changes
• Set rout e dampening
• Don’t damp DNS root server rout es
• Damp f lapping cust omer-advert ised rout es

using pref ix-lengt h sensit ive set t ings

• Don’t damp upst ream-advert ised rout es
• No rout e redist ribut ion f rom iBGP int o I GP

16

BGP Conf iguration template

• Per-Neighbor set t ings
• Reduce impact of session reset
• Always perf orm sof t reset of BGP sessions
• MD5 prot ect ion of t he TCP session
• Per-neighbor password
• Use per-neighbor pref ix f ilt er t emplat es
• I nbound and out bound f ilt ers on pref ixes
• Use local address f or next hop
• Next -hop-self
• Use maximum pref ix t hreshold wit h hold opt ion
• Maximum-pref ix <

n> discard-over-limit

• Don’t negot iat e t he BGP version
• Version 4
• I P f ilt ers f or TCP port 179
• I f using mult ihop, t hen use TTL t hreshold

17

Protecting the payload

• How t o increase your conf idence in

det ermining t hat what rout es you learn f rom your eBGPpeers is aut hent ic and accurat e

• How t o ensure t hat what you advert ise

t o your eBGP peers is aut hent ic and accurat e

18

Customer Routes

• Aut hent icat e cust omer rout ing

request s:

• Check validit y of t he addr ess
• Own space – validat e request against local

rout e obj ect regist ry

• Ot her space – validat e request against RI R

rout e obj ect dat abase regist ered POC

• This is of t en harder t han it originally looks!
• Adj ust explicit neighbor eBGP rout e

f ilt ers t o accept rout e advert isement s f or t he pref ix

• Apply damping f ilt er s

19

SKA Peer Routes

• Higher level of mut ual t rust
• Accept peer rout es - apply local policy

pref erences

• Filt er out bound rout e advert isement s

according t o local policy set t ings

• Use max pref ix wit h “discard-over-

limit ” act ion (if available)

20

Upstream Routes

• One-way t rust relat ionship
• Apply basic rout e f ilt ers t o incoming

rout e advert isement s

• RFC 1918 rout es
• own rout es (?)

21

Even so

• I t s not all t hat good is it ?

22

Routing Security

• The basic rout ing payload securit y quest ions t hat

need t o be answered are:

• Who inj ect ed t his address pref ix int o t he net work?
• Did t hey have t he necessary credent ials t o inj ect t his

address pr ef ix? I s t his a valid address pref ix?

• I s t he f orwarding pat h t o reach t his address pref ix

t rust able?

• What we have t oday is a relat ively insecure syst em

t hat is vulnerable t o various f orms of disrupt ion and subversion

• While t he prot ocols can be reasonably well prot ect ed, t he

management of t he rout ing payload cannot reliably answer t hese quest ions

23

What I really want to see…

• The use of aut hent icat ion cert if icat e chains

t o allow aut omat ed validat ion of :

• t he aut hent icit y of t he rout e obj ect being

advert ised

• aut hent icit y of t he origin AS
• t he binding of t he origin AS t o t he rout e obj ect
• Such cert if icat es t o be car ried in BGP as

payload at t r ibut es

• Cert if icat e validat ion t o be a part of t he

BGP rout e accept ance / r eadver t isement process

24

What would also be good…

• A mechanism t o check t he validit y of a

received AS pat h

25

And what should be retained…

• I s BGP as a “block box” policy rout ing

prot ocol

• Many operat or s don’t want t o be f or ced

t o publish t heir rout e accept ance and redist ribut ion policies.

• BGP as a “near real t ime” prot ocol
• Any addit ional overheads of cert if icat e

validat ion should not impose signif icant delays in rout e accept ance and readvert isement

26

Status of Routing Security

• We are nowhere near where we need t o be
• We need more t han “good rout ing housekeeping”
• We are in need of t he adopt ion of basic securit y

f unct ions int o t he I nt ernet ’s rout ing domain

• I nj ect ion of reliable t rust able dat a
• Address and AS cert if icat e inj ect ion int o BGP
• Explicit verif iable t rust mechanisms f or dat a dist ribut ion
• Adopt ion of some f orm of cert if icat ion mechanism t o validat e

rout ing prot ocol inf ormat ion dist ribut ion

27

Thank You!