Where it is

Open Plugins > Installed Plugins (point 1 in the image). On the row for Cisilino Site Defense Network (point 3) you’ll find the Deactivate link. After deactivation (point 4) the same row shows Activate and Delete.

What happens on deactivation

Deactivating the plugin stops it without touching the data. On deactivation the plugin does four things.

1. it logs the event “Plugin deactivated on this site” and tries to deliver it to the panel, if configured.
2. it cancels the three scheduled tasks.
3. it empties both .htaccess blocks, the blocked-IPs one and the hardening one.
4. it updates WordPress’s rewrite rules.

Warning: while deactivated, no rule stays in force. Blocked IPs can access the site again, and hardening no longer applies. The plugin isn’t even loaded, so the other protections don’t act either. The security headers stop too, though a browser that already received HSTS will remember it for the time that was set.

The database stays intact. If you reactivate the plugin, the .htaccess blocks are rebuilt, and you’ll find the settings exactly as you left them.

How to uninstall the plugin

To uninstall the plugin you need to press Delete in Installed Plugins, after deactivating it. Before you do, follow these steps.

1. In the Activity log tab, check that the “awaiting delivery to the panel” row is at zero, if you use the panel.
2. In the Debug log tab, download any files you need. Then, if you want, press Delete all files.
3. Back up the site, if you haven’t already.
4. Deactivate the plugin and press Delete.

What gets removed and what stays

When you choose to uninstall the plugin, it first logs “Plugin uninstalled from this site: local data removed” and tries to deliver that to the panel. Then it deletes everything, whatever happened with delivery.

The following is removed.

• the four tables csdn_events, csdn_overrides, csdn_rate_hits and csdn_activity.
• almost every option whose name starts with csdn_, including the panel credentials, the whitelist and the tab settings. Three remain, listed below.
• the rate limiting suspension data on every user.
• the plugin’s temporary data.
• the rules in the plugin’s two .htaccess blocks and the rewrite rules. The # BEGIN and # END markers stay in the file, empty.

The following stays instead.

• the debug log files in the csdn-debug-* folder inside uploads, because they are your own data: delete them by hand, or with the Delete all files button, before uninstalling.
• the history already delivered to the panel, which sits on the panel, not on your site.
• the lines in .htaccess that sit outside the plugin’s markers.
• three minor options: csdn_registration_lock (the User registration policy), csdn_remote_ban_reasons (the reasons for blocks received) and csdn_trigger_token (the token received from the panel). The user data csdn_registration_blocked_at also stays, if present, along with the temporary csdn_rl_block_* data, which expires on its own. These can be removed by hand from the database.

Warning: uninstalling the plugin also deletes the local activity log. Rows not yet delivered to the panel are lost if the panel doesn’t respond.

Personal data processed by the plugin

The plugin keeps its data on your own site, in the database. Never the password. Here’s what it processes.

• Failed logins: IP address, username tried, number of attempts, first and last occurrence, and block status. There’s no automatic deletion: they stay in the database until you uninstall the plugin.
• Activity log: date and time, WordPress user (id, login, role), IP, type of action, the object involved (for content, its title) and a short description. In some cases it adds details: for a new user, the email and roles; for a profile edit, the previous and new values of email, login, display name and website. It doesn’t save the content of posts, comments or files. For options with a suspicious name, such as keys or tokens, it only logs that they changed.
• Rate limiting: the IP and type of submission from guests, kept for one day. Author suspensions sit in the user’s own data.
• IP overrides, whitelist and the blacklist received.
• Debug log, if you switch it on: files that can contain paths and fragments of data.

The local log keeps 30 days by default, and at most 500 rows. You can change both values in the Activity log tab.

What leaves the site

Only if you connect the panel. Every 15 minutes the plugin sends the failed logins: IP, username, outcome “failed” and date. It sends up to 200 at a time. It adds the customer code and the site’s URL. It receives the blocked IPs. The activity log, with the details above, is normally sent straight away, at the end of the request, and whatever is left queued goes out with the 15-minute round. It only runs if both the log and the “Send activity to the panel” option are on. Manual overrides are never sent.

What to write in your privacy notice

For as long as you haven’t decided to uninstall the plugin, your site’s privacy notice should mention at least these points.

• that the site logs the IP and username of failed login attempts, for security reasons.
• that it keeps a log of user actions, with IP addresses, and for how many days it keeps them.
• that, if you’ve connected the panel, some of this data is sent to the external service.
• who the data controller is, and how users can exercise their rights.

Adapt the text to your own situation, with your advisor if you have one: this manual is no substitute for legal advice. For the basics on plugins, the official WordPress guide also explains the difference between deactivating and deleting.

If something goes wrong

If the site shows an error after deactivation, check .htaccess via FTP and see the chapter Troubleshooting and frequently asked questions. If you decided to uninstall the plugin by mistake, the local data doesn’t come back: you’ll need a site backup.

Previous chapter: Troubleshooting and frequently asked questions. Back to the index with the introduction to the CSDN manual.

The post Deactivation, uninstallation and personal data first appeared on Matteo Cisilino.

Troubleshooting CSDN: where to start

Before hunting for the exact answer, run through this checklist.

1. Can you still open wp-admin? If so, almost everything can be fixed from the plugin’s Settings page.
2. Read the notices at the top. The plugin explains the outcome of its actions in coloured boxes.
3. Remember the last thing you changed: a hardening rule, a policy, a limit.
4. If there’s a Check now button, use it before guessing.
5. If you can no longer get into the site, get your FTP access or the hosting’s file manager ready.

Logins and blocks

I’ve locked myself out: what do I do?

If you still have access to WordPress, for example from your phone on mobile data, open the Blocked IPs tab. Find your IP and press Unblock. If your IP isn’t listed but you’re still blocked (which can come from the optional security list), go to the General tab, “Local IP overrides” section: enter the IP, choose “Always unblock (unban)” and press Save override. Then, in the General tab, press Add to whitelist.

If you’re blocked from the site too, and see a 403 error, log in via FTP and open .htaccess. Remove the line with your IP, or the whole block between # BEGIN Cisilino Site Defense Network and # END Cisilino Site Defense Network.

Warning: the manual edit is temporary. The same source will rewrite the block at the next event: a failed login, a sync, or the 15-minute round. As soon as you’re back in, use Unblock and the whitelist.

Why didn’t the whitelist unblock me?

The whitelist only stops failed logins from being counted. It doesn’t remove blocks already in place. To remove a block you need Unblock, which creates a permanent unblock override on this site.

A legitimate user has been blocked

The attempts counter is cumulative per IP and never resets on its own. Even scattered mistakes over weeks can reach the threshold, which defaults to 10. Unblock the IP and whitelist it, or raise the threshold in Remote settings, where the field is called “Local block threshold (failed attempts)”.

An IP’s block never ends

A local block doesn’t expire. A manual block expires after the chosen duration, from 1 hour to 7 days. If you chose “Permanent (until you remove it)”, it doesn’t expire. A block received from the panel disappears once the panel removes it from the list. A timed unblock, once it expires, brings the block back if the original source is still there. For a definitive unblock use Unblock, which is permanent.

