firewall on demand
play

Firewall-On-Demand Service Andreas Polyrakis, GRNET 15-16 February - PowerPoint PPT Presentation

GRNET Firewall-On-Demand Service Andreas Polyrakis, GRNET 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Contents 2 Firewall-On-Demand Motivation & Technology background Implementation Future plans &


  1. GRNET Firewall-On-Demand Service Andreas Polyrakis, GRNET 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia

  2. Contents 2  Firewall-On-Demand  Motivation & Technology background  Implementation  Future plans & synergies 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  3. MOTIVATION & TECHNOLOGY 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  4. DDoS illustated 4 Attackers use zombies 1 zombie: Relative easy to handle army of zombies: big problem…: @ 1Meg: 100 = 200Meg • 500 = 500Meg • 2,000 = 2Gig • 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  5. Motivation 5  Need for better tools to mitigate transient attacks and anomalies  eg DDOS, spambots, viruses, scans, …  “ Better ” in terms of  Granularity : Per-flow level  Source/Dest IP/Ports, protocol type, DSCP, TCP flag, fragment encoding …  Action : Drop, rate-limit, redirect  Speed : 1-2 orders of magnitude quicker  (seconds/minutes rather than hours/days)  Efficiency : closer to the source, multidomain  Automation : integration with other systems (eg IDS/IPS, log analyzers,…)  Manageability 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  6. BGP FlowSpec 6 RFC 5575, August 2009 “Dissemination of flow specification rules with BGP”  Allows BGP to propagate an n-tuple filter with flow matching criteria and actions  matching criteria: a combination of source/dest prefix, source/dest port, ICMP type/code, packet size, DSCP, TCP flag, fragment encoding, etc…, E.g.:  all packets to 10.0.1/24 and TCP port 25  all packets to 10.0.1/24 from 192.0.0.0/8 and destination port {range [137, 139] or 8080  Filtering actions: accept, discard, rate-limit, sample, redirect, etc...  Information independent of unicast routing (different NLRI).  …But it is automatically validated against unicast routing. 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  7. Advantages of signaling via BGP 7  An incremental addition to deployed mechanisms  Complexity/scalability issues already solved, proven scalability and flexibility of BGP in adding new services  Multicast, IPv6, L3 VPN, L2 VPN, VPLS  Reuse of:  internal route distribution infrastructure (e.g.: route reflector or confederation design)  existing external relationships (e.g.: inter-domain BGP sessions to a customer network)  A trust model already in place  normally follows (the well-established trust of) unicast routing  Accept filter when advertised by next-hop for the destination prefix (compare destination address of traffic filtering rule with best match unicast route for this prefix)  Originator of filter and unicast route must be same.  No more specifics from a different AS.  Can be overridden 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  8. Comparing BGP flowspec with… 8 Traditional Firewalls, ACLs BGP blackhole routing (Complementary technologies, Flowspec can be considered as rather than competitive) an enhancement of BGP  No need for expensive, blackhole routing: dedicated hardware  Distributed across the network,  Less coarse applied as soon as traffic enters  More actions the network  Separate NLRI  Actions closer to the source (no capacity wasting)  Adequately fine-grained, even on core/backbone networks  Multidomain – easy propagation towards the upstream  Easy automation & integration 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  9. BGP FlowSpec Status 9  RFC 5575, August 2009  Vendor support:  Juniper : Supported in JUNOS since 7.3 !!!!  Cisco : Not supported, no official plan…   But participates in the RFC  Other big vendors: No  But: Supported by Quagga, ExaBGP and some other routing daemons  IPv6 support: No 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  10. GRNET FoD Implementation 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  11. Design Principles (1) 11  Goal: A service that will allow GRNET customers to mitigate transient attacks & anomalies at their upstream (GRNET) level  NOT a permanent firewalling service. Rules should be removed at the end of the attack (otherwise auto-expire).  Target audience: GRNET customers (NOCs)  Target network: GRNET  Web-based tool, shibboleth authentication of the users  Customers can control which of their users have access to the tool through appropriate “Entitlement” 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  12. Design Principles (2) 12  Functionality  Implementation of transient firewall filters across all GRNET routers  empowered by BGP flowspec  Flow granularity:  Source/Destination IPs  Source/Destination ports  More to be added in later versions (eg TCP flags)  Flow Manipulation:  Drop  Rate limit to three predefined values: 10Mbps. 1Mbps, 100Kbps  More actions may be allowed in later versions, eg redirect  Authorization & Security  Customers should only not be able to affect traffic destined to themselves  GRNET core network must be immune to the tool (in case of bug, misbehavior, compromise) 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  13. Design Principles (3) 13  Programmatic API  REST API to be added in future versions, in order to allow integration with other tools  Coding:  Secure  Based on modern technologies  Open: Open-source license, well-documented, no GRNET- specifics or hardwired stuff  Synergies:  Customers  GEANT & NRENs  GRNET or 3rd party security tools. CERT/CIRTs, IPS/IDS,… 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  14. FoD Operation Overview 14 GEANT IX Customer’s NOC representative  logs into a web tool (shibboleth) and describes flows and actions Flow destination is validated  against the customer’s IP space A dedicated router is configured  (netconf) to advertise the route via BGP flowspec eBGP sessions propagate the n-  FoD tuple to GRNET router(s). iBGP further propages the tuples to all GRNET routers. FoD router Dynamic firewall filters are  implemented on all routers Attack is mitigated (dropped,  GRNET rated-limited) upon entrance FoD Customer UI End of attack: Removal via the  tool, or auto-expire Customer 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  15. User Interface (1) 15 Firewall-On-Demand 15 February 2012, APM meeting, Dubrovnik

  16. User Interface (2) 16 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  17. Demo (iperf simulated attack) 17 A 100Mbps attack Typically less than 15 seconds Flow limited to 100Kbps

  18. Implementation - Architecture 18

  19. Implementation - Technologies 19  Open Source project  Python Django ORM & jQuery Javascript lib  Multilayered architecture  Shibboleth: User authentication based on special attrib  Django: UI rendering & db modeling  Long polling: fetch updates without reloading  Celery/beanstalk: apply configuration without locks  nxpy: Network XML to python classes proxy  Ncclient: python netconf client (ncclient)  Caching, cron jobs, REST API (next release), mobile interface (future release) 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  20. Information Flow 20 • User login • Rule management • Creation, modification, removal UI • Notifications, status • Transform rules to python objects • DB operations • Transform python objects to netconf XML configuration Middleware • Apply XML configuration via XML RPC to device • Save received configuration to device (switch) • Propagate rule via eBGP to peer routers • Rule filters and acts on matching flows Network 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  21. Status 21  Alpha version of the service already running http://fod.grnet.gr/  Pre-production (beta) within February  Source code soon to be released: http://code.grnet.gr/ 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  22. Future & Synergies 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  23. Expanding the service to the GEANT community 23  Phase 1: GEANT participation  Configure routers to accept BGP flowspec NLRI  Establish BGP peerings with GRNET  Peerings are protected by route-maps  GRNET customers’ filters are applied at GEANT level PARTICIPATING GEANT NREN  Phase 2: NREN participation  Juniper equipment is required  GRNET  Also, NREN Customers could propagate their filters through their bgp peerings instead of using the UI Customer FoD 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

  24. Synergies with security teams 24  Connect to the domain’s IPS/IDS, honeypots, …  Connect to GEANT anomaly detection tool  Connect to any CERT/CIRT team that we trust  “Soft” actions can make adoption easier  Rate-limit instead of drop 15-16 February 2012, 5 th TF-NOC meeting, Dubrovnik, Croatia Firewall-On-Demand

Recommend


More recommend