Security & Hardening

A server is most exposed not when something attacks it, but when it quietly drifts: a firewall left open, a password login no one disabled, a certificate that expired last week, a mail server that will relay for anyone. FrontierStack treats hardening as a continuous, observable state rather than a one-time checklist. The Security pane is your console for the host in front of you; the AI Administrator (Chapter 13) carries the same checks across your whole fleet over SSH. Everything here is read-only until you ask for a change, and every change is one you could make by hand.

10.1The firewall: Application Firewall and pf

macOS ships two firewalls and FrontierStack reads both. The Application Firewall (ALF) is the per-app layer you set in System Settings; the Security pane reports its state — enabled, stealth mode, block-all-incoming, and how many app rules exist — so you can confirm at a glance that it is on. The pf packet filter is the lower, port-level layer, and this is the one FrontierStack manages directly.

App-managed pf rules live in their own file, ~/Library/Application Support/FrontierStack/pf-frontierstack.conf, loaded into a dedicated frontierstack anchor that is wired idempotently into the system /etc/pf.conf. Keeping rules in their own anchor means FrontierStack never edits Apple's base ruleset and your rules survive a reload without trampling anything. Adding or removing a rule reloads pf through an authenticated admin prompt.

From the AI side, the firewall_rule tool adds or removes a single allow/deny rule for a port, optionally scoped to a source address. It detects the target's operating system first: This Mac and remote macOS hosts get pf (the frontierstack anchor); Linux servers get ufw. It never sends a ufw command to a Mac or a pf rule to Linux.

10.2Intrusion prevention and the open-ports watch

An open port that has to stay open still needs a guard. The Security pane integrates two intrusion-prevention engines. fail2ban bans IP addresses that match abusive log patterns — SSH and Apache brute force are the classic cases; the pane shows whether it is installed and running, its jail count and how many addresses are currently banned, with a one-click Reload and a "write a starter jail.local" action that drops in a sane SSH jail without overwriting your overrides. CrowdSec adds a shared reputation network on top, showing its active decision count and a Metrics button. Both run as root services installed via Homebrew.

The Open Ports section lists every listener on the host. A companion watch — remote-control and screen-sharing exposure — specifically flags VNC/Screen Sharing (:5900), Apple Remote Desktop, AnyDesk, TeamViewer, Chrome Remote Desktop, Splashtop, RustDesk and Tailscale exit-node advertising, and turns red when someone is connected right now. The Recent Intrusions and Active Bans sections aggregate detections from fail2ban.log, CrowdSec, Suricata's eve.json and Wazuh's alerts.json, newest first; sources you do not run are simply skipped. A new ban, a new listener or an active inbound session can each raise an alert — configure delivery in Chapter 11. The same section checks FileVault on this Mac, judged by what the Mac holds: if it is off while the Mac has SSH access to linked servers or the app-managed SSH key, the row turns red and an alert is raised, because a lost or stolen laptop would give up the keys to your whole fleet. A Mac with no fleet credentials is left alone.

10.3SSH hardening

SSH is the single most valuable door on most servers, so the Security pane includes an SSH Hardening Audit. It reads the effective configuration with sshd -T — not just the file on disk, but what the daemon actually applies after its drop-ins — and flags the settings that matter: PermitRootLogin, PasswordAuthentication, and the rest. When SSH is reachable from the network the pane says so plainly, because that is exactly where the findings matter.

The baseline for an internet-facing host is key-based authentication with PasswordAuthentication no. Apply fixes by editing /etc/ssh/sshd_config.d/ rather than the main file, so package updates leave your hardening intact. FrontierStack's own fleet channel already follows these rules: it uses Ed25519 keys, BatchMode=yes, IdentitiesOnly=yes and host-key trust-on-first-use recorded in known_hosts (Chapter 8). If a host's key access breaks, the repair_ssh_access tool reinstalls the managed key using a one-time login password held in your local vault — the password is read on your Mac and never sent to the AI.

10.4Server Security: the posture check for a remote host

Everything above describes the Security pane for this Mac. The Server Security pane is its counterpart for a linked server: the same posture check, read over SSH, for any host in your fleet. Open a server's detail and click Check… beside Security, or open the pane directly and pick a server from the host menu. A single scan reports the SSH hardening that matters (PermitRootLogin, PasswordAuthentication, the listening port), whether a firewall is present and enabled (ufw, firewalld, nftables or raw iptables), the intrusion-prevention engines running (fail2ban, CrowdSec), the count of pending security updates (apt, dnf, yum), every service listening on all interfaces, and host-integrity smells — world-writable directories missing the sticky bit, unexpected SUID binaries.

Each finding is scored High · Warning · Info · OK and rolled up into a one-line summary badge, so you can sweep a fleet and see at a glance which host needs attention. The pane never changes anything: a Fix it link takes you to the pane that actually makes the change — the Server Firewall pane to enable a firewall or edit rules, the Remote Tools SSH-hardening review, or the security tools that install fail2ban/CrowdSec. It reads deepest as root or with password-less sudo; without either it runs what it can and tells you so. Cross-links run both ways: the local Security pane links to macOS Firewall, Server Security links to Server Firewall, and a pinned server's panes link to both.

10.5Security updates and breach warnings

The Security Updates pane (Security Tools) lists, for this Mac and every linked server, the security fixes that are waiting. Each server reports its own: apt's -security pocket on Debian and Ubuntu, dnf or yum advisories with their CVE numbers on Red Hat–family systems, zypper security patches, FreeBSD's pkg audit, Alpine updates checked against OSV.dev, and Software Update on a Mac. Homebrew doesn't mark security fixes, so its outdated formulae are listed separately. The check reads only, every six hours, as root where a sudo password is saved; the one thing it changes is apt's package lists when they are over a day old. Linux and FreeBSD servers with a Host Monitor (1.28 or later) run the same check themselves and report through it, with no SSH session or sudo password; Macs are always checked over SSH.

