ACLs Applied to a CPU Defend Policy
About CPU Defend Policy
CPU defend policy limit the rate of the traffic sent to the local CPU, to prevent attack packets and reduce the invalid packets takes, release the burden of CPU.
The summary of deployment for CPU defend policy is, divide the CPU packets into two parts, one part is trusted and the other part is untrusted. Protect the trusted packets (set the larger bandwidth for them) and limit the rate of the untrusted packets (set smaller bandwidth for them).
CPU defend policy uses four modules to insulate or control the trusted traffic and the untrusted packets.
| Module | Function |
|---|---|
| TCP/IP attack defense | Directly discards the TCP/IP attack packet. TCP/IP attack defense function is enabled by default.
TCP/IP attack defense supports discarding the following four kinds of attack packets.
|
| Whitelist | Protects the trusted packets. The bandwidth for the packets added to whitelist is assurable. The attack does not impact the service in whitelist.
The following protocols are auto added to the whitelist by default when TCP session established: BGP, LDP, MSDP, FTP-server, SSH-server, Telnet-server, FTP-client, Telnet-client, and SSH-client.
Whitelist is enabled by default. Modifying the default parameters in the whitelist is not recommended. To extend the application, you can use user-defined flows. |
| Blacklist | Limits the rate of untrusted packets. The blacklist is enabled by default, but there is no packets added to blacklist by default. You can add the invalid or unknown packets to the blacklist so that the system can minimize the bandwidth for them or directly drop them. |
| User-defined Flow | Protects the trusted packets. User-defined flows allow users to flexibly customize the attack defense policy to protect the CPU against different types of attack packets.
With user-defined flows, you can specify the flows to be protected and control the parameters, such as the bandwidth, priority, and packet length for the flows. In addition, you can send each user-defined flow to a specific channel for granular isolation and precise control. |
The whitelist, blacklist, and user-defined flow use ACL to define the characters of the flow.
Each CPU defend policy can be configured with one whitelist, one blacklist, and one or more user-defined flows, as shown in the following figure.
cpu-defend policy 4 whitelist acl 2001 blacklist acl 2002 user-defined-flow 1 acl 2003 user-defined-flow 2 acl 2003 user-defined-flow 3 acl 2004 # cpu-defend policy 5 whitelist acl 2005
Procedure of a CPU Defend Policy
- Performs the URPF, TCP/IP attack defense, and GTSM check. Continues to do the next step for the packets that pass the checks. The packets not pass the checks are discarded.
- Matches against the whitelist. Performs CAR and go to step 5 for the packet those match the permit rule. Discards the packets those match the deny rule. Continues to do the next step for the mismatched packet.
- Matches against the blacklist. Performs CAR and go to step 5 for the packet those match the permit rule. Discards the packets those match the deny rule. Continues to do the next step for the mismatched packet.
- Matches against the user-defined flow. Performs CAR and go to step 5 for the packet those match the permit rule. Discards the packets those match the deny rule. Continues to do the next step for the mismatched packet.
- Checks all packets based on application layer association. Sends only the packets belong to enabled protocols. The packets belong to disabled protocols are discarded.
In the steps 2, 3 and 4, the "mismatched" includes:
- The packets mismatch all rules of the ACL.
- The ACL does not exist.
- The ACL exists but no rule in the ACL.
Directly drops the management packets received from the non-management interfaces.