159 lines
8.4 KiB
Markdown
159 lines
8.4 KiB
Markdown
---
|
|
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
|