Blocks look odd behind a proxy or a CDN

The plugin reads the IP only from REMOTE_ADDR and ignores the X-Forwarded-For header, because it can be forged. Look at the line “Your current IP is …” under the IP address field in the General tab. If it isn’t your public IP, the plugin is seeing the proxy’s address. In that case, avoid blocking or whitelisting that address until you’ve sorted it out with whoever manages the proxy.

Errors after the .htaccess rules

This part of troubleshooting CSDN covers rules written to the server’s own file.

The site shows a 500 error after saving the hardening rules

The plugin makes no copy of .htaccess and doesn’t check the syntax after writing it. An error, or a rule your server doesn’t accept, shows up straight away as a 500 error.

1. Log in via FTP or the file manager.
2. Make a copy of .htaccess.
3. Delete the block between # BEGIN Cisilino Site Defense Network - Hardening and # END Cisilino Site Defense Network - Hardening.
4. Reload the site, then correct the settings in the Hardening / IDS tab.

The hardening block is only rewritten when you save that tab or reactivate the plugin, not by the 15-minute round. Your manual fix therefore stays in place.

I wrote a custom path and the whole site gives a 403

In the custom paths box, every line is literal text, with no wildcards. The rule blocks any address containing that string. Writing / or wp blocks everything, including wp-admin. Remove the hardening block via FTP, as above. Then, in the Hardening / IDS tab, fix or empty the “Custom paths to block” box and save. If you don’t fix it, a new save or a plugin reactivation will rewrite the rule, and the site will go back to giving a 403.

You see “Settings saved, but writing to .htaccess failed”

The .htaccess file isn’t writable: check the permissions. The rules in that block aren’t active. The two switches that act in PHP, meaning XML-RPC and ?author=N, stay active regardless.

The test says the PHP block in uploads doesn’t work

In the Test tab, the “Check PHP execution block in uploads” box reports whether the test file was executed. Check that your hosting allows .htaccess in that folder, and that there’s no more specific <Directory> block. On nginx the rules have no effect. The rule only covers the standard uploads folder.

A plugin or the theme has stopped working

Switch off the last rule you turned on and save. The most common cases: blocking PHP in uploads breaks plugins that write PHP files there; disabling XML-RPC stops remote apps and functions; blocking executable uploads also rejects files such as .svg.

Users, authors and visitors

An author can no longer publish: “your account is suspended”

Rate limiting has seen too much content created too quickly. By default the limit is 150 items in 300 seconds, with a 3600-second suspension. From the Rate limiting tab, in the suspended users table, press Revoke suspension. Otherwise, wait for it to expire.

Switching off “Rate limit active” doesn’t remove a suspension already under way. Before a large import, raise the limit N or switch off the cap.

A visitor sees “Too many submissions”

A guest has sent too many comments or forms too quickly: more than 2 in 60 seconds by default, with a 3600-second block. The block is by IP, so it can hit several people in the same office. Raise the N value in the visitors section. There’s no list of exceptions.

I can’t create an editor or administrator user

That’s intentional. The default User registration policy is “Low-privilege roles only”, and it makes no exception, not even for you. Switch temporarily to “No restriction”, create the user, then switch back. With “No registration (exclusive)” nobody can create users. Also check the default role under Settings > General in WordPress: if it’s a forbidden role, registrations are rejected.

Connecting to the panel

The panel connection doesn’t show

The status is in the “Panel connection status:” box at the top of the Remote settings tab. If the box is missing, the fields were incomplete: you need the Customer code, the API key and the Panel URL. After “Save and verify connection” no separate banner appears.

• “Panel URL not secure: https is required …”: the address must start with https. The plugin also refuses to save an http URL.
• “Authentication rejected by the panel: customer_code or API key incorrect.”: double-check both values.
• “Unable to reach the panel: …”: a network, DNS or certificate problem.
• “Invalid response from the panel (not JSON).”: the address doesn’t point to the right panel.

If the panel doesn’t respond, local protection carries on and the queued data is sent on the next round. The plugin works even without the panel.

Activity isn’t reaching the panel

In the Activity log tab, look at the diagnostics table and the “awaiting delivery to the panel” row. Press Try sending now: the result appears in the diagnostics. The row cap, 500 by default, deletes the oldest ones even if they haven’t been delivered.

Debug log, integrity and headers

The debug log won’t turn on

There are two possible messages. “the uploads folder is not writable”: fix the permissions on uploads. “the files in its folder appear reachable from the internet”: probably a server with no .htaccess, such as nginx. Block access to the csdn-debug-* folder in the server configuration and try again. If the log stopped because of the 200 MB cap, download or delete the files and turn it back on.

Integrity says “the plugin’s files do not match”

If you’ve edited a plugin file by hand, that’s normal. Otherwise, treat the site as potentially compromised: reinstall the plugin from a trusted copy and check the rest. If the message says there’s no reference at all, reactivate the plugin to take a new snapshot.

HSTS won’t turn on, or won’t turn off

To turn it on you must open the plugin’s settings over https, otherwise you’ll see “HSTS was NOT activated”. Always save from an https page. Unticking the box stops the header being sent, but browsers that already received it will remember it for a long time.

If you can’t find the answer

If this troubleshooting CSDN page isn’t enough, turn on the debug log, reproduce the problem and read the entry. Then open a discussion on the plugin’s support forum: it’s the place to get help and see problems already reported. Don’t paste server paths or sensitive data.

Previous chapter: Debug log: PHP errors in their own file. Next chapter: Deactivation, uninstallation and personal data. For the index: the CSDN manual.

The post Troubleshooting CSDN: FAQ first appeared on Matteo Cisilino.

Where it is

Go to Settings > Cisilino Site Defense Network (point 1 in the image) and open the Debug log tab (point 2). There are three sections:

• point 3: “Site debug log”, with status and activation.
• point 4: “Collected files”.
• point 5: “Latest entries”.

What the WordPress debug log is for

It comes in useful when the site shows a blank page or a critical error, when something breaks after an update, or when your hosting won’t let you edit wp-config.php or read the logs. The WP_DEBUG and WP_DEBUG_LOG constants are defined before the plugins load, so a plugin can’t turn them on. This log instead uses a PHP error handler hooked onto the plugin’s own loading.

This log adds to things, it doesn’t replace anything. Errors keep arriving wherever they arrived before, meaning debug.log and the server log. It sends nothing to the panel.

How to use it

1. Open the Debug log tab.
2. Choose Stay on for: 1 hour, 24 hours (default) or 7 days.
3. Choose Maximum size per file.
4. Press Turn on the debug log. You’ll read “Debug log turned on. It switches itself off when the chosen time runs out; the files stay.”.
5. Reproduce the problem on the site.
6. Go back to the tab. Read “Latest entries”, or download the file from the “Collected files” section.
7. When you’re done, press Turn off the debug log, or wait for it to expire. You’ll see “Debug log turned off. The files collected are still here below.”.

