ZEISMO / SECURITYA practical guide from first setup to everyday checks, safe changes and recovery.
01 / WALKTHROUGH
Before changing protection, keep a recent backup and verify that you can reach your hosting control panel. Test changes on a staging copy when possible.
Open Setup. Read the Monitor-mode explanation, choose safeguards, choose alerts and privacy, and review the exact settings before applying. Moving between tutorial steps does not save anything.
Setup review is required when you first open ZEISMO Security after an update. Applying keeps the current firewall enabled status and Monitor or Block mode, access rules, category switches, proxy settings and two-factor enrollment. New installations start with Monitor defaults. Completion opens Overview; help and two-factor recovery remain accessible during review.
The optional first scan inspects eligible local files. A complete first scan creates a local comparison baseline; it does not establish that the files were safe beforehand. Skipping this immediate scan does not disable the daily schedule.
After applying, test a logged-out visit, login, contact form, search, checkout and any app integrations you use. Review Scanner and Activity before switching any firewall category to Block.
02 / WALKTHROUGH
Events (24h), Blocked (24h) and Critical (24h) count stored event groups from the previous 24 hours. Similar requests may be grouped; these are not unique attacker or visitor totals.
The timeline offers 24 hours, seven days or 30 days. Its range does not change the labelled 24-hour cards. The current mode tells you whether category enforcement is off, monitoring or blocking selected categories.
The WordPress toolbar score measures eight configuration checks: firewall enabled, login limiter, headers, public REST users, neutral errors, version exposure, disabled editor and absence of an admin username. It is not a safety certificate.
No events can mean no matching traffic, trusted-user testing, caching before WordPress, an inactive firewall or a collection problem. A refresh error means data is unavailable, not zero threats.
03 / WALKTHROUGH
Scanner reads wp-admin, wp-includes, plugin folders and theme folders. Eligible extensions are PHP, PHTML, PHP5, JavaScript, HTML, HTM and CSS. Each file must be readable, not a symbolic link and no larger than 2 MB.
The scan is bounded to 30,000 eligible files. Uploads, the database, root-level WordPress files, unsupported file types and individual skipped files are outside its reported coverage. Up to 500 findings and 100 recent file timestamps are saved.
Added, modified and deleted findings describe differences from your saved local hashes. Malware findings describe packaged pattern matches. Intentional updates and legitimate code can produce findings; never delete blindly.
An incomplete scan keeps the previous baseline. Fix access or execution limits with your host and scan again. Only trust current versions after checking the changes against a known-good source.
Open the printable scan report to print or save a PDF with your browser. It omits absolute server paths and file contents, but relative paths still reveal site structure. Keep the report private.
Daily scanning uses WP-Cron. On a quiet site, ask your host to arrange a dependable cron trigger. Scan completion depends on server resources; a scheduled event is not proof that a scan finished.
04 / WALKTHROUGH
Back up first, compare the file with a trusted vendor copy and involve a competent administrator if you cannot determine whether the match is legitimate.
Quarantine requires the host to configure ZEISMO_SEC_QUARANTINE_DIR as an existing writable directory outside every public document root. Direct filesystem access is required. The plugin does not create a safe server location automatically.
Only a currently selected malware finding in a plugin or theme can be moved. Core files, symbolic links, missing files and this active Security plugin are rejected. Quarantine can stop part of the website from working.
There is no restore or repair button. If you quarantined a legitimate file, your host or developer must restore it from a trusted source and check the site. Do not automatically accept a new baseline just to hide the incident.
05 / WALKTHROUGH
Monitor records qualifying suspicious requests without category-based blocking. Block enforces only an enabled top category when the score reaches the configured threshold. The default threshold is 70; allowed values are 20–100.
Categories are SQL injection, cross-site scripting, path traversal/file inclusion, command injection and vulnerability scanners. A scanner signature describes a suspicious client or request pattern, not proof of a successful vulnerability exploit.
Explicit address bans can block in Monitor mode. Trusted addresses and users with the edit_posts capability bypass the firewall. Normal admin pages, WP-Cron and command-line requests are excluded. Test public flows while logged out.
The engine runs inside WordPress and allows the request if its processing throws an error. It does not protect traffic served entirely by a cache/CDN, replace server patching or provide DDoS mitigation.
Choose Direct connection unless your host has verified the proxy arrangement. Cloudflare/proxy settings also require trusted proxy ranges configured through ZEISMO_SEC_TRUSTED_PROXIES. Never trust arbitrary forwarding headers.
If a legitimate visitor is blocked, note the route and reference, review Activity, then relax the affected category or return to Monitor. If an explicit ban is involved, changing Monitor alone may not help; contact your administrator to review the rule.
06 / WALKTHROUGH
Available new ban types are a single IP address, a CIDR range or a user-agent substring. Choose Log only to observe a match, or Block to enforce it. Duration choices are one hour, one day, one week or permanent.
Trusted addresses accept IP or CIDR and bypass firewall processing, including explicit bans. Use only addresses you control. Prefer temporary entries while testing.
Use Remove ban or Remove trust beside the relevant rule, read the confirmation and confirm. Removing a ban stops that rule from denying matching requests. Removing trust restores firewall checks for matching visitors. Changes are recorded in Recent security changes. Expired rules can also be removed.
Older records may contain country or score match types. This request pipeline does not supply those values to the ban matcher, so those records must not be relied on for protection. New setup does not offer these unsupported rule types.
Recent security changes shows a bounded history of selected administrative events. It is not an external, tamper-proof audit trail. Keep independent backups and server logs for incident investigation.
07 / WALKTHROUGH
The login limiter tracks failures by client address and username. The default is eight failures in a 15-minute transient window, renewed by failed attempts. A successful login clears that combination. Correct proxy configuration matters.
Two-factor enrollment is optional and applies to your own administrator account on a single-site HTTPS installation. Setup never enables it silently. Open Two-factor, confirm your current password, add the key and confirm a working code.
Save recovery codes immediately. Each is one-use with your password. Replacing codes invalidates the old ones and signs out other sessions; your setup session stays open. Five bad code attempts trigger a five-minute rate window.
Enrolled users cannot authenticate through application passwords or XML-RPC. Standard WordPress login is supported; custom login screens and SSO need separate testing. Check your integrations before enrolling.
If you lose both the authenticator and recovery codes, contact your hosting administrator. Deactivating the plugin stops this protection; changing WordPress authentication salts can require host-assisted re-enrollment. An old database restore may revive used recovery codes.
08 / WALKTHROUGH
Store IP addresses controls address storage in firewall and failed-login records. Turning it off affects future records; it does not immediately erase existing data. Hashed identifiers and other event metadata may still be recorded.
Mask addresses applies to future firewall event addresses only, not failed-login address records. Do not treat masking as complete anonymisation of all logs.
Event retention can be set from seven to 365 days, with 60 as the default. Scheduled maintenance deletes old firewall and failed-login records. Firewall event IP addresses are also cleared after 90 days; failed-login IP addresses follow the chosen retention period. Cron delays can delay deletion.
Critical-event email is optional. A newly logged event scoring at least 80 can produce a notice, with a one-hour duplicate-fingerprint cooldown. It uses the WordPress mail system; transport acceptance does not prove inbox placement.
Administrator/security-change email is a separate optional setting. It covers selected administrator, firewall/login and two-factor changes, with at most ten attempts per clock hour and a five-minute identical-notice cooldown. Failed sends are not retried.
Changing the notification address or disabling change alerts can notify the previous address, subject to sending limits. Do not enter an address you do not control. During setup, mail remains off unless you select the corresponding switches.
Local protection does not require a ZEISMO account. A private scan report is created locally. Email notifications leave through your configured mail service. This release does not activate cloud AI, reputation feeds or paid services.
09 / WALKTHROUGH
Browser headers add nosniff, SAMEORIGIN framing, a strict-origin-when-cross-origin referrer policy and a permissions policy denying camera, microphone and geolocation. Test embeds and device-dependent features before leaving this on.
Public REST user protection hides the standard logged-out user endpoints. Numeric-author protection returns a 404 for logged-out numeric author lookups. Neither hides all public author information.
Neutral login errors reduce information in error messages. Version reduction removes generator output but cannot conceal every version reference.
Disabling the built-in file editor is recommended for sites with controlled deployment. A constant already defined by your host can override the plugin choice; the current request cannot undo a constant it already loaded.
XML-RPC is left off as a blocking choice by default. Enable Disable XML-RPC only if remote publishing, Jetpack or other integrations do not need it. Saved changes may take effect on the next request and cached pages may need purging.
10 / WALKTHROUGH
Content Protection is a separate add-on included in existing Security Pro and higher plans, with no separate charge. It is not bundled into the free core. Download it from your Security account when available, install it separately, connect your account and verify Pro access before enabling visitor controls. This release is awaiting publication approval.
The master switch is off by default. Independent controls deter text selection, copy/cut actions, context menus and image dragging on eligible public pages. Only selected controls apply after Save changes.
Buttons, links, form fields, editable content, accessible interactive widgets and normal popups are exempt from interception. Test the real theme, menus, search, checkout and dialogs while logged out before enabling it for visitors.
Administrators, previews, feeds, API responses and recognised WooCommerce cart, checkout and account pages are excluded. You can add page IDs and path-prefix exceptions. A path prefix can exclude multiple URLs; review it carefully.
Changing the labelled sample preview does not save settings or prove compatibility with every theme. Save first, purge full-page/CDN caches and test a fresh logged-out window. Do not serve cached administrator pages to visitors.
This is casual copy deterrence, not DRM. Visitors can still use screenshots, page source, disabled JavaScript or other extraction tools. It does not establish copyright ownership or prevent determined copying.
Paid controls pause when the subscription is past due, unpaid, paused, expired, cancelled or otherwise ineligible. Scheduled cancellation remains valid until the paid period ends. Settings and free security remain intact; verified renewal resumes saved controls. Browser and WordPress checks run about every five minutes, with a maximum fifteen-minute cached lease. Connection failure cannot extend that lease. Purge page caches after changes; modified local code cannot be remotely guaranteed.
11 / WALKTHROUGH
After setup: test public pages and important forms, confirm your own login works and check the first scan result. Add two-factor protection only when you have prepared a recovery method.
Each week: review recent critical events and unfamiliar administrator changes, check Last scan is recent, review temporary access rules and verify your backup can be restored.
After updates: compare changed files with the expected release, test site functions and accept a baseline only after verification. A new update can be legitimate even when many files change.
Before changing enforcement: keep hosting access available, test one category at a time and review any affected customer journey. Do not deliberately attack a live customer site to test a rule.
12 / WALKTHROUGH
Use Contact ZEISMO support on any Security screen, or Ask ZEISMO for help in Scanner, to open a private conversation at app.zeismo.com/portal/security/support. Sign in or create a free account and verify your email. No paid plan is required. Submit your question, read replies while the page is open, or return to the same conversation later. Email notifications are not automatic. No site data, logs, files or credentials are uploaded by the plugin.
No activity appears: check the mode, use a logged-out visit, consider caching and remember that only qualifying suspicious requests are recorded. Normal traffic is not a traffic-analytics feed.
Scan incomplete or stale: check file readability, resource limits and WP-Cron with your host. A missing last-scan time means no saved result, not a clean scan.
Quarantine unavailable: configure private storage through your host. Do not choose a public uploads directory or move files manually without a recovery plan.
Email missing: verify the saved recipient, the alert switch, rate limits and your WordPress mail setup. Check spam and mail logs; a sent or accepted status is not confirmed delivery.
Settings appear unchanged: submit Save, refresh and check the stored switch. For header, version or editor changes, open a new request and purge relevant caches. Host constants can take precedence.
A normal request is blocked: distinguish a category decision from an explicit ban. Monitor affects category enforcement; trusted-address exceptions are broad and should be tightly limited.
Contact support@zeismo.com or online@zeismo.com. Include plugin/WordPress/PHP versions, the affected screen, approximate time and redacted error text. Never send passwords, authenticator keys, recovery codes, private tokens or unredacted security reports in a public support thread.
Included does not mean enabled. Some entries describe different uses of the same scanner or firewall. These local core controls need no paid plan.
01 / 52
Compares eligible WordPress core files with a locally saved baseline.
Run Scanner on a known-good site. After later scans, investigate added, modified or deleted files before trusting a new baseline.
Covers wp-admin and wp-includes. It does not download official WordPress checksums, inspect root-level files or prove the first baseline is clean.
02 / 52
Shows changes to eligible files inside installed plugin folders.
Scan before and after a planned plugin update. Compare unexpected changes with a trusted copy of that plugin.
Runs during scans, not continuously. An intentional update can produce legitimate findings.
03 / 52
Compares eligible theme files against the saved local baseline.
Scan after a theme update or an unexpected appearance change. Confirm intentional edits before accepting the current versions.
Does not inspect database-stored templates or certify a theme as malware-free.
04 / 52
Looks for packaged suspicious-code patterns in eligible local files.
Run Scanner, read each rule and file path, then ask a trusted developer to investigate uncertain matches.
Pattern matches are clues, not a diagnosis. Both false positives and missed threats are possible.
05 / 52
Flags selected PHP execution patterns involving request input or encoded code.
Review a flagged PHP file against its original vendor version before changing it.
Uses a fixed set of expressions; it does not execute the file or understand every PHP program.
06 / 52
Finds selected long encoded strings and decoding-plus-execution patterns.
Check why a plugin or theme contains the flagged encoding and whether the file matches its trusted source.
Encoding alone is not malicious. Other encodings and obfuscation can be missed.
07 / 52
Flags selected patterns often associated with remote command execution.
If an unexpected file matches, restrict access through your host and investigate the site with a security specialist.
Shares the local malware rules; it is not an exhaustive backdoor inventory.
08 / 52
Brings signature findings and baseline changes into one review list.
Start with unfamiliar files and changes outside your maintenance window. Keep a backup before remediation.
Only eligible files in the configured scan roots are examined. Empty results are not a clean-site certificate.
09 / 52
Records modification times for recently changed eligible files during a scan.
Use the baseline findings in Scanner to review changes; the saved scan also keeps up to 100 recent file timestamps for technical investigation.
The current screen has no separate recent-files viewer. Timestamps cover the previous seven days and can be changed; they do not establish when an intrusion occurred.
10 / 52
Records administrator creation and administrator-role grants in the local audit history.
Open Access rules and review Recent security changes for accounts you do not recognise.
This is event recording, not continuous account-behaviour analysis or automatic account suspension.
11 / 52
Records failed login attempts and supports the local login limiter.
Keep login limiting on in Settings. Ask your site administrator to inspect local login records when investigating repeated failures.
Failed-login records are stored separately; the Activity screen is the firewall event log, not a complete failed-login viewer.
12 / 52
Temporarily rejects repeated failed logins for an address-and-username combination.
Enable Limit repeated login attempts. The default threshold is eight failures; wait 15 minutes after the last failed attempt before trying again.
Depends on correct client-address detection. It is not a global distributed-attack defence and can affect users sharing an address and username.
13 / 52
Uses the local login-attempt limiter to slow repeated password guesses.
Enable the login limiter and add two-factor authentication to your own administrator account.
This entry describes the same limiter, not an additional independent protection engine.
14 / 52
Blocks unauthenticated numeric author lookups that can reveal a username.
Enable Block numeric author username discovery in Settings; test public author links afterwards.
Does not hide public display names, existing author pages or usernames disclosed by another plugin.
15 / 52
Disables XML-RPC methods and removes the pingback response header.
Turn on Disable XML-RPC only after checking whether mobile publishing, Jetpack or another integration needs it.
Can break integrations. It is off by default and is separate from firewall Monitor mode.
16 / 52
Removes the XML-RPC method surface when XML-RPC is disabled.
Use the Disable XML-RPC switch if none of your integrations depends on this endpoint.
This is the XML-RPC disable control, not a separate rate limiter for applications that keep XML-RPC enabled.
17 / 52
Removes the built-in plugin and theme code editors from the dashboard.
Keep this enabled when you deploy edits through a controlled development process. Reload the next request after changing it.
Does not prevent filesystem, hosting or deployment access. A host-level DISALLOW_FILE_EDIT setting can keep the editor disabled even when this switch is off.
18 / 52
Removes WordPress generator output that advertises the version.
Keep Reduce WordPress version exposure enabled and continue installing security updates.
Other assets or endpoints may still reveal a version. Concealing it is not a substitute for updates.
19 / 52
Adds browser headers for content sniffing, framing, referrers and device permissions.
Enable Send safe browser security headers, then test embedded pages and any feature using a camera, microphone or location.
SAMEORIGIN restricts cross-site framing. Camera, microphone and geolocation are denied by this header set. Server/CDN rules can override responses.
20 / 52
Removes public WordPress user-list and user-detail REST routes for logged-out visitors.
Enable Stop public REST API user enumeration. Check any public author directory or front-end app that uses these endpoints.
Logged-in access and other plugins may still expose account information.
21 / 52
Uses one neutral error message when WordPress rejects a login.
Enable Use neutral login error messages to avoid explaining which part of a login was wrong.
Changes the message, not password strength or the outcome of authentication.
22 / 52
Flags an account using the predictable username admin.
Review the Overview warning and manage administrator accounts through WordPress Users. Ensure another verified administrator works before changing access.
The warning does not rename or delete an account automatically.
23 / 52
Highlights administrator accounts without a recorded recent login.
Review the Overview warning with the account owner before deciding whether access is still needed.
Uses a 90-day threshold and locally recorded logins or registration age. Missing pre-installation history is not proof the person never logged in.
24 / 52
Summarises recorded firewall events, critical events and current mode.
Open Overview, check whether the firewall is Off, Monitoring or Blocking, and review Activity before changing enforcement.
Counts describe stored event groups, not unique attackers, visitors or every request to your server.
25 / 52
Shows how many of eight configuration checks currently pass.
Hover or open the Security item in the WordPress toolbar, then review the relevant settings.
A score of 100 is not proof a site is secure. It is a configuration checklist, not a penetration test or malware result.
26 / 52
Lets an administrator start a local file scan on demand.
Open Scanner and choose Run full scan. Wait for the request to finish, then review coverage, findings and last-scan time.
Large sites can hit file or server execution limits. An incomplete scan should never be treated as full coverage.
27 / 52
Can notify a selected address about newly recorded critical firewall events.
Enable critical-event emails in Settings and choose an inbox you monitor. Review the corresponding Activity entry when a notice arrives.
Uses the site mail system. Repeated notices for the same event fingerprint are suppressed for one hour; delivery to an inbox is not guaranteed.
28 / 52
Shows time-bounded patterns in the recorded firewall activity.
Use Overview for totals, categories, targeted routes and the activity timeline; use Activity for event details.
The timeline range does not change the four labelled 24-hour summary cards. Repeated event records may be grouped.
29 / 52
Registers a daily local scan through WordPress scheduling.
After activation, check that Last scan advances. Ask your host to check WP-Cron if a low-traffic site stops running scheduled work.
WP-Cron depends on requests or a configured system trigger. A daily schedule is not an exact delivery time or real-time monitoring.
30 / 52
Applies the additional packaged patterns used by the same local scanner.
Review the named rule for each finding and compare suspicious code with a trusted vendor copy.
This build has eight fixed pattern rules, not a cloud intelligence feed or continuously updated signature subscription.
31 / 52
Uses suspicious-code patterns as practical investigation clues.
Review the context of a finding instead of deleting a file just because a pattern matched.
The heuristics are fixed rules, not AI reasoning, sandbox execution or guaranteed malicious-behaviour detection.
32 / 52
Inspects eligible JavaScript files with the packaged pattern rules.
Investigate unexpected redirect code and compare it with the intended behaviour of the site.
Does not run JavaScript or inspect every script delivered dynamically, remotely or from the database.
33 / 52
Looks for a small set of spam-related words near link markup in eligible files.
Check a flagged file and compare rendered content with the content you intentionally published.
Database content is not scanned. Legitimate writing may match, and many spam techniques fall outside these patterns.
34 / 52
Flags selected JavaScript assignments that redirect to an external URL.
Verify the destination and why the redirect exists before deciding whether to remove it.
A normal payment, login or navigation redirect can match. Server, database and other redirect mechanisms may be missed.
35 / 52
Flags selected external iframes that appear hidden in eligible source files.
Review the iframe destination and compare the file with a trusted version.
Hidden iframes can be legitimate. Visible, dynamically created or differently hidden frames may not match.
36 / 52
Looks for selected upload-and-command-execution patterns.
Treat an unfamiliar matching file as an investigation priority and involve your hosting administrator.
A fixed pattern match does not confirm a webshell, and absence of a match does not rule one out.
37 / 52
Moves a selected reported suspicious plugin or theme file into private server storage.
Ask the host to configure private quarantine storage first. Back up the site, verify the finding and choose Quarantine for an eligible malware finding.
Can break the affected plugin or theme. Core files and this active Security plugin cannot be moved by this action. There is no automatic repair or restore button.
38 / 52
Adds authenticator codes to your own administrator login after explicit enrollment.
Use Two-factor over HTTPS, confirm your password, add the setup key to an authenticator and verify a fresh code. Save the recovery codes immediately.
Single-site standard WordPress login only. Existing application passwords and XML-RPC authentication are blocked for enrolled users; custom login and SSO need compatibility testing.
39 / 52
Provides one-use alternatives when your authenticator is unavailable.
Keep the codes in your password manager or offline. Sign in with your password and one unused recovery code.
Each code works once. Replacing the codes invalidates the old set and signs out other sessions. Restoring an old database backup may restore previously used codes.
40 / 52
Blocks or logs matching addresses or ranges until a chosen expiry.
In Access rules, choose IP address or CIDR, enter a value you have verified, and select one hour, one day or one week.
A block rule can act even in Monitor mode. Addresses can be shared or change; broad ranges can affect legitimate visitors.
41 / 52
Keeps an explicit address restriction active without an expiry.
Use a permanent rule only when the target and impact are understood. Review the rule and its hit count regularly.
Remove ban stops enforcement by that rule after confirmation. The removed rule remains visible for review; other protections still apply.
42 / 52
Lets a trusted address or CIDR bypass this plugin's firewall evaluation.
Add only verified addresses you control in Trusted addresses, preferably with a short expiry.
The exception also bypasses explicit firewall bans. Remove trust restores normal firewall checks. Logged-in administrators and editors keep their built-in exemption; WordPress authentication and the separate login limiter remain unchanged.
43 / 52
Keeps a bounded local history of selected account and security actions.
Review Recent security changes under Access rules after a scan, baseline acceptance, quarantine or administrator change.
The view shows recent records, not a complete forensic history of all WordPress actions or a tamper-proof external archive.
44 / 52
Examines selected requests after they reach WordPress and records suspicious signals.
Start in Monitor, test normal visitor journeys, then enable Block mode for the categories you have reviewed.
Not an edge firewall or DDoS service. Trusted users/addresses, normal admin requests, cron and CLI are excluded; an internal firewall error allows the request through.
45 / 52
Scores selected request patterns associated with SQL injection.
Review SQL injection events, then enable its category in Block mode if the observed traffic warrants it.
Blocking also requires the risk threshold. Pattern inspection does not fix vulnerable application code.
46 / 52
Scores selected suspicious script and markup patterns in request input.
Test forms and content-submission tools before enabling the XSS category in Block mode.
Legitimate HTML can resemble an attack. It does not scan stored database content or guarantee protection against every XSS technique.
47 / 52
Checks selected request patterns that can indicate an attempt to execute commands or code.
Review the event context before enabling Command injection in Firewall.
Shares the command-injection request rules. It is not a patch for a vulnerable plugin or an operating-system sandbox.
48 / 52
Checks selected path and wrapper patterns associated with local file inclusion.
Review related events and enable Path traversal & file inclusion only after testing normal site requests.
Shares the traversal category and does not change filesystem permissions or repair vulnerable code.
49 / 52
Looks for selected suspicious file-wrapper and inclusion patterns in requests.
Use the Path traversal & file inclusion category and keep WordPress, plugins and themes updated.
Shares the traversal rules; not every external URL or remote inclusion technique is detected.
50 / 52
Scores attempts to reach unintended paths using selected traversal patterns.
Inspect the affected route and test legitimate download or file-selection flows before enforcing the category.
Patterns and normalisation are bounded. A matching request is evidence to review, not proof a file was accessed.
51 / 52
Scores selected shell-command patterns in incoming request input.
Enable the Command injection category only after reviewing its Monitor-mode findings.
Shares rules with the remote-code-execution label. Detection is not operating-system process monitoring.
52 / 52
Combines weighted request signals into a risk score from 0 to 100.
Review event categories and scores. In Block mode, an enabled top category and a score at or above the threshold are required for category enforcement.
This is deterministic rule scoring, not behavioural AI or a probability that an attacker succeeded. Signals below 20 are not recorded as firewall events.