We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byAnnabel Kennington
Modified over 2 years ago
Nicolas FISCHBACH Senior Manager, IP Engineering/Security - COLT Telecom firstname.lastname@example.org - http://www.securite.org/nico/ version 1.0 Secure Network Infrastructure Deployment PacSec.JP 2003 - Pacific Security Japan
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 2 Agenda » Router Security >Router security basics » Infrastructure Security >Filtering, BGP/DNS >Forensics » Distributed Denial of Service >Trends in attacks, worms and botnets >Detection and mitigation » Other recent and new risks >IPv6, MPLS, Lawful Intercept, etc. » Conclusion
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 3 Router Security » Router Security 101 >Good infrastructure security starts with good router security >Packet forwarding vs “received” packets performance >Like on any system: -Use VTY (virtual TTY) ACLs, avoid passwords like “c”, “e”, “cisco”, “c1sco” and use an AAA system like TACACS+ -Avoid shared accounts and use privilege levels/restrict commands -Turn off unneeded services, restrict SNMPd -Activate logging (but not too much!) -Configuration and ROMMON/IOS images integrity -Make your router “forensics ready” -Etc.
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 4 Router Security » Router Security 101 >Your biggest security risk ? -The Customer Diagnostic/NOC guy leaking configurations to customers that include shared/common passwords and communities, the management ACLs, TACACS+ server IPs, etc. -Think filtering scripts/peer approval >Like with any program or application: don’t trust client input -What could happen if the customer unplugs your managed router and plugs his own router (management ACLs, filtering, etc) ?
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 5 cr tr ccr cr ar cpe cr cpe Edge Core Access Customer (access) Customer (transit) Router “types” Infrastructure Security ISPx ISPy ISPa ISPb tr ISPm ISPk ppr ISPm ISPy ISPj ixpr Transit Peering (IX or private) Access (/30) Link “types”
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 6 Infrastructure Security » Infrastructure Security >The Internet is considered a “critical infrastructure” >Filtering routing information and filtering traffic (IP layer) are complementary >BGP and DNS are the core protocols >Your backbone: large firewall or transit network ? >Data-center vs core infrastructure based detection -Data-center: in-line (“complete packet”) -Infrastructure/distributed: Netflow (“header only”) -Find the right mix of both.scalability.CAPEX.sampled Netflow (high probability of missing single packets) vs one in-line device (mirrored traffic) per larger POP
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 7 Edge Core Access Customer receive ACLs [rACL] infrastructure ACLs [iACL] transit ACLs edge [tACLe] transit ACLs access [tACLa] Router “types” Infrastructure Security » New ACLs “types”
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 8 Infrastructure Security » New ACLs “types” >iACLs: why should anybody with Internet connectivity be able to “talk” to your network core ? (traffic directed at the infrastructure) -you need a structured address plan >rACLs: helps to protect the Route Processor (traffic directed at the router) >tACLs: enables filtering on the forwarding path (traffic “transiting” your network) >Keep them short and generic, avoid exceptions >“Default permit” or “default deny” ?
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 9 Infrastructure Security » New ACLs “types” >Combine them with anti-spoofing ACLs/uRPF at the edge >Don’t forget management traffic (telnet/SSH, SNMP, TFTP, syslog, AAA, etc) and routing protocols >What to do with ping and traceroute (ICMP/UDP): incoming and outgoing (for troubleshooting) » Other types of “filtering” >Re-coloring (QoS): enforce it at your AS boundaries >Rate-limiting: what to throttle and what does it break ? >Other options to protect the router -rate-limit the traffic to the RP (data punt/slow path) -Avoid “administrative traffic generating options” (like ACLs with logs) -IP options, ICMP, mcast “filtering”, etc.
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 10 Infrastructure Security » ACLs (Access Control Lists) >Always (try to) use compiled ACLs: avoid log[-input], source port, output ACLs, etc. >Where to filter: edge, core, transit, peerings ? >What to filter: protocols, src/dst IP, src/dst ports, header ? >Who should filter: tier1, tier 2/3 providers (with broadband home users), enterprise (FWs) ? >In which direction: to and/or from the end-users (ie. protect the Internet from the users and/or vice-versa) ? >Depending on the hardware and software capabilities: micro-code/IOS and engines (-: 0, 1, 4; +: 2; ++: 3) >Scalability of the solution (no easy way to maintain distributed ACLs policies) >How long should you keep these filters in place ?
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 11 Infrastructure Security » uRPF (unicast Reverse Path Forwarding) >Strict uRPF for single-homed customers (route to source IP points back to the ingress interface) >Loose uRPF for multi-homed customers (route/network prefix present in the routing table) >Loose uRPF doesn’t protect from customer spoofing >Adapt strict/loose policy depending on your customers’ setup >Statistics prove that uRPF is not really deployed (nor loose, nor strict)
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 12 Infrastructure Security » Other (“edge”-only) features >NBAR (Network Based Application Recognition) -Used with custom Cisco PDLMs (Packet Description Language Module) to identify P2P traffic in quite some university networks >TCP Intercept -Usually done by the enterprise FW >What else do you want you router to do for you today ? ;-)
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 13 Infrastructure Security » BGP (Border Gateway Protocol) >Not as easy as many think (and say) to hijack BGP sessions! >BGP flaps (dampening) or route changes are more common >Trivial passwords and no VTY ACL on a BGP speaking router: cool “warez” for underground/SPAM communities (like eBay accounts or valid CC numbers) >Filtering: -Default-free routing in the core (to avoid the magnet effect) -Apply the same strict policy to transit/peerings than to customers (AS_path, prefixes, max-pref, RIR allocations, etc) -Martian/Bogons/RFC1918/RFC3330 -ISPs stopping to announce/route/filter the AR CPE /30 >Account for BGP sessions (especially in full-mesh deployments, on RRs and on peering routers) and use md5
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 14 Infrastructure Security » BGP (Border Gateway Protocol) >Origin-AS/prefix relation is never verified >AS_path to key locations (especially DNS root servers) >What’s next ? -Secure BGP.RIRs to run PKIs and act as CAs.Verify “ownership” (Origin-AS/prefix).Signed BGP Update message -SoBGP.Distributed Origin-AS/prefix check.New “BGP Security” message » IGP (Internal Gateway Protocol) >Scope is much more limited, but don’t forget to secure it (OSPF, IS-IS, etc)
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 15 Infrastructure Security » DNS (Domain Name System) >Quite a few attacks recently >DNS “abuse” due to bad network/system setups and broken clients: AS112 project (distributed servers to answer negative RFC1918 PTR queries) >IP anycast helps but makes debugging more difficult (which server is actually producing the error ?) >Key to watch Origin-AS and AS_path from/to root and gtld DNS servers » Is BGP/DNS “hijacking” a real threat ?
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 16 Infrastructure Security » Forensics: BGP, Netflow (and ACL logs) >Hop-by-hop DDoS attack tracing using ACLs or ip source- tracker isn’t very effective >BGP Update messages and (sampled Netflow) accounting will be part of the next-generation high-bandwidth IDSes and a must for historical data: Netflow for the more high level view (ie. the flow) and traffic dumps for the low level view (ie. the actual data) >Distributed Route Collectors give a much better view >Putting these bits together create a good anomaly detection system and good source for historical data (next to enabling you to do better traffic management ;-)
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 17 Distributed Denial of Service » Trends in DDoS >Yesterday: bandwidth abuse, exploiting bugs, TCP SYN, UDP and ICMP floods (amplifiers) >Today: -PPS (packet-per-second), against the SP infrastructure, non- spoofed sources (who cares if you have 150k+ bots anyway) and reflectors -Short lived route announcements (for SPAM usually) >Tomorrow: -QoS/”extended header” -CPU (crypto intensive tasks like IPsec/SSL/TLS/etc) -Protocol complexity and other attacks hidden/mixed with or even part of normal traffic where complete state information/traffic needs to be tracked ? -Non-cached items in distributed content networks
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 18 Distributed Denial of Service » DDoS Detection >ACLs, queue counters, NMS (CPU, interface counters, etc) >Netflow and dark IP space/bogons/backscatter monitoring >“Honeybot” approach -Watch IRC/P2P/etc based communications -Run bots in “safe mode” -Listen to Lance’s talk on honeypot technologies >Customers ;-) » DDoS Mitigation >ACLs and CAR (rate-limit) >null0 routing (blackholing), (anycast) sinkhole, shunt, traffic rerouting and “cleaning” >Propagated blackholing (special community)
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 19 Distributed Denial of Service » Trends in worms >The “worms of the summer”, bots and botnets and their effect on routing stability >What if the guys who wrote recent worms had a clue or different objectives ? -Worm “engines” becoming better, more distributed payload -Worms == SPAM (i.e. going commercial) ? >Which policies do SPs apply: leave everything open until it hurts the infrastructure or block for days on early warning ? >Can we win the race (analyze and mitigate in <1h) ? >After “everything on top of IP” the trend is “everything on top of HTTP[s]” (ie. circumventing firewalls 101): what if the next one is going over 80/tcp ? ;-) >Listen to jose’s talk on worms
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 20 Distributed Denial of Service » Netflow based detection >Flow (src/dst IP, src/dst port, protocol, ToS, if, no payload) >Usual traffic distribution (90% TCP, 8% UDP, <1% ICMP/GRE/IPsec/others - 50% of small packets) >Needs as much fine tuning as an IDS Edge Access Router “types” NOC tr ccr ar tr ppr ixpr (Sampled) Netflow Aggregated Netflow Flows (SNMP) Alerts collector controller
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 21 Distributed Denial of Service » Traffic diversion (and inspection/cleaning) >The alternative to strict filtering (which usually means the attacker won) ? >Required when layer3+ and stateful information is needed >BGP and/or Policy Based Routing (PBR) as the triggering mechanism(s) >Tunnels: MPLS, GRE, L2TPv3, IPsec, etc. >Such “cleaning centers” should be distributed across your network (large POPs, known attack entry points, etc) >Same concept can be applied to honeynets (distributed honeynets/honeyfarms)
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 22 Distributed Denial of Service » Traffic diversion (and inspection/cleaning) Edge Access Router “types” “Attack” traffic “Good” traffic Flows “Bad” traffic cr tr ccr cr ar cr tr ppr ixpr ar inspection server Core
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 23 Other recent and new risks » IPv6 >IPv6 is not the 128 bits address field version of IPv4 >New/updated protocols and new implementations >Same old and well known bugs will make it into new code >Current IPv6 “network” is a large lab! >Listen to itojun’s talk on IPv6 security » Inter-AS MPLS VPNs >Multi-Protocol Label Switching is considered as secure as other layer 2 technologies like FR and ATM: but the environment is IP based and much more complex and open >Inter-Service Provider MPLS VPNs imply transitive trust, no AS boundary anymore
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 24 Other recent and new risks » Lawful Intercept >Actively being deployed in lots of countries >A cool remote sniffer for Network Operations to dump traffic without having to pray or say “oops!” each time they press “Return” after entering “debug ip packet details” ? >An easy way for an attacker to do the same ? >The router is not the only device you may have to own, the MD (Mediation Device) is also part of the game
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 25 Other recent and new risks » What if this is only the top of the iceberg… >… and somebody comes up with a bug in the code on the forwarding path ? >… and the Cisco IPv4 wedge bug had leaked or been publicly announced ? >“Quick” upgrading Core/Edge vs. bugscrub ? >Effects/risks of non-diversity (HW and SW) ? >Listen to FX’s talk on Cisco IOS vulnerabilities » “Broken” devices >[Flawed router] NTP “DDos” >tcp.win == 55808 ?
© 2003 Nicolas FISCHBACH PacSec.JP 2003 - Pacific Security Japan 26 Conclusion » Conclusion » See also >Backbone and Infrastructure Security Presentations -http://www.securite.org/presentations/secip/ >(Distributed) Denial of Service Presentations -http://www.securite.org/presentations/ddos/ » Q&A Image: http://www.inforamp.net/~dredge/funkycomputercrowd.html
Nicolas FISCHBACH Senior Manager, IP Engineering/Security - COLT Telecom - version 1.01 Infrastructure.
FOR INTERNAL USE ONLY [Your business] exceeds with COLT Network Response to DDoS attacks – TNC 2006 Nicolas FISCHBACH Senior Manager, Network Engineering.
Network Security1 – Chapter 3 – Device Security (B) Security of major devices: How to protect the device against attacks aimed at compromising the device.
Hack.LU 2006 In SPace Nobody Can Hear You Scream Nicolas FISCHBACH Senior Manager, Network Engineering Security, COLT Telecom -
Staff AAA. Radius is not an ISP AAA Option RADIUS TACACS+ Kerberos.
Point Protection 111. Check List AAA to the Network Devices Controlling Packets Destined to the Network Devices Config Audits.
Filtering Spoofed Packets Network Ingress Filtering (BCP 38) What are spoofed or forged packets? Why are they bad? How to keep them out.
Nicolas FISCHBACH Senior Manager, IP Engineering/Security - COLT Telecom - version 1.0 Voice over IP (VoIP)
Joe Budzyn Jeff Goeke-Smith Jeff Utter. Risk Analysis Match the technologies used with the security need Spend time and resources covering the most.
Network Monitoring System In CSTNET Long Chun China Science & Technology Network.
Edge Protection 111. The Old World: Network Edge Core routers individually secured Every router accessible from outside “outside” Core telnet snmp.
– Chapter 4 – Secure Routing
MPLS-based traffic shunt Nicolas FISCHBACH Senior Manager - IP Engineering/Security RIPE46 - Sept
© 2007 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.1 ISP Responsibility Working at a Small-to-Medium Business or ISP – Chapter 8.
Firewalls. Overview of Firewalls As the name implies, a firewall acts to provide secured access between two networks A firewall may be implemented as.
Router Hardening Nancy Grover, CISSP ISC2/ISSA Security Conference November 2004.
Network Security1 Secure Routing Source: Ch. 4 of Malik. Network Security Principles and Practices (CCIE Professional Development). Pearson Education.
Firewalls By Tahaei Fall What is a firewall? a choke point of control and monitoring interconnects networks with differing trust imposes restrictions.
Security Management Process 1. six-stage security operations model 2 In large networks, the potential for attacks exists at multiple points. It is suggested.
COEN 252: Computer Forensics Router Investigation.
Cisco Exam Questions IMPLEMENTING CISCO IOS NETWORK SECURITY (IINS V2.0) VERSION: Presents: 1.
Chapter 9: Access Control Lists
Access Control Key concepts: Controlling the data flow within a network ACL (access control lists)
06-Sep-2006Copyright (C) 2006 Internet Initiative Japan Inc.1 Prevent DoS using IP source address spoofing MATSUZAKI ‘maz’ Yoshinobu.
Security fundamentals Topic 10 Securing the network perimeter.
11 SECURING YOUR NETWORK PERIMETER Chapter 10. Chapter 10: SECURING YOUR NETWORK PERIMETER2 CHAPTER OBJECTIVES Establish secure topologies. Secure.
© 2008 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 1 Chapter 8: Monitoring the Network Connecting Networks.
2006 Double Shot Security, Inc. All rights reserved 1 Operational Security Current Practices APNIC22 - Kaohsiung, Taiwan Merike Kaeo
Access Control List ACL. Access Control List ACL.
MPLS L3 and L2 VPNs Virtual Private Network –Connect sites of a customer over a public infrastructure Requires: –Isolation of traffic Terminology –PE,
FIREWALL TECHNOLOGIES Tahani al jehani. Firewall benefits A firewall functions as a choke point – all traffic in and out must pass through this single.
Attacking on IPv6 W.lilakiatsakun Ref: ipv6-attack-defense-33904http://www.sans.org/reading-room/whitepapers/protocols/complete-guide-
Network Security Chapter 11 powered by DJ 1. Chapter Objectives Describe today's increasing network security threats and explain the need to implement.
© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—6-1 Scaling Service Provider Networks Scaling IGP and BGP in Service Provider Networks.
Session 2 Security Monitoring Identify Device Status Traffic Analysis Routing Protocol Status Configuration & Log Classification.
Kevin Miller Carnegie Mellon University Three Practical Ways to Improve Your Network.
PacNOG 6: Nadi, Fiji Dealing with DDoS Attacks Hervey Allen Network Startup Resource Center.
1 Chapter 6 Network Security Threats. 2 Objectives In this chapter, you will: Learn how to defend against packet sniffers Understand the TCP, UDP, and.
MENU Implications of Securing Router Infrastructure NANOG 31 May 24, 2004 Ryan McDowell
IPv6 Has built in security via IPsec (Internet Protocol Security). ◦ IPsec Operates at OSI layer 3 or internet layer of the Internet Protocol Suite.
© 2008 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 1 Chapter 9: Access Control Lists Routing & Switching.
IT443 – Network Security Administration Instructor: Bo Sheng
© 2006 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 Filtering Traffic Using Access Control Lists Introducing Routing and Switching.
Transitioning to IPv6 April 15,2005 Presented By: Richard Moore PBS Enterprise Technology.
BGP Transit Autonomous System
Chapter 7 Denial-of-Service Attacks Denial-of-Service (DoS) Attack The NIST Computer Security Incident Handling Guide defines a DoS attack as: “An action.
Access Control List (ACL) W.lilakiatsakun. Transport Layer Review (1) TCP (Transmission Control Protocol) – HTTP (Web) – SMTP (Mail) UDP (User Datagram.
Network security Further protocols and issues. Protocols: recap There are a few main protocols that govern the internet: – Internet Protocol: IP – Transmission.
Building Your Own Firewall Chapter 10. Learning Objectives List and define the two categories of firewalls Explain why desktop firewalls are used Explain.
Chapter 8. Upon completion of this chapter, you should be able to: Understand the purpose of a firewall Name two types of firewalls Identify common.
© 2017 SlidePlayer.com Inc. All rights reserved.