The “Status:” line tells you whether the log is “on, switches off on dd/mm/yyyy hh:mm”, “off (expired on …)” or “off”. While the log is on you can change the size with Save size.

Collected files

The table lists name, size, and the Download and Delete buttons. Below you’ll find Delete all files. Before deleting, the plugin asks for confirmation: “Delete this file? This cannot be undone.”. For Delete all files the text is “Delete all debug log files? This cannot be undone.”. If there’s nothing you’ll read “No files: the log has never been switched on, or it hasn’t logged anything yet.”.

Latest entries

The box shows the 200 most recent entries, newest first. The All levels menu lets you filter by Fatal error, Parse error, Recoverable error, Warning, Notice or Deprecated. Then press Filter. For anything else, download the files. If the filter finds nothing, you’ll read “No entries match this filter.”.

An entry has this shape:

[2026-10-29 10:15:03 UTC] Warning: message in /path/file.php:12 | GET /page

• The time is in UTC, different from the site time shown in the Activity log.
• After the vertical bar you’ll find the method and path of the request, without the query string. From the command line or cron you’ll see “cli/cron”.
• A multi-line message, such as a stack trace, stays a single entry, with the following lines indented.
• The lines “Info: debug log enabled (user N)” and “Info: debug log disabled (user N)” carry no level: a filter hides them.

Default values and limits

• Duration of the WordPress debug log: 1 hour, 24 hours or 7 days. Any other value becomes 24 hours.
• Size per file: 1, 5, 10, 25 or 50 MB. The default is 5 MB. The chosen size is saved when you press Turn on the debug log or Save size. Watch out: Turn off the debug log resets the size to 5 MB, because that form doesn’t include the size menu.
• Overall cap: 200 MB, adding up the .log and .zip files together.
• Every message is truncated to 4000 characters.
• It only logs PHP errors: not slow queries, JavaScript errors or HTTP requests.

Examples

• A critical error after a plugin update: turn it on for 1 hour, reload the page, filter “Fatal error”. The entry shows the file and line, for example /…/plugins/xyz/file.php:210 | GET /shop/.
• Occasional warnings: 24 hours, filter on Warning or Deprecated. If the file has been rotated, download the zip.
• A slow site with no clear cause: 7 days with 25 MB files, then look for Notice and Warning entries that keep repeating.

Keep it on for only as long as you need: often 1 hour is enough.

Warning: the debug log files contain server paths and fragments of data. Don’t share them publicly. They stay on disk even after switching off and after uninstalling the plugin, which deletes the options but not the files. Delete them yourself when you’re finished. The overall cap is 200 MB.

Warning: on an nginx server, turning it on can be refused until the server blocks the csdn-debug-* folder. The message is “Debug log not turned on: the files in its folder appear reachable from the internet (probably a server with no .htaccess support, such as nginx). The logs can contain paths and data: block access to the csdn-debug-* folder in the server configuration and try again.”. If you don’t manage the server yourself, ask whoever does.

Warning: the log doesn’t see errors suppressed with @, nor ones generated before the plugin loads. For example, it doesn’t see errors from wp-config.php. The plugin’s WordPress debug log doesn’t replace the server’s own logs.

What happens behind the scenes

The WordPress debug log saves its files in a folder named wp-content/uploads/csdn-debug- followed by 16 random characters. Inside are an index.php, a .htaccess denying access, and the file in use, csdn-debug.log. On activation the plugin writes a test file and tries to read it over HTTP. If it responds, the plugin refuses to turn the log on.

When the file in use exceeds the chosen size, it is closed, compressed into a .zip, and a new one starts. No entry is lost. The original .log is only deleted once the zip has been verified. If the compression fails, the .log stays. “Latest entries” only reads from the file in use, so after a rotation the older entries sit inside the zip files.

Before rotating, the plugin checks the 200 MB cap. If it’s reached, the log stops so nothing gets overwritten. The yellow notice reads: “The log has stopped because the files reached the space cap (200 MB): to avoid overwriting data, it stops writing. Download or delete the files, then turn it back on.”. To start again, delete the files and turn the log back on.

On expiry the log switches itself off, but the files stay. The plugin never truncates or deletes them: only you do that, with Delete or Delete all files. For fatal errors, the entry is written at the end of the request.

If the WordPress debug log doesn’t work

• “Debug log not turned on: the uploads folder is not writable.”: check the permissions on the wp-content/uploads folder.
• The log doesn’t write: if writing fails, the plugin reports it with an entry “Site debug log: …” in the “Last attempts” of the Activity log tab.
• The log has stopped for the cap: download what you need, delete the files, and turn it back on.

The general guide to the manual explains where this tab fits in. To understand the WordPress constants better, look at the official WordPress debugging guide: it explains WP_DEBUG and WP_DEBUG_LOG, which this plugin cannot replace.

Previous chapter: Activity log. Next chapter: Troubleshooting and frequently asked questions.

The post Debug log: PHP errors in their own file first appeared on Matteo Cisilino.

Where it is

In the backend go to Settings > Cisilino Site Defense Network (point 1 in the image). Open the Activity log tab (point 2). From top to bottom you’ll find these sections:

• point 3: “Activity log settings”.
• point 4: the status row above the form, with the row counters.
• point 5: “Panel delivery diagnostics”.
• point 6: “Logged activity”, the table with the filters.
• point 7: “Clear the local log”.

What the activity log WordPress keeps is for

It helps you answer questions like “who deactivated that plugin?” or “which IP did that user log in from?”. Every event is a row in the site’s database table.

Don’t confuse it with the per-IP failed-login counter, which decides the blocks. They are two separate pieces of data, with different retention rules. A failed login attempt, though, also shows up here, one row per attempt.

For a long history and for serious searches, the panel is better. The local log also works without the panel. The connection is set up in Remote settings.

How to use it

1. Open the tab and look at the row “Rows in the local log: N — awaiting delivery to the panel: M”.
2. In the form, choose the settings described below.
3. Press Save log settings. You’ll see “Activity log settings saved.”.
4. To read the events go to “Logged activity”. Choose a group from the All groups menu, or type into the User, object or IP field, then press Filter.

The form settings

• “Log activity on this site”: turn it off and no new rows are written. Old ones stay.
• “Local retention (days)”: from 0 to 3650. With 0, nothing is deleted for age.
• “Rows kept cap”: from 0 to 1,000,000. With 0 there’s no cap.
• “Send activity to the panel”: requires the connection set up in Remote settings.
• “Immediate delivery”: sending starts at the end of the request, without making the visitor wait. Turn it off, and sending happens only with the 15-minute synchronisation.
• “What to log”: one box for each of the 18 event groups.

The event groups

