Lesson 13: Bot Defense and Application DoS — An Advanced WAF Introduction

F5 ASM CLASSROOM • LESSON 13

Level: Advanced  |  Suggested study and lab time: 60 minutes
Instructor: Harpreet Singh Virdi, CISSP, CCSP

Start Here / Course Guide · All lessons

---

Why ordinary request inspection is not enough

A request can be well formed and still contribute to abuse. Automated clients can scrape valuable information, repeatedly attempt logins, or consume expensive application resources. A WAF signature alone does not tell you whether the request rate or client behavior is acceptable.

This is an introduction to capabilities that may require Advanced WAF or other licensed functionality. Confirm your exact entitlement and release. Do not assume that every ASM deployment includes every bot or behavioral DoS feature.

Three different questions

• Content: does the request violate the application's security rules?
• Automation: what evidence suggests this is a browser, an approved integration, or unwanted automation?
• Availability: is traffic degrading the service or exhausting resources?

A bot is simply an automated client. Search indexing, uptime checks, and business integrations may be legitimate. “Block all bots” is rarely a complete requirement. An application DoS incident can involve valid requests that repeatedly hit an expensive endpoint.

Understand challenges

Some controls use browser challenges or JavaScript behavior. An API client may not execute JavaScript, and an accessibility tool or unusual browser may need special consideration. Choose controls that fit the client population. A successful challenge is one signal, not an authorization decision.

Guided observation lab

1. Inventory your synthetic clients: interactive browser, approved API script, health monitor, and a bounded test automation client.
2. Record a low-volume baseline: request rates, response times, error rates, and backend resource use.
3. Review the supported bot/DoS profiles and attach only the intended observation configuration to your lab virtual server.
4. Generate small, controlled traffic changes within a pre-agreed ceiling. Do not flood the network or run an uncontrolled stress tool.
5. Compare client classification, WAF events, latency, and application metrics.
6. If you test mitigation, do so in the lab with a rollback ready and verify the approved API client still works.

Expected result: you can distinguish a classification event from demonstrated service degradation. A small lab may not trigger adaptive or behavioral thresholds; no detection under light traffic is not proof that a feature is broken.

Choose metrics that explain impact

Track requests per second alongside endpoint cost, latency, failures, and server health. Ten expensive searches can matter more than hundreds of cached images. Baselines must include normal peaks and unusual legitimate events such as a book launch or batch integration.

Common mistake

Do not publish one universal threshold for all applications. A mitigation that helps one service may reject normal activity on another. Define detection, response, exceptions, and recovery together, and ensure the operations team can recognize when the response is harming users.

Knowledge check

Why might a browser challenge break a legitimate integration?

Instructor answer

The integration may not support the browser behaviors required by that challenge. Identify the client type and apply a supported protection strategy suited to its trust boundary and capabilities.

---

Further reading

• F5 documentation: preventing dos attacks on applications
• F5 documentation: big ip asm implementations

Independent educational material. Menus, defaults, and feature availability vary by BIG-IP release and license. Use the documentation for your installed version. Perform exercises only in your authorized lab. Examples and expected results are instructional; these labs have not been executed on a BIG-IP device for this blog.

← Previous lesson · Course guide · Next lesson →