Where it is

In the WordPress side menu open Settings > Cisilino Site Defense Network (point 1 in the image). Then choose the General tab (point 2). Further down you’ll find three sections:

• point 3: “Recent activity log”.
• point 4: “Local IP overrides”.
• point 5: “Trusted IPs (whitelist)”.

After every action you’re always taken back to the General tab, even if you started from the “Blocked IPs” tab. The confirmation message appears there.

What it’s for

Overrides let you force the blocking or unblocking of a single address. This works regardless of the failed-attempts threshold and the list received from the panel. They apply only to this site: they are never sent to the panel.

The whitelist serves a different purpose. It lists the addresses that must never be counted as failed login attempts, for example your office network.

How to use it

Reading the log (point 3)

The “Recent activity log” section shows the “Last 50 failed login attempts detected on this site.” The columns are IP, Username tried, Attempts, Status and Last seen. The status is “Blocked” or “Watched”. There is one row for each IP, with a cumulative counter. The username shown is the last one that was tried. If there’s nothing you’ll read “No events recorded.” Don’t confuse this list with the “Activity log” tab: that’s a separate topic.

Blocking or unblocking an IP (point 4)

This is the part you need in order to block IP WordPress by hand.

1. In the “IP address” field write a single address, for example 203.0.113.5.
2. Under “Action” choose “Block (ban)” or “Always unblock (unban)”.
3. Under “Duration” choose “Permanent (until you remove it)”, “1 hour”, “6 hours”, “24 hours” or “7 days”.
4. Press “Save override”. If the IP is valid you’ll read “Override saved and .htaccess updated.” The message appears even if .htaccess isn’t writable: it doesn’t prove the block is active.

Below the form is the table of active overrides, with the columns IP, Action, Expiry and Created on. Each row has a “Remove” button. Removing an override shows a confirmation that .htaccess was updated. If the table is empty you’ll find “No active overrides.”

Using the whitelist (point 5)

1. In the box write one address or network per line, for example 203.0.113.5 or 203.0.113.0/24.
2. Press “Save whitelist”. You’ll read “Whitelist saved.”

If your IP isn’t in the list, a warning tells you so. The “Add to whitelist” button inserts only that entry and leaves the others untouched.

Default values and limits

• The default action is “Block (ban)”, and the default duration is “Permanent (until you remove it)”.
• The “IP address” field accepts only a single IPv4 or IPv6 address. A CIDR such as 203.0.113.0/24 is rejected with “Invalid IP.”
• Each IP can have only one override. If you save a second one for the same address, it replaces the first.
• The whitelist accepts single IPs and IPv4 CIDR networks with a prefix from 0 to 32. Watch out: 0.0.0.0/0 is accepted and covers every IPv4 address, so it switches off failed-login counting for everyone. For IPv6 only the exact address is valid.
• Invalid rows in the whitelist are discarded, and the message tells you how many, for example “1 row discarded because it is invalid.” Duplicates are removed.
• Saving the whitelist replaces the entire previous list.

Warning: the “IP address” field is already filled in with your own IP, and below it you’ll read “Your current IP is …”. The default action is “Block (ban)”. If you press “Save override” without looking, you block yourself, immediately, and you’ll see a 403 error on the whole site. Always check the action and the address before saving.

Warning: the “Unblock” button on the “Blocked IPs” tab asks for no confirmation. It immediately creates a permanent override. The whitelist doesn’t remove existing blocks: an IP that’s already blocked stays blocked even if you add it to the list, until you unblock it. It doesn’t stop the panel’s blocks, the security list or the manual bans either: it only stops failed logins from being counted. Blocking also only works with Apache or LiteSpeed, and with a writable .htaccess file. With other servers the ban exists in the tables, but the server doesn’t apply it.

What happens behind the scenes

When you decide to block IP WordPress with an override, the plugin rewrites a block of .htaccess between # BEGIN Cisilino Site Defense Network and # END Cisilino Site Defense Network. The rest of the file is left untouched. The blocked IPs are the union of four sources: the local block for failed logins, the panel’s list, the optional list from the “Security level”, and manual bans. The unban removes from that union the entry matching the address you wrote. A panel network (for example 198.51.100.0/24) only leaves if you unblock 198.51.100.0, not a single IP inside that network. The unblock also applies to the optional “Security level” list (Noob, Casual, Berserk). Those IPs don’t appear in the “Blocked IPs” tab, but an unban neutralises them anyway.

The plugin reads the visitor’s IP from REMOTE_ADDR and ignores X-Forwarded-For. Behind a proxy or a CDN the address seen can be the proxy’s. In that case a block risks hitting every visitor.

Expirations work like this:

• A timed manual ban is removed when it expires, and the address leaves .htaccess at the next check cycle, within around 15 minutes.
• A local ban, the kind triggered by too many failed logins, doesn’t expire on its own. It is removed only with an unban.
• A timed unban, once it expires, brings the block back if the original source is still there.

Every time you save or remove an override, and every change to the whitelist, is written to the activity log.

Practical examples

Block IP WordPress for a day

You want to stop the address 203.0.113.5 for 24 hours. Write it in “IP address”, leave “Block (ban)”, choose “24 hours” and press “Save override”. In the “Blocked IPs” tab it will show up with the source “manual”.

