Quickly block an attacker

Sometimes situations will arise where an attacker needs to be blocked temporarily, while the security posture is being reconfigured. Since the hostile traffic is not being filtered, admins recognize that their security posture needs to be strengthened, but they need some time to analyze the situation. Meanwhile, the attacker should be blocked.

It might seem that admins should merely add the system tag for the attacker's IP (e.g., ip:82-64-131-193) to the Enforce Deny column in the applicable ACL Profile. This can work (as long as the attacker is consistently using the same IP), but it's not necessarily the best approach.

Using a Global Filter

The better approach is usually to create a Global Filter, based upon criteria that will match the attacker (but will not match any other traffic source), with an Action to block the matching requests.

Here's why this is usually the optimal choice:

While both approaches can be done when the attacker is using a single IP (or a set of IPs), the second one also supports situations where the attacker is rotating IPs, and therefore needs to be identified with a combination of characteristics.
The ACL Profile will limit the blocking to specific paths/URLs (those defined in the Security Policies associated with it, and used within one or more Server Groups). The Global Filter will block the attacker's activity globally, which is usually more desirable.
The Global Filter is more efficient during processing, because the hostile requests are blocked earlier in the traffic filtering process.
The ACL Profile approach can result in the long-term accumulation of "special cases" within the Profiles, if admins are not diligent about cleaning them up when they're no longer needed. This situation is not ideal, because it can be messy and difficult to manage. The Global Filter approach makes it easier to also consists in creating special cases, but they are more visible and thus, easier to find and purge when no longer necessary.

Consider a dedicated Global Filter for long-term management

Instead of creating and discarding one-off Global Filters, it's often better to maintain a dedicated Global Filter for manually blocking attackers. As traffic sources need to be blocked (or unblocked), admins can just add (or remove) matching criteria.

This creates a single location for administering these special cases. Admins can easily monitor the current list of manual interventions, and purge them as they become obsolete.

PreviousProtect sensitive information in logs and analytics NextRedirect or block HTTP traffic

Last updated 2 months ago

Was this helpful?

Using a Global Filter

Here's why this is usually the optimal choice:

While both approaches can be done when the attacker is using a single IP (or a set of IPs), the second one also supports situations where the attacker is rotating IPs, and therefore needs to be identified with a combination of characteristics.

The ACL Profile will limit the blocking to specific paths/URLs (those defined in the Security Policies associated with it, and used within one or more Server Groups). The Global Filter will block the attacker's activity globally, which is usually more desirable.

The Global Filter is more efficient during processing, because the hostile requests are blocked earlier in the traffic filtering process.

The ACL Profile approach can result in the long-term accumulation of "special cases" within the Profiles, if admins are not diligent about cleaning them up when they're no longer needed. This situation is not ideal, because it can be messy and difficult to manage. The Global Filter approach makes it easier to also consists in creating special cases, but they are more visible and thus, easier to find and purge when no longer necessary.

Consider a dedicated Global Filter for long-term management

This creates a single location for administering these special cases. Admins can easily monitor the current list of manual interventions, and purge them as they become obsolete.