0

I have a WebAPI service deployed on Azure Service Fabric, and I want to block malicious/junk requests as early as possible - ideally not hitting my service at all (to avoid being hammered and to not use CPU cycles on processing such requests). For example, /api/foo is a valid request, and /index.php is a junk I wish not to process.

I use OWIN middlewares for configuring requests pipeline (not IIS), it is possible to filter requests there - but that's already too late.

There is the Azure Gateway which can be used to route different requests to different places, but nothing says it can be configured to drop some request paths.

What is the best practice for blocking the requests early enough?

Nightman
  • 101
  • 1
  • 7

2 Answers2

1

You could use a reverse proxy, like Azure API Management on top of your cluster. Or use Traefik or Envoy inside the cluster (running as a Service) to filter and route incoming traffic.

LoekD
  • 11,402
  • 17
  • 27
1

Azure Application Gateway is a Layer 7 Load Balancer, that has a feature to route requests by domain or URL path.

You could create the rules you want, for example: http://example.com/api/*resource* and anything else you map to an external IP that would render a static page or nothing at all.

But nothing prevents your server from receiving requests on a valid route with invalid data like http://example.com/api/*resourceThatDoesNotExist* or multiple calls on a heavy endpoint.

The application firewall it provides will protect you from most DDos attacks, but won't prevent people or bots from reaching your servers if this is your concern.

App Gateway does not provide any integration with service fabric out of the box, so it require a lot of manual configuration.

Azure API Management, has built-in integration with service fabric and provide some features that will help you add more protection to your application, it will:

  • Present facades to your APIs instead of direct access, so that you can expose the exact endpoints you want.
  • Validate JWT tokens, API keys, certificates and credentials, so that the requests only reaches your server if authenticated
  • configure quotas & limits, so that you can prevent usage abuse
  • configure access and permissions

This will add extra security, but also add cost and maintenance.

There are many alternatives, but most of them will require a bit of configuration to integrate with your service fabric applications:

NGINX, you can deploy inside your cluster or outside, configure the routing rules and protect the access from there.

You could also use other alternatives like:

Diego Mendes
  • 10,631
  • 2
  • 32
  • 36