Clients still blocking due to http response code 407, with Attack Detection

Products

• ISG Proxy

Issue/Introduction

Customer’s Current CPL:

<Exception>

exception.id=policy_denied attack_detection.failure_weight(0)

exception.id=authentication_failed attack_detection.failure_weight(0)

 

<proxy>

http.response.code=403 attack_detection.failure_weight(0)

 

x.x.x.x - Blue Coat SG-VA Series#show attack-detection client blocked

 

IPv4 clients have been blocked Unblock time

x.x.x.x 2025-09-15 09:01:49+00:00UTC

Environment

ISG-Proxy

Cause

The CPL only excludes 403, policy_denied, and authentication_failed. It does not exclude 407. So repeated 407s are still counted toward the client’s failure counter and can trigger blocking. That’s why you see the client at x.x.x.x in the blocked list.

Resolution

What to change

Add explicit exclusions for 407 (and - if it fits your environment - 401 as well, since origin-server auth loops can create noise too):

<Exception>
exception.id=policy_denied attack_detection.failure_weight(0)
exception.id=authentication_failed attack_detection.failure_weight(0)

<proxy>
http.response.code=403 attack_detection.failure_weight(0)
http.response.code=407 attack_detection.failure_weight(0)
http.response.code=401 attack_detection.failure_weight(0)

CPL Explained

1. Exception scope

    

   exception.id=policy_denied attack_detection.failure_weight(0)

   • Any request that hits a policy_denied exception (for example, blocked by policy) will not contribute to the failure counter.

    

   exception.id=authentication_failed attack_detection.failure_weight(0)

   • Authentication failures raised as exceptions (e.g., proxy authentication not completed) also won’t add to the failure count.

2. Proxy response scope

    

   http.response.code=403 attack_detection.failure_weight(0)

   • Normal Forbidden responses will be ignored by Attack Detection.

    

   http.response.code=407 attack_detection.failure_weight(0)

   • Proxy Authentication Required responses (407) will no longer count as failures. This is the critical one that solves your issue, since repeated 407s were driving clients into block state.

    

   http.response.code=401 attack_detection.failure_weight(0)

   • Unauthorized responses (401) from origin servers will also be ignored. This is optional, but useful if you have web applications that generate many 401 challenges as part of normal login workflows.

How this works in practice

• Attack Detection normally increments a failure counter for each client when it sees events like auth loops, resets, SSL errors, etc.

• Once the counter reaches the Client Failure Limit (150 in your config), the client is blocked for the defined unblock time (2 minutes).

• By assigning failure_weight(0), these specific response codes or exception events are excluded from the calculation.

• That means:

  • Clients that loop on 407s won’t get blocked.

  • Clients that hit lots of 403s won’t get blocked.

  • Clients that fail authentication (401s, Proxy auth failures) won’t get blocked.

• Other failures (DNS lookup failures, TCP resets, SSL handshake errors, etc.) will still count toward the counter.

Additional Information

The tradeoff

• Benefit: avoids false positives (normal policy blocks, normal 401/407 workflows won’t trigger Attack Detection).

• Risk: a true attack that generates only these response types (e.g., brute-force auth flood causing many 401/407s) will not be mitigated by client blocking.

That’s why Broadcom documentation recommends tuning carefully: set failure_weight(0) if a failure type is pure noise in your environment, or leave it at the default failure_weight(1) (or increase above 1) if you want those events to count toward blocking.

What this means in practice

• failure_weight(0) → event is ignored, does not increment the client’s failure counter.

• failure_weight(1) (default) → each occurrence increments the counter by one.

• failure_weight(n) where n > 1 → each occurrence increments the counter by n. This can be used if you want a certain failure type (for example, authentication_failed) to accelerate blocking faster than others.

Attack Detection – Failure Weight Tuning

Failure Type Example	failure_weight Value	Effect on Attack Detection
policy_denied	0	Ignored – does not increment failure counter
authentication_failed	0	Ignored – no client blocking for repeated failures
http.response.code=403	0	Ignored – avoids false positives on policy blocks
http.response.code=407	0	Ignored – prevents auth loops from blocking clients
Any failure type	1 (default)	Each event increments the failure counter by 1
Any failure type	>1	Each event increments the failure counter by that value (accelerates blocking)

 

There is no support for fractional values to “partially count” events - it’s strictly whole numbers.

Steps to Test the Attack Detection Fix

1. Apply Updated CPL

• Install the new CPL with:

• Verify the policy compiles successfully and is active.

2. Reset Any Current Blocks

• Either wait for the unblock timer to expire (2 minutes in your config), or manually unblock the client using CLI:

  enable

  configure terminal

  attack-detection

  client

  unblock <client-ip>

  Example:

  EdgeSWG#(config client) unblock x.x.x.x

3. Generate Test Failures

From a test client machine:

• Access a URL that you know triggers a 403 policy denied.

• Perform an action that generates 407 Proxy Authentication Required responses (e.g., wrong credentials or auth loop).

• Trigger a site/application that generates 401 Unauthorized responses.

4. Monitor Attack Detection

On the appliance, check the blocked list:

show attack-detection client blocked

• Confirm that your test client IP does not appear in the list, even after multiple 403/407/401 responses.

5. Validate in Logs

• Review access logs for the test client:

  • You should see the 403/407/401 entries logged.

  • But the client is not blocked by Attack Detection.

• This proves the CPL exclusions are working (events are logged but ignored for failure counting).