Connlimit as an option for ip access-lists

This feature is introduced in SLX lately for hardening the security of management plane.

Starting from 20.3.2 release, management ACL configurations provides connlimit as an option to restrict the number of connections from a given host, using a specific protocol or application port.

For example- the below configuration when applied to the management port restricts the number of tcp connections to the SLX mgmt. IP from the given client IP to N, where N can range between 1-65536.

SLX(config)#ip access-list extended check

SLX(conf-ipacl-ext)# permit tcp host <client IP> host <SLX mgmtIP> connlimit <N>

The protocol option tcp in the above example is specified as udp, which restricts udp connections or can be specified as even ip that restricts both udp and tcp connections to given number N.

Instead of specific client IP there is an option to provide any as an argument that filter connections on specified protocol from any IP address to the given value N for the connection limits.

SLX(conf-ipacl-ext)# permit ip any any connlimit N

SLX(conf-ipacl-ext)# permit tcp any any connlimit N

When we specify application ports to the access-list with conn limit option, you can apply these restriction to specific application protocols alone and allow rest of the traffic. The below example restricts number of SSH connections, which uses port 22 from the specified client IP.

SLX(conf-ipacl-ext)# permit tcp host <client IP> host <SLX mgmtIP> eq 22 connlimit N.

Restricting connlimits to application protocols can be a highly useful service in mitigating DDOS attacks, by preventing access from malicious clients.

For example - the HTTP/HTTPs service in SLX has a restriction of allowing maximum of 30 parallel REST connections to SLX.

A DDOS attack scenario is observed in field, when a buggy client, which do not close its sockets but monitor SLX heart beat that sends periodic unauthorized REST requests to SLX at a rapid rate, such that it exhausted the 30 connections in quick time and denied the other operational REST client access to SLX for sometime, until the socket state transitions cleaned up the orphaned connections.

The connlimit can be applied in the below manner to prevent such a DDOS attack from a malicious client by specifying the connlimit like below, if it is known that the operational REST client would have maximum of say 10 parallel REST connections to SLX.

In the below example client IP 1 is the operational client and client IP 2 is the heartbeat monitor. It also prevents a malicious client IP 3 from exhausting the REST connections in similar way and causing denial of service.

SLX(conf-ipacl-ext)# permit tcp host <client IP 1> host <SLX mgmtIP> eq https connlimit 10

SLX(conf-ipacl-ext)# permit tcp host <client IP 2> host <SLX mgmtIP> eq https connlimit 10

To use the connlimit options with an access-list it may be required that the administrator first configures a permit ip rule with any any option to allow other traffic without disruption. This is because of the order of IP table rules that are added by default in SLX.

In order to understand the IP tables order and how to use connlimit correctly and the limitations, please refer to 20.3.2 security guide ACL section.

It is also suggested that administrators do not use connlimit with generic protocols like tcp, udp and ip with any any option, unless they are very familiar with management connections to the SLX on field to prevent possible disruption of traffic that is not intended to be restricted.