How to Use F5 Distributed Cloud to Obfuscate Ingress and Egress Traffic

For anyone new to the content that I put out, it’s generally focused on government (or more government) and generally any organization that are stuck trying to sort out some sort of government compliance situation. Recently I have had an influx of customers that have requirements around Cyber Liability Insurance (It’s a real thing!).

In May of 2021 the United States Government Accountability Office put our a report on Cyber Insurance (Report to Congressional Committees, Insurance and Policyholders Face Challenges in an Evolving Market). Link: https://www.gao.gov/assets/720/714429.pdf

While the report does not mention specific requirements or solutions that Cyber Liability Insurance requires, it does highlight the financial impact of Cyber Attacks.

And with most things I post, I have had enough customers asking about different requirements of their policies that they have had trouble solving that it made sense to share a solution with all of you.

The thing that I have been getting asked about the most lately concerns IP address Obfuscation of ingress and egress. For anyone that’s never had to be concerned about how easy it can generally be to bypass security solutions there are a couple of things to be concerned about that obfuscation can help with.

And just so we are clear, INGRESS is easy, you don’t even have to think about it, we do all that automagically for you if you publish services through our global network, but where most people have issues with Egress. But before we dive into that, some might wonder WHY a Cyber Liability Policy might want you to obfuscate your address space. So lets walk through a shortened attack plan.

1. Reconnaissance

If I were the type to plan an attack against an organization, I would generally go through and gather all the information I could first. One example is extracting all of the DNS records for the organizations domains. I can then evaluate which records are pointing to off-premises and on-premises (this can be as simple as looking at the different IP blocks and plugging them in on a site like https://ipinfo.io/). I would very quickly know which ones belong to a SaaS vendor or Cloud Service Provider, and which belong to an Internet Service Provider. From there, it’s pretty simple to start formulating an attack plan. (I would also do any research into an individuals I would target at this phase as well, if I were the type.). Bill_at_F5 Likes to use Shodan, which is also passive for the attacker, but there are tons of OSINT tools out there to use that anyone with a small bit of knowledge can run.

2. Scanning

The next thing I would do is start running some scans. I, personally, would probably try to stay as invisible and non-intrusive as possible at this stage too. Too many solutions from F5 that could fingerprint my client, so I would want to use different clients, I would want them to look as natural as possible, so I wouldn’t want to script TOO much, and if I were to run something like gotestwaf or wafw00f, I would probably do it from an endpoint that didn’t live in my house (some would say obfuscating my address).

3. Etcetera

Im not going to go through the rest of the process of what someone could or would do, but just to give you an idea. Also, I wanted to put a bunch of filler in before I got to the recipe, because that’s what all the recipe sites do and everyone loves that so much. So on to the recipe!

So Again, How to use F5 Distributed Cloud Services (XCS) to Obfuscate ingress and egress?

Ingress

For Ingress the solution is pretty simple. If you aren’t familiar with some of the core concepts of F5 Distributed Cloud, I highly recommend checking out our documentation at https://docs.cloud.f5.com/docs/ves-concepts/system-overview But to summarize, for ingress traffic you have the ability to deploy a Customer Edge (CE) Site into your on-premises datacenter that connects you securely to our private global network.

From there it’s an easy step to publish application and services using our any ip blocks across our any cast infrastructure globally, and all traffic traverses our global network. This includes things like Volumetric and L7 DDOS, GeoFencing, Bot, and WAAP protections (prebuild with our best practices in place).

Egress

Egress can be fairly simple as well, and it’s even more simple now that there are some terraform templates that can help get things up and running.

Essentially you have the ability to tell all internal traffic to use your Local Customer Edge Site as default gateway, and from there to egress from a remote Customer Edge Site location.

Configuration

So first, you need to have F5 Distributed Cloud with at least 2 Customer Edge Sites. This is an easy fix, so jump right on that! Then, we need to set up a local Customer Edge in your on-premises environment and create a Fleet.

How to Create a Fleet: https://docs.cloud.f5.com/docs/how-to/fleets-vsites/create-a-fleet

Part of creating a fleet is setting up Inside, Outside, and Global Network objects (https://docs.cloud.f5.com/docs/how-to/networking/virtual-networks). Just think of these as routing tables that you can push across multiple objects. Basically you can create the objects for your Fleet and leave them blank, no need for routes right now.

Another part of creating the fleet is a Network Connector (https://docs.cloud.f5.com/docs/how-to/networking/network-connectors ), and this is where the configs start to change up. What we want to do for this use-case is connect our Local Inside Network Directly to our Global network (essentially putting them on the same L3), to our Remote Outside Network Directly, also pointing to our Global Network.

A configuration object to be aware of, Simple Routes are not available for Azure sites via the UI, but as an API first platform, you can generally pull off a lot of magic by going direct to the hourses mouth, or however that goes, I'm not a word scientist. The provided TF builds out a functional example of everything discussed here so you have a good solid reference.

And if you arent interested in Infrastucture as Code and want to do things manually, there are some screenshots (and example JSON) below.

Network Connector for Cloud Egress Site

{
  "metadata": {
    "name": "titan-global-direct-cloud",
    "namespace": "system",
    "labels": {},
    "annotations": {},
    "description": "Global Network Connector for Cloud Site.",
    "disable": false
  },
  "spec": {
    "slo_to_global_dr": {
      "global_vn": {
        "tenant": "f5",
        "namespace": "system",
        "name": "titan-global-network"
      }
    },
    "disable_forward_proxy": {}
  }
}

Network Connector for On-Premises Site

{
  "metadata": {
    "name": "titan-global-direct-fleet",
    "namespace": "system",
    "labels": {},
    "annotations": {},
    "description": "Global Network Connector for Local Fleet.",
    "disable": false
  },
  "spec": {
    "sli_to_global_dr": {
      "global_vn": {
        "tenant": "f5",
        "namespace": "system",
        "name": "titan-global-network"
      }
    },
    "disable_forward_proxy": {}
  }
}

Routes on Outside Interface in Cloud Site

"outside_static_routes": {
        "static_route_list": [
          {
            "simple_static_route": "8.8.8.8/32"
          },
          {
            "simple_static_route": "8.8.4.4/32"
          },
          {
            "simple_static_route": "128.0.0.0/1"
          },
          {
            "simple_static_route": "0.0.0.0/1"
          }
        ]
      },
      "global_network_list": {
        "global_network_connections": [
          {
            "slo_to_global_dr": {
              "global_vn": {
                "tenant": "f5",
                "namespace": "system",
                "name": "titan-global-network"
              }
            }
          }
        ]
      }
    }