* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com

* Podcasts
* Social Channels
* Video Streaming

 

 

 

 

 

ABOUT DEVCENTRAL

DevCentral News Technical Forum Technical Articles Technical CrowdSRC Community Guidelines DevCentral EULA Get a Developer Lab License Become a DevCentral MVP

RESOURCES

Product Documentation White Papers Glossary Customer Stories Webinars Free Online Courses F5 Certification LearnF5 Training

SUPPORT

Manage Subscriptions Professional Services Professional Services Create a Service Request Software Downloads Support Portal

PARTNERS

Find a Reseller Partner Technology Alliances Become an F5 Partner Login to Partner Central

---

©2024 F5, Inc. All rights reserved.

Dear Dev Central,

We have an externalized \"API service\" LTM VS that we use for various external service providers to send us call back receipts (Email, Fax, SMS etc). We want to restrict who can use this externalized VS to avoid DDoS attempts, but we are not able to do so via IP address as these external service providers change their IP addresses regularly. I was thinking that maybe we could restrict it down using an iRule that inspects the URI path for certain expressions as the external SP's send to us using a set number of URI paths that only we know about. The VS uses port 443 so the communications are encrypted. My question is this: If we develop an iRule that drops all traffic that doesn't contain certain expressions in the URI Path, are there any other ways an attacker could circumvent this and still hammer the VS? Or will the iRule drop any and all attempts that dont match the URI Path conditionals? Are there better ways to restrict this traffic other than an iRule? We have ASM installed on our LTM device.

I hope this makes sense. Thanks.

Dear Dev Central,

We have an externalized \"API service\" LTM VS that we use for various external service providers to send us call back receipts (Email, Fax, SMS etc). We want to restrict who can use this externalized VS to avoid DDoS attempts, but we are not able to do so via IP address as these external service providers change their IP addresses regularly. I was thinking that maybe we could restrict it down using an iRule that inspects the URI path for certain expressions as the external SP's send to us using a set number of URI paths that only we know about. The VS uses port 443 so the communications are encrypted. My question is this: If we develop an iRule that drops all traffic that doesn't contain certain expressions in the URI Path, are there any other ways an attacker could circumvent this and still hammer the VS? Or will the iRule drop any and all attempts that dont match the URI Path conditionals? Are there better ways to restrict this traffic other than an iRule? We have ASM installed on our LTM device.

I hope this makes sense. Thanks.

The F5 Certification is excited to announce that all five of the NEW F5 Certified BIG-IP Administrator Certification (F5 CAB) exams are now live and available to schedule via the new Education Services Portal.

What part of the environment are you trying to protect? DDoS protection is more complicated than blocking certain clients/requests. For example, is it that the backend servers can't handle the load, or the ISP is the limiting factor, or the SSL TPS of the BIG-IP? LTM/AFM can do the L3/L4 blocking, ASM can do L7. Silverline can do the cloud scrubbing.

ASM can parse the JSON by creating a content profile and you can then act on the key/values of the JSON, limit metacharacters, scrub data for logs, etc. And it can also rate limit at the L7 level to block certain types of attacks. An iRule can also do L7 stuff like you mentioned, dropping/resetting/responding with custom responses based on URI's, headers, POST data, etc.

Dave,

The business is concerned about the back end Databases being hammered with spoofed API calls. They only want approved sources to be able to make these calls to the API Virtual Server. We initially thought to approach this by trying to restrict the calls using source IP address, but the external service providers (Mailgun, Twilio, etc) were not able to provide those and they advised against it anyway. So I started looking at maybe using static strings in the URI path that the service providers use to make calls to us and sapplying an iRule to the VS that will drop any inbound requests that dont specifically contain the defined URI path expressions. I am just not sure if this is the best approach, or if there were any way a potential attacker could circumvent this control. Obviously if they knew the string they could plug that in and launch an attack but the only ones who know the string are us and the SP. Its kind of like a password in that way.

Thanks.

Yeah, I'd say in that case it seems like a pretty solid approach.

You have a few options, you could use an LTM policy or an iRule. If an iRule, create a datagroup with all the entries in it. You'll be happy when you have to add more in the future. LTM would be able to handle lots of requests vs ASM, but I don't think it sounds like F5 performance will be limiting you here.

The other option would be to use ASM. Many would argue it's overkill for this, but there's some other benefits. You could add all the URL endpoints with a wildcard, like /api/v1/stringa/* /api/v1/stringb/* and then block all the other endpoints. I assumed it's a REST API, but if it's XML/SOAP based, you can also parse it. Obviously bot defense isn't going to help much since your clients are automated. The thing I like about the ASM approach is that another engineer looking at it would see lists of URLs in the GUI vs a scary programming language and datagroups. You'd also get a better interface for seeing the blocks and better built-in logging.

BIG-IP has a lot of tools for the job, so it's really what fits your environment.

Dave,

Thank you so much for your feedback. I'm happy to know were on the right track here. I will look at the ASM option as it sounds like it would be easier to track the blocks as you suggested.

Thanks again for your time and rapid responses.

Authentication? That'd be my first thought... Via client certs perhaps?

Even a shared secret key in a custom header would do it (Then just close the connection if the header is not in the request).