> For the complete documentation index, see [llms.txt](https://docs.link11.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.link11.com/product-guides/network-ddos-v3/interface/access-control.md).

# Access Control

The Access Control page allows administrators to define rules that override the standard detection and mitigation logic for specific traffic sources. Rules are self-service and take effect immediately.

## Rule Types

| Rule Type     | Behaviour                                                                                                                                                                                                              | When to Use                                                                                                            |
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Whitelist** | Traffic matching this rule bypasses all detection and blocking.                                                                                                                                                        | Known-good sources that must never be interfered with — monitoring services, trusted partners, internal probing tools. |
| **Greylist**  | Traffic from this source is excluded from all signal tracking and cannot trigger mitigation. May still be blocked if other traffic activates mitigation and the packets match its criteria. See below for full detail. | Sources that generate anomalous-looking traffic known to be legitimate — load testing tools, high-rate automation.     |
| **Blacklist** | Traffic matching this rule is always denied, regardless of the current system state.                                                                                                                                   | Known-malicious sources that should always be blocked.                                                                 |

#### How Greylisting Works

Traffic from a greylisted IP is excluded from all signal tracking. It does not contribute to any signals, and therefore cannot contribute to the high quality signals that trigger mitigation. In effect, the system does not characterise traffic from greylisted sources as anomalous or malicious — it is invisible to the detection engine.

However, greylisting does not guarantee that traffic will always pass. If other traffic — from non-greylisted sources — moves the system into an active mitigation, greylisted IPs may still be blocked if their packets match the criteria of that mitigation (packet hashes, source ports, protocols, TCP state checks, and similar). The greylist affects detection, not mitigation enforcement.

Use a Whitelist rule if a source must be guaranteed to never be blocked under any circumstances.

## Common Use Cases

**Greylist: Hyperscaler patch cycles**

A common scenario is Windows or software patch cycles delivered via hyperscaler infrastructure such as Microsoft Azure or AWS. During a patch window, a large number of your servers may simultaneously pull updates from a broad and unpredictable set of IP ranges belonging to the hyperscaler. This produces exactly the kind of traffic pattern that looks like an attack — a spike in unique sources, high connection rates, concentrated destination IPs — but is entirely legitimate.

Whitelisting the entire hyperscaler IP space is not practical or desirable. Instead, greylisting the relevant hyperscaler CIDR ranges against the specific destination IPs being patched prevents that traffic from contributing to signals or triggering mitigation, while leaving detection active for all other sources. Once the patch window closes, the rules can be deactivated or removed.

**Greylist: Load testing and performance benchmarking**

Load testing tools running from cloud infrastructure or a test harness generate high-volume traffic to specific protected IPs. This will rapidly produce signals and could trigger mitigation against the test source. Greylisting the test tool's IP range against the target protected IPs allows the test to run without interference.

**Whitelist: Monitoring and synthetic probing**

External monitoring services that probe protected IPs at regular intervals from fixed, known IP addresses should be whitelisted. These sources need a guarantee that they will always reach the destination — even during an active attack — so that monitoring alerts accurately reflect real availability rather than mitigation side-effects.

**Blacklist: Known malicious infrastructure**

IP ranges associated with known attack infrastructure, bulletproof hosting providers, or sources that have repeatedly targeted your network can be permanently blacklisted to ensure they are always denied, regardless of current traffic conditions.

## Rule Table

Rules are displayed across four tabs: **All**, **Whitelist**, **Greylist**, and **Blacklist**. The table columns are:

| Column         | Description                                                               |
| -------------- | ------------------------------------------------------------------------- |
| Rule Type      | Whitelist, Greylist, or Blacklist.                                        |
| Source IP      | The source IP address or CIDR range the rule applies to.                  |
| Destination IP | The destination (protected) IP address or CIDR range the rule applies to. |
| Comment        | An optional free-text note describing the purpose of the rule.            |
| Date Added     | When the rule was created.                                                |
| Status         | Whether the rule is currently **Active** or **Inactive**.                 |

## Adding a Rule

Click **Add new Rule** to open the creation form. Each rule requires a rule type, a source IP or CIDR range, and a destination IP or CIDR range. Multiple source/destination pairs can be added to create a set of rules in one operation. An optional comment can be added to describe the purpose of the rule. Set the rule to Active or Inactive at creation. Rules can be toggled or deleted inline from the table.

{% hint style="info" %}
Rules take effect immediately when created or toggled — there is no approval workflow.

Whitelist rules complement the system's automatic baseline-based source protection. The system already learns top legitimate sources automatically, but an explicit Whitelist rule provides an additional guarantee for critical sources.
{% endhint %}