Security Center and telemetry
The Security Center in AACP is a single menu and has six separate screens under it. The menu itself does not go to a page; it only opens.
| Menu entry | What it shows |
|---|---|
| Overview | Security score, IP bans, open sessions, two-factor authentication, login code by email |
| Live threats | Attack attempts caught by telemetry, a "Ban" button |
| Audit findings | SecurityAuditor's configuration findings and score |
| Security settings | The Security tab of System Settings |
| Telemetry settings | Telemetry on/off and retention periods |
| Malware scanner | File system scan |
Telemetry has two modes
Telemetry keeps a light record for every request; writing is done after the response is sent (kernel.terminate), so it is not added to the visitor's wait.
- Visitor mode: page views, unique IPs, popular paths, traffic chart. This is the default.
- Security mode: when the
telemetry.security_enabledsetting is turned on, every request additionally passes throughThreatAnalyzer. It is off by default; while off, the Live threats screen shows only configuration recommendations.
ThreatAnalyzer is signature-based: it looks for SQL injection, XSS, LFI / path traversal (../) and known attack tools; it also scores noise aimed at login paths. Three details prevent false alarms:
- Authoring fields are exempt from body scanning: staff text fields such as
body,contentandexcerptare not scanned (output passes through text format filters, SQL is parameterized; these are not injection points). Forum topic and reply submissions are exempt in the same way. - Staff areas are handled separately: the rule set is different for POSTs under
/admin/and/aacp/. - Admin screens that save content and code are exempt from scanning for a signed-in administrator: doc page and translation saves, the module editor and the theme editor (POST only, an exact route list
RequestGuardSubscriber::ADMIN_CONTENT_SAVE_PATHS). Because--lines and code samples in Markdown resemble SQL/XSS signatures, without this exemption the site owner could be banned by a false alarm. The ban list is checked first for these requests too; no other path is exempt.
Retention periods
Records are kept for different periods depending on severity, and a cron job deletes the old ones:
| Severity | Default period |
|---|---|
| Info | 3 days |
| Warning | 7 days |
| Critical | 30 days |
| Threat | 90 days |
The periods change from the Telemetry settings screen (telemetry.retention_*).
IP bans
The Ban button on the Live threats screen appears only on records of critical and threat severity. IpBanService writes the IP to the cp_banned_ips table; the request guard (RequestGuardSubscriber) rejects later requests early, so a banned IP never runs the rest of the application. Bans are listed on the Overview screen and removed from there.
The allowlist takes priority: addresses in security.ip_allowlist are not affected by any ban and cannot be automatically banned. In addition, the IP of a signed-in administrator (AdminIpAllowlist) carries the same exemption for the duration of the session: it is added on sign-in, deleted on sign-out, and if there is no sign-out it drops 30 minutes after the administrator's last request; it is written to the cache, not the database.
A quick fix for someone banned by mistake (from the panel, by SQL in the database, from the recovery console): explained step by step on the "Security and IP blocks" page of the module documentation.
Audit findings
SecurityAuditor reviews the configuration (strong password rules, two-factor authentication, headers, settings…) and produces a score. Every finding has a severity and a recommended fix. This is the security-focused counterpart of cp:doctor's site-wide checks.
Malware scanner
MalwareScanner scans files rule by rule. The rules cover encoded eval chains (eval(base64_decode(...)), gzinflate(base64_decode(...))), calls that execute request data (eval, system, exec, include with $_REQUEST), known web shell names, obfuscated chr() and hexadecimal escape sequences, tampering with disable_functions and very long base64 blocks; each rule has a severity (high, medium, low). Files with double extensions and executable files in the upload folder are flagged separately. For very large files only the beginning and the end are read, so that a single file does not consume memory. The scan proceeds batch by batch as a job; there is a progress bar and it can be cancelled. There are four actions for every finding: ignore (a false alarm; goes quiet for the same file, same rule and same content digest), quarantine, restore from quarantine and permanently delete from quarantine. If the content changes, the ignore becomes invalid and the finding appears again.
A signature-based scanner catches known patterns. A clean result does not prove the site is safe; do not neglect your backups and updates.
Recovery console
When the database or the firewall breaks, the way into the admin panel is the /aacp/recovery address. It makes no database query; it is protected by AACP_RECOVERY_TOKEN in .env. If the token is empty the console is closed; cp:doctor reports this as a warning, because a closed console means "no way back". Choose the token long and random.
Which permission
The Security Center screens require the system.security.manage capability; the Telemetry settings and part of the Overview open with system.aacp.access. Give these only to administrators you trust.