menu implications of securing router infrastructure nanog 31 may 24, 2004 ryan mcdowell...

15
MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell [email protected]

Upload: cassandra-burns

Post on 03-Jan-2016

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

Implications of Securing Router Infrastructure

NANOG 31May 24, 2004

Ryan [email protected]

Page 2: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

Control Plane Packet Filters

• Receive Access-List (rACL) on Cisco• Input filter on Lo0 on Juniper• Deployed in 2002

Deny IP fragments Permit SSH, SNMP, DNS, TACACS, NTP, etc

• secured by src/dst pairs Permit BGP, IGMP, PIM Permit subset of ICMP Permit UDP >= 1024

• do not break traceroute to the router Deny everything else

• and count it…

Page 3: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

Page 4: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

Page 5: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

Control Plane Packet Filters

• How we deployed Cisco rACLs:1. Build the access-list2. Replace all deny statements with permit3. Deploy on several routers4. If you get matches where you shouldn’t,change to permit/log and see what it is5. Repeat until no more unexpected matches

• Constantly improve Add src/dst pairs, reduce src/dst ranges, etc

Page 6: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

Control Plane Packet Filters

• Good IP addressing strategy needed• Made routers harder to kill• Really helps with the magic packet

attacks• Few operational implications

“Sprint’s routers are broken because I cannot ping your router with a 1501/4471 byte (fragmented) packet.”

• Change control can be difficult• Routers still vulnerable to attacks

against TCP/179, ICMP, IP options, UDP, etc

Page 7: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

Limit Reachability To Control Plane IP Addresses• Most attacks target IPs on routers

obtained from a traceroute• Let’s remove the ability to reach

SprintLink-Customer /30 networks from the big dangerous Internet

Page 8: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

ISP A

Customer C

SprintLinkRoute 192.0.2.0/24 to Null0

192.0.2.4/30

Advertise 192.0.2.0/24 via eBGP

Best route to 192.0.2.4/30 is null0

ISP B

Do not redistribute connected routes into BGP or igp. Run next-hop self

.5

.6

Static route to 192.0.2.6/32added if needed

Page 9: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

ISP A

Customer C

SprintLink

192.0.2.4/30

ISP B

.5

.6

Packets from 192.0.2.4/30 will pass uRPF check (i.e. ICMP Type 3 Code 4)

192.0.2.4/30 is no longer reachable from ISP A

192.0.2.4/30 is still reachable from ISP B

Page 10: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

Limit Reachability To Control Plane IP Addresses• Does not add 100% security

But makes it a little harder for the attacker

• 25% of customers required the use of their point-to-point address

• Took over a year to implement• Implications

Traceroute through the router not impacted Any packets to the routers breaks

• PING– Folks LOVE to PING our routers…

• Traceroute

Page 11: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

Limit Reachability To Control Plane IP Addresses• Do the same thing in the core

“advertise-passive-only” in Cisco IS-IS export policy in Juniper

Page 12: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

ISP A

Customer C

SprintLinkRoute 192.0.2.0/24 to Null0

192.0.2.6/31

ISP B

192.0.2.4/31

Do not redistribute connected routesinto BGP or igp. Run IS-IS “advertise passive-only”

Can’t reach 192.0.2.4/30

Can’t reach 192.0.2.4/31

Can reach 192.0.2.6/31

.7

.6

.4

.5

Page 13: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

Limit Reachability To Control Plane IP Addresses• RFC1918 loop backs for management

(SNMP, SSH, iBGP, etc….)• Rate limiting rACL

CoPP (Control Plane Policing) on Cisco

• Apply BTSH/GTSH to rACL• Ignore IP-Options

Forward packets as if there are no options set

Similar to “no ip source-route” on Cisco

Page 14: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

What does all this mean?

• Don’t plan on sending any packets destined to the router. But this is already happening with the

MPLS-ization of networks.

• More secure infrastructure Not perfect, but better than where most of

us are now Can be done without ingress filtering

which is hard

Page 15: MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell ryanm@sprint.net

MENU

References

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s22/ft_ipacl.pdf

http://www.juniper.net/solutions/literature/app_note/350013.pdf