The groups carry these labels, identical in the “What to log” boxes and in the All groups menu: Logins (login, logout, failed attempts); Users (creation, profile edits, roles, deletion); Content (posts, pages, custom post types); Categories and tags; Comments; Media (attachments); Plugins (activation, deactivation, installation, update); Themes (theme switch, update, customisation); WordPress updates; WordPress settings; Navigation menus; Widgets; Theme/plugin file editor from wp-admin; Content export; File uploads (including those outside the media library); Plugin file integrity; Plugin settings (including this plugin’s own); Plugin lifecycle (deactivation, uninstallation, log clearing).

For WordPress settings only a selection of the main options is logged, for example blogname, siteurl, admin_email, default_role and active_plugins. For other plugins, only settings declared with register_setting() or saved through options.php are visible. The file editor logs the attempt, not the outcome.

How to read the table

The columns are When, User, IP, Group, Action, Detail and Sent. There are 50 rows per page, most recent first. Use Previous and Next to move around. If there’s nothing, you’ll read “No activity recorded (with these filters).”.

Group and Action appear with their raw name, for example plugins and deactivated. Anyone not logged in shows as “(not authenticated)”. In the Sent column you’ll find the panel’s confirmation date, or “—” if the row is still queued. The technical details field isn’t visible here: it’s read on the panel.

An example row: 12/10/2026 09:14:02, user mario (administrator), IP 203.0.113.5, group plugins, action deactivated.

Examples of reading it

• The “Logins (login, logout, failed attempts)” group and a suspicious IP: a run of failed followed by a success can mean someone has guessed the password.
• A users row with action role_changed and an unexpected user: check whether it’s a privilege escalation.
• A row in the Uploads group with a block warning: someone tried to upload a dangerous file.

Default values for the activity log WordPress keeps

• Logging on, sending to the panel on, immediate delivery on, every group active.
• Retention: 30 days. The age-based deletion runs once a day.
• Row cap: 500. The check runs every 100 inserts, so the table can exceed it by about 100 rows.
• If you save with no group ticked, the log stays on but writes nothing.
• It doesn’t log normal visits, and it doesn’t export data.

Warning: a failed login saves the username typed. If someone types their password into the username field, that text stays in the log, which can go to the panel. The plugin doesn’t filter it out. Keep this in mind when you share or read the log.

Warning: the row cap (default 500) deletes the oldest rows even if they haven’t been sent to the panel yet. The cap takes priority over the delivery guarantee. On sites with a lot of unauthenticated traffic (failed logins, comments, file submissions), 500 rows can run out quickly. If you need the full history, raise the cap, but bear in mind that setting it to 0 removes the limit on disk space.

Warning: “Clear activity log” is irreversible locally. It first asks for confirmation: “Clear the whole local activity log? This cannot be undone.”.

What isn’t saved

Plain-text passwords are never logged. When a profile is edited, only the fact that the password changed is saved. The plugin’s “API Key” field is shown as ***. Options from other plugins whose name contains words like key, secret, token, password, auth, salt, nonce, license or credential have their value replaced with “*** (value not logged)”. Option values are truncated to 200 characters.

Panel delivery diagnostics

The section at point 5 is useful when activity isn’t reaching the panel. A failed send shows no visible error: the rows stay queued and retry. The only symptom is the “awaiting” counter that doesn’t drop.

The table shows, among other things, “Panel connection”, “Activity log”, “Sending to the panel”, “Immediate delivery”, “Rows queued”, “error_log() destination” and “Last send attempt”. Problem values are in red. If the last attempt shows fewer rows accepted than sent, you’ll see “Rows rejected by the panel”: those rows aren’t retried.

There are three buttons:

• Try sending now: makes a test send immediately. The result appears in the table.
• Enable detailed logging (then Disable detailed logging): also logs successful sends.
• Clear diagnostic log: clears only the “Last attempts” list, which holds at most 25 entries. It only appears if there are entries.

What happens behind the scenes

At the end of the request the plugin closes the response to the visitor, where the server allows it, and sends the rows to the panel in batches of at most 200, oldest first. A row counts as delivered only once the panel confirms receiving it. A synchronisation every 15 minutes acts as a safety net.

Age-based retention deletes old rows once a day. If sending is on and the panel is configured, it only deletes rows already confirmed. Otherwise it deletes purely by age.

Clearing the log first tries to send the backlog, then deletes everything. It logs the clearing event, which becomes the first row of the new log. It sends no delete command to the panel: the history already sent stays there. After clearing you’ll read “Local activity log cleared. History already sent to the panel was not touched.”. If there were rows never delivered, a bold warning tells you how many were lost.

If the activity log WordPress keeps won’t send

• The “awaiting” counter doesn’t drop: open the diagnostics, check the last attempt and the HTTP code, then press “Try sending now”.
• A yellow box on the panel that doesn’t confirm: the panel may be out of date. The rows stay queued and nothing is lost.
• Connection “NOT configured”: without a customer code, API key and URL nothing is sent. Go back to Remote settings.

For a wider guide to good logging practice, read the OWASP logging guide: it explains what’s worth logging and what to avoid.

Back to chapter 1, the index of the manual. Previous chapter: Rate limiting. Next chapter: Debug log.

The post Activity log WordPress: the CSDN tab first appeared on Matteo Cisilino.

Where it is

Go to Settings and choose Cisilino Site Defense Network (point 1 in the image). Open the “Rate limiting” tab (point 2). Saving requires the manage_options permission; on multisite you need manage_network_options.

There are four sections. Point 3 is “How it works, in practice: what gets counted”. Point 4 is “1. Authors: publishing too often”. Point 5 is “2. Visitors: comments and contact forms”. Point 6 is “Currently suspended users”. All time values are in seconds.

What it’s for

The cap on authors stops an account publishing at full speed before it fills the site with content. The cap on visitors slows anyone flooding comments and forms. The code also knows a third cap, the mandatory email. You’ll find it in the “User registration” tab, described in the previous chapter.

How to use it

What gets counted (point 3)

The info box explains the rules. For authors, the check fires when WordPress saves a post or a page. The plugin counts how many posts and pages by that author have a creation or publication date within the last T seconds. If there are more than N, the author is suspended. The save that crosses the threshold goes through fine: the suspension blocks the ones that follow.

Plugins and themes don’t count, nor do logins, edits to content older than the window, auto-drafts, revisions, the trash, media, comments or other content types. Temporary environments, like the Plugin Check test one, are ignored.

Warning: the example written in that info box still quotes N=3. It’s old text. The real default value is 150 items in 5 minutes, from version 1.0.13.

Authors (point 4)

1. Tick “Rate limit active” to limit authors’ publishing.
2. Decide whether to keep “Email alert”: you get a mail when an author is suspended.
3. Set “N: allowed items”, from 1 to 1000. Default 150.
4. Set “T: window (seconds)”, from 10 to 86400. Default 300, meaning 5 minutes.
5. Set “S: suspension (seconds)”, from 60 to 2592000. Default 3600, meaning 1 hour.
6. Press Save rate limiting settings.

The mail goes to the admin address set under Settings > General. It contains the user, the content within the window, the expiry, and a list of up to 20 recent items to check. The suspension doesn’t change that content.

Visitors (point 5)

