Firewall on Demand A multidomain approach Leonidas Poulopoulos, Yannis Mitsos – GRNET NOC Firewall on Demand workshop TF-MSP meeting November 2014
Network threats GRNET Cloud IaaS
DDoS illustrated
GRNET - Rapid Anomaly Detection Python tool - rady VolumetricPackets (WP-pingback)
Consequences Performance degradation – GÉANT Backbone – NRENs Outages Services malfunction Resources – Human – Equipment
Mitigation Techniques though time acls, firewall filtersRTBHBGP flowspec
The acl way Detect attack Profile it Apply local ACL Notify upstream Apply NREN ACLs Notify upstream Apply upstream ACLs Phone calls s TIME TIME TIME
The BGP way Well established model of trust Stable and robust – Powers the internet Remote triggered black-hole routing BGP flow specification – “My name is Wall, Fire Wall”
Who are you BGP Flowspec? BGP Flowspec defined in RFC 5575 Layer 4 (TCP and UDP) firewall filters to be distributed in BGP on both a intra- domain and inter-domain basis Match – source/dest prefix – source/dest port – ICMP type/code – packet size – DSCP – TCP flag – fragment type – Etc Actions – accept – discard – rate-limit – sample – redirect – etc
A firewall filter over BGP??? Propagates wherever BGP flow spec is enabled – Currently supported by Juniper To the very ends of the network To peering networks – Downstream – Upstream Ideas! Apply to a single point and let it propagate to my borders Sounds like attacks are now mitigated closer to source!!! – YES!!!! Seems that it is more granular than RTBH – YES!!!! Can we automate this?? Can we go from RFC to tool? – Have already done this!!!
Can you remind me why we need BGP flowspec? Distributed across the network Closer to the source Fine-grained even on core/backbone networks Multidomain easy propagation towards the upstream via BGP Easy automation & integration ACL S Flowspec: enhancement of RTBH Does not affect all traffic to victim Less coarse More actions Separate NLRI BGP RTHB
Firewall on Demand – from RFC to tool D EVELOPED BY : GRNET G RANULARITY : Per-flow level A CTION : Drop, rate-limit, redirect S PEED : 1-2 orders of magnitude quicker E FFICIENCY : closer to the source, multi-domain A UTOMATION : integration with other systems M ANAGEABILITY : status track, web interface N EED FOR BETTER TOOLS TO MITIGATE TRANSIENT ATTACKS
GRNET setup
How does it work? Customer’s NOC logs in web tool & describes flows and actions Destination validated against customer’s IP space A dedicated router is configured to advertise the route via BGP flowspec Dynamic firewall filters are implemented on all routers Attack is mitigated upon entrance End of attack: Removal via the tool, or auto-expire Web NETCONF eBGP iBGP
Have you tried it in production? GRNET network in production since years 21Tbytes 100rules 40 users 20 peers
Is there a chance that I shoot my leg???? BGP Flowspec is a “sharp knife” Protocol/Tool level protection – Flowspec filters – BGP filters – Authorization Users can only act for their networks – Application level protection Protected networks Alerts for violation Everything according to procedures
Time to go multidomain fod.geant.net
FoD recipe 1 central FoD instance BGP flowspec enabled in GÉANT routers 3 flavors – NREN without BGP flowspec supporting equipment – NREN with BGP flowspec equipment that uses local FoD – NREN with BGP flowspec equipment that uses GEANT’s FoD
All together
Phase 1 tests Click Apply 6 seconds later…
FoD Application Architecture O PEN S OURCE
Under the hood Django application – 1.4 – Debian Wheezy system packages Application server – Gunicorn HTTP server – Apache Proxy module Database – MySQL Caching – Memcached Job scheduler – Celeryd Que – Beanstalkd Network client – Ncclient - NETCONF
Installation and monitoring Extensively tested on Debian Wheezy – Using system packages Done in ~ 30 mins Monitored components – Host checks – Service checks Apache (check_http) Gunicorn (check_mk) Celeryd (check_mk)
Joining FoD Shibboleth attributes: – (maps to HTTP_ ) – persistent-nameid or persistent-id or targeted-id (all map to HTTP_REMOTE_USER) A valid institution/peer with active subnets
Support GRNET will actively support FoD Same codebase Small changes in single and multidomain – Shibboleth vs. eduGAIN Full installation documentation of multidomain flavor will be provided by the end of Nov 2014
To Do’s Full documentation for multidomain setup Multidomain repository Harden security – Limit access ACL – Introduce Shibboleth attributes (?) Test on production network with manual entry Invite 2-3 NRENs to join
Thank you