Cisilino Site Defense Network

Cisilino Site Defense Network watches failed login attempts on your
WordPress site. Once an IP exceeds a configurable threshold, it gets
blocked locally by adding a rule to the site’s .htaccess file
(compatible with both Apache 2.4 and 2.2).

Documentation: guides for every feature (in Italian) are published at
https://www.cisilino.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
flagged, including double extensions such as “harmless.php.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
wp-config.php, for a time you choose (1 hour, 24 hours or 7 days). It
adds to debug.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
to .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
folder inside uploads, protected by .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,
  debug.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
headers (via WordPress, not .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
  live in .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
(https://cisilino.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.