1. Tick “Rate limit active” to limit guest submissions.
2. “Email alert” is off by default. On an exposed site it could generate a lot of mail. It goes to the same admin address under Settings > General, once per block.
3. “N: allowed submissions”, from 1 to 100. Default 2.
4. “T: window (seconds)”, from 5 to 3600. Default 60.
5. “S: IP block (seconds)”, from 60 to 2592000. Default 3600.

This cap only concerns people who aren’t logged in. It counts submissions by IP and by type, comments or forms. A block on comments doesn’t block forms. The contact forms covered are Contact Form 7’s. A rejected comment shows “Too many submissions” with a 429 error.

If a value is outside the limits, the plugin moves it to the nearest allowed one. Saving shows “Rate limiting settings saved. Values outside the allowed limits have been moved to the nearest one.”

Rate limiting WordPress: suspensions and blocks

A suspended author keeps their role and can still use the rest of the admin panel. They lose, though, the permission to create and publish posts and pages. “Add New Post” and the pages menu items disappear, and opening those screens gives “permission denied”. An unclosable notice appears in the dashboard.

Warning: author suspension affects administrators too. A suspended administrator loses the ability to create and publish, but can still open Settings and revoke their own suspension. There’s no list of exceptions for users, roles or IPs: the IP whitelist in the General tab doesn’t exempt anyone from rate limiting.

Warning: the visitor block is by IP. Several people behind the same IP, such as an office, can be blocked together. In that case raise N. The plugin only reads the connecting address (REMOTE_ADDR) and not proxy or CDN headers: behind a reverse proxy or a CDN every visitor can appear with the same IP and end up blocking each other.

How to revoke a suspension

You have two routes.

1. Wait. The suspension ends on its own after S seconds.
2. In the section at point 6, “Currently suspended users”, press Revoke suspension on the user’s row. You’ll see “Suspension revoked: the user can create and publish content again.” If the table is empty, you’ll read “No suspended users.”

The table shows at most 100 users. The dashboard notices carry the links “Revoke the suspension” and “Check and revoke”, which lead to the same tab.

Switching off “Rate limit active” doesn’t remove a suspension already in progress. To remove it you have to revoke it, or wait for it to expire.

What happens behind the scenes

The suspension is information saved on the user, with an expiry date. For guests, every submission is logged for 24 hours in a plugin table, then counted within the window. If two requests arrive together, one extra may slip through. Suspensions and blocks land in the Activity log, if it’s on and if the Users and Comments groups are enabled.

Warning: a legitimate bulk import can trip the cap on authors. Before a migration, switch off the cap or raise N.

Examples of rate limiting WordPress

• A blog with a single author: you can lower N to 10 or 20 with T=300. You’ll catch a compromised account sooner. These are trial values, not a rule of the plugin.
• A newsroom that duplicates or imports pages: keep 150/300 or higher.
• Offices with a shared IP: raise visitors’ allowed submissions to 3 or 5.

Useful conversions: 300 seconds is 5 minutes, 3600 is 1 hour, 86400 is 1 day. To learn more about the general topic, read the OWASP guide on Blocking Brute Force Attacks, which explains why limiting repeated attempts matters.

Previous: User registration: who can create accounts. Next: Activity log: what happened on the site. For the general index go to chapter 1 of the manual.

The post Rate limiting: limits on authors and visitors first appeared on Matteo Cisilino.

Where it is

In the WordPress menu open Settings and then Cisilino Site Defense Network (point 1 in the image). Choose the “User registration” tab (point 2). Saving requires the manage_options permission; on multisite you need manage_network_options.

There are three sections. Point 3 is “Registration policy”. Point 4 is “Allowed roles (only at the “low-privilege roles” level)”. Point 5 is “Mandatory email”.

What it’s for

The policy applies to every route of account creation: the wp-admin panel, the REST API, XML-RPC, WP-CLI, and any plugin or theme using WordPress’s own functions to create users. The check is done in PHP, without touching the .htaccess file.

How to use it

Registration policy (point 3)

Choose a single level out of three. They don’t add up.

• “No restriction (disabled)”: the module is off and WordPress behaves as usual.
• “Low-privilege roles only (never administrator/editor/author)”: this is the default level. The allowed roles at point 4 apply.
• “No registration (exclusive)”: no new user can be created at all.

Allowed roles (point 4)

This only applies at the low-privilege roles level. You can tick subscriber (ticked by default), contributor and customer (useful with WooCommerce). The administrator, editor, author and shop_manager boxes are always disabled, marked “never allowed”.

Mandatory email (point 5)

The box “Don’t create users without a valid email address” is on by default. It stops users being created without a valid email, through any route. It doesn’t touch users who already exist. This setting is saved together with the rate limiting ones, but is managed here.

At the end, press Save registration policy. You’ll see “User registration policy saved.” The save lands in the Activity log, under the label “User registration”.

User registration WordPress: default values and limits

• The default policy is “Low-privilege roles only”, active even if you’ve never saved anything.
• The starting allowed role is subscriber alone.
• Forbidden roles are always discarded, even if someone tries to submit them by hand.
• The list of roles is fixed: it doesn’t show your site’s custom roles.
• There are no email domain lists, captchas or anti-spam checks on registrations.

Warning: with “No registration (exclusive)” nobody can create users, not even the administrator. The “Add New User” item disappears from the menu, and opening user-new.php by hand gives a 403 error. If, at the low-privilege roles level, you untick every role, the list stays empty and no user is allowed at all. Here, though, the menu item and the page stay visible: the 403 error only arrives when you try to create the user.

With the default level you can’t create an editor or an author, not even as an administrator. The plugin makes no exception for someone already logged in. To create a user with a high role, switch temporarily to “No restriction”, create the user, and then switch back.

Also check the “New user default role” under Settings > General in WordPress. If it’s a forbidden role, such as Editor, every registration without an explicit role is rejected.

What happens behind the scenes

The main check acts on the pre_insert_user_data filter, only when a user is created. Changes to existing users always go through. A rejected attempt shows the title “Registration not allowed” with a 403 error. On the REST API you get a 403 JSON error instead of the page.

With any policy active, the plugin removes the XML-RPC method wp.newUser. With the exclusive policy it also forces WordPress’s “Anyone can register” option to false. At the low-privilege level, that option stays whatever you chose.

There’s also a safety net after creation. If an account is somehow created in violation of the policy, the plugin immediately strips its role and writes an event to the Activity log. The account isn’t deleted, so you can examine it.

Warning: a compromised plugin or theme writing straight to the users table with a database INSERT doesn’t pass through any filter. No PHP plugin can stop that. The user registration WordPress protection in this tab is a strong barrier, but it isn’t absolute.

Examples

• A showcase site with no public users: choose “No registration (exclusive)”.
• A site with subscribers or comments: leave the default level with subscriber.
• A shop with WooCommerce: add customer.
• You need to add a collaborator with a high role: use “No restriction” only for as long as needed.

If something goes wrong

