Cisilino Site Defense Network

Description

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).

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).

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.

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.

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.