Whitelist for the office network

Write 203.0.113.0/24 into the whitelist and press “Save whitelist”. From that moment the wrong logins from that network are no longer counted. Do this before testing with wrong passwords.

I’ve blocked myself

If you can still open the admin area, for example from your phone on mobile data, go to “Blocked IPs” and press “Unblock” on your IP. Then add it to the whitelist. If instead you see a 403 across the whole site, you can connect via FTP and remove the line with your IP from the .htaccess file. Be careful: the plugin can rewrite it on the next event, so as soon as you’re back in, use “Unblock” and the whitelist.

To understand more about how Apache handles these access controls, read the Apache access control guide: it explains the directives the plugin writes for you.

In short, to block IP WordPress carefully means checking the action and the address before saving. Previous chapter: General tab: block threshold and plugin status. Next chapter: Blocked IPs tab: reading the blacklist. The index is in the CSDN manual.

The post Blocking, unblocking and whitelisting first appeared on Matteo Cisilino.

Where it is

Open Settings and then “Cisilino Site Defense Network” (point 1 in the image). The “General” tab (point 2) is the one that opens first. At the top of the page there is a row of counters: “IPs blocked locally”, “IPs received from the panel” and “IPs from the optional security list”. Below, the tab has four sections. Point 3 is “Recent activity log”, point 4 is “Local IP overrides”, point 5 is “Trusted IPs (whitelist)” and point 6 is “Upload monitoring”.

In this chapter we cover point 3 and the threshold. Manual blocking and unblocking, and the whitelist (points 4 and 5), are in chapter 5. Upload monitoring (point 6) is in chapter 8.

The recent activity log

The section shows the “Last 50 failed login attempts detected on this site.” The columns are as follows.

• “IP”: the address the attempts come from.
• “Username tried”: the last username attempted from that IP.
• “Attempts”: the total failed logins from that IP.
• “Status”: “Blocked” or “Watched”.
• “Last seen”: date and time, in the site’s time zone.

Watch out for one detail: there is one row per IP, not one row per attempt. If the same IP tries ten different usernames, you’ll see a single row with “Attempts” at 10 and the last username tried. If there’s nothing to show, you’ll read “No events recorded.”

“Watched” means the IP has failed some logins but hasn’t yet reached the threshold. Watched IPs are also sent to the panel, if you have made the connection described in chapter 3.

How the block threshold works

The value is set in the “Remote settings” tab, in the “Local block threshold (failed attempts)” field. The default value is 10. The form field accepts from 3 to 100, but only the browser enforces that: the server doesn’t check the limits, and an empty value or 0 becomes 10. For every failed login the plugin reads the IP, increases that row’s counter and checks the total. When the total reaches the threshold, the row switches to “Blocked”. The .htaccess file is rewritten immediately, without waiting for synchronisation. On a server that ignores .htaccess (nginx, for instance) the block has no effect on traffic.

A technical example: with a threshold of 3, two failed attempts from 203.0.113.7 leave it “Watched”. The third blocks it.

The threshold applies even without the panel. The connection only serves to exchange IP lists, not to block locally.

The threshold is cumulative

This is the most surprising part of the block threshold. The counter has no time window and never resets. Every failed login adds to the previous ones, even if weeks have passed. A contributor who occasionally mistypes a password can, over time, reach the threshold and find themselves locked out of the site.

Warning: for networks you know (office, headquarters) use the whitelist, described in chapter 5. Whitelisted IPs aren’t even counted. A manual unblock (“Always unblock”) keeps the IP out of .htaccess for as long as the override exists, but it doesn’t reset the count and the row stays “Blocked”. If the override expires or you remove it, the IP goes back to being blocked.

To understand further why simply counting attempts isn’t enough as a defence, you’ll find a useful guide on the OWASP page about blocking brute force attacks, which discusses the pros and cons of automatic blocking.

The risk of a proxy or a CDN

The plugin reads the visitor’s address only from REMOTE_ADDR. It deliberately ignores headers such as X-Forwarded-For, because an attacker can forge them. If the site sits behind a proxy, a CDN or a load balancer, REMOTE_ADDR can be the proxy’s IP rather than the visitor’s.

Warning: in that case every failed login would be attributed to the same IP. Once the threshold is reached, you could end up blocking the proxy’s IP, and with it every visitor. Check the “IP” column of the log: if you always see the same address, even for different users, you’re in this situation. Whitelisting the proxy’s IP unblocks the visitors, but from that moment no failed login passing through it is counted any more: the protection against repeated attempts stops working. Use an upstream defence (on the proxy or the CDN) and don’t rely on the threshold alone.

If something goes wrong

• A legitimate user shows as “Blocked”: add their network to the whitelist and unblock them as explained in chapter 5.
• You always see the same IP for different people: suspect a proxy, as described above.
• You want to change the block threshold: go to “Remote settings”, change the field and click “Save and verify connection”. If you don’t have the panel, the connection fields stay empty.

The block threshold stays local: you decide how strict to be.

Previous chapter: Connecting the plugin to the panel: Remote settings. Next chapter: Blocking, unblocking and whitelisting: the manual overrides. The full index is in chapter 1.

The post Block threshold: the General tab first appeared on Matteo Cisilino.