Akamai Diversity

The Akamai Blog

How can you control and optimize network access policies as a front-line defense strategy?

The following is a guest post from Director Global Service Delivery Patrice Boffa and Solutions Architect Harish Jakkal.


Locking down access to a Web application based on information from the Network Layer of the Open Systems Interconnection (OSI) model is the most basic level of request filtering mechanism available. There are many network firewalls in the market that inspect the source/destination IP address of the request to making routing decisions on whether to forward or deny requests.

Using Network Layer Controls within these firewalls, you can either allow or disallow end-user access to the Web application.  At the Network Layer, the parameter available to make the decision is the advertised IP of the end-user.  Many firewalls ship with a geo-location database that lets you correlate an IP to a geographical region.  This provides the flexibility to allow or deny end-users based on their advertised geographical location rather than listing all IP spaces for each geographical region. 

Network Layer Controls are typically maintained using a rather long list of IP/CIDR/Geo whitelist or blacklist.  However, this approach has the following limitations:

  1. Many firewalls are still on-premise devices that may not be able to scale up to volumetric attacks like Distributed Denial of Service (DDoS).
  2. Firewall configurations can be cumbersome to maintain and lack flexibility in the conditional logic that you wish to apply.
  3. Some firewalls club policies into one single configuration file.  As a result, each update to a policy requires deploying the configuration, which could be challenging from a change management perspective.  Many firewalls still require manual intervention when updating the access control list, which is more likely to be prone to human errors.

How do we solve these problems?  The Akamai KONA Network List Management feature provides a cloud-based, scalable alternative to controlling access to your Web application that is both easy-to-use and flexible.  Network List Management allows you to create and maintain logical lists of blacklists or whitelists. 

A network list can be of the type:

  1. IP: A network list that contains only IPs/CIDRs.
  2. Geo: A network list that contains two letter country codes.
blog_screenshot_1.png

For instance, in the screenshot above, the network list:


  • My Corporate IP List is an IP List that contains all IPs/CIDRs that are part of my corporate network. Such a list can be used to allow access to QA/Dev instances of a Web application to facilitate testing during the development cycle while restricting access to requests originating from the rest of the Internet.
  • Embargo Country List is a Geo List that contains the list of all embargoed countries. Such a list can be used to deny access to requests originating from the embargoed countries at the Akamai edge.
blog_screenshot_2.png
Once a list is created, you have the ability to set an action on the list:

  • Allow: All requests from the IPs/Geos in the list will be allowed access through to the Web application. (Note: This should not be considered as a way to bypass WAF.)
  • Deny: All requests from the IPs/Geos in the list will be denied access to the Web application at the Akamai edge.

Network Lists visible in the Akamai Portal can be classified into two categories:

  1. Akamai Shared Network Lists: The CSIRT and the engineering team at Akamai constantly monitors evolving threats to create and share network lists with the relevant set of customers' so that such lists are readily available for you to block at the Akamai edge. For instance, an Akamai financial services customer might have a different set of lists as compared to a commerce customer with some overlap if threat vectors are common to these verticals. These lists have the Akamai Wave logo preceding the name of the list as evidenced in the screenshot above.
  2. Customer Generated Network Lists: These are lists created by our customers' based on specific business or technical requirements.

The most common use cases where Network Lists can be used are:

  • Controlling access to your application at the Akamai edge.
  • WAF Bypass Network List: Using this feature you can designate a network list for which you would like to bypass Akamai WAF execution.
  • Out-of-Band Updates: If your content delivery configurations use a list of IPs/CIDRs/Geos that need constant updates, consider replacing them with network list so that you do not have to deploy a new configuration each time an update is required.

Network Lists provide the flexibility in maintaining and updating Network Layer Controls without having to worry about change management processes that come about as a result of having to deploy a new firewall configuration each time.

While setting the premise for this post, I also mentioned that a lot of these processes tend to be manual and by their nature can tend to be error prone. Hence, with the Network List Management feature, Akamai has provided a RESTful API framework that allows our customers to create, read, update and delete network lists and individual network list elements viz., IPs/CIDRs/Geos. 

Network List API allows us to automate the process of maintaining Network Layer Controls within WAF by making RESTful API calls through non-browser based clients, thus cutting down on man hours required to prune and upload extensive lists of IPs/CIDRs/Geos. 

Typical uses cases where such automation can provide operational efficiencies are: 

  • Fraud detection systems within your infrastructure invoke the API on an hourly basis to update a network list that includes all IPs/CIDRs identified to have exhibited fraudulent behavior to be denied at the Akamai edge.
  • Hackers have been known to leverage The Onion Router (TOR) network to partake in efforts to destabilize the origin infrastructure. Just by the nature of the TOR network the list of IP's keeps changing quite frequently. A script can frequently scrape a list of IP's from the relevant source and update a network list that has been created to deny requests from the TOR network at the Akamai edge.
  • Controlling access to a site that only your partner companies can access based on signups is easier with Network Lists. In frequent intervals, you can invoke the API to deploy an IP whitelist allowing access only to your partners.

...the possibilities are endless in terms of how you can leverage the Network List feature and the API.

You can engage with @AkamaiPS on Twitter to assess how you can utilize Network Lists to gain operational efficiencies in maintaining Network Layer Controls within Akamai KONA.


Patrice Boffa is Director Global Service Delivery and Harish Jakkal is Solutions Architect at Akamai.


Leave a comment