hermes-skills/skills/security-audits/SKILL.md

name, description, version, author, platforms, metadata

name	description	version	author	platforms	metadata
security-audits	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.	1.1.0	Sho'Nuff	linux	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:

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:

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