Custom Rule Builder allows for the construction of custom application layer control rules to cover customer-specific situations that the KRS v1.0 rule set does not address.

Specifications are available in the API catalog.

Previously, reputation profiles could only be configured based on a certain category and a threshold. Now, enhanced criteria are available that can be combined in profiles to achieve different outcomes based on the source’s location, as well as exclude certain partners from Client Reputation scrutiny.

Custom Rule Builder allows for the construction of custom application layer control rules to cover customer-specific situations that neither the CRS v1.6.1 nor KRS v1.0 rule sets address.

You can now choose, as rate category criteria, one or more IP network lists to either match on or not match on.

This change applies to accounts participating in the proof-of-concept testing of the IPv6 rate accounting feature. Nonparticipating accounts will see no changes in Control Center’s Rate Category definition pages. IPv6 rate accounting will be released to all customers in a forthcoming Control Center release.

Previously, some IP addresses and CIDRs added to Network Lists would either cause an entire list to be ignored, or the entries in question would not properly match to request IP addresses. Now, Luna Control Center and the related Network List APIs warn you when invalid network list construction is encountered. Specifically, this occurs when an IP address has an octet with a leading zero (e.g., 192.168.1.001) and/or the CIDR mask is /0. Luna does not correct the lists for you, however. You must correct the errors yourself and then reload the list

Previously, Client Reputation considered both the connecting IP address and the XFF request header when applying whitelists. If a whitelisted IP address was added to this header, the request would then bypass Client Reputation, an undesired behavior. This has been rectified, and XFF request headers are no longer considered.

To facilitate transitioning all Kona Site Defender customers to the Kona Rule Set, only KRS v1.0 is now available to new Firewall Policies’ Application Layer Controls. In addition, cloning an existing Firewall Policy that uses CRS v1.6.1 is not permitted. You can still, however, create a new KSD configuration based on an existing one that contains a Firewall Policy using CRS v1.6.1.

Previously, in a KSD configuration, only one WAF Bypass Network List could be entered per Match Target. Since this feature is commonly used to eliminate all WAF processing on client requests and responses, it has now been expanded to allow for multiple WAF Bypass Network List entries per Match Target up to a maximum of ten.

This change applies to accounts participating in the proof-of-concept testing of the IPv6 rate accounting feature. Nonparticipating accounts will see no changes in Control Center’s Rate Category definition pages. IPv6 rate accounting will be released to all customers in a forthcoming Control Center release.

Previously, some IP addresses and CIDRs added to Network Lists would either cause an entire list to be ignored, or the entries in question would not properly match to request IP addresses. Now, Control Center and the related Network List APIs warn you when invalid network list construction is encountered. Specifically, this occurs when an IP address has an octet with a leading zero (e.g., 192.168.1.001) and/or the CIDR mask is /0. Control Center does not correct the lists for you, however. You must correct the errors yourself and then reload the list.

To simplify KSD configuration and facilitate consolidation of Rate Category definitions with those of Rate Policies, the Client Identifier menu is now on the Rate Policy setup scheme, which you can access from the Security Configuration parameters page.

The account-level configuration is blank.

The start-date-to-end-date report length is restricted to a 30-day window within the 90-day period.

Previously, only one level of domain was allowed (e.g., .example.com). Now, multiple levels are allowed (e.g., .example.example.com, *a.b.c.d.e.com).