If a sign-up is rejected with the message about a role not being allowed, check WordPress’s default role and the roles ticked at point 4. The Activity log tells you if an account has had its role stripped by the safety net. To understand the roles better, read the page on roles and capabilities in the WordPress documentation. It lists what each role can do.

Previous: Paranoic Hardening: security headers and the admin session. Next: Rate limiting: limits on authors and visitors. For the general index go to chapter 1 of the manual.

The post User registration: who can create accounts first appeared on Matteo Cisilino.

Where it is

In the WordPress side menu go to Settings and choose Cisilino Site Defense Network (point 1 in the image). Open the “ Paranoic Hardening” tab (point 2). Saving requires the manage_options permission; on multisite you need manage_network_options.

The tab has four sections. At point 3 you’ll find “Paranoic Hardening — HTTP security headers”. At point 4 there’s “HTTP Strict Transport Security (HSTS)”. Point 5 is “Security header check”. Point 6 is “Autologout of inactive administrators”.

What it’s for

Headers are instructions the site sends the browser along with every page. The plugin sends them through WordPress’s send_headers hook, without touching the .htaccess file. So you don’t risk a 500 error, and they work even without mod_headers.

The headers only cover the public site. They are never sent in the admin area. The plugin offers no Content-Security-Policy, and it doesn’t send X-XSS-Protection.

How to use Paranoic Hardening

HTTP security headers (point 3)

• X-Content-Type-Options sends nosniff. The browser stops “guessing” a file’s type. The risk here is practically nil.
• X-Frame-Options sends SAMEORIGIN. The site can no longer be embedded in an <iframe> on another domain. If a partner site shows your pages, it will stop doing so.
• Referrer-Policy sends strict-origin-when-cross-origin. Towards other domains only the domain travels, not the path. Third-party statistics tools wanting the full referrer won’t get it.

Tick the boxes you need and press Save Paranoic Hardening. You’ll see the notice “Paranoic Hardening settings saved and applied.” Boxes you don’t tick are saved as off.

HSTS (point 4)

HSTS tells the browser to always use https with your domain. There are three boxes: “Enable HSTS”, “includeSubDomains” and “Preload”. The header sent carries max-age=31536000, meaning one year. The value is fixed and cannot be changed.

The plugin refuses to activate it if the page wasn’t opened over https. In that case it saves the rest and shows a red warning: “Settings saved, but HSTS was NOT activated: this request did not arrive over https. Open the panel over https and try again.” If the page is over http, the three boxes are also disabled.

If you turn off “Enable HSTS”, on saving “includeSubDomains” and “Preload” are reset too. If you turn HSTS back on, you’ll need to tick them again.

Security header check (point 5)

Press Check now. The plugin makes a real request to the site’s home page and checks which headers genuinely arrive. The result appears in the box, with the date of the last test.

• Green: “All the expected headers are present in the site’s real response.”
• Red: the active headers that didn’t arrive. This can be a proxy, a CDN or another plugin removing them. HSTS shows as missing even if the home address is http rather than https, because the plugin only sends it on https requests.
• Blue: “No active header to check: enable at least one option above and save.”
• Red with “Check request failed”: the request didn’t succeed.

The test checks whether a header is present, not its value. It doesn’t run on its own: you have to press it.

Autologout of administrators (point 6)

This section of Paranoic Hardening has its own button, Save autologout for administrators. Tick “Enable” to log out inactive administrators. Then set the “Inactivity timeout (seconds)”. If the browser blocks localStorage (in a private window, for instance), the check never fires and you’re never logged out.

The default value is 900, meaning 15 minutes. The minimum is 60 and the maximum is 86400. If you write a number outside those limits, the plugin moves it to the nearest allowed value. For example, 30 becomes 60. The notice stays green, so reread the number in the field after saving.

Only users with the manage_options permission are logged out. Editors and authors aren’t touched. Inactivity is measured in the browser: mouse, keyboard, scrolling and touch all count. The session closes just as with “Log Out”, and unsaved changes in an open form are lost.

Recommended order of activation

1. Open the panel over https.
2. Turn on X-Content-Type-Options, save and press “Check now”.
3. Turn on Referrer-Policy, save and check.
4. Check that no site embeds yours, then turn on X-Frame-Options, save and check.
5. Turn on autologout with a generous timeout, for example 1800. Lower it only after a few days.
6. Last of all, consider HSTS, without includeSubDomains and without Preload.

Turn on one option at a time. If something breaks, you’ll know straight away which one did it.

The risk of HSTS, includeSubDomains and Preload

Warning: HSTS can’t be undone from the site. If you untick it, the plugin stops sending the header, but browsers that already received it will remember it until it expires. The plugin never sends max-age=0, so there’s no “cancel”. The tab’s own banner says so too: the effects can stay visible for weeks or months.

With HSTS on, the browser refuses any non-https connection to the domain. If the certificate expires or breaks, the browser no longer even shows the “proceed anyway” screen. The site becomes unreachable from that browser.

• includeSubDomains extends the rule to every subdomain. A single subdomain without valid https, even a test one or a future one, becomes unreachable for anyone who has already visited the site. Only turn it on if every subdomain is, and will remain, https.
• Preload only adds the preload flag to the header. On its own it doesn’t register the site: submitting it to the browsers’ list is done by hand on hstspreload.org. The list sits inside the browsers, and getting out of it takes weeks. Treat Preload as a final, one-way decision.

Always save from the https version of the panel. Disabled boxes aren’t sent by the browser: saving from an http page switches off HSTS and its sub-options.

What happens behind the scenes

The Paranoic Hardening settings are WordPress options, not server rules. Autologout prints a script only on admin pages. The script records the last activity in the browser’s localStorage and checks the timeout every 5 seconds. On expiry it asks admin-ajax.php to log you out and takes you to the login page. The save only lands in the Activity log if you actually changed something.

If something goes wrong

• The box turns red after “Check now”: a proxy, a CDN or another plugin is stripping the headers. Check their configuration.
• A partner site no longer shows your pages: untick X-Frame-Options and save.
• You can’t turn on HSTS: reopen the panel with the https address.
• To check the headers by hand, use your browser’s developer tools or curl -I on the site’s https address.

To understand HSTS better, read the page on Strict-Transport-Security on MDN. It explains max-age, includeSubDomains and preload precisely.

Previous: Test tab: checking that the protections work. Next: User registration: who can create accounts. For the general index go to chapter 1 of the manual.

The post Paranoic Hardening: headers and autologout first appeared on Matteo Cisilino.

Where to find the WordPress security test

Open Settings > Cisilino Site Defense Network (point 1 in the image). Click the Test tab (point 2). You’ll find two boxes:

• point 3: “Check PHP execution block in uploads”.
• point 4: “Plugin file integrity”.

After each button the site takes you back to the General tab, with a notice at the top. The result, though, is written in the Test tab. Reopen it to read it.

Check PHP execution block in uploads

