To improve your protection against brute force attacks you can specify Login- and IP-based access rules so that every login attempt is additionally validated against them.
You can add those rules in two places: on the Logs tab of the LLAR plugin page installed on your WordPress site and/or in your billing account at the following address https://my.limitloginattempts.com/acl
If you do that from your plugin, the rules will be applied only to your website. If you do that in your LLAR account, the rules will work for all websites under your account. If you do that in both places, they will work together, but the local rules will take precedence over the global rules, except for the Pass rule (see below).
Rule Types
There are currently 3 types of rules:
- deny – all attempts matching this rule will always be denied unless there is an allow rule that overrides it.
- allow – all attempts matching this rule will be allowed to try to log in. This is the default behavior for any attempt – users can try to log in, but the attempt will be checked using our cloud’s security intelligence algorithms (in addition to your own access rules). Use the allow rule when you need to make an exclusion from the deny rule (see examples below).
- pass – all attempts matching this rule will go through w/o any verification and penalty. This is the default behavior as though the LLAR plugin is not installed, so use this at your own risk! We don’t recommend using this rule. Also, note that the pass rule is the most powerful rule and it overrides any other rule. For example, if you denied an IP locally within the site’s settings, but added the same IP in your LLAR account with the pass rule, the pass rule will still take priority.
Login Access Rules Examples
| Pattern: admin Rule: deny Result: All attempts from the “admin” username will be denied. |
You can use “*” and “?” in your login (not IP) patterns. “*” replaces any number of characters, “?” replaces just one character.
| Pattern 1: * Rule 1: deny Pattern 2: admin Rule 2: allow Result: Attempts from any username other than “admin” will be denied. |
| Pattern: admin Rule: pass Result: All attempts from the “admin” username will be allowed w/o any limit. Don’t do that unless you 100% sure that’s what you want. |
IP Access Rules Examples
| Pattern: 10.0.0.0 Rule: deny Result: All attempts from the 10.0.0.0 IP will be denied. |
You can use CIDR notation.
| Pattern: 10.0.0.0/32 Rule: deny Result: All attempts from the 10.0.0.0-10.0.0.255 IP range will be denied. |
Human-friendly ranges are supported too.
| Pattern: 10.0.0.0-10.0.0.255 Rule: deny Result: All attempts from the 10.0.0.0-10.0.0.255 IP range will be denied. |
| Pattern 1: 10.0.0.0/32 Rule 1: deny Pattern 2: 10.0.0.10 Rule 2: allow Result: All attempts from the 10.0.0.0-10.0.0.255 IP range excluding 10.0.0.10 will be denied. |
IPv6 are supported too – using both individual and CIDR notations.
