A bit of theory¶

Security is a major concern of today’s networks and in particular reactive protection against Denial of Service attacks. To date, attack mitigation is carried out mainly by two security approaches. The first approach is to deploy old style access lists either close to the server, resulting in valuable resources already wasted, or to the ingress point of the target domain. In the latter case uplink bandwidth is also wasted while the administrative overhead and large response times together with the coarse nature of access lists renders the mitigation actions ineffective. An improvement is based on a technique known as Remote Triggered Black-Hole (RTBH). Using BGP as a security tool, the receiving router translates a BGP community into a discard Next-Hop. The coarse actions that are implemented by RTBH, render the victim unreachable to the entire Internet, thus terminating in itself the DDOS attack. The positive side of RTBH is that the network administrators have successfully mitigated the flood of inter-domain traffic but even in this case the uplink remains flooded with attack traffic. An enhancement to existing approaches would be the deployment of a security tool that would allow firewalling rules to be propagated to different domains independent of unicast routing, while allowing for n-tuple of matching and filtering actions.

We, in GRNET's NOC, driven by the need to provide advanced security services develop our own in-house security provisioning platform using readily available Open-Source software. Our approach towards security provisioning is the usage of flow specification NLRIs to successfully convey filtering information amongst neighboring domains.Our deployment is based on BGP family flow supporting hardware (RFC 5575). We have deployed a hardware box (Juniper EX4200) that is layer 3 capable and supports BGP and address family flow. This box is located in one of GRNET’s data centers and conveys flow information through external BGP sessions with GRNET border routers. A first (coarse) level of trust is applied on the BGP sessions and is based on the well established trust of unicast routing. To allow for automation we have mitigated a more strict authorization model to the web front-end. Therefore a filter is applied on the routers that allow all GRNET customers rules to be accepted on the flow routing table.

Our web platform is developed in Python Django framework. The platform allows for creation, modification and deletion of flow rules via a wizard-like GUI. Authentication is performed via Shibboleth using an appropriate Entitlement attribute, carried only by NOC personnel. This gives the service a federated nature and eliminates any concern that the mechanism is a DDOS by itself. Authorization is based on address space assignments to GRNET’s customers. A number of GRNET’s clients are assigned a private AS number not allowing in this case the use of RIPE public whois. To address this issue GRNET has implemented a local private whois server where all the records are kept. Each client Institution/University has each own address space allocated by RIPE and also registered by GRNET Hostmaster in appropriate route-object located on the local whois server.

While existing bgp flow-spec approaches make usage of bgp daemons, our implementation is solely based on NETCONF. NETCONF was chosen for being a secure management protocol with clean XML structure and a well defined request/response schema. Furthermore, the hardware that the rules are applied supports NETCONF. On the backend of the tool, a python NETCONF proxy middleware translates user requests to BGP flow rules and vice-versa. The NETCONF middleware applies the produced configuration to the hardware box via a python SSH-NETCONF client. Configuration retrieval is also supported to allow for syncing and reconciliation. Device configuration is mapped to Python classes that can be easily distributed and reused among a variety of applications. Once a request for a new flow rule is placed, configuration is applied to the aforementioned hardware box and is then propagated via BGP to GRNET’s routers. What really boosts the deployment of the platform is the use of open source tools that map network configuration to service elements. This allows for interdomain deployment as tools can be easily adapted to each domain needs and requirements.

..and some action¶

Firewall on Demand runs as a Gunicorn gevent application. The GUI is served via Apache proxying of the WSGI application. As Django is used, Django templates serve the frontend along with some jQuery libs. Rule requests are stored in a database. Once a rule is requested and some checks are passed server-side, a new Celery job is spawned. The request is translated from python objects (model) to XML Netconf device configuration via nxpy. This configuration is passed to a Python Netconf client (Shikar's patched client) and then to the device (EX4200) via XML-RPC. As Celery runs on one worker, requests are passed to the device in a serial manner, thus avoiding locks. Once the configuration is applied to the device, the device responds. The response is parsed by the "python objects to network configuration proxy" and via a long-polling mechanism is presented to the user.

The system architecture is presented right here.

Want to see it in action?¶

Login Screen

Logging in with your federation account brings you to your customer's rules:

Let's create a new rule...

Right... submitting the form brings us to the home screen, with the new rule added as pending.
Let's check the console. The console is updated via long polling whenever there is a status update. No page refresh is required. It works similarly to facebook's chat and twitter's new tweet notifications. The console is a modified jQuery dialod ;) .

Great! The request seems to have been applied to the device. It's active!
Let's check the device... ssh to our device and then "edit private"->"show routing-options flow"...

Awesome! Our rule has been applied to EX4200. It will be propagated via eBGP to its neighboring router and BGP flow spec will do the rest!!

Editing is easy to accomplish

Removing the rule from the device is even easier

Each user can apply rules targeting only his administrative network

We have conducted tests on our production network. The average time before a DDOS is mitigated is 30 seconds counting from the moment that the user clicks "Apply" on the creation form.

A live screencast is availiable at: http://www.youtube.com/watch?v=VZy7DG8sjSk

Stay tuned for updates...

Authors: Leonidas Poulopoulos, Michalis Mamalis, Andreas Polyrakis