Urgency comes from public sources. A waiting update that fixes a CVE on CISA's Known Exploited Vulnerabilities list turns the server red and alerts at once. OSV.dev supplies the CVEs behind Debian, Ubuntu and Alpine updates; FrontierStack sends it package names and versions only. endoflife.date flags operating systems and runtimes that no longer get fixes (a distribution's own PHP or Python is left to the distribution, which backports fixes). Enfour patch advisories, signed like the breach advisories but with a key of their own, cover urgent cases with the fixed version for each branch. Routine security updates alert only after they have waited longer than you choose, seven days by default.

Automatic Updates… on a server's row opts it in to security-only updates inside a maintenance window: apt installs only security-pocket packages and keeps your configuration files, dnf and yum use --security, zypper installs security patches, FreeBSD upgrades what pkg audit reported, Alpine what OSV lists, and a Mac only the Homebrew formulae an Enfour advisory names (as your user). Each window runs once. Before a run FrontierStack checks free space on /var; afterwards it reports any service that stopped. You can also let fixes for exploited vulnerabilities install straight away, and on a Mac require a recent Time Machine backup first.

Breach warnings come from the same signed source as KeyRotate's. When a service people paste API keys into is breached, Enfour publishes an advisory; FrontierStack checks twice a day, verifies the signature, recognises sites built with the service from their pages, shows the vendor's checklist in that service's pane and keeps a Security alert open until you mark it dealt with. The alert also fires when the affected software is installed on this Mac or reported by a server. KeyRotate knows which keys you saved in the service and helps you replace them.

10.6Edge Appliances: NetScaler, BIG-IP and the VPN gateways

The appliances on your perimeter — Citrix NetScaler ADC/Gateway, F5 BIG-IP, FortiGate, Palo Alto PAN-OS, Ivanti Connect Secure, Cisco ASA/FTD, Kemp LoadMaster, SonicWall SMA and SonicWall firewalls — are where most large intrusions of the last few years began: CitrixBleed, the 2026 NetScaler zero-days, the FortiOS SSL-VPN bugs, GlobalProtect, Ivanti's 2024–25 chain, ArcaneDoor, the SonicOS SSL VPN flaw behind the Akira and Fog ransomware attacks. The Edge Appliances pane (Routers & Firewalls, and inside each vendor's catalogue pane) keeps asking the questions those campaigns turned on.

For each appliance it reads the running version and checks it against the vendors' own bulletins, exploited-in-the-wild first, taking into account the features actually switched on — a CVE that needs a Gateway virtual server or DTLS is marked affected but not in use only when the configuration proves the feature is absent; when it can't tell, it assumes the worst. It flags end-of-life branches, configuration the attackers relied on (management on data-plane or WAN interfaces, SSLv3/TLS 1.0, default SNMP communities, no remote logging, unencrypted config secrets, admin accounts with names from attacker playbooks), and the health of virtual servers, HA pairs and certificates. Every finding names the fixed version and the advisory, and lists the vendor's post-upgrade steps, such as NetScaler's session kills after CitrixBleed.

Connecting. Use a dedicated read-only account — a NITRO user bound to the read-only command policy, a BIG-IP Auditor, a FortiOS API user with a read-only profile, a PAN-OS “Superuser (read-only)” key, an Ivanti read-only administrator, a Kemp key with no write rights. Cisco ASA/FTD and SonicWall SMA have no safe read API, so you type the version. Credentials go only over HTTPS and only after the appliance proves who it is: a publicly trusted certificate, or a self-signed one whose fingerprint you compared with the console and approved. If an approved certificate changes, FrontierStack sends nothing and raises a critical alert.

SonicWall firewalls. The TZ, NSa, NSsp and NSv firewalls run SonicOS, and for most of their owners they are the SSL VPN as well (catalogue entry SonicWall Firewall). Add one either way: type the firmware version, or enable the SonicOS API (RFC-2617 Basic authentication) so FrontierStack can also read the model, serial number, WAN-side management and SSL VPN settings. SonicOS lets only full administrators use its API, so there is no read-only account to create; FrontierStack logs in without pre-empting an administrator who is using the web UI, and logs out after every check. The version is checked against SonicWall's PSIRT advisories, exploited CVEs first — CVE-2024-40766 (improper access control in management and SSL VPN, used by Akira and Fog ransomware), CVE-2024-53704 (SSL VPN session hijack) and CVE-2020-5135 (an HTTP request buffer overflow). Two checks are specific to SonicWall. The hardware model's end of support is tracked separately from the firmware: every Gen 6 model is now past it, however current its 6.5.5 firmware. And a reminder asks you to look in MySonicWall ▸ Product Management ▸ Issue List for the firewall's serial number, because configuration backups stored in MySonicWall's cloud were exposed in September 2025; if it is listed, or you can't tell, follow SonicWall's Essential Credential Reset.

Patched is not clean. For a CVE that was exploited before most people patched, a fixed version keeps a reminder — run a compromise check, rotate the credentials the box held, end old sessions — until you mark it handled. For NetScaler and BIG-IP, link the appliance to a fleet server whose SSH host key you have verified and run the compromise scan: a fixed, read-only script built from CISA, Mandiant, Citrix and F5 indicators. A scan that is cut short, or that lacks a tool, says so; it is never shown as clean.

10.22.1Riverbed SteelHead and SD-WAN gateways

WAN optimizers and SD-WAN gateways sit at the edge too, and they're managed as a fleet, so Edge Appliances covers them. A Riverbed SteelHead, Interceptor or SteelCentral Controller (SCC) connects through the RiOS REST API with a REST access code (Administration ▸ Security ▸ REST API Access ▸ Add Access Code), which FrontierStack exchanges for a short-lived token on every check. It shows model, serial, RiOS version and whether the optimization service is running. Add the SCC rather than each box: one entry then lists every SteelHead the SCC manages with its health and connection, and Alerts fires when one becomes degraded or critical. A single SteelHead's health and alarms aren't in its REST API; read them by SNMP with the Riverbed SteelHead template in Devices, and watch the Health OID there if you want an alert.

Riverbed SteelConnect EX SD-WAN gateways are read through the Versa Director that manages them, at https://director:9182 with a read-only Director account: every organization's gateways with reachability, services status, config sync and critical alarms. Type the Director's release as its version. FrontierStack carries no fixed-version advisory tables for Riverbed or Versa, so the pane says that plainly rather than reporting “no advisories”; CISA's exploited list is still checked against them — it includes CVE-2024-39717, the 2024 Versa Director zero-day.

No longer sold, still monitored. SteelConnect CX — the SDI-130, SDI-330, SDI-1030, SDI-2030, SDI-5030 and SDI-USB gateways, SDI switches and access points, virtual gateways in AWS and Azure — and SteelHead SD (570-SD, 770-SD, 3070-SD) left Riverbed's price list in 2020 but run in plenty of branches. Add the SteelConnect Manager realm that manages them (https://yourrealm.riverbed.cc, or an on-premises SCM) with an SCM account that has REST API access: each check lists every appliance with its model, site and whether SCM sees it online, and Alerts fires when one goes offline. Cloud SCM is Riverbed's public service, so its address isn't treated as an exposed management interface. A medium lifecycle finding links Riverbed's end-of-support notice until you mark it noted; add a SteelHead SD's optimization side as a Riverbed SteelHead entry as well.

10.22.2VPN concentrators and the Citrix estate

The Show switch at the top of the pane narrows it to VPN Concentrators or to Citrix. Besides the gateways above, it covers Check Point Quantum (type the Gaia train and Jumbo Hotfix Take, for example R81.20 Take 166; a fw ver build number is not a Take and never counts as patched), WatchGuard Firebox, Zyxel ATP / USG FLEX, Array AG, OpenVPN Access Server, Juniper SRX, Sophos Firewall and Barracuda CloudGen. Where an appliance's API reports it (NetScaler Gateway today), the summary shows connected VPN users and a finding appears when they reach 90% of the licensed limit.

For Citrix, NetScaler Console and NetScaler SDX are read over NITRO with a read-only account; an SDX also has the NetScaler build of every VPX instance it hosts checked against the bulletins. XenServer / Citrix Hypervisor is read through XenAPI on the pool coordinator with a read-only account, and Virtual Apps and Desktops, ShareFile StorageZones Controller and Citrix SD-WAN take a typed release. NetScaler itself now also reports whether SAML is configured (the precondition for the October 2026 bulletins), unsaved configuration, a licence close to expiry, full disks and NTP sync switched off.

VMware host hardware. Add a vCenter Server to watch every ESXi host it manages, or a single ESXi host, with a user holding the built-in Read-only role (approve the host's self-signed certificate in the pane). Each check reads every host's fan, power-supply, temperature, memory, CPU and storage sensors and its connection and maintenance state; a yellow or red sensor, or a disconnected host, raises an alert. Sensors that report no health state are listed but never alerted on, and installing the server maker's CIM providers (Dell, HPE, Lenovo images) gives fuller hardware health. Hosts in lockdown mode refuse direct logins unless the user is on the exception list, so add vCenter instead.

10.7Rogue Device Watch: a hidden mail sender on your network

In August 2025 a couple checked into a hotel in Kobe, connected a computer to the room's network, hid it in a corner and checked out. An accomplice controlled it remotely and sent several hundred thousand phishing mails through the hotel's internet line, so the mail appeared to come from the hotel. The Rogue Device Watch pane (Routers & Firewalls) exists to catch that kind of box. Your Mac cannot see it: guest Wi-Fi isolates clients, and device discovery only sees the Mac's own segment. The router sees every connection, so FrontierStack asks the router.

Outbound mail. Every 10 minutes, for each pinned router with API credentials (OPNsense; pfSense with the REST API v2 package; MikroTik RouterOS; OpenWrt), FrontierStack reads the connection table and keeps, for each internal device, the set of external mail servers it has talked to in the last hour. Port 25 is server-to-server SMTP: a laptop never needs it, a mail server or a spam bot does. Mail apps send through their own provider on 587 or 465, so those ports only count when a device reaches an unusually wide spread of providers. A device that isn't an approved mail server and reaches 5 or more servers on port 25 (adjustable in the pane) raises a Hidden mail sender alert in the Security group. The alert gives its IP, plus the MAC address and hostname from the router's DHCP leases, and the steps: find it by its MAC (the lease list, then the switch port or access point it hangs off), disconnect it, block outbound TCP 25 from guest and LAN networks except your mail server, and check whether your WAN address has landed on a spam blocklist. One stray connection is listed under the router, but never alerts.

Approved mail servers are entered as an IP address, a range or a MAC address, and never alert. Servers you manage in FrontierStack that run Postfix, Exim, Dovecot or another mail service are offered as one-click suggestions. A scanner that e-mails scans directly is the other usual entry.

Devices that never leave. Under each router, mark its guest networks: pick a name the router reports (an interface, DHCP server or UniFi network) or type an address range. Then turn on Flag devices that never leave a guest network. A client that stays online there for more than 7 days (adjustable) without a break raises a Long-stay guest device alert, because guests come and go. Presence is measured between scans, so a Mac that was asleep or closed never breaks a stay or invents one. The hotel's own equipment on the guest network, such as a smart TV or a room thermostat, is cleared with Acknowledge. The check is off by default.

Policy advice. On OPNsense and pfSense, once a guest network is marked, its firewall rules are read once a day to see whether that network can open TCP 25 to any server on the internet. If it can, the pane recommends a block rule above the one that allows internet access: guests' mail apps keep working on 587 and 465, and a hidden mailer can no longer send. Open Firewall Rules takes you to the router's own page. When an alias decides the answer, or the API shows no rules for that network, the pane says it couldn't tell rather than guessing.

10.8The LAN Compromise Check: a device that has been taken over

On a switched network only the router sees every device's internet connections, so the check reads the connection table of each router Rogue Device Watch can read (OPNsense, pfSense, MikroTik RouterOS, OpenWrt) — on Check now, or every two minutes with Watch the network continuously — and keeps six hours of who connected where. It flags beaconing (new connections to one address on a steady timer), connections to addresses with no domain name on non-web ports, contact with addresses on public threat lists (abuse.ch Feodo Tracker, Spamhaus DROP, Emerging Threats, CINS Army; Tor exits as a weaker sign), unexpected inbound connections from the internet, scanning of remote-login ports, and proxy-like fan-out. Each device gets a worry score out of 100, a plain-language explanation and steps for its own router to cut its internet, move it to a quarantine VLAN or take it off the network — each a rule or network for that device alone. Mark your own port forwards Expected and addresses you know Trust. High and critical devices raise an alert; the AI Administrator ranks and explains them with security_audit scope=lan_compromise. Smart devices check in with their maker's cloud too, so one signal is a reason to look, not proof.

10.9Printer privacy & security audit

A printer's device page has Run privacy & security audit. It asks the printer only what any computer on the network could: make, model and firmware (IPP, SNMP with the factory community, its web page), which services answer, whether its settings pages want a password, whether it hands out its job history with document names, whether it holds stored jobs, faxes or scans, and whether it uses a maker's cloud service. It tests your public address from outside on the printer's ports (through Globalping; switch it off if you prefer) and lists CVEs that mention the model. Every exposing setting is ordered by risk, followed by click-by-click steps for HP, Brother, Epson and Canon to set a password, wipe stored jobs, close remote access and turn off unused services. Nothing on the printer is changed. The AI Administrator runs the same audit with security_audit scope=printer.

10.10Deeper forensics tooling

When a quick scan is not enough, the heavier analysis lives as installable services in the Security Tools catalog category — reveal them with the catalog filter (Chapter 6). Volatility 3 is a memory-forensics framework for examining a RAM capture; capa identifies the capabilities hidden inside an executable; the CAPE and Cuckoo sandboxes detonate a suspicious sample in isolation and extract its configuration and behaviour. Threat-intel services such as URLhaus, OpenPhish and OpenCTI feed your YARA and sandbox rules. SIEM platforms such as Wazuh have their own SIEM & Security Data section, described below.

10.11The EDR Fleet board

If your endpoints already run a commercial EDR agent, the EDR Fleet pane gives you one read-only roll-up across every console. Choose Add Console…, pick a provider and paste its API credentials — stored in the Keychain, never in the AI's view. Endpoint and open-detection counts are pulled from each vendor's REST API for SentinelOne, Huntress, CrowdStrike, Sophos Central, Bitdefender GravityZone and Microsoft Defender for Endpoint; Jamf Protect and LimaCharlie connect for reachability, and any other console can be added as Generic (reachability only). A Fleet totals row sums the lot. The board refreshes every few minutes; a console going unreachable raises an alert under the Security group, with its open-detection count riding along in the alert detail. Open Console jumps you to the vendor's own dashboard for the deep work.

10.12SIEM & Security Data

The SIEM & Security Data sidebar section separates a security-operations workflow that used to be scattered between Security Tools and Logging. Its SIEM Overview answers the first fleet question: which security platforms and data paths does FrontierStack know about, and are their watched management endpoints reachable? A row becomes configured only when the app has concrete evidence — a saved API credential, a detected local install, or a remote endpoint watch. A saved key is labelled Credentials saved, not Connected; a TCP response is labelled Reachable, not Healthy. This distinction prevents a listening but broken or unrelated service from receiving a false green status.

The section has two layers:

• SIEM platforms — Wazuh, Security Onion, Splunk, Elastic Security, Microsoft Sentinel, Google Security Operations, Graylog, IBM QRadar, Sumo Logic Cloud SIEM, Rapid7 InsightIDR, LogRhythm, Devo, FortiSIEM and OpenText ArcSight.
• Security-data pipelines — VirtualMetric DataStream, Cribl Stream, Logstash, Vector, Fluent Bit, Fluentd, NXLog, syslog-ng and OpenTelemetry Collector. These collect, normalize, filter, buffer and route telemetry; they are not themselves necessarily the place where an analyst hunts an incident.

Open a service to choose the right setup. A cloud-only SIEM shows a Connect area for its account/tenant and least-privilege API token, stored in the macOS Keychain, with no meaningless local Install button. A self-hosted or hybrid platform offers its vendor deployment path and a Remote Instance watch for the management console. Collectors with a real Homebrew formula can be installed and controlled locally; Linux/Windows agents and appliances link to their supported packages instead of pretending to be Mac services.

Sources & coverage links the layers rather than merging them. Use EDR Fleet for endpoint-console coverage, Security for host/network detections and intrusion prevention, and Logs for local troubleshooting. The SIEM destination owns full event retention, correlation, hunting and incident response. FrontierStack remains the health and control plane: it keeps credentials local, checks the pieces it can prove, alerts on lost reachability, and takes you to the correct console for the deep work.

10.13Read-only security audits

The fastest way to learn where a host actually stands is the AI's security_audit tool, which runs a comprehensive, entirely read-only sweep on This Mac or any linked server over SSH. It self-detects the OS and checks pending security updates, disk encryption (FileVault or LUKS), the firewall (Application Firewall + pf on macOS, ufw / iptables on Linux), SSH hardening, listening ports, UID-0 and privileged accounts, passwordless-sudo (NOPASSWD) entries, intrusion prevention and recent failed logins. It uses passwordless sudo only where it is available and degrades gracefully where it is not. Nothing changes; you get a prioritised list of findings and specific fixes, which you can then apply yourself or hand back to the AI behind the usual approval card. Set target to a server's name to audit it remotely; omit it for the local Mac.

10.14The Security Audit pane: an exploitable-only auditor in a sandbox

The read-only security_audit sweep above tells you how a host is configured. The Security Audit pane asks a harder question: what here can an attacker actually exploit? It turns a coding agent into an adversarial auditor that maps the target, hunts from many angles — injection, broken access control, authentication and authorization, business logic, cryptography, exposed secrets, SSRF, misconfiguration and chained attacks — then tries to disprove each of its own findings, so what survives is only the issues with a concrete attack path. Every finding carries a scenario and a fix; there is no theoretical noise.

It runs in two modes. Codebase points the agent at a repository or web-project folder and audits the source. Infrastructure audits your own estate from the signals FrontierStack already gathers — Cloudflare zones and their TLS/WAF settings, domain and certificate health, each pinned server's OS, exposed services, remote-access and MDM/Activation Lock/FileVault posture, and the local firewall — assembled into a redacted inventory the agent then attacks.

The whole run happens inside a Sandcastle Docker sandbox, so an adversarial agent pointed at untrusted code never touches your host directly. The app provisions the sandbox image and runner the first time you run an audit (it needs Docker or Podman running); after that, runs start immediately. Findings render with severity badges and can be saved to Obsidian or raised as Alerts for anything critical or high. As everywhere else, only a redacted prompt leaves your Mac — secrets are stripped first — and the sandboxed agent authenticates with your Claude subscription using a token from claude setup-token (or an Anthropic API key).

Before the agent starts, FrontierStack checks for exposed .env files and Git repositories itself — the agent never sees either. In Codebase mode it looks through the folder (a web content folder that isn’t a repository works too; only the agent step needs Git), asks any of your sites that serves the folder for each .env and .git it finds, and flags a .env that is committed or not git-ignored. In Infrastructure mode it requests /.env and /.git/HEAD over HTTPS on every domain it knows, Cloudflare zones included. A catch-all page that answers every address doesn’t count, and only whether a file is served is kept, never its contents. Hits appear under Exposed .env & Git as critical findings.

10.15Strix: AI penetration testing

The audits so far are read-only: they inspect how a host is configured and where its code might be exploitable. Strix goes further — it runs an active penetration test. From the Strix AI Security Testing section of the Security pane you point it at a repository folder, a Git URL, a domain, a URL or an IP address (or pick one of your linked hosts), choose a depth of Quick, Standard or Deep, and it maps the attack surface, attempts real exploit paths, and writes a penetration-test report.

FrontierStack does this by driving the open-source Strix command-line agent locally on your Mac and reading the run artifacts it leaves on disk — the findings, the run metadata and the report — rather than scraping any hosted service. If the CLI is not installed the section says so and offers an Install Strix… link; Update Strix upgrades it through uv or pipx, never by piping a script into a shell. An AI provider key is optional; when you supply one it is stored in the macOS Keychain, handed only to the local Strix process, and never displayed or sent to any cloud model — the pane shows only whether a key is configured.

The tiles summarise the last run: Critical, High and Medium counts, duration, anything new in the last 24 hours, and any failed scans. A run in progress shows live phase text and a Stop button; when new critical or high findings appear you get a local notification unless Silence alerts is on. Open Findings and Export Report surface the detail, and Re-run Failed Scan and Restart Scan Engine recover from a bad run. Serious findings are treated as sensitive and are never sent to cloud AI. The AI Administrator can drive Strix as well, through strix_status, strix_scan and strix_control, all covered in Chapter 13.

10.16Certificate Sources and TLS

An expired certificate is a self-inflicted outage. The Certificate Sources dashboard gives you one row per issuance stack on the host — Let's Encrypt (via acme.sh), Certbot, Step CA, Traefik and Cloudflare SSL — with expiry read directly from the certificates themselves using openssl. Cloudflare uses the token and zone you configured for its analytics; sources that are not present on this Mac show dimmed. For Traefik you can point the dashboard at its acme.json; for Step CA, at its URL.

For issuing certificates, FrontierStack offers two paths. mkcert creates a locally-trusted certificate — ideal for development on .localhost or LAN names, where a public CA is irrelevant; the Certificates pane's Get action uses it when installed. For anything the public must reach, use Let's Encrypt: the AI's issue_certificate tool runs acme.sh or certbot on This Mac or a linked server, and for the DNS-Cloudflare method it reads a CF_TOKEN vault secret that is injected at run time, never sent to the model. For a commercial certificate, pick GlobalSign Atlas as the certificate authority in the Certificates pane’s ACME section, enter the EAB key ID and HMAC key from the Atlas portal and register once; issuing and renewing then work the same way, and the HMAC key stays in the Keychain.

10.17Mail security

A mail server is two distinct risks: it can be spoofed (someone forges mail as your domain) and it can be abused (it relays mail for a stranger). FrontierStack addresses both, with tools that understand the old Apple Server case where Postfix sits underneath.

• Anti-spoofing DNS — email_auth_dns builds the SPF, DMARC and (optional) DKIM TXT records: SPF declares who may send for the domain, DMARC tells receivers how to treat failures, DKIM cryptographically signs outgoing mail. With publish=cloudflare it creates the records for you; otherwise it prints the exact records to paste into BIND, dnsmasq or your registrar.
• DMARC reports — the DMARC Reports pane reads the daily aggregate reports that Gmail, Microsoft, Yahoo and other receivers send to your record's rua= address. Add the IMAP mailbox that address delivers to and FrontierStack checks it every hour, parses the zip, gzip or XML attachments, and shows each domain's pass rate and every server sending as it. The verdict per server separates sometimes fails (a server of yours missing DKIM or SPF on some mail — fix these first) from mail that authenticates only as another domain and mail that isn't authenticated at all (usually spoofing). Reports can also be imported from Suped. Alerts fire when a mailbox can't be read, when your own servers fail more than the threshold, or when a domain stops reporting. Check here before moving a domain from p=none to quarantine or reject; the AI reads the same summary with email_auth_dns action=reports.
• DKIM keys — generate_dkim_key runs opendkim-genkey on the server for a domain and selector and returns the public key as the TXT record to publish; the private key stays on the server for the OpenDKIM milter.
• Postfix hardening — harden_mail_postfix applies safe defaults over SSH with postconf: require SMTP AUTH to relay (this closes an open relay), reject unknown and unlisted sender domains, optionally enforce sender/login matching. It reloads Postfix and prints the effective settings.
• Open-relay test — test_open_relay runs a safe SMTP conversation (EHLO / MAIL FROM / RCPT TO to an external domain, then QUIT without sending) and reports whether the external recipient was rejected (good) or accepted (an open relay — bad).
• Delivery probe — from a server's Mail Server Policy section, send one tagged test message end-to-end through the relay and read the exact SMTP verdict: accepted & queued (with the queue id), deferred, rejected, or a TLS-certificate failure. This is what distinguishes “accepted then silently dropped” from real delivery — and on a relay addressed by its LAN IP, whose STARTTLS certificate can't verify, a Trust LAN relay option retries over an encrypted-but-unverified channel. On an Apple Server.app box FrontierStack also finds Postfix's real log even when the config leaves it to syslog/ASL, and reads the mail queue and the Server.app /Library/Logs/Mail/ files.
• Account check — in the Mail Server pane, type in a mail account's POP3, IMAP and SMTP settings and click Check Settings. Each server is tried the way a mail client connects, and each step says what it found: a server name that doesn't resolve, a port that refuses or is silently dropped by a firewall, a security mode that doesn't match the port (SSL/TLS on 110 or 587, STARTTLS on 995, 993 or 465), TLS 1.0/1.1, and a certificate this Mac doesn't trust — with the reason: expired, issued for another name, self-signed or missing its intermediate. It then signs in, reads the message count and logs out, and a refused login shows the server's own reply. Nothing is downloaded, sent or deleted, and the password is never saved. It isn't sent at all when the certificate is invalid or the connection is unencrypted, unless you turn that on.

Certificate auto-renewal. A mail server proves its name to Let's Encrypt through DNS, not a web page. Mail Server ▸ Certificate Auto-Renewal checks, for a linked server, whether acme.sh renews the certificate Postfix and Dovecot use through Cloudflare DNS and installs it where they read it; Set Up Auto-Renewal… fixes whatever is missing, using a Cloudflare token limited to that zone's DNS, and renews once to prove it works. The server is then checked daily, with an alert if the certificate gets within 20 days of expiry.

Mailbox sizes. When the mail disk fills up, the first question is whose mail is filling it. Mail Server ▸ Mailboxes ▸ List Mailboxes lists every mailbox on the chosen server, largest first, with the total and Copy as CSV. Where Dovecot can list its users, the sizes come from Dovecot with message counts and quota use; otherwise FrontierStack measures the mail folders on disk, including macOS Server.app's per-user folders, which are shown by account name rather than GUID. It only reads. Linked servers need their sudo password saved so every folder can be measured.

10.18Password AutoFill and Credential Exchange

FrontierStack already keeps the logins for the web pages you administer — a router or printer saved under Routers & Network ▸ Web links, the Synology or QNAP admin account, a server controller in Boot Media, a service sign-in. The Password AutoFill pane (Secrets & Vaults) lets Safari and other apps fill them, so you stop copying passwords out of the app.

1. Open Secrets & Vaults ▸ Password AutoFill. If the status line says FrontierStack isn't turned on, choose Turn On… and enable FrontierStack in System Settings ▸ General ▸ AutoFill & Passwords.
2. Under Saved in FrontierStack, choose Offer next to each login Safari may fill. Logins the app doesn't hold elsewhere can be added with Add a Login….
3. On the device's web page, pick the FrontierStack suggestion (or open the passwords menu and choose FrontierStack), then confirm with Touch ID or your Mac's password.

Credential Exchange (macOS 26 and later) is the FIDO standard for moving passwords between password managers. In Passwords — or any password manager that supports it — export to an app and choose FrontierStack. macOS hands the data straight across; nothing is written to disk on the way. FrontierStack then shows a review: logins whose address belongs to this network (a known FrontierStack login, a fleet server, a private address) are already ticked, and where FrontierStack has the login but not yet its password, the imported one can fill it. Untick anything you don't want. Passkeys, verification codes, cards, notes and every unticked login are discarded when you finish, and the Audit Log records only counts.

Going the other way, Export to a Password Manager… lets you tick saved logins and send them to another app, after Touch ID or your password; macOS then shows its own sheet to choose the destination.

10.19Who may change things from outside

Everything above hardens the machines FrontierStack looks after. This section is about hardening FrontierStack itself — because an app holding SSH keys, database passwords and cloud tokens for a whole fleet is a more attractive target than any single server it manages.

FrontierStack can be driven from outside through several doors: the MCP server for AI clients, the inbound HTTP control server for webhooks and the mobile panel, App Intents for Shortcuts and Siri, and — when you enable them — agent integrations. Each already carries its own token. Above all of them sit two settings in Remote Control & Lock, and it is worth being clear about which question each one answers.

The App Lock answers what survives a lock. Set a password, lock the app, and the window is covered while every external surface is either blocked outright or held to read-only.

10.22.3Fleet: require a physical security key

A Fleet licence adds Physical security key immediately beside the password-lock settings. Choose Yubico YubiKey, Google Titan or FEITIAN ePass, then enrol the key through Apple's system security-key sheet. FrontierStack stores only the public credential; the private key never leaves the dongle.

Once enabled, FrontierStack starts locked and re-locks when it goes into the background. It does nothing — the window and every external control surface remain gated — until an enrolled key is connected or presented and you touch it. If you also configured an App Lock password, unlocking is two-step: the correct password and a physical-key touch are both required. A missing key never falls back to password-only access.

Register up to three keys and keep at least one backup somewhere separate. The supported families are YubiKey, Google Titan and FEITIAN FIDO2/ePass. On iPhone and iPad, use a compatible USB-C or Lightning key, or present an NFC-capable model when Apple's sheet asks. Removing the policy also requires a fresh touch from a currently enrolled key, so someone with an unlocked session cannot silently weaken it.

Paired devices and Script Secrets

With a key enrolled, Paired devices need the key too is on by default. Creating a pairing code, pairing KeyRotate and raising a paired device’s permissions — a higher level, the remote shell or AI changes — each take a touch on this Mac. Demoting or revoking a device never does. A phone’s secrets and shell requests are refused until a touch opens a device key session (15 minutes by default). When a phone asks without one, the key prompt appears on the Mac, at most once a minute. Locking FrontierStack closes the session, and Paired Devices shows whether it’s open.

The AI’s Script secrets can be sealed with the key too: Encrypt with Security Key… in AI Administrator stores the values in secrets.env.fsenc, encrypted with a key that only a touch of an enrolled security key can recover (FIDO2 PRF, macOS 26.4 or later). The names stay visible. The values need a touch after each launch or lock and relock after an hour; a script that uses one asks for the touch when it runs. Use Add Backup Key… for every backup key. Keys enrolled before this feature existed must be removed and enrolled again first, and FrontierStack won’t let you remove all keys while secrets are sealed to them.

SSH with a security key. In a linked server’s Edit Settings, Create Security-Key SSH Key… makes an ed25519-sk key on your security key, installs it on the server using the access you already have, and switches the server over only after a test session succeeds. You can optionally remove the old key from the server. Day to day, Open Key Session takes one touch, and monitoring, commands and terminals share that session until it has been idle for the timeout (60 minutes by default, set per server). While the session is closed, that server’s monitoring pauses rather than showing it as down, and nothing in the background ever waits for a touch. Apple’s built-in ssh can’t use FIDO keys, so this Mac needs Homebrew’s OpenSSH — FrontierStack offers to install it. That applies to every server, Linux and Windows included; nothing extra is installed on the server, which only needs OpenSSH 8.2 or later. Stop Using Security Key… returns the server to its previous key.

External changes answers a different question: in an unlocked app, how much must an outside caller do before it can change anything? It applies to every external surface at once — the MCP server, the control panel, Shortcuts and the command line. Three levels. Full auto lets external tools act without asking — defensible only when you trust every connected client and the machine it runs on. Confirm each action, the default, puts an approval panel in front of every change, naming the caller. While a request is waiting and FrontierStack isn’t the frontmost app, its Dock icon keeps bouncing — including after you look away without answering — and stops once the request is answered. The notification for a waiting request carries Deny and Allow once buttons — visible on hover, or permanently if you set FrontierStack to Alerts in System Settings › Notifications. Deny always works from the notification. Allow once asks for Touch ID when human-presence protection uses it, and with hardware-input protection it opens the panel instead, because a click on a notification cannot be told apart from a synthetic one. Timed grants stay on the panel. Calls that only read — a mail-server audit, a DNS record listing — are never prompted. Password required demands your password before an external tool touches a server at all.

The confirm tier has a release valve that matters during an incident. Approving a change offers Allow for session, which grants five minutes — but only for that one caller and that one kind of action. Approving a service restart from an MCP client does not authorise a shell from that client, and does not authorise a restart requested through the mobile panel. The narrowness is the point: repeated prompting during an outage is exactly what drives people to switch to full auto permanently, and a grant that leaked sideways would be worse than the prompting it replaced.

Three properties hold at every level, and they are what make the setting trustworthy rather than merely configurable. Reading is never gated — a monitoring client keeps working whatever you choose, because a dashboard that goes dark during an incident is a liability. Credentials, shell access and FrontierStack’s own settings can never be changed from outside, at any level; those are refused rather than prompted, on the reasoning that a request arriving from a remote tool is simply the wrong origin for reading a password or running an arbitrary command. And session grants are never written to disk: quitting the app or locking it clears them, so a five-minute convenience cannot quietly become a standing permission you forgot you gave.

10.22.4Human-Presence Approvals — when the AI can move the mouse

Confirmation panels assume the person clicking them is a person. An AI agent that drives the whole computer (“computer use”) breaks that assumption: it can post synthetic mouse and keyboard events, or press controls directly through Accessibility, and either way it presses Approve exactly like you would — on the very card that exists to stop it. Human-Presence Approvals, in the same Remote Control & Lock pane, closes that route with two levels.

Real keyboard & mouse only examines the press behind every approval. A genuine click or keypress is delivered by macOS with no posting process behind it; a synthetic event carries the posting app's identity, and an Accessibility press arrives with no input event at all. Anything that isn't real hardware input is rejected: the approval card stays open, a note on it says what happened, the event is recorded in the Change Log (naming the posting app when it can be identified) and a notification tells you an automation just tried to approve something.

Real input + Touch ID adds the proof that settles it: every approval also asks for Touch ID (or a paired Apple Watch), with no password fallback — a password is exactly what a synthetic keyboard can type, while a fingerprint is the one thing software on the Mac can never post. Touch ID is asked for even when a security key is enrolled, deliberately: a key left plugged into the Mac sits within reach of the software running on it, and your fingerprint doesn't. Only a Mac with neither Touch ID nor a Watch falls back to a touch of an enrolled security key.

The gate covers every approval decision — script cards, security confirmations, external tool grants, AI-proposed fixes and the App Lock password — and denying never needs proof, so the protection can only ever stop an approval, never keep something running. Two side effects are deliberate and worth knowing: input injected by Screen Sharing, VNC or a KVM counts as synthetic (approve at the machine itself, or use the Touch ID level, which works over Screen Sharing via the Watch); and key remappers such as Karabiner-Elements, or assistive tools that press controls through Accessibility, are treated as synthetic too.

10.22.5KeyRotate: the master copy of your keys

KeyRotate, Enfour's Mac App Store key manager, pairs with FrontierStack at the Companion app (credentials only) level and then holds the master copy of the keys FrontierStack uses: AI provider keys, Cloudflare, hosting, email lists, agent tokens, CLI Proxy's client key, and the key of every service pane and SaaS monitor that takes a single key, such as Firecrawl, Supabase, Shopify or PagerDuty. The Stripe monitor's restricted key and the GitHub, GitLab, Gitea and Bitbucket tokens link only when you choose to, because they are usually narrower than an app's key. While paired, KeyRotate sends each of those keys to FrontierStack and keeps it current, and a key you type into FrontierStack goes back to KeyRotate a few seconds after you stop typing. KeyRotate then rewrites every file it writes that key to. That transfer is a single-use ticket for one account, valid for two minutes, that only the signed companion can redeem. The link that carries the ticket names the account and never contains the value. Script Secrets sync the same way, except any you have sealed to a security key, which are never sent to KeyRotate. Names that change how a script runs, such as PATH, never sync, and a secret you delete in FrontierStack stays deleted.

The first time KeyRotate opens while FrontierStack is running, it offers to import FrontierStack's keys. FrontierStack shows which keys would go to which app, with Deny as the default, and Allow then needs Touch ID whenever the Mac can use it, with no fallback to the password. Only a Mac without usable Touch ID accepts an Apple Watch, an enrolled security key, or failing those the login password. FrontierStack does not have to be open: hidden, or quit to Only Background, its background service starts the app when KeyRotate calls. A phone can never make this request, even at Full control, and every send is recorded in the audit log.

Rotations through KeyRotate. When the AI Administrator rotates a key with the credentials tool and KeyRotate is paired, it asks KeyRotate to do it by default, so the new key reaches every file KeyRotate writes it to rather than only FrontierStack. FrontierStack opens a keyrotate://rotate link that carries only the account name and a single-use ticket; KeyRotate acts only after confirming that ticket over its signed, pinned connection. KeyRotate applies its own rules — an active subscription, and Touch ID when it is locked, with the prompt naming FrontierStack as the asker — sends FrontierStack the new key, rewrites its other target files when its automatic-update setting is on, and reports back to the waiting tool. The old key is never revoked. Pass via: frontierstack to rotate here instead. Any stored key can be rotated: automatically where the vendor’s API issues a replacement (with the key itself or a stored admin key), otherwise by hand — FrontierStack or KeyRotate opens the vendor’s key page and verifies the new key you paste. When a stored key appears in a prompt to the AI Administrator, it offers to rotate it; outside AI tools over MCP and the CLI (frontierstack keys, frontierstack rotate <service>) are told to offer the same when they see a leaked key.

10.20Agent login with auth.md

Passwords are the worst credential to automate, so FrontierStack never asks you to paste a long-lived one for a third-party service. Instead it discovers auth.md — an open specification (originated by WorkOS) that a service can publish at https://<host>/auth.md to tell AI agents how to sign in on your behalf. A service's Connect ▸ Login Automation (auth.md) disclosure, and the AI's check_authmd tool, fetch that public file and summarise the advertised flows (agent-verified or user-claimed), scopes and OAuth endpoints — or report that none is published. The grant itself happens at the service and issues a short-lived, revocable, scoped token; FrontierStack stores no password. Cloudflare and Firecrawl publish an auth.md today, with more services appearing.

10.21The signed-request trust model (FS1)

FrontierStack's own control surfaces — the local control server, the MCP server, and the remote fsagent — are protected by a bearer token over TLS. A token alone, though, is a shared secret: replayable, and no proof of who is calling. The FS1 signed-request scheme adds a second factor on top. Every request is signed by an approved per-device Ed25519 key; the server keeps an allow-list of public keys and rejects anything signed by a key it has not explicitly approved. A leaked token then controls nothing on its own — this is the HTTP equivalent of the SSH keys your fleet already trusts.

Each request carries the device's key id, a timestamp, a random nonce and a signature over a canonical string. The server verifies the key is approved, the timestamp is within a 60-second window, the nonce is unseen (claimed only after the signature checks out, so a bad signature cannot burn nonces), and the signature is valid. The same scheme is implemented identically in the macOS app, the Go agent and the iOS client, pinned by a cross-language test.

You manage devices in the Paired Devices pane, in the Overview group of the sidebar (it used to live inside this Security pane). Each paired phone or tablet shows its label, key fingerprint, last-seen time, a scope picker and a Revoke button. Pairing is meant for one or two people with a couple of devices each — enrolment is capped at four — and each device carries a scope:

The same section holds the per-surface Require request signing switches for the control and MCP servers. Roll-out is deliberately gentle: the servers accept a token or a signature while signing is optional, with a bootstrap exception so you can enrol the first key with the token you already hold — turning on enforcement can never lock everyone out.

Two further per-device controls sit on each row. Allow AI Administrator (on by default, at any scope) governs whether that one phone may talk to the AI at all — you can let a trusted handset chat while blocking another, and the switch only ever restricts: even with it on, the AI still requires the app unlocked, a signed device, and a full-scope "Allow changes" for anything that mutates. Allow remote shell is offered only at full scope and is off by default; it is the explicit grant a phone needs to open a command-line shell and to install its own SSH key on your servers for direct access when this Mac is offline. If a handset is lost, Secure lost phone blocks the device and its older queued actions at once, closes its sessions, strips its direct-SSH keys from reachable servers and deactivates its push token; offline servers stay listed so you can finish the cleanup when they return.

Bluetooth pairing fallback. When a new phone cannot reach this Mac over Wi-Fi or Tailscale — a locked-down guest network, client isolation, a captive portal — enrolment can still complete over Bluetooth. Turn on Allow Bluetooth pairing (off by default) and the Mac advertises a short-lived GATT service only while the Pair dialog is open; the phone scans the same one-time QR code and runs the identical signed-enrolment handshake, just carried over BLE instead of HTTPS. Because the FS1 signature is transport-agnostic, the Bluetooth path inherits the same trust guarantees without a TLS channel.

Reaching the Mac from anywhere. Out of the box, a paired phone reaches the Mac only while both sit on the same network. If no Tailscale is detected on the Mac, the Paired Devices pane recommends installing it: with Tailscale on the Mac and the iOS Tailscale app on the phone or iPad, both signed into the same tailnet, pairing keeps working from anywhere — the Mac keeps a stable private address, traffic stays end-to-end encrypted, and no router ports are opened.

10.22Hardening the headless Mac

A display-less server has its own security trade-offs, and the Headless Setup tool (covered fully in Chapter 8 and Chapter 17) surfaces the one that matters most here: its System Status section warns when FileVault is on, because an encrypted Mac with no keyboard or screen cannot be unlocked at boot — it will sit at the FileVault prompt instead of coming back online. For a headless box you generally choose between full-disk encryption and unattended restart, and FrontierStack makes that choice explicit rather than letting you discover it after the next power cut. Enabling Screen Sharing or Remote Login on such a host is exactly the kind of exposure the Open Ports watch will then keep an eye on.