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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend