Fastly's next-gen WAF (formerly Signal Sciences) integrates with Kong Konnect to block malicious requests to your services. Kong Gateway provides a robust and secure enterprise API management platform to front web traffic. In partnership, Fastly focuses on Layer 7 application security for that traffic. This article will explain how Kong Konnect and Fastly work together.

The above diagram shows a high-level view of the Fastly Cloud Engine architecture. On the left, you would have a Kong Gateway connected to the Fastly plugin. Once connected, Fastly runs an agent as a sidecar container. Whenever Kong Gateway gets an incoming request, the Fastly plugin will immediately get invoked and pass that request over to that agent.

In 1-3 milliseconds, the agent will inspect the request locally. During that time, if the agent sees a request that contains some sort of attack, such as an SQL injection, it’s going to sanitize it by redacting any sensitive fields. By default, the agent redacts usernames, passwords, credit card numbers, etc. Asynchronously, the agent pushes the metadata of that request to the cloud agent to aggregate that attack data across all the different agents in your environment.

In addition to that, Fastly pulls in feeds of information (middle of the diagram above).

• External Sources include anything from data center IPs, known malicious IPs and Tor nodes.
• Customer Sources will be specific to the customer, including IPs or countries you may want to block.
• Fastly NLX (Network Learning Exchange) is the threat intelligence feed.

All this information is made available through the Fastly management console on the right side of the above diagram. In the UI, you can see all this data, edit rules and modify lists. Or you can also do all of this through the Fastly API.

Before I dive into some use cases, look at the above diagram, which shows my demo environment's topology. I have installed Kong Konnect and the Fastly Cloud Engine at the admin layer, where admins can define policies. My Kong data plane is going to receive requests from our external consumers.

Konnect will be responsible for some policies related to the API gateway layer. The Fastly agent will be responsible for some other policies, therefore connecting to the cloud engine to ensure that the request is good to be routed upstream.

The steps from a high level go like this:

1. Kong Gateway and Fastly create policies.
2. The control plane publishes policies to the data plane.
3. A consumer sends requests to the data plane.
4. The data plane applies the Kong Gateway policies.
5. The Fastly agent enforces the specific policies defined in the Fastly Cloud Engine.

If both policies are OK, Kong Gateway will pass along the request of the upstream microservices.

Now that I've explained how Kong Konnect and Fastly work together to protect your APIs and services, let's go into a few practical use cases.

Kong Konnect and Fastly Use Case #1: Malicious SQL Injection

In my example, I have multiple routes already defined. I use these routes to expose some paths to my external customers. Consumers will use this path to send requests to the API gateway.

I've already set up the Fastly plugin and applied it globally. That means Kong Gateway and Fastly will confirm all requests are good to route upstream.

To start sending requests to Kong Gateway, you can use Insomnia, our API spec editor.

To set up a simple use case, you could try the API key policy. To consume a route, you'll have to inject an API key inside the request. Once you send a request, you should get a 200. If you don't inject the API key first, you should receive a 401, meaning the API gateway won't allow you to consume the upstream.

What if your query push on the request received a malicious SQL injection request to the API gateway? Somehow you must identify the type of threat and prevent these requests from being consumed by your API gateway and services. If you have the Fastly plugin, it should take care of this and give you a 406, meaning Fastly recognizes that the request is malicious and will not allow your gateway or applications to consume it.

In the Fastly Next-Gen WAF management console, you should see a site rule defined to prevent this exact SQL injection threat. More than that, you should see reports of the other threats that Fastly have identified.

Kong Konnect and Fastly Use Case #2: FinTech Account Enumeration

In the following example, I have a module running in Kong Konnect and an agent plugged in. I also have an app that might handle transferring of funds or payments.

In Fastly, you can set up rules around those APIs to look for a spike in fund transfers. For example, in eCommerce, you may have a credit card validation endpoint. An attacker can enumerate through different credit card numbers, trying to validate them against your API. Fastly stops those types of attacks.

To demonstrate this, I have a FinTech workspace. In this app, I can view my account summary, transfer funds, login, etc.

Under site rules, I set up various use cases with the rules builder. Here you can specify conditions based on the HTTP request, including the IP address, method, POST or GET, etc. You can use all these different parameters to define a custom rule and choose to block, allow, get visibility or rate limit actions.

In my FinTech example, this endpoint shows me my account summary, and it’s a GET request to this endpoint. There’s a query parameter involved. And we’re checking the response codes to see if it’s a 200 or 500. I'm rate limiting this activity after six queries in one minute.

Suppose somebody is enumerating through different account numbers at a velocity greater than six in a minute. In that case, the system will block that activity and that IP from viewing any account information.

To test this, I'll try transferring $300 within my purposely vulnerable demo application. I can change this account number in the URL and see other users' accounts that aren't necessarily mine. I can enumerate through different accounts and get back the information that I really shouldn’t be getting.

Fastly protects against this type of attack. After the third request, you should stop getting 200 responses and start getting 406 responses, meaning Fastly started to block after reaching that threshold.

In the Fastly console, you should see those account summaries and the requests that Fastly stopped. You could dive deeper and see the request, user agent and IP that it came from and complete metadata.

Kong Konnect and Fastly Use Case #3: FinTech Account Takeover

My final example takes a look at account takeover. Here I ran the same script as I did in use case #2 with one exception. This time I can run it for the login failure use case. That means making many login attempts with an incorrect username and password.

Eventually, this should trip a threshold and start getting blocked. Initially, you would get back 200s, but after the tenth request, you should start getting back a 406. That means the system failed to log in too many times and had too high a request velocity. If I try to log in to the application now, I get blocked.

In each of these use cases, we were able to customize Fastly rules and define them based on the application and the business logic.

Request a demo to learn more about the Fastly plugin for Kong Konnect.