WordPress plugin intelligence profile

Cisilino Site Defense Network

Blocks login brute-force attempts in .htaccess, optionally exchanges hostile IPs with the Cisilino network, offers whitelisting and basic hardening.

WP PlugIndex snapshot

Current directory snapshot

Tested up to WordPress 7.1
Current version1.0.15
WordPress coverageTested up to WordPress 7.1
Minimum stackWP 5.8 · PHP 7.4
Directory statusactive
Last directory update29 Oct 20263d ago
Active installationsNewAdoption metric — not a quality score
WordPress.org ratingNo WordPress.org ratings yet
Official packageDirect from WordPress.org

Repository metrics are context, not quality scores. Active installations measure adoption and can strongly reflect a plugin’s age and historical popularity. Ratings, recent updates and “Tested up to” metadata also do not guarantee modern code, error-free operation, security, feature completeness or suitability for a particular site. Why active installs don’t tell the whole story →

WP PlugIndex currently records Cisilino Site Defense Network version 1.0.15 as active, updated 3d ago and tested up to WordPress 7.1.

Overview

About this plugin

Cisilino Site Defense Network watches failed login attempts on your

WordPress site. Once an IP exceeds a configurable threshold, it gets

htaccess file

2).

Documentation: guides for every feature (in Italian) are published at

com/category/csdn/.

Blacklist and log

A single page (Settings > Cisilino Site Defense Network) shows:

  • a unified blacklist (IPs blocked locally, received from the network, or

added manually), with an “Unblock” button on each row;

  • a log of the last 50 detections;
  • a manual ban/unban override for a specific IP, with an optional

expiry (permanent, 1 hour, 6 hours, 24 hours or 7 days);

  • a whitelist of trusted IPs (e.g. your office network): unlike an

unban, a whitelisted IP is not even counted as a failed attempt.

Activity log (local, with its own retention)

A dedicated tab (“Registro attivita”) records what happens on the site:

logins and logouts, failed login attempts, user creation/deletion/role

changes, content published or deleted, comments, media, plugin and theme

activation/update, WordPress core updates, changes to significant core

settings, menus, widgets, theme/plugin file edits from wp-admin, and

content exports. Each group can be turned on or off individually.

Plugin settings changes are recorded too, with a before/after of the

fields that actually changed: this plugin’s own settings in full detail

(panel connection, whitelist, hardening, IP overrides, activity log

options), and other plugins’ settings when they are declared through the

WordPress Settings API. Values of options whose name suggests a secret

(key, token, password, licence…) are never recorded – only the fact

that they changed.

Emptying the local log, deactivating and uninstalling the plugin are

themselves recorded as events. Emptying the local log never sends any

deletion command to the panel: the history already delivered there stays

untouched.

Deactivating or uninstalling the plugin is itself recorded, and the plugin

tries to deliver that final entry to the panel before removing anything —

so the panel can tell “the plugin was removed on purpose” apart from “the

site went silent”.

Each entry is written locally first, in its own table, and then

delivered to the panel immediately – at the end of the request in which

it happened, never inside the action itself, so a visitor never waits

for the panel. If the panel is unreachable the entry simply stays queued

and is retried: delivery is delayed, entries are not lost. The daily

retention cleanup only removes entries the panel has already confirmed,

so a long panel outage can never make undelivered events disappear.

The retention on the panel side is a separate setting, managed by the

customer in the panel: shortening the local retention does not shorten

the panel’s history, and vice versa.

Integrity self-check

The plugin verifies the MD5 hashes of its own files against a manifest

shipped with the release (or, if that is absent, a snapshot taken at

activation), once a day and on demand. Modified, missing and unexpected

files are all reported – a web shell dropped into a plugin folder is one

of the most common ways an infection hides. The result is also sent to

the panel, because a copy of that information outside the machine is the

one an attacker on that machine cannot edit.

Known limit, stated plainly: whoever can already write to the files can

also rewrite the manifest or disable the check. This detects tampering,

it does not prevent it.

File upload monitoring

Uploads are recorded even when they do not go through the media library

– plugin forms, admin-ajax endpoints, arbitrary theme uploads – which is

where most web shells actually get in. Executable extensions are

jpg”, and can

optionally be rejected outright (off by default, since it can break

plugins that legitimately upload archives).

Site debug log (optional)

A dedicated tab turns an extra PHP error log on and off without editing

php, for a time you choose (1 hour, 24 hours or 7 days). It

log and the web server log, it never replaces them, and

nothing is deleted or truncated automatically: a file that outgrows the size you choose (1 to 50 MB) is closed, compressed

zip and checked before the original is removed, and the log stops (and says so) at a 200 MB

cap rather than overwrite older data. Files live in a randomly named

htaccess; the log refuses to start

if that folder turns out to be reachable from the internet. Limits: it

sees errors raised after this plugin loads, not those suppressed with @.

Optional hardening

A dedicated section (everything disabled by default, must be turned on

manually) lets you:

  • block PHP execution inside wp-content/uploads;
  • disable directory listing where no index file exists;
  • block direct access to wp-config.php,.htaccess, readme.html,

log;

  • block custom paths;
  • disable XML-RPC;
  • block user enumeration via?author=N.

Paranoic Hardening (optional, HTTP security headers)

A separate section, also disabled by default, sends optional security

htaccess – works even without

mod_headers): X-Content-Type-Options: nosniff,

X-Frame-Options: SAMEORIGIN, Referrer-Policy:

strict-origin-when-cross-origin, and Strict-Transport-Security (HSTS).

Every option has an inline explanation of what it does and what it can

break. HSTS in particular can make a site unreachable to a browser that

already received it if the site later stops being served over https at

all times – saving it is refused outright if the request isn’t https, and