This box tests the “Block PHP execution in wp-content/uploads” rule from the Hardening / IDS tab, described in the Hardening / IDS chapter. The text explains that this is the only way to know whether the rule is genuinely effective on this site. A disabled AllowOverride, or a more specific block on the server, could make it useless without telling you.

How to use it

1. In the Hardening / IDS tab, turn on the rule and click “Save hardening rules”.
2. Open the Test tab.
3. In the “Check PHP execution block in uploads” box, click “Check now”.
4. Go back to the Test tab and read the result, in the “Last test:” row with its date.

If the rule isn’t active and saved, the button is disabled. The box shows: “Turn on and save the “Block PHP execution in wp-content/uploads” rule in the Hardening / IDS tab before you can run this test.”.

What the test does

The plugin writes a small test .php file into uploads. It requests it over HTTP, with a 10-second limit. Then it deletes it straight away, whatever happens. The file contains nothing but a check print statement.

How to read the result

• Green: “Block effective: the request to the test file received N.”. The number is 403 or 404.
• Red: “WARNING: the test PHP file was EXECUTED (response N).” The rule isn’t blocking anything. The message suggests checking that AllowOverride allows .htaccess in that folder, and that there’s no more specific <Directory> block.
• Yellow: “Unclear result (response N, body not recognised): check manually with a direct request to the site.”.
• Blue: “Rule disabled: turn it on and save it before running the test.”.
• Red, for errors: “Unable to determine the uploads folder.”, “Unable to write the test file to uploads (permissions?): test not run.”, or “Check request failed”, with the reason.

Warning: if the site can’t call itself, for instance because of a firewall, an HTTP password or a local DNS setting, the test returns an error or an unclear result. A 404 counts as a block, but it could be caused by something else. The test only checks the standard uploads folder. For a few seconds a .php file exists in uploads: if the block doesn’t work it could be executed, but it only contains a check print statement.

Plugin file integrity

This is the second part of the WordPress security test. The second box compares the MD5 hashes of the plugin’s .php files against the ones expected. It looks for files that are changed, missing or added. The check runs on its own once a day. The “Check now” button runs it immediately.

The box states a fixed limit: anyone who already has write access to the files can also rewrite the hashes or switch off the check. It’s a tamper detector, not a barrier.

How to use it

1. Open the Test tab.
2. In the “Plugin file integrity” box, click “Check now”.
3. Read the notice: “Integrity check run: the result is in the “Plugin file integrity” box.”.
4. Reopen the Test tab and read the box.

How to read the result

Green: “All N files checked match. Last check: date.”. If the reference is a snapshot, the box adds that it detects later changes, not a plugin already compromised at installation. Red: “WARNING: the plugin’s files do not match what is expected.”, with the lists “Changed”, “Missing” and “Unexpected”. Yellow: “No reference available”. In that case, reactivate the plugin.

The manual button doesn’t write to the activity log. Only the scheduled check does that, and only if it finds a problem or if the files return to normal after an alert. For the details, read the Upload monitoring and the integrity check chapter.

Warning: if you’ve edited a plugin file by hand, the red alert is normal. If you haven’t, treat the site as potentially compromised: reinstall the plugin from a trusted copy and check the rest of the installation.

If something goes wrong

Repeat the WordPress security test after every fix. If the PHP test returns red, the rule isn’t protecting anything. Ask your hosting provider whether .htaccess is enabled. If the server doesn’t read .htaccess, nginx for instance, the rule has no effect. Repeat the test after every fix. A 403 is the response you want to see: the page on status code 403 on MDN explains what it means.

Previous chapter: Upload monitoring and the integrity check. Next chapter: Paranoic Hardening: security headers and the admin session. For the list of chapters go back to the introduction to the manual.

The post Test tab: checking the protections work first appeared on Matteo Cisilino.

Where it is

Watch out for the location: the form isn’t in the “Hardening / IDS” tab. Open Settings > Cisilino Site Defense Network (point 1), stay on the General tab (point 2) and scroll right to the bottom. After the whitelist you’ll find the “Upload monitoring” section (point 3). The integrity check, instead, is read in the Test tab, covered in the Test tab chapter.

What upload monitoring is for

The section says: “Logs files uploaded to the site, including those that don’t go through the media library: plugin forms, admin-ajax endpoints, arbitrary uploads from a theme.” That is where most webshells get in. A log that only watches the media library won’t see them.

How to use it

1. Open the General tab and scroll down to “Upload monitoring”.
2. Check the “Monitoring” row: “Log file uploads”.
3. Check the “Block executable files” row: “Reject uploads with an executable extension (.php, .phtml, .phar, .sh, .htaccess…)”.
4. Click “Save upload monitoring”.
5. Read the notice: “Upload monitoring settings saved.”.

Log file uploads

This option is on by default. The events go into the “File uploads” group of the activity log. For a request with no file, the cost is nil. The plugin notes every request that contains a file, together with the field and the address that received it. The actions you’ll see in the log are:

• “File received in a POST request”.
• “File uploaded”.
• “WARNING: potentially executable file uploaded”.
• “Upload BLOCKED”.

The local log holds at most 500 rows, unless you change the cap in the activity log settings. How to read it is explained in the Activity log chapter.

Block executable files

This option is off by default. It only works if “Log file uploads” is also on: with monitoring off, the block does nothing, even if its box is ticked. If you turn it on, WordPress rejects the file with the message: “File type not allowed on this site (Cisilino Site Defense Network: executable file upload blocked).” The check also catches double extensions, such as image.php.jpg.

The extensions treated as dangerous are: php, php3, php4, php5, php7, php8, phtml, phps, phar, pht, shtml, cgi, pl, py, rb, sh, bash, htaccess, htpasswd, jsp, asp, aspx, exe, so, dll, ini, svg and svgz.

Warning: the list also blocks .svg, so SVG logos can no longer be uploaded. It also blocks .ini, .py, .exe and .dll, which turn up in attachments and packages. The plugin looks at every part after the first dot. A name such as archive.pl.zip is therefore rejected. The block only applies to uploads handled by WordPress (the wp_handle_upload_prefilter filter). A plugin that saves the file on its own is logged (“File received in a POST request”) but not stopped. Anyone writing straight to disk, without a request that carries a file, leaves no trace in this log.

The integrity check

Unlike upload monitoring, here you aren’t looking at new uploads but at files already present. The plugin compares the MD5 hashes of its .php files against the ones expected. It looks for files that have been changed, are missing, or have been added. It excludes the tests and dist folders. Files that aren’t PHP aren’t checked.

The check runs once a day, through the WordPress scheduling system. On a low-traffic site it can slip. The reference is the checksums.json file in the plugin folder, if present. Otherwise the plugin uses a snapshot of the files taken on activation and on every version change.

How to read the outcome

You’ll find it in the Test tab, in the “Plugin file integrity” box, which also has the “Check now” button to run the check immediately. There are four cases:

• “No check has run yet.”, if it has never started.
• Green box: “All N files checked match. Last check: date.”.
• Yellow box: “No reference available: cannot verify. Reactivate the plugin to take a new snapshot of the files.”.
• Red box: “WARNING: the plugin’s files do not match what is expected.”, with three lists: “Changed”, “Missing”, “Unexpected”.

