Presentation is loading. Please wait.

Presentation is loading. Please wait.

MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell

Similar presentations


Presentation on theme: "MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell"— Presentation transcript:

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

2 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…

3 MENU

4

5 Control Plane Packet Filters How we deployed Cisco rACLs: 1. Build the access-list 2. Replace all deny statements with permit 3. Deploy on several routers 4. If you get matches where you shouldn’t, change to permit/log and see what it is 5. Repeat until no more unexpected matches Constantly improve ­Add src/dst pairs, reduce src/dst ranges, etc

6 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

7 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

8 MENU Route 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 Do not redistribute connected routes into BGP or igp. Run next-hop self.5.6 Static route to 192.0.2.6/32 added if needed

9 MENU 192.0.2.4/30.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

10 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

11 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

12 MENU Route 192.0.2.0/24 to Null0 192.0.2.6/31 192.0.2.4/31 Do not redistribute connected routes into 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

13 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

14 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

15 MENU References http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120 newft/120limit/120s/120s22/ft_ipacl.pdf http://www.juniper.net/solutions/literature/app_note/350013.pdf


Download ppt "MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell"

Similar presentations


Ads by Google