a self-test can check which headers actually reach a real request to the

site (a proxy/CDN in front of it may otherwise strip them silently).

Rate limiting

A dedicated tab limits two kinds of abuse, each with its own on/off switch, its

own thresholds and its own email alert switch:

  • Authors: a user who creates or publishes more than N posts/pages (default

3) within a time window (default 5 minutes) is suspended for a configurable

duration (default 1 hour) — they can no longer create or publish content,

without their role being changed. The site’s main administrator can get an

email with the recent content to review (the suspension never edits or

deletes it). Active suspensions are listed in the tab and can be lifted

manually before they expire. While a suspension is active, a notice in the

WordPress admin tells the suspended user why and until when, and shows

administrators who is suspended with a link to lift it. Only posts and pages

count: installing or updating plugins, logins, auto-drafts, revisions, trashed

items, media and other content types do not, and neither does anything that

happens inside a WordPress installation or a temporary environment with a

different table prefix (for example the test installation created by the

Plugin Check plugin).

  • Guests (comments and contact forms): a non-logged-in visitor who sends

more than N comments or Contact Form 7 submissions (default 2) within a

short window (default 60 seconds) has their IP blocked for that kind of

submission for a configurable duration (default 1 hour). Only the

submission is rejected — the site’s pages stay reachable. The counter lives

in its own table, so it works even on sites with comments disabled (where a

contact form is the only entry point left).

A related, separate switch lives in the “User registration” tab: no new user

can be created without a valid email address, from any path (wp-admin, REST

API, WP-CLI, or a third-party plugin calling WordPress’s own user-creation

functions).

Cisilino network (optional)

If you configure the URL of a Cisilino Site Defense Network panel with a

customer code and API key (plugin Settings), the site periodically

(every 15 minutes) sends a digest of observed IPs and receives back the

IPs already banned for your customer by other sites in the network — so

a hostile IP detected elsewhere gets blocked here too, without waiting

for it to hit this site as well. See “== External services ==” below for

details on what is sent.

With no configuration at all, the plugin still protects the site on

its own, locally only, with no outbound calls whatsoever.

Known limitations

Stated plainly, so nobody relies on protection that is not there:

  • Apache only for server-level rules. IP blocks and hardening rules

htaccess: nginx ignores them (see the FAQ).

  • PHP execution in uploads is blocked for the standard

wp-content/uploads folder, in any letter case and also when WordPress

sits in a subfolder. An uploads folder moved elsewhere with the

UPLOADS constant is not covered. Use the “Verifica ora” button in the

hardening tab to check what the server really does.

  • User enumeration is blocked on?author= only. The REST endpoint

/wp-json/wp/v2/users is a public WordPress API and stays open,

because many themes and plugins depend on it.

  • Multisite. All sites of a network share one.htaccess, so the

plugin settings are reserved to the network super admin. If several

sites connect to the panel, each sync rewrites the same block of

banned IPs: the last one wins. Connect one site per network.

  • Trusted IPs (whitelist): IPv4 accepts single addresses and CIDR

ranges, IPv6 only exact addresses.

  • Site debug log: see its section above (errors raised before this

plugin loads, or suppressed with @, are not seen).

External services

This plugin can connect, only if you explicitly configure it (Settings >

Cisilino Site Defense Network > Panel URL, customer code, API key), to a

“Cisilino Site Defense Network” panel — a server that you or your

provider manage, not a third-party service imposed by the plugin. If

you leave these fields empty, the plugin makes no external calls at

all: it works locally only.

Once configured, the plugin contacts the panel for one purpose:

  • IP digest exchange (every 15 minutes, or on the panel’s manual poll

request): sends your customer code, the site URL, and a digest of

failed login attempts observed since the last send (remote IP,

attempted username, outcome, date/time — never the password). Receives

back the list of IPs already banned for your customer. Endpoint:

{panel URL}/api/ip-exchange/sync.

  • Activity digest (same request, same endpoint, only if the activity

log and its “send to panel” option are both enabled): the activity

entries not yet sent – date/time, WordPress user and role, IP, event

group and action, name of the object involved, and a short summary.

Never any password, and never the content of a post, comment or file.

The reference panel is a Cisilino product

com/ ). Since the URL is

configurable, a user could in theory point it at their own compatible

panel: in that case this disclosure applies to that panel, not to

Cisilino.

WordPress.org metadata

Plugin tags

Topics listed for this plugin in the WordPress.org directory.

  • brute force
  • firewall
  • htaccess
  • login
  • security
Compatibility & maintenance

Compatibility & maintenance

Tested with WP 7.1

Marked as tested with the current WordPress 7.1 release.

Current WordPress releaseWordPress 7.1
WordPress.org Tested up to7.1
Minimum requirementsWordPress 5.8 · PHP 7.4
Update activity29 Oct 20263d ago

“Tested up to” is directory metadata supplied by the plugin author. WP PlugIndex does not turn an older declaration into a claim that the plugin is incompatible.

Changes recorded by WP PlugIndex

Recent tracked changes

Version1.0.121.0.15
WordPress compatibility7.1.37.1.4
Version1.0.111.0.12
Version1.0.101.0.11
WordPress compatibility7.1.17.1.3
Version1.0.91.0.10
Version1.0.81.0.9
Version1.0.71.0.8
Version1.0.51.0.7
Version1.0.41.0.5
Tracking & source

WP PlugIndex tracks public WordPress.org directory metadata and records selected version, compatibility and availability changes as they are detected.

Plugin watchlist

Watch this plugin

Sign in to your WP PlugIndex account or create a free account. Free accounts can watch up to 5 plugins and see what changed.

Watch limit

Watchlist limit reached

You have reached your current active watch limit.