At most 15 names appear in each list. If you see red and haven’t touched the files by hand, the plugin tells you to treat the site as potentially compromised. Reinstall the plugin from a trusted copy and check the rest of the installation.

If the reference is the snapshot, the green box says so. That comparison finds changes made afterwards, not a plugin already compromised at the time of installation.

Warning: integrity is a detector, not a barrier. Anyone who has already written to the files can also rewrite the hashes or switch off the check. Manual changes, or an upload that stops halfway, produce a red alert.

What happens behind the scenes

Upload monitoring and integrity share the same log. The daily check writes to the activity log in only two cases: when it finds a problem, and when, after a problem, things return to normal. When all is well it writes nothing. The log is then sent to the panel, so a copy of the alert sits off your server.

If something goes wrong

Upload monitoring stays useful even with blocking switched off. If a legitimate plugin stops uploading files, switch off “Block executable files” and try again. To understand which uploads reach the site, leave monitoring on and check the log. For the rules on files in uploads, see also the Hardening / IDS chapter.

The risk this is trying to reduce is described by OWASP: read the page on unrestricted file upload, useful for understanding why uploads are a weak point.

Previous chapter: Hardening / IDS: the rules for .htaccess. Next chapter: Test tab: checking that the protections work. Index: introduction to the manual.

The post Upload monitoring and the integrity check first appeared on Matteo Cisilino.

Where to find WordPress hardening

Open Settings > Cisilino Site Defense Network (point 1 in the image). Then click the Hardening / IDS tab (point 2). In the tab you’ll find three sections, in this order:

• point 3: under the heading “Hardening / access control (IDS)”, the row “.htaccess rules”.
• point 4: “WordPress”.
• point 5: “Custom paths to block”.

At the top the tab says: “Optional rules applied at server level (.htaccess) or in WordPress. All off by default: only turn them on if you know they won’t conflict with the site’s themes or plugins.” At the bottom there’s a single button: “Save hardening rules”.

What it’s for

The rules reduce the attack surface. Three switches write to the .htaccess file, as does the custom paths field. Two switches are WordPress filters. This isn’t a firewall and it doesn’t analyse requests: here “IDS” means rules for accessing files and folders.

The .htaccess rules (point 3)

Block PHP execution in wp-content/uploads

The full label is “Block PHP execution in wp-content/uploads (protection against shells uploaded as an “image”)”. The plugin replies with 403 to any request for a file with extension php, php3, php4, php5, php7, php8, php9, phtml, phps, phar or pht whose address contains /wp-content/uploads/. Capital letters don’t matter.

It only works with Apache 2.4 (it needs the mod_authz_core module: without it, the rule does nothing and doesn’t report that). On nginx the .htaccess file is ignored and no rule in this tab has any effect, aside from the WordPress filters. It covers the standard uploads folder, not a custom one. It can break plugins that genuinely serve PHP files from that folder. To know whether it works on your site, use the test in the Test tab chapter.

Disable directory listing for folders without an index

It writes a single line: Options -Indexes. Opening a folder with no index page will now show a 403 error instead of the file listing. If you use a folder as a public list of downloads, that listing disappears.

Block direct access to wp-config.php, .htaccess, readme.html, debug.log

The plugin writes a rule for each name and replies with 403. The check is on the file’s name, not its path. It therefore applies to any file with that name in any folder on the site, even inside other plugins. A plugin that publishes its own readme.html or debug.log will be blocked.

The WordPress rules (point 4)

These two WordPress hardening rules are PHP filters. They don’t touch .htaccess.

Disable XML-RPC

The label is “Disable XML-RPC (brute force/pingback, almost never needed on modern sites)”. The xmlrpc.php file stays in place, but WordPress refuses the XML-RPC methods that require login. Warning: this stops the WordPress mobile app, part of Jetpack’s functions, and publishing from external clients. The pingback.ping method doesn’t require login, and the filter doesn’t stop it: don’t rely on this rule to close down pingbacks. Trackbacks don’t use XML-RPC and aren’t affected. The plugin’s connection to the panel doesn’t use XML-RPC either, so it isn’t affected.

Block user enumeration via ?author=N

If the request contains the author parameter with a value (other than empty or 0), the public site shows “Not found.” with a 404 response. Warning: this rule doesn’t protect the REST API. The user list at /wp-json/wp/v2/users stays reachable. Some themes and plugins use ?author= to filter archives, and these will be blocked.

Custom paths to block (point 5)

This text field is for anyone who wants to close a specific folder, for example /wp-content/uploads/old-backup/. Write one path per line. Empty lines are ignored.

Each line is literal text. Capital letters matter, and the part after the ? in the address isn’t compared. The help text under the field talks about “patterns”, but none exist here. There are no wildcards: *, ^ and $ count as plain characters. The plugin blocks with 403 any address that contains that string, anywhere within it. That’s why the path /wp-content/uploads/old-backup/ also blocks /blog/wp-content/uploads/old-backup/x.

This field has no switch. The rule is active as soon as the field isn’t empty and you save.

Warning: if you write / or wp you block the whole site, admin area included. To get back you would need to fix .htaccess via FTP. Even a string such as /uploads/ blocks every image. Avoid the % character in paths.

Default values

Five switches off and an empty field. The settings live in the csdn_hardening option.

How to use it

Take it slowly: WordPress hardening is done one rule at a time.

1. Make a copy of .htaccess before you start.
2. Tick a single rule.
3. Click “Save hardening rules”.
4. Check that the site opens and that the admin panel works.
5. Move on to the next rule.

After saving you are taken back to the General tab, not the one you saved. At the top you’ll find the notice. On success it says “Hardening rules saved and applied.”. On failure it says “Settings saved, but writing to .htaccess failed (permissions?). The rules are not active.”. With the failure, the two PHP filters stay active regardless.

Warning: the plugin makes no backup of .htaccess whatsoever. It doesn’t even check the syntax before writing. A rule that your server doesn’t support can cause a 500 error across the whole site. On a multisite network the file belongs to the network: the error hits every site.

What happens behind the scenes

The plugin writes between two markers: # BEGIN Cisilino Site Defense Network - Hardening and the matching # END. The rest of the file is untouched. A second, separate block holds the blocked IPs. If you deactivate the plugin, both blocks are emptied. If you turn everything off and save, the hardening block stays empty.

If something goes wrong

If the site shows a 500 error after WordPress hardening, open .htaccess via FTP. Delete the lines between the two hardening markers. Then try again with fewer rules. If nothing is written to the file, check the permissions on .htaccess.

For a wider view of good practice, read the official guide to hardening WordPress: it explains other measures that sit outside the plugin.

Previous chapter: Blocked IPs tab: reading the blacklist. Next chapter: Upload monitoring and the integrity check. For the full list of chapters go back to the introduction to the manual.

The post Hardening / IDS: the .htaccess rules first appeared on Matteo Cisilino.