---
name: security-audits
description: "Implement and maintain automated and periodic security audits for IT Pro Partner infrastructure — SSH attempt monitoring, package vulnerability scanning, config drift detection, port scanning, and failed login reviews."
version: 1.1.0
author: Sho'Nuff
platforms: [linux]
metadata:
  hermes:
    tags: [security, audit, monitoring, compliance, logging]
---

# Security Audits

Automated and periodic security audits for all ITPP servers. Results should eventually be surfaced through the IT Pro Partner operations portal.

## Lynis nightly scan (deployed Jul 6, 2026)

A `lynis` audit runs nightly at 3 AM on the netcup box via `~/.hermes/scripts/lynis-scan.sh`. It compares warnings count against the previous run and only alerts on NEW findings — silent if nothing changed.

**Installation:**
```bash
apt-get install lynis
lynis audit system --quick  # initial baseline
```

**Cron setup:**
- Schedule: `0 3 * * *`
- Script: `lynis-scan.sh` (no_agent mode)
- Alert: only on warning count change, via Telegram
- Next step: install on wphost02 and Tony's box

**Verification:**
```bash
lynis audit system --quick | grep -E "Warnings|Hardening|Score"
grep "^warning\[\]" /var/log/lynis-report.dat
```

**Current baseline (Jul 6, 2026):**
- Netcup box: Hardening index 62/100, 3 warnings (1 vulnerable package, 2 DNS)
- wphost02: Hardening index 63/100, 3 warnings

| Type | Frequency | What it checks |
|---|---|---|
| **Automated** | Every tick | Open ports, recent failed SSH logins, disk usage alerts, service status |
| **Periodic** | Daily / Weekly | Package vulnerability scan, config drift vs known-good baseline, SSL cert expiry, user account audit |

## Wazuh vs simple cron approach

The user asked about Wazuh for security monitoring. Honest assessment:

**Wazuh pros:** Covers vulnerability scanning (CVEs), file integrity monitoring, intrusion detection (HIDS), log correlation, compliance checks (CIS), centralized dashboard — all in one.

**Wazuh cons:** Needs ~4GB RAM + 2 vCPU for the manager (CPX21 class). Takes a full day to deploy properly. Replaces the need for Graylog entirely since it handles log management.

**Simple cron approach (what we'd start with):** `lynis` weekly audits, SSH auth.log monitoring, automated port scans. Takes 30 minutes. Covers immediate gaps until Wazuh is ready.

**Recommendation:** Start with the cron approach for quick wins, plan Wazuh for when the portal goes customer-facing and compliance matters.

## Audit scope (per server)

### SSH audit
- Check `/var/log/auth.log` or `journalctl -u ssh` for failed login attempts in last 24h
- Count unique IPs attempting to brute force
- Check for non-root user accounts with shell access
- Verify `PermitRootLogin` and `PasswordAuthentication` settings

### Package audit
- `apt list --upgradable` for known security patches
- Check for unattended-upgrades status
- Verify kernel version matches expected image

### Service audit
- Check that critical services (Hermes gateway, cron, email) are running
- Verify Tailscale status
- Check Docker containers are running (if applicable)

### Network audit
- Scan for unexpected open ports with `ss -tlnp`
- Check firewall rules (ufw/iptables)
- Verify no services are listening on 0.0.0.0 that shouldn't be

## Alerting

- Security issues go to the user's Telegram immediately
- Low-urgency items (package updates, cert expiry > 30 days) go into a daily digest
- False positives should be tracked to prevent re-alerting on the same finding
- No alert is the expected state — silent means healthy

## Portal integration

When the portal is built, these audit results should appear on a dedicated Security Dashboard page with:
- Per-server health indicators
- Failed login trends over time
- Update status
- Last audit timestamp

**Pitfalls:**

- **auth.log rotation:** On Debian 13, auth logs may be under `/var/log/auth.log` or journalctl. Check both.
- **netcup SMTP block:** Automated email alerts may not send if the SMTP script uses port 587. Always use 2525.
- **Don't alert on the same thing twice:** Track last-reported state in a sentinel file under `/root/.hermes/scripts/.audit-*`.
- **For standalone scripts (no_agent), output must be self-explanatory:** The script output is delivered verbatim. No LLM is running to interpret it. Format alerts as plain text that the user can understand immediately.
- **Wazuh is on the roadmap** for full SIEM/XDR coverage across all servers (added Jul 6, 2026 to portal todo). Until deployed, Lynis + SSH monitoring are the active security audit tools.
- **Bitdefender GravityZone → Wazuh integration (Jul 15, 2026):** Germaine uses Bitdefender through SyncroMSP for Windows client endpoints. Official Wazuh integration path: Bitdefender GravityZone Event Push Service → `gz-evpsc` connector (Ubuntu VM) → Rsyslog → Wazuh manager. This enables unified Bitdefender + Wazuh events per MSP client, correlated timelines, and per-client compliance reporting (CIS/PCI). Bitdefender detects malware/EDR at the endpoint; Wazuh correlates with HIDS/FIM/SCA/network data for the full attack chain. Requires: Wazuh manager (CPX21), Bitdefender connector VM (~2GB), GravityZone API key for endpoint inventory.

- **Wazuh MCP plan (Jul 14, 2026):** Build `wazuh-mcp` as separate CPX21. Expose agent deployment, SCA/CIS checks, syscollector inventory, alert retrieval, and aggregated per-server security assessment tool. Note: Wazuh 4.8 removed the vulnerability API endpoint — CVE data accessible through Wazuh indexer (OpenSearch) side-channel.
- **VirusTotal integration (Jul 14, 2026):** Add to long-range plan as supplementary threat intel. Use cases: hash/file lookup, URL scan, IP/domain reputation. Integrate into security assessment reports alongside Wazuh + Lynis findings. API key pending.
- **Lynis is deployable on any Linux server** via a single `apt-get install lynis` + cron script. No subagent, tracking, or licensing needed. Done on netcup and wphost02. Tony's box is next.

## Operational security (approved user policy)

These rules govern how the agent operates on infrastructure, approved by Germaine on July 5, 2026.

### Read-only default
- Explore/check/read operations are automatic and need no approval
- Any state change (write, delete, modify, restart, reboot, config change) requires explicit user approval

### Destructive action approval
Before executing a destructive action, state the exact impact:
> "[action] on [server]. Impact: [what will happen]. Proceed?"

Then wait for "yes" or another affirmative. Do not proceed on implied consent.

### API key least-privilege
- Every API key used by the agent must be scoped to minimum permissions needed
- When a user provides a new key, verify its scope if possible and flag if it seems over-privileged
- Examples: Cloudflare = DNS edit only (not zone delete), Wasabi = write to backup buckets (not delete), Stripe = read-only (no refunds/charges)

### Session summaries
After any session that involved changes (config edits, server modifications, cron job changes, API key setup), provide a concise summary of every operation performed, its result, and any side effects.

### No assumed consent between actions
Each action stands alone. Completing task A does not imply consent for task B, even if B is closely related. Ask again.

## ITGC / Compliance Context

During a Jul 7, 2026 session, the user asked where we stand on ITGC controls (IT General Controls). Honest assessment for internal reference:

**What would pass a SOC 2 / ITGC review:**
- Access management: MFA on every admin access, quarterly access reviews, formal on/offboarding
- Change management: Documented tickets with approval, rollback plans
- Computer operations: Formal incident response plan, runbooks, documented backup restore testing
- Program development: Code review, source control

**What we actually have:**
- SSH key-only (no passwords), least-privilege API keys, Tailscale isolation
- Daily backups to S3 + warm standby + nightly Lynis scans
- No MFA on any admin access — biggest single gap
- No change tickets, no incident response plan, no access reviews

**The user's instruction: "Keep these audits/controls in mind as we build these systems."**

This means: when deploying new services (DRE portal, Zabbix, Wazuh, Mautic), build with audit readiness in mind from day one:
- Access logging on every service
- Least-privilege by default on every new service
- Documentation baked into deployment
- Change tracking in the project log
- MFA consideration at design time