by Brett Andrew 28/10/2024

We are constantly improving our enterprise grade attack detection and prevention and here is something you might find useful if you find the same scenario.

We found an API download of a single file was being requested hundreds of times per second, but just under DDoS levels and the IP address was rotating, if you are seeing this in your app service logs. This could be the same situation we had.

Firstly if you are using Azure Front Door and you find your App Service is being peppered by a RIPE domain with the IP range of 147.243.0.0/16 like 147.243.116.118 and you cant block it. I've included this IP range as most likely you are coming here to work out why you cant block this "hacker".....

This IP range is the Azure Front Door IP range, so don't block it. The real IP address you have to get from the Azure Front Door logs, there is actually really good reporting under the Azure Front Door already, so use it to work out the IP. You can research X-Forward-For header which Azure Front Door sends the originators IP address from. Firewalls do this too - often a similar header name, so remember that when you are looking at the App Services logs to find your potential attacker.

Once we tracked down the originating IP address, we found the originating IP address was a clients Proxy address, we were able to log onto our application for that customer and see all the users who were all sharing that address to confirm. The 2nd highest was a users ISP home domain, which helped us narrow it down to a singler person.

Here is what it was, a user was creating a PowerBI report and the logo image they were using was retrieved via API, e.g.https://www.ourdomainexample.com/api/website/downloadimage?imageguid=0989asd8f8sda9f90sd8f

What happens when PowerBI has an image with a URL? Everytime the report loads, it refreshes, you edit and make a change, this image is also refreshed. So our solution was to use the Front Door caching and add a new endpoint and tell azure front door to cache these

e.g https://www.ourdomainexample.com/api/websiteCached/downloadimage?imageguid=0989asd8f8sda9f90sd8f

To my amazement, this CDN caching actually stopped the traffic being requested at the Azure Front Door too. Between Azure Front Door CDN and PowerBI, PowerBI got the message, downloads the image once now, not 10,000 times per hour. So it was just someone creating a complex PowerBI report and every edit, adjustment in PowerBI caused a reload. This friendly fire was simply because PowerBI did not know that the image was not supposed to be cached and was doing the right thing. When a file download and it is cached, it has a header called Cache-Control which tells not only browsers, but other applications what the rules are.

The Cache-Control header is a directive in HTTP headers used to specify caching policies in both requests and responses. It tells browsers and intermediary caches how to handle the caching of web content.

Key Directives:

• no-store: Prevents caching entirely.
• no-cache: Forces validation with the server before using cached content.
• max-age: Sets the maximum time (in seconds) content can be cached.
• public or private: Indicates if the response is cacheable by any cache (public) or only by the browser (private).
• must-revalidate: Ensures content must be revalidated with the server once it becomes stale.
  

If that is not your issue, then there are a few other steps you can do to harden your App Service / Azure Instances. For example:

• Lock down servers from being accessible directly (only accessible via Azure front door)
• Install Azure Front Door WAF ( Web Application Firewall)
• Turn on Azure Front Door Logs for DEV/STAGING/PRODUCTION
• Add Sentinel (an Azure platform for monitoring and detecting threats)
• Review any large DDoS attacks (if any), review and add to WAF