An Operational Perspective on BGP Securit y Geof f Hust on February 2005 1
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 . 2
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 3
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? 4
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 5
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 6
Components of the network model Peers Upstreams BGP Route Reflectors IGP Interior Routers iBGP Edge Routers eBGP Customers 7
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 8
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 9
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 10
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 11
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 on 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 12
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 on session inst abilit y and updat e f loods 13
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 14
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 15
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 16
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 17
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 18
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) 19
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 (?) 20
Even so • I t s not all t hat good is it ? 21
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 22
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 23
What would also be good… • A mechanism t o check t he validit y of a received AS pat h 24
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 25
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 26
Thank You! 27
Recommend
More recommend
