Skip to content

Security Monitoring

Comprehensive security monitoring procedures and operational guidance for MDHosting Ltd infrastructure.

Operational Focus

This documentation provides execution-ready procedures for security monitoring activities. It documents current capabilities, daily operational tasks, and preparation for enhanced monitoring with Wazuh SIEM deployment.

Overview

This document establishes security monitoring procedures for MDHosting Ltd, covering both current monitoring capabilities and planned enhancements with Wazuh SIEM deployment. It provides operational guidance for detecting, investigating, and responding to security events across the infrastructure.

Purpose: - Document current monitoring capabilities and procedures - Provide operational guidance for security event detection and analysis - Establish alert triage and escalation procedures - Prepare for Wazuh SIEM deployment and integration - Support incident response through effective monitoring

Scope: - All MDHosting infrastructure (3 servers at Hetzner Germany) - Security events, anomalies, and potential threats - Log aggregation, analysis, and retention - Integration with incident response procedures

Integration Points: - Incident Response - Escalation procedures and response workflows - GDPR Compliance - Data breach detection and notification requirements - Network Architecture - Network security zones and firewall rules - Wazuh Deployment Project - Future monitoring capabilities (planned Q1 2025)

Current vs. Planned Monitoring

Current State (January 2026): - Distributed logging across individual servers - Manual log analysis and review - Basic intrusion prevention (CSF, Fail2Ban) - Imunify360 FREE - ModSecurity WAF, basic IDS/IPS (OSSEC-based) - KernelCare - Live kernel patching without reboots - cPanel Security Centre monitoring - ClamAV malware scanning - Reactive security posture (respond to alerts)

Imunify360 + Wazuh Compatibility

Imunify360 (even the FREE version) conflicts with Wazuh agents due to both using the /var/ossec directory (both OSSEC-based). This conflict prevents deployment of Wazuh on current cPanel servers. See revised deployment strategy below.

Planned Enhancement - Two-Phase Approach:

Phase 1: Grafana Stack Deployment (Q1 2026 - Immediate): - Grafana + Prometheus + Loki stack for infrastructure monitoring - Centralised log aggregation and metrics collection - Dashboards for system health, performance, and security events - Compatible with current cPanel + Imunify360 environment (no conflicts) - Deployed via Docker/Portainer on separate monitoring server - See Grafana Monitoring Project for details

Phase 2: Wazuh SIEM Deployment (Post-ApisCP Migration): - Wazuh SIEM on new ApisCP servers (no Imunify360 = no conflict) - Real-time security event detection and alerting - Automated threat detection and correlation - File integrity monitoring (FIM) - Vulnerability detection - Integration with Grafana for unified visualization - Proactive security posture (detect before impact) - See Wazuh Deployment Project for details

Transition Strategy: - Phase 1 (Now): Deploy Grafana stack for immediate monitoring improvements - Current Security: Continue using Imunify360 FREE + KernelCare on cPanel servers - Phase 2 (Post-ApisCP): Deploy Wazuh on new ApisCP servers without Imunify360 - Integration: Grafana will visualize both infrastructure metrics and Wazuh security events - No Agents on cPanel: Wazuh agents will NOT be installed on current cPanel servers due to Imunify360 conflict - Maintain operational continuity throughout transition - Document phase-specific procedures in respective project documentation

Current Monitoring Capabilities

Monitoring Architecture

MDHosting's current monitoring architecture relies on distributed logging and security tools across three servers, with manual analysis and correlation performed by the administrator.

graph TB
    subgraph "Monitored Servers"
        EU1[eu1.cp<br/>Hosting Server<br/>CPX31 - 4 vCPU, 8GB RAM<br/>~30 Client Accounts]
        NS1[ns1.mdhosting.co.uk<br/>Primary DNS<br/>CX22 - 2 vCPU, 4GB RAM]
        NS2[ns2.mdhosting.co.uk<br/>Secondary DNS<br/>CX22 - 2 vCPU, 4GB RAM]
    end

    subgraph "Security Tools"
        CSF[CSF Firewall<br/>Connection tracking, rate limiting<br/>Auto-blocking]
        FAIL2BAN[Fail2Ban<br/>Intrusion prevention<br/>SSH, cPanel, SMTP protection]
        IMUNIFY[Imunify360 FREE<br/>ModSecurity WAF, basic IDS/IPS<br/>OSSEC-based - uses /var/ossec]
        KERNEL[KernelCare<br/>Live kernel patching<br/>No reboot required]
        CLAM[ClamAV<br/>Malware scanning<br/>On-demand and scheduled]
        CPANEL[cPanel Security Centre<br/>Security advisories<br/>System checks]
    end

    subgraph "Log Sources"
        SYSLOG[System Logs<br/>/var/log/messages<br/>/var/log/secure]
        APACHE[Web Server Logs<br/>/usr/local/apache/logs/<br/>domlogs/]
        MAIL[Email Logs<br/>/var/log/exim_mainlog<br/>/var/log/maillog]
        CPLOG[cPanel Logs<br/>/var/log/cPanel/<br/>access_log, error_log]
    end

    subgraph "Manual Analysis"
        ADMIN[Administrator Review<br/>SSH access<br/>Log file analysis<br/>Event correlation]
    end

    EU1 --> CSF
    EU1 --> FAIL2BAN
    EU1 --> IMUNIFY
    EU1 --> KERNEL
    EU1 --> CLAM
    EU1 --> CPANEL
    NS1 --> CSF
    NS1 --> FAIL2BAN
    NS2 --> CSF
    NS2 --> FAIL2BAN

    EU1 --> SYSLOG
    EU1 --> APACHE
    EU1 --> MAIL
    EU1 --> CPLOG
    NS1 --> SYSLOG
    NS2 --> SYSLOG

    SYSLOG --> ADMIN
    APACHE --> ADMIN
    MAIL --> ADMIN
    CPLOG --> ADMIN
    CSF --> ADMIN
    FAIL2BAN --> ADMIN

    style EU1 fill:#3498db,stroke:#2c3e50,stroke-width:2px,color:#fff
    style NS1 fill:#3498db,stroke:#2c3e50,stroke-width:2px,color:#fff
    style NS2 fill:#3498db,stroke:#2c3e50,stroke-width:2px,color:#fff
    style CSF fill:#e74c3c,stroke:#2c3e50,stroke-width:2px,color:#fff
    style FAIL2BAN fill:#e74c3c,stroke:#2c3e50,stroke-width:2px,color:#fff
    style IMUNIFY fill:#e74c3c,stroke:#2c3e50,stroke-width:2px,color:#fff
    style KERNEL fill:#27ae60,stroke:#2c3e50,stroke-width:2px,color:#fff
    style CLAM fill:#e74c3c,stroke:#2c3e50,stroke-width:2px,color:#fff
    style CPANEL fill:#f39c12,stroke:#2c3e50,stroke-width:2px,color:#fff
    style ADMIN fill:#8e44ad,stroke:#2c3e50,stroke-width:2px,color:#fff

Security Tools Overview

CSF (ConfigServer Security & Firewall)

Purpose: Stateful packet inspection firewall with connection tracking, rate limiting, and automated IP blocking.

Capabilities: - Connection rate limiting (80 connections per IP, 50 to port 80) - SYN flood protection (100/s rate, 150 burst) - Port flood protection (SSH: 5 connections per 300s, HTTP/HTTPS: 100 connections per 5s) - Automated IP blocking based on threat detection - Login failure tracking integration with LFD (Login Failure Daemon)

Configuration Files: - /etc/csf/csf.conf - Main configuration - /etc/csf/csf.allow - IP whitelist (permanent allow) - /etc/csf/csf.deny - IP blacklist (permanent deny) - /etc/csf/csf.ignore - IPs to ignore in LFD checks

Monitoring Activities: - Review blocked IPs and reasons for blocking - Monitor connection tracking statistics - Analyse port flood events - Review LFD trigger alerts

Commands: 

# Check CSF status
csf -l                    # List current rules and blocks
csf -g [IP]              # Search for IP across all lists
csf -t                   # List temporary IP bans

# IP management
csf -d [IP] "Reason"     # Deny IP with reason
csf -a [IP] "Reason"     # Allow IP permanently
csf -tr [IP]             # Remove temporary ban
csf -dr [IP]             # Remove from deny list

# Statistics and logs
csf -s                   # View summary statistics
tail -f /var/log/lfd.log # Monitor real-time LFD alerts

Alert Thresholds: - 5 SSH login failures → Temporary block (5 minutes) - 5 cPanel login failures → Temporary block (5 minutes) - 5 LFD triggers → Permanent block (requires manual review) - SYN flood exceeding threshold → Automatic rate limiting

See Also: Network Architecture - Firewall Rules for complete CSF configuration details.

Fail2Ban

Purpose: Intrusion prevention system that monitors log files for malicious patterns and bans IP addresses based on configurable rules.

Monitored Services: - SSH (sshd) - Failed login attempts - cPanel (cpanel, whm) - Control panel authentication failures - SMTP (exim) - Email authentication failures and spam attempts - Apache - Web application attacks, brute force attempts

Configuration: - /etc/fail2ban/jail.conf - Main configuration (do not edit directly) - /etc/fail2ban/jail.local - Custom configuration overrides - /etc/fail2ban/filter.d/ - Log pattern matching rules - /etc/fail2ban/action.d/ - Actions to take when bans occur

Ban Configuration: - Ban time: 10 minutes (default) - Find time: 10 minutes (window to count failures) - Max retries: 5 failed attempts within find time window

Monitoring Activities: - Review banned IPs and reasons - Monitor service-specific ban rates - Analyse attack patterns (geographic, timing, targets) - Investigate persistent attackers

Commands: 

# Service status
systemctl status fail2ban
fail2ban-client status           # List active jails

# Jail-specific status
fail2ban-client status sshd      # SSH jail status and banned IPs
fail2ban-client status cpanel    # cPanel jail status
fail2ban-client status exim      # SMTP jail status

# IP management
fail2ban-client set sshd unbanip [IP]     # Unban specific IP
fail2ban-client get sshd banned           # List banned IPs

# Logs and statistics
tail -f /var/log/fail2ban.log    # Real-time monitoring
grep "Ban" /var/log/fail2ban.log | tail -20  # Recent bans

Alert Indicators: - Rapid increase in ban rate (possible coordinated attack) - Bans from unusual geographic locations - Multiple failed attempts across different services (targeted attack) - Repeated bans of same IP after unban (persistent attacker)

Imunify360 FREE

Purpose: Web Application Firewall (WAF), intrusion detection and prevention system (IDS/IPS) with ModSecurity integration.

Capabilities: - ModSecurity Web Application Firewall with rule sets - Basic intrusion detection (OSSEC-based) - Proactive Defense against zero-day attacks - Malware scanning (basic, complements ClamAV) - Real-time blocking of malicious requests - Automatic IP reputation management

Key Limitation:

Wazuh Compatibility Conflict

Imunify360 uses /var/ossec directory (OSSEC-based architecture), which conflicts with Wazuh agents. This prevents deployment of Wazuh on servers with Imunify360 installed, even the FREE version. Wazuh deployment must occur on new ApisCP servers without Imunify360.

Configuration: - Managed via WHM → Plugins → Imunify360 - ModSecurity rules: WHM → Security Centre → ModSecurity - Free version provides basic protection without advanced features

Monitoring Activities: - Review blocked requests and malware detections - Monitor ModSecurity rule triggers - Check for false positives affecting client sites - Review IP reputation blocks

Common Commands: 

# Check Imunify360 status
imunify360-agent version
systemctl status imunify360

# List blocked IPs
imunify360-agent blocked-port list

# Malware scan status
imunify360-agent malware-scanning status

# View recent events
tail -f /var/log/imunify360/console.log

Free vs. Paid Comparison: - FREE: ModSecurity, basic IDS, limited malware scanning, IP reputation - Paid: Advanced threat detection, proactive defense, automated response, patch management, reputation management

Current Status: Using FREE version (sufficient for current scale). Consider upgrading to paid version (£12-18/month per server) if advanced threat detection needed before ApisCP migration.

KernelCare

Purpose: Live kernel patching service that applies security patches without requiring server reboots.

Capabilities: - Automatic kernel security patch application - Zero downtime patching (no reboot required) - Protection against kernel-level vulnerabilities - Maintains kernel version while applying security fixes - Reduces maintenance windows

Benefits: - Continuous uptime for client services - Rapid vulnerability remediation - No scheduling of maintenance windows for kernel patches - Reduced risk of extended vulnerability exposure

Configuration: - Managed by cPanel licensing (included with cPanel licenses) - Automatic updates enabled by default - Patches applied within hours of release

Monitoring Activities: - Verify patches are applying successfully - Monitor for any patch failures or conflicts - Check patch application history

Commands: 

# Check KernelCare status
kcarectl --info

# List applied patches
kcarectl --patch-info

# Update patches manually (automatic by default)
kcarectl --update

# Check patch history
kcarectl --check-updates

Alert Response: - If patch application fails, investigate kernel compatibility - Monitor for kernel updates that may require full reboot - Verify uptime and patch status alignment

ClamAV (Malware Scanning)

Purpose: Open-source antivirus engine for detecting trojans, viruses, malware, and other malicious threats.

Scanning Capabilities: - On-demand scanning of files and directories - Scheduled daily scans of web directories - Email attachment scanning integration - Virus definition updates (daily automatic)

Monitored Locations: - /home/*/public_html/ - All client website directories - /home/*/mail/ - Email storage directories - /tmp/ and /var/tmp/ - Temporary file storage - Upload directories and file storage locations

Scanning Schedule: - Daily: Automatic scan of all web directories (03:00 local time) - Weekly: Full system scan including mail directories (Sunday 02:00) - On-demand: Manual scans for suspected infections or client requests

Configuration: - /etc/clamd.d/scan.conf - ClamAV daemon configuration - /etc/freshclam.conf - Virus definition update configuration - /usr/local/cpanel/3rdparty/mailman/clamav/ - cPanel integration

Monitoring Activities: - Review scan results for detected malware - Monitor scan completion and any failures - Analyse infection patterns (file types, locations, timing) - Track virus definition update status

Commands: 

# Manual scanning
clamscan -r /home/username/public_html/     # Scan specific directory recursively
clamscan -r --infected /path/to/scan/       # Show only infected files
clamscan -r -i --remove /path/              # Scan and automatically remove infected files (CAUTION)

# Virus database status
freshclam                                    # Update virus definitions manually
sigtool --info /var/lib/clamav/daily.cvd    # Check database version

# Scan history and logs
tail -f /var/log/clamav/clamd.log           # Real-time daemon log
grep "FOUND" /var/log/clamav/clamd.log      # List detected infections

Alert Response: 1. Malware Detected: - Quarantine infected files (move to /root/quarantine/) - Identify source (uploaded file, plugin vulnerability, compromised credentials) - Notify affected client - Investigate infection vector - Scan related files and accounts for spread - Follow Incident Response - Malware Playbook

  1. Scan Failures:
  2. Check for database update issues
  3. Verify sufficient disk space for scanning
  4. Review scan logs for permission errors

cPanel Security Centre

Purpose: Centralised security monitoring and configuration interface for cPanel/WHM servers.

Monitoring Features: - Security Advisor (automated security checks) - Security Policy configuration and enforcement - SSL/TLS certificate monitoring - ModSecurity Web Application Firewall status (via Imunify360) - Imunify360 integration (FREE version installed) - KernelCare live patching status - Security update notifications

Security Advisor Checks: - Outdated cPanel version - Unencrypted FTP (check for FTP usage, recommend SFTP) - MySQL root password status - Tweak settings security review - Compiler access (disabled for non-root users) - Shell fork bomb protection - Background process killer status

Monitoring Activities: - Weekly Security Advisor review (check for new warnings) - SSL certificate expiration monitoring (Let's Encrypt auto-renewal) - ModSecurity rule update tracking - Security update notifications review

Access: 

WHM → Security Centre → Security Advisor
URL: https://eu1.cp:2087/scripts2/sa (requires root/WHM login)

Alert Response: 1. Security Advisor Warnings: - Review recommended actions - Assess risk level and impact - Implement fixes or document accepted risk - Re-run advisor to verify resolution

  1. SSL Certificate Issues:
  2. Verify Let's Encrypt autorenewal functionality
  3. Check domain DNS resolution
  4. Review certificate logs: /var/log/letsencrypt/letsencrypt.log

  5. Force renewal if needed: /usr/local/cpanel/scripts/renew_ssl_certificates

  6. Security Updates:

  7. Review update details and changelogs
  8. Schedule update during maintenance window
  9. Create backup before applying updates
  10. Test critical functionality after updates

Log Sources and Locations

System Logs (All Servers)

Location: /var/log/

Log File Purpose Key Events Retention
/var/log/messages General system messages Boot, kernel, hardware, system errors 4 weeks (logrotate)
/var/log/secure Authentication and authorisation SSH logins, sudo usage, authentication failures 4 weeks
/var/log/cron Scheduled task execution Cron job execution, failures 4 weeks
/var/log/boot.log System boot messages Boot process, service startup Last boot only

Common Monitoring Tasks: 

# SSH authentication monitoring
grep "Failed password" /var/log/secure | tail -20          # Recent failed SSH attempts
grep "Accepted publickey" /var/log/secure | tail -20       # Successful SSH logins
grep "sudo:" /var/log/secure | tail -20                    # Sudo command usage

# System errors and warnings
grep -i "error\|fail\|warning" /var/log/messages | tail -50
tail -f /var/log/messages                                   # Real-time system monitoring

# Login session tracking
last -20                                                    # Recent login sessions
lastb -20                                                   # Recent failed login attempts
who                                                         # Currently logged-in users

Web Server Logs (eu1.cp only)

Apache Access Logs: 

/usr/local/apache/logs/access_log             # Main server access log (WHM, server hostname)
/usr/local/apache/domlogs/domain.com          # Per-domain access logs (client websites)
/usr/local/apache/domlogs/domain.com-ssl_log  # Per-domain SSL access logs

Apache Error Logs: 

/usr/local/apache/logs/error_log              # Main server error log
/usr/local/apache/domlogs/domain.com.error    # Per-domain error logs

Log Format (Combined): 

IP - - [timestamp] "REQUEST" status bytes "referrer" "user-agent"
Example:
203.0.113.45 - - [07/Jan/2026:14:23:15 +0000] "GET /wp-login.php HTTP/1.1" 200 1234 "-" "Mozilla/5.0..."

Common Monitoring Tasks: 

# Detect brute force attempts on WordPress login
grep "POST /wp-login.php" /usr/local/apache/domlogs/domain.com | wc -l
grep "POST /wp-login.php" /usr/local/apache/domlogs/domain.com | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

# Find 404 errors (potential scanning/probing)
grep " 404 " /usr/local/apache/logs/access_log | tail -20

# Monitor high-traffic IPs (potential DoS)
awk '{print $1}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -20

# Check for suspicious requests (SQLi, XSS attempts)
grep -E "(\%27|\%23|union|select|script)" /usr/local/apache/logs/access_log | tail -20

# Real-time monitoring
tail -f /usr/local/apache/logs/access_log

Alert Indicators: - Excessive 404 errors from single IP (scanning/probing) - Repeated POST requests to login pages (brute force) - SQL injection patterns in URLs (%27, union, select) - Unusual user-agent strings (bot detection) - High request volume from single IP (DoS attempt)

Email Logs (eu1.cp only)

Exim (SMTP) Logs: 

/var/log/exim_mainlog        # Main email server log (all SMTP transactions)
/var/log/exim_rejectlog      # Rejected messages (spam, policy violations)
/var/log/exim_paniclog       # Critical errors (should always be empty)

Dovecot (IMAP/POP3) Logs: 

/var/log/maillog             # IMAP/POP3 authentication and access

Log Format Examples: 

# Exim mainlog format
2026-01-07 14:23:15 1qABCD-0001Xy-ZZ <= sender@domain.com H=mail.server.com [203.0.113.45] P=esmtps X=TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256 S=1234 id=messageid@domain.com
2026-01-07 14:23:16 1qABCD-0001Xy-ZZ => recipient@destination.com R=lookuphost T=remote_smtp H=mx.destination.com [198.51.100.20]

# Maillog (Dovecot) format
Jan  7 14:23:15 imap-login: Login: user=<user@domain.com>, method=PLAIN, rip=203.0.113.45, lip=192.0.2.10, secured, session=<sessionid>

Common Monitoring Tasks: 

# Authentication failures (potential brute force)
grep "authentication failed" /var/log/maillog | tail -20
grep "auth failed" /var/log/exim_mainlog | tail -20

# Rejected email (spam detection)
tail -50 /var/log/exim_rejectlog
grep "rejected" /var/log/exim_mainlog | tail -20

# Outbound email volume (detect compromised accounts sending spam)
grep "<=" /var/log/exim_mainlog | grep "$(date +%Y-%m-%d)" | wc -l     # Today's sent count
exim -bpc                                                                # Current queue size

# Top email senders (identify potential spam accounts)
grep "<=" /var/log/exim_mainlog | awk '{print $6}' | sort | uniq -c | sort -rn | head -10

# PANIC log check (should always be empty - critical errors)
cat /var/log/exim_paniclog        # If this has content, investigate immediately

# Frozen messages (stuck in queue)
exim -bp | grep frozen | wc -l
exiqgrep -z -i                    # List frozen message IDs

Alert Indicators: - Non-empty /var/log/exim_paniclog (CRITICAL - investigate immediately) - Rapid increase in outbound email volume (compromised account) - High number of frozen messages (delivery issues or spam) - Repeated authentication failures (brute force attack) - Large queue size (delivery problems or spam backlog)

cPanel Logs (eu1.cp only)

cPanel/WHM Access and Error Logs: 

/usr/local/cpanel/logs/access_log     # cPanel/WHM web interface access
/usr/local/cpanel/logs/error_log      # cPanel/WHM errors and warnings
/usr/local/cpanel/logs/login_log      # cPanel user login attempts and sessions
/usr/local/cpanel/logs/stats_log      # Statistics processing (Awstats, Webalizer)

Common Monitoring Tasks: 

# Failed cPanel login attempts
grep "FAILED LOGIN" /usr/local/cpanel/logs/login_log | tail -20
grep "Failed" /usr/local/cpanel/logs/access_log | grep "login" | tail -20

# Successful cPanel logins
grep "SUCCESSFUL LOGIN" /usr/local/cpanel/logs/login_log | tail -20

# Recent cPanel user activity
tail -50 /usr/local/cpanel/logs/access_log

# cPanel errors
tail -50 /usr/local/cpanel/logs/error_log | grep -i "error\|warning"

# Monitor specific user account activity
grep "username" /usr/local/cpanel/logs/access_log | tail -20

Alert Indicators: - Multiple failed login attempts from single IP (brute force) - Successful login from unusual geographic location (compromised credentials) - Errors related to disk space, licensing, or system resources - Unusual activity patterns (e.g., rapid file operations, mass deletions)

DNS Logs (ns1 and ns2)

BIND/Named Logs (if using BIND): 

/var/log/named/queries.log    # DNS query log (if query logging enabled)
/var/log/named/security.log   # BIND security events

cPanel DNS Logs: 

/var/log/messages             # DNS service startup, errors (search for "named")

Common Monitoring Tasks: 

# Check DNS service status
systemctl status named

# Monitor for DNS amplification attacks (high query volume)
grep "query" /var/log/messages | grep "$(date +%b\ %e)" | wc -l

# Find top querying IPs (identify potential DNS abuse)
grep "query" /var/log/messages | awk '{print $NF}' | sort | uniq -c | sort -rn | head -10

# Check for SERVFAIL responses (potential configuration issues)
grep "SERVFAIL" /var/log/messages | tail -20

Limited DNS Logging

By default, cPanel DNS (BIND) does not enable query logging due to performance impact and log volume. Query logging can be enabled for troubleshooting but should be disabled after investigation to prevent excessive log growth.

Alert Indicators: - Abnormally high query volume (DNS amplification attack) - Queries for unusual domains (potential malware C2 communication - requires DPI) - Frequent SERVFAIL responses (configuration or upstream issues) - Service restarts or failures (check system logs)

Monitoring Workflows

Daily Monitoring Activities

Morning Security Check (15 minutes):

  1. Review Overnight Alerts: 

    # Check CSF/LFD alerts
tail -100 /var/log/lfd.log | grep -i "alert\|block\|trigger"

# Check Fail2Ban activity
grep "Ban" /var/log/fail2ban.log | grep "$(date +%Y-%m-%d)"

# Check for system errors
grep -i "error\|fail\|critical" /var/log/messages | grep "$(date +%Y-%m-%d)" | tail -20

  2. Verify Service Availability: 

    # Check all critical services
systemctl status httpd mysqld exim dovecot named fail2ban

# Check cPanel service status (on eu1.cp)
/scripts/check_cpanel_pkgs --list

  3. Review Disk Space and System Resources: 

    # Disk space check
df -h | grep -vE "tmpfs|devtmpfs"

# Memory usage
free -h

# Load average
uptime

# Top resource-consuming processes
ps aux --sort=-%mem | head -10

  4. Check Mail Queue: 

    # Queue size (should be <100 normally)
exim -bpc

# If queue is large, investigate top senders
exim -bp | exiqsumm | tail -20

  5. Review Malware Scan Results: 

    # Check if overnight ClamAV scan completed
grep "ScanDate" /var/log/clamav/clamd.log | tail -1

# Check for any infections found
grep "FOUND" /var/log/clamav/clamd.log | grep "$(date +%Y-%m-%d)"

Response Actions: - If critical alerts or service failures detected, escalate to incident response procedures - If disk space >80%, investigate and clean up log files or backups - If mail queue >500, investigate for spam or delivery issues - If malware detected, follow containment procedures

Weekly Monitoring Activities

Weekly Security Review (30 minutes, recommended: Monday mornings):

  1. Security Advisor Review:
  2. Log in to WHM → Security Centre → Security Advisor
  3. Review new warnings or recommendations
  4. Implement fixes or document accepted risks

  5. Update security advisor review log

  6. Firewall and IDS Analysis: 

    # Review most blocked IPs (CSF)
csf -l | grep "# Blocked" | wc -l

# Top 20 blocked IPs
grep "LFD" /var/log/lfd.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

# Fail2Ban ban statistics
fail2ban-client status | grep "Jail list" -A 20
fail2ban-client status sshd | grep "Total banned"

  7. Authentication Failure Analysis: 

    # SSH failed login attempts (unique IPs)
grep "Failed password" /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -rn | head -20

# cPanel failed logins
grep "FAILED LOGIN" /usr/local/cpanel/logs/login_log | tail -50

# Email authentication failures
grep "authentication failed" /var/log/maillog | wc -l

  8. Web Application Attack Analysis: 

    # SQL injection attempts
grep -E "(\%27|union|select)" /usr/local/apache/logs/access_log | wc -l

# WordPress brute force attempts
for domain in $(ls /usr/local/apache/domlogs/ | grep -v "\."); do
  echo "=== $domain ==="
  grep "POST /wp-login.php" /usr/local/apache/domlogs/$domain 2>/dev/null | wc -l
done

# Scanning activity (404 errors from same IP)
grep " 404 " /usr/local/apache/logs/access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

  9. SSL Certificate Status: 

    # Check certificate expiration dates
/scripts/checkcertificates

# Verify Let's Encrypt autorenewal
cat /var/log/letsencrypt/letsencrypt.log | grep "$(date +%Y-%m-%d)"

  10. Update and Patch Status:

  11. Check AlmaLinux security updates: dnf check-update --security
  12. Review cPanel updates: WHM → Update Preferences → Update Status
  13. Review WordPress core/plugin updates (client sites)

Response Actions: - Block persistent attackers at firewall level (permanent deny) - Notify clients of brute force attempts on their sites - Apply security patches and updates during maintenance window - Document attack patterns and trends for quarterly review

Monthly Monitoring Activities

Monthly Security Audit (1-2 hours, recommended: First Monday of month):

  1. Comprehensive Log Analysis:
  2. Review authentication patterns across all services
  3. Analyse attack vectors and geographic sources
  4. Identify compromised accounts (unusual login locations, excessive email sending)

  5. Review system and application errors for security implications

  6. User Account Audit: 

    # List all system users
cat /etc/passwd | grep "/bin/bash"

# Check for users with sudo access
grep -Po '^sudo.+:\K.*$' /etc/group

# Review SSH authorised keys
find /root/.ssh/ -name "authorized_keys" -exec cat {} \;

# cPanel account status review
/scripts/listaccts --format email,user,domain,suspended

  7. Vulnerability and Security Updates:

  8. Apply monthly cPanel updates (WHM → Update Preferences → cPanel)
  9. Review and apply AlmaLinux security patches
  10. Check for new security advisories affecting infrastructure

  11. Review WordPress core/plugin vulnerabilities (WPScan database or security bulletins)

  12. Malware Scan and File Integrity: 

    # Full system malware scan (run manually, resource-intensive)
clamscan -r -i /home/ --log=/var/log/clamav/monthly-scan-$(date +%Y-%m-%d).log

# Check for suspicious SUID/SGID files
find / -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null

# Check for world-writable files (security risk)
find /home/ -type f -perm -002 -ls 2>/dev/null

  13. Firewall Rule Review:

  14. Review CSF allow/deny lists for outdated entries
  15. Verify firewall rules align with current network architecture
  16. Remove temporary blocks that should be permanent (or vice versa)

  17. Update IP whitelists for administrative access

  18. Backup Verification:

  19. Verify automated backups completing successfully
  20. Test random backup restoration (quarterly full restore test)
  21. Check backup retention compliance

  22. Review off-site backup integrity

  23. Documentation Updates:

  24. Update this monitoring document with new procedures or tools
  25. Document any security incidents and lessons learned
  26. Update contact information if vendors or procedures changed
  27. Review and update incident response procedures

Response Actions: - Remove unnecessary user accounts or access - Apply security patches promptly (critical: within 48h, high: within 7 days) - Quarantine and investigate any malware detections - Update firewall rules and IP whitelists - Document findings in monthly security report

Quarterly Monitoring Activities

Quarterly Security Review (2-4 hours):

  1. Comprehensive Security Posture Assessment:
  2. Review 3 months of security metrics and trends
  3. Analyse incident frequency and types
  4. Evaluate effectiveness of security controls
  5. Identify recurring issues or patterns

  6. Assess progress on security roadmap

  7. Threat Landscape Review:

  8. Research new threats targeting hosting providers
  9. Review OWASP Top 10 and applicability to infrastructure
  10. Assess impact of new vulnerabilities (AlmaLinux, cPanel, WordPress ecosystem)

  11. Update threat model in Security Overview

  12. Security Tool Effectiveness:

  13. Evaluate CSF/Fail2Ban effectiveness (false positive rate, missed attacks)
  14. Review ClamAV detection rates and false positives
  15. Assess cPanel Security Centre recommendations

  16. Identify gaps in detection capabilities

  17. Security Training and Awareness:

  18. Review and update security procedures documentation
  19. Test incident response procedures (tabletop exercise)
  20. Refresh knowledge of GDPR breach notification requirements

  21. Review vendor security contacts and escalation procedures

  22. Compliance Review:

  23. GDPR compliance audit (review GDPR Compliance document)
  24. Verify data processing agreements with vendors
  25. Review data retention and deletion procedures

  26. Check ICO registration status and accuracy

  27. Long-Term Planning:

  28. Review security roadmap progress
  29. Update Wazuh deployment timeline if needed
  30. Plan security improvements for next quarter
  31. Budget for security tools or services

Deliverables: - Quarterly Security Report (metrics, trends, incidents, recommendations) - Updated threat model and risk assessment - Security roadmap progress update - Documentation updates based on lessons learned

Alert Detection and Triage

Alert Sources

Current Alert Mechanisms:

  1. Email Alerts (LFD - Login Failure Daemon):
  2. IP blocks and unblocks
  3. Excessive resource usage by accounts
  4. Port flooding
  5. Connection limit violations

  6. Suspicious file uploads or modifications (basic)

  7. Manual Detection:

  8. Log file review (daily/weekly procedures above)
  9. Service monitoring (systemctl status checks)
  10. Resource monitoring (disk, memory, load average)

  11. Client reports (service issues, suspicious activity)

  12. cPanel Notifications:

  13. Security Advisor warnings
  14. Service Monitor alerts (if enabled)
  15. Backup completion/failure notifications

Alert Delivery: - LFD alerts: Email to root@ (admin email alias) - Check email regularly: mail command on server or forward to external email

Alert Prioritisation

Critical (Response: Immediate, <1 hour): - Non-empty /var/log/exim_paniclog (mail system critical error) - Service failures affecting client sites (httpd, mysqld, exim down) - Confirmed malware infection or active breach - DDoS attack causing service unavailability - Disk space >95% (service failure imminent) - Multiple simultaneous LFD triggers (coordinated attack)

High (Response: <4 hours): - Repeated failed authentication attempts (brute force attack in progress) - Large mail queue (>1000 messages, potential spam) - Malware detected in client accounts - Unusual outbound email volume (compromised account likely) - Port flood or SYN flood events - WordPress brute force attacks (client notification needed)

Medium (Response: <24 hours): - Security Advisor new warnings - Firewall rule violations (persistent scanning) - Disk space 80-95% (trending toward full) - Failed backup notifications - SSL certificate expiration within 7 days (if Let's Encrypt autorenewal failed) - Moderate increase in 404 errors (scanning activity)

Low (Response: <1 week): - Informational LFD blocks (single failed attempt, auto-blocked) - Routine security updates available - cPanel minor version updates - Historical log analysis findings (trends, not active threats)

Alert Triage Process

graph TB
    ALERT[Alert Received] --> CLASSIFY{Classify Severity}

    CLASSIFY -->|Critical| CRITICAL[Critical Response<br/>Immediate action<br/>Follow incident response]
    CLASSIFY -->|High| HIGH[High Priority<br/>Investigate within 4h<br/>Take action if confirmed]
    CLASSIFY -->|Medium| MEDIUM[Medium Priority<br/>Investigate within 24h<br/>Schedule remediation]
    CLASSIFY -->|Low| LOW[Low Priority<br/>Log for review<br/>Address during weekly check]

    CRITICAL --> INCIDENT[Escalate to<br/>Incident Response]
    HIGH --> INVESTIGATE[Investigate]
    MEDIUM --> INVESTIGATE
    LOW --> LOG[Log for Review]

    INVESTIGATE --> CONFIRM{Threat<br/>Confirmed?}
    CONFIRM -->|Yes| INCIDENT
    CONFIRM -->|No| FALSE[False Positive<br/>Document and close]
    CONFIRM -->|Unknown| ESCALATE[Escalate for<br/>Further Analysis]

    INCIDENT --> IR[Follow Incident<br/>Response Procedures]
    IR --> DOCUMENT[Document Actions<br/>and Outcomes]
    DOCUMENT --> LESSONS[Update Procedures<br/>Lessons Learned]

    FALSE --> DOCUMENT
    LOG --> DOCUMENT

    style CRITICAL fill:#e74c3c,stroke:#2c3e50,stroke-width:2px,color:#fff
    style HIGH fill:#f39c12,stroke:#2c3e50,stroke-width:2px,color:#fff
    style MEDIUM fill:#f39c12,stroke:#2c3e50,stroke-width:2px,color:#fff
    style LOW fill:#3498db,stroke:#2c3e50,stroke-width:2px,color:#fff
    style INCIDENT fill:#e74c3c,stroke:#2c3e50,stroke-width:2px,color:#fff
    style IR fill:#8e44ad,stroke:#2c3e50,stroke-width:2px,color:#fff

Triage Steps:

  1. Receive and Classify Alert:
  2. Identify alert source and type
  3. Assign initial severity based on prioritisation matrix above

  4. Note timestamp and initial context

  5. Initial Investigation (5-10 minutes):

  6. Review relevant log files for context
  7. Check if alert is isolated incident or part of pattern
  8. Verify affected systems and services are operational

  9. Assess immediate impact to clients or services

  10. Confirm Threat or False Positive:

  11. True Positive (Confirmed Threat): Escalate to incident response
  12. False Positive: Document reason, adjust alert rules if needed, close alert

  13. Uncertain: Continue investigation or escalate to external resources (vendor support, security forums)

  14. Escalation Decision:

  15. If threat confirmed → Follow Incident Response procedures
  16. If service impact detected → Follow restoration procedures

  17. If client data involved → Consider GDPR breach notification requirements (GDPR Compliance - Data Breach)

  18. Documentation:

  19. Log all alerts (even false positives) in alert register
  20. Document investigation steps and findings
  21. Record actions taken and outcomes
  22. Update procedures if new attack vector or gap identified

Alert Register Format: 

Alert Log: /root/security/alert-register-YYYY.log

Date/Time | Alert Source | Severity | Description | Investigation | Action Taken | Outcome | Escalated?
2026-01-07 14:30 | LFD | High | SSH brute force from 203.0.113.45 | Reviewed /var/log/secure, 50 failed attempts | Permanent IP block (csf -d) | Blocked, no compromise | No
2026-01-08 03:15 | ClamAV | High | Malware found in /home/client/public_html/uploads/ | Confirmed PHP backdoor | Quarantined file, notified client | Client site secured | Yes (client breach)

Integration with Incident Response

Security monitoring provides the detection and initial assessment capabilities that feed into the incident response process documented in Incident Response.

Detection Phase Integration

Monitoring Role: - Detect potential security incidents through log analysis and alerts - Provide initial context and evidence for incident assessment - Trigger incident response procedures when thresholds met

Incident Response Role: - Receive alerts from monitoring procedures - Classify incidents using severity levels - Execute containment, eradication, and recovery procedures

Transition Criteria (Monitoring → Incident Response):

Escalate to incident response procedures when:

  1. Critical Severity Alert: Immediate escalation, no further triage needed
  2. High Severity Alert with Confirmed Threat: After brief investigation confirms genuine security incident
  3. Medium Severity Alert with Service Impact: If client services affected or data compromise suspected
  4. Multiple Related Alerts: Pattern of alerts suggesting coordinated attack
  5. Client-Reported Security Issue: Always treat as potential incident until ruled out

Handoff Process:

  1. Create Incident Record: 

    Incident ID: INC-YYYY-MM-DD-###
Date/Time: [timestamp of initial detection]
Source: [monitoring alert or manual detection]
Initial Severity: [Critical/High/Medium/Low]
Brief Description: [one-line summary]

  2. Gather Initial Evidence:

  3. Save relevant log file sections
  4. Document affected systems and accounts
  5. Note detection method and indicators

  6. Preserve evidence before containment actions

  7. Notify Incident Handler:

  8. Single operator environment: Self-notification via incident record
  9. Document transition from monitoring to response mode

  10. Set response timer based on severity

  11. Follow Incident Response Procedures:

  12. Refer to Incident Response - Detection and Initial Assessment
  13. Use incident-specific playbooks as appropriate:

Evidence Preservation

Critical for Incident Response:

When escalating to incident response, preserve evidence BEFORE taking containment actions:

# Create incident evidence directory
mkdir -p /root/security/incidents/INC-YYYY-MM-DD-###/

# Preserve relevant logs (adjust date/time range as needed)
cp /var/log/secure /root/security/incidents/INC-YYYY-MM-DD-###/secure.log
cp /var/log/messages /root/security/incidents/INC-YYYY-MM-DD-###/messages.log
cp /var/log/exim_mainlog /root/security/incidents/INC-YYYY-MM-DD-###/exim_mainlog
cp /usr/local/apache/logs/access_log /root/security/incidents/INC-YYYY-MM-DD-###/apache_access.log

# Current system state
ps aux > /root/security/incidents/INC-YYYY-MM-DD-###/processes.txt
netstat -tulpn > /root/security/incidents/INC-YYYY-MM-DD-###/network.txt
w > /root/security/incidents/INC-YYYY-MM-DD-###/logged_in_users.txt
last -20 > /root/security/incidents/INC-YYYY-MM-DD-###/recent_logins.txt

# If malware suspected, preserve infected files before deletion
cp [infected-file] /root/security/incidents/INC-YYYY-MM-DD-###/malware-sample/

Evidence Retention: - Keep all incident evidence for minimum 12 months - GDPR breach incidents: Retain evidence for 3 years minimum - Document chain of custody and analysis performed

Response Feedback to Monitoring

Post-Incident Monitoring Enhancements:

After incident resolution, update monitoring procedures to detect similar incidents in future:

  1. Add Detection Rules:
  2. Create custom log patterns for identified attack vectors
  3. Adjust Fail2Ban filters if new attack method discovered

  4. Update CSF triggers for specific indicators

  5. Lower Alert Thresholds:

  6. If incident wasn't detected promptly, reduce threshold for similar alerts

  7. Balance sensitivity vs. false positive rate

  8. Document Lessons Learned:

  9. Update monitoring procedures in this document
  10. Add indicators of compromise (IOCs) to watch list

  11. Share knowledge in post-incident review

  12. Test Detection:

  13. Verify new monitoring rules would have detected the incident
  14. Simulate similar attack patterns to test alerting

Wazuh SIEM Deployment Preparation

Critical: Post-ApisCP Migration Only

Wazuh deployment is ONLY planned for new ApisCP servers, NOT current cPanel infrastructure.

Reason: Imunify360 (even FREE version) conflicts with Wazuh agents due to both using the /var/ossec directory (OSSEC-based). Current cPanel servers have Imunify360 installed and cannot run Wazuh agents without conflicts.

Strategy: Deploy Wazuh after migrating to ApisCP (new servers without Imunify360). See Wazuh Deployment Project for detailed implementation plan.

Interim Solution: Deploy Grafana + Prometheus + Loki stack for infrastructure monitoring on current servers. See Grafana Monitoring Project.

Current State vs. Wazuh Capabilities

Current Limitations (Addressed by Wazuh):

Current Gap Impact Wazuh Solution
Distributed logs across 3 servers Difficult correlation, time-consuming analysis Centralised log aggregation and indexing
Manual log review required Delayed detection, analyst fatigue Real-time automated threat detection
No file integrity monitoring Undetected backdoors or configuration changes FIM with alerting on suspicious changes
Basic intrusion detection (CSF/Fail2Ban) Misses sophisticated attacks Advanced IDS with threat intelligence
No vulnerability scanning Unknown security gaps Automated vulnerability detection
Reactive security posture Respond after compromise Proactive threat hunting
Limited compliance reporting Manual GDPR/PCI compliance checks Automated compliance dashboards

Enhanced Monitoring with Wazuh:

  1. Centralised Log Aggregation:
  2. All three servers send logs to Wazuh Manager
  3. Unified interface for log search and analysis

  4. Long-term log retention (configurable, 90+ days recommended)

  5. Real-Time Threat Detection:

  6. Pre-built rules for common attack patterns
  7. Custom rules for MDHosting-specific threats
  8. Threat intelligence integration (IP reputation, malware signatures)

  9. Automated alert generation and escalation

  10. File Integrity Monitoring (FIM):

  11. Monitor critical system files (/etc/, /bin/, /sbin/)
  12. Monitor web application directories (/home/*/public_html/)
  13. Monitor cPanel configuration files

  14. Alert on unauthorised modifications with file diffs

  15. Vulnerability Detection:

  16. Automated CVE scanning of installed packages
  17. Integration with vulnerability databases
  18. Prioritised vulnerability reporting

  19. Remediation tracking

  20. Compliance Dashboards:

  21. PCI DSS compliance reporting (if needed for payment processing)
  22. GDPR compliance monitoring (access controls, encryption, data retention)

  23. CIS Benchmarks alignment tracking

  24. Incident Response Integration:

  25. Automated incident creation for high-severity events
  26. Correlation of related events across servers
  27. Timeline visualisation for investigations
  28. Evidence collection and preservation

Wazuh Architecture (Post-ApisCP Migration)

Future Infrastructure

This diagram shows the planned NEW ApisCP servers that will be deployed post-migration, NOT the current cPanel infrastructure. Wazuh agents will only be installed on these new servers.

graph TB
    subgraph "New ApisCP Infrastructure - Post-Migration"
        APIS1[NEW ApisCP Server 1<br/>AlmaLinux 10<br/>~30 Client Accounts<br/>NO Imunify360]
        APIS2[NEW ApisCP Server 2<br/>AlmaLinux 10<br/>Additional capacity<br/>NO Imunify360]
        DNS1[NEW DNS Server 1<br/>PowerDNS<br/>AlmaLinux 10]
        DNS2[NEW DNS Server 2<br/>PowerDNS<br/>AlmaLinux 10]
    end

    subgraph "Wazuh Agents - NEW Servers Only"
        AGENT1[Wazuh Agent<br/>ApisCP Server 1<br/>Log shipping, FIM, Vuln scan]
        AGENT2[Wazuh Agent<br/>ApisCP Server 2<br/>Log shipping, FIM, Vuln scan]
        AGENT3[Wazuh Agent<br/>DNS Server 1<br/>Log shipping, FIM]
        AGENT4[Wazuh Agent<br/>DNS Server 2<br/>Log shipping, FIM]
    end

    subgraph "Wazuh Infrastructure - Option 1: Hetzner CPX11"
        MANAGER[Wazuh Manager<br/>Log processing, rules engine<br/>Alert generation<br/>CPX11: 2 vCPU, 2GB RAM, 40GB]
        INDEXER[Wazuh Indexer<br/>OpenSearch database<br/>Log storage and search<br/>Same CPX11 instance]
        DASHBOARD[Wazuh Dashboard<br/>Web interface<br/>Visualization, reporting<br/>Same CPX11 instance]
    end

    subgraph "Wazuh Infrastructure - Option 2: Separate Components"
        MANAGER2[Wazuh Manager<br/>CPX21: 3 vCPU, 4GB RAM]
        INDEXER2[Wazuh Indexer<br/>CPX21: 3 vCPU, 4GB RAM]
        DASHBOARD2[Wazuh Dashboard<br/>CPX11: 2 vCPU, 2GB RAM]
    end

    APIS1 --> AGENT1
    APIS2 --> AGENT2
    DNS1 --> AGENT3
    DNS2 --> AGENT4

    AGENT1 -->|TLS 1514| MANAGER
    AGENT2 -->|TLS 1514| MANAGER
    AGENT3 -->|TLS 1514| MANAGER
    AGENT4 -->|TLS 1514| MANAGER

    MANAGER --> INDEXER
    INDEXER --> DASHBOARD

    ADMIN[Administrator] -->|HTTPS 443| DASHBOARD
    ADMIN -->|HTTPS 443| DASHBOARD2

    AGENT1 -.->|Option 2| MANAGER2
    AGENT2 -.->|Option 2| MANAGER2
    AGENT3 -.->|Option 2| MANAGER2
    AGENT4 -.->|Option 2| MANAGER2
    MANAGER2 -.-> INDEXER2
    INDEXER2 -.-> DASHBOARD2

    style APIS1 fill:#3498db,stroke:#2c3e50,stroke-width:2px,color:#fff
    style APIS2 fill:#3498db,stroke:#2c3e50,stroke-width:2px,color:#fff
    style DNS1 fill:#3498db,stroke:#2c3e50,stroke-width:2px,color:#fff
    style DNS2 fill:#3498db,stroke:#2c3e50,stroke-width:2px,color:#fff
    style AGENT1 fill:#27ae60,stroke:#2c3e50,stroke-width:2px,color:#fff
    style AGENT2 fill:#27ae60,stroke:#2c3e50,stroke-width:2px,color:#fff
    style AGENT3 fill:#27ae60,stroke:#2c3e50,stroke-width:2px,color:#fff
    style AGENT4 fill:#27ae60,stroke:#2c3e50,stroke-width:2px,color:#fff
    style MANAGER fill:#f39c12,stroke:#2c3e50,stroke-width:2px,color:#fff
    style INDEXER fill:#f39c12,stroke:#2c3e50,stroke-width:2px,color:#fff
    style DASHBOARD fill:#f39c12,stroke:#2c3e50,stroke-width:2px,color:#fff
    style ADMIN fill:#8e44ad,stroke:#2c3e50,stroke-width:2px,color:#fff

Deployment Options:

Option 1: All-in-One (Recommended for <5 agents, lower cost): - Single Hetzner CPX11 server (€4.15/month, £3.60/month) - Wazuh Manager, Indexer, and Dashboard on same instance - Sufficient for 3 monitored servers with moderate log volume - Lower infrastructure cost, simpler management - Total added cost: ~£43/year

Option 2: Separated Components (Better performance, scalability): - Wazuh Manager: CPX21 (€7.95/month, £6.90/month) - Wazuh Indexer: CPX21 (€7.95/month, £6.90/month) - Wazuh Dashboard: CPX11 (€4.15/month, £3.60/month) - Better performance under heavy load, easier scaling - Higher infrastructure cost, more complex management - Total added cost: ~£210/year

Recommended: Start with Option 1 (All-in-One), migrate to Option 2 if performance issues or client count exceeds 50.

Pre-Deployment Checklist

Infrastructure Preparation:

  • Provision Wazuh server (Hetzner CPX11 for All-in-One deployment)
  • Configure network firewall rules (allow port 1514 from monitored servers)
  • Set up DNS record for Wazuh server (e.g., wazuh.mdhosting.internal)
  • Allocate IP address and update network documentation

Monitored Server Preparation (NEW ApisCP Servers Only):

ApisCP Servers Only

Wazuh agents will ONLY be installed on NEW ApisCP servers (AlmaLinux 10) without Imunify360. Do NOT attempt to install on current cPanel servers due to /var/ossec directory conflict.

  • Verify NEW ApisCP servers are deployed (post-migration)
  • Confirm NO Imunify360 installed on new servers
  • Verify sufficient disk space for agent installation (~200MB per agent)
  • Open firewall rules for agent communication (port 1514 to Wazuh Manager)
  • Document log locations and formats on ApisCP servers
  • Identify critical files for FIM monitoring on ApisCP
  • Create backup before agent installation (recommended)

Access and Authentication:

  • Generate SSH keys for Wazuh server access
  • Plan authentication method for Wazuh Dashboard (HTTPS, basic auth initially)
  • Configure email for alert notifications (use existing admin email)
  • Document access credentials in secure location

Monitoring Plan:

  • Define initial rule sets to enable (start with defaults, customise iteratively)
  • List critical directories for FIM monitoring
  • Set alert severity thresholds (Critical, High, Medium, Low)
  • Plan alert escalation and notification preferences
  • Define log retention policy (recommend 90 days minimum)

Documentation:

  • Create detailed Wazuh deployment plan in Wazuh Deployment Project
  • Document Wazuh-specific procedures and workflows
  • Update network architecture documentation with Wazuh integration
  • Create Wazuh troubleshooting guide

Training and Testing:

  • Familiarise with Wazuh documentation and web interface
  • Plan initial testing period (monitor without production alerting)
  • Schedule transition from current monitoring to Wazuh-based workflows
  • Test incident response procedures with Wazuh alerts

Deployment Timeline (Post-ApisCP Migration)

Prerequisite: ApisCP Migration Complete

Wazuh deployment begins ONLY after ApisCP migration is complete and new servers are operational. Estimated start: Q3-Q4 2026 (after Q2-Q3 2026 ApisCP migration).

Phase 1: Planning and Preparation (1-2 weeks after ApisCP migration): - Verify NEW ApisCP servers are stable and operational - Confirm NO Imunify360 on new servers - Complete pre-deployment checklist - Provision Wazuh infrastructure (separate monitoring server) - Document deployment plan in Wazuh Deployment Project

Phase 2: Wazuh Installation (1 week): - Install Wazuh Manager, Indexer, Dashboard on monitoring server - Configure basic settings and authentication - Verify web interface accessibility - Configure email notifications - Set up integration with Grafana (already deployed in Phase 1)

Phase 3: Agent Deployment (1 week): - Install Wazuh agents on NEW DNS servers (lower risk, test first) - Test agent connectivity and log shipping - Install Wazuh agents on NEW ApisCP hosting servers - Verify all agents reporting correctly to Manager

Phase 4: Rule Configuration (2-3 weeks): - Enable default rule sets - Configure file integrity monitoring for critical paths - Create custom rules for MDHosting-specific threats - Tune alert thresholds to reduce false positives

Phase 5: Testing and Tuning (2-3 weeks): - Monitor Wazuh alerts in parallel with current procedures - Adjust rules and thresholds based on false positive rate - Test incident response integration - Document Wazuh-specific workflows

Phase 6: Production Cutover (1 week): - Transition primary monitoring to Wazuh-based workflows - Maintain current procedures as backup during initial period - Update incident response procedures with Wazuh integration - Communicate changes to clients if monitoring services offered

Total Timeline: 8-11 weeks (2-3 months) AFTER ApisCP migration completes

Target Deployment: Q3-Q4 2026 (July-December 2026) - contingent on ApisCP migration completion in Q2-Q3 2026

Monitoring Metrics and Reporting

Key Performance Indicators (KPIs)

Detection Metrics:

Metric Definition Target Current (Baseline)
Mean Time to Detect (MTTD) Average time from event occurrence to detection <1 hour for Critical, <4 hours for High Not measured (manual detection)
False Positive Rate Percentage of alerts that are not genuine threats <10% Unknown (estimate 20-30%)
Alert Volume Total security alerts per week Monitor trend, reduce over time ~50-100 LFD emails/week
Coverage Percentage of infrastructure with monitoring 100% 100% (basic), 0% (advanced)

Response Metrics:

Metric Definition Target Current (Baseline)
Mean Time to Acknowledge (MTTA) Average time from detection to initial response <1 hour for Critical, <4 hours for High Not measured
Mean Time to Contain (MTTC) Average time from detection to containment <2 hours for Critical, <8 hours for High Not measured
Mean Time to Resolve (MTTR) Average time from detection to full resolution <4 hours for Critical, <24 hours for High Not measured
Incident Recurrence Percentage of incidents that recur after resolution <5% Unknown

Security Posture Metrics:

Metric Definition Target Current
Patch Compliance Percentage of systems patched within SLA (Critical: 48h, High: 7d) >95% ~90% (estimate)
Vulnerability Count Total known vulnerabilities (Critical/High severity) <5 Critical, <20 High Unknown (no scanning)
Blocked Attack Attempts Total blocked IPs per week (CSF + Fail2Ban) Monitor trend ~200-300/week (estimate)
Malware Detection Rate Malware detections per month <5 (ideally 0) ~1-2/month

Monitoring Reports

Daily Security Summary (Automated Email - Future with Wazuh):

MDHosting Security Summary - [Date]
=====================================================

CRITICAL ALERTS: 0
HIGH ALERTS: 2
  - SSH brute force from 203.0.113.45 (BLOCKED)
  - WordPress login attempts on client-site.com (ONGOING)

MEDIUM ALERTS: 5
  - Security Advisor: New cPanel update available
  - Disk space 82% on eu1.cp /home partition
  - Mail queue: 156 messages (normal: <100)
  - CSF: 23 temporary IP bans (last 24h)
  - Fail2Ban: 45 SSH bans (last 24h)

SYSTEM STATUS: ALL SERVICES OPERATIONAL
  - eu1.cp: UP, Load: 1.23, Disk: 82%
  - ns1: UP, Load: 0.15, Disk: 45%
  - ns2: UP, Load: 0.12, Disk: 43%

INCIDENTS: 0 open, 1 closed (last 24h)
  - INC-2026-01-06-001: WordPress brute force - RESOLVED

ACTIONS REQUIRED:
  - Review high alerts and take action if needed
  - Monitor WordPress brute force activity
  - Clean up disk space on eu1.cp

Weekly Security Report (Manual - Current):

Prepared every Monday morning, documenting previous week's activity:

  1. Executive Summary:
  2. Overall security posture (good/concerning)
  3. Notable incidents or attacks
  4. Key metrics (alerts, blocks, incidents)

  5. Actions taken

  6. Alert Summary:

  7. Total alerts by severity (Critical/High/Medium/Low)
  8. Top alert types (brute force, scanning, malware, etc.)
  9. Geographic sources of attacks

  10. Trends vs. previous week

  11. Firewall and IDS Activity:

  12. CSF blocks: Temporary and permanent
  13. Fail2Ban bans by service (SSH, cPanel, SMTP)
  14. Top blocked IPs and attack patterns

  15. Firewall rule changes

  16. Authentication and Access:

  17. Failed authentication attempts (SSH, cPanel, email)
  18. Successful administrative logins (review for anomalies)

  19. Account lockouts or suspicious access patterns

  20. Malware and Vulnerabilities:

  21. Malware detections (if any)
  22. Security updates applied
  23. Vulnerability assessment results

  24. Pending patches or updates

  25. System Health:

  26. Service availability (uptime, outages)
  27. Resource utilisation (disk, memory, load)
  28. Backup status (success/failure)

  29. Performance issues or concerns

  30. Actions Taken:

  31. Incidents responded to
  32. Firewall rules updated
  33. Security patches applied

  34. Client notifications sent

  35. Recommendations:

  36. Follow-up actions required
  37. Security improvements needed
  38. Training or procedure updates

Monthly Security Dashboard (Future with Wazuh):

Visual dashboard with key metrics:

  • Alert trend charts (by severity and type)
  • Top attack sources (geographic map)
  • Service availability and uptime
  • Patch compliance status
  • Vulnerability trends (count and severity)
  • Incident summary (count, resolution time, types)
  • Compliance status (GDPR, PCI DSS if applicable)

Quarterly Security Review (Comprehensive):

Detailed analysis and strategic planning document covering:

  1. Threat Landscape Analysis:
  2. Observed attack trends over quarter
  3. New threats and vulnerabilities identified

  4. Industry threat intelligence integration

  5. Security Control Effectiveness:

  6. Evaluation of detection capabilities (MTTD, false positives)
  7. Incident response effectiveness (MTTA, MTTC, MTTR)

  8. Tool and process improvements needed

  9. Incidents and Lessons Learned:

  10. Incident summary (count, types, severity)
  11. Root cause analysis for major incidents
  12. Procedure updates based on lessons learned

  13. Training gaps identified

  14. Compliance Status:

  15. GDPR compliance review
  16. Regulatory changes impacting operations

  17. Audit findings and remediation

  18. Security Roadmap Progress:

  19. Planned initiatives completed
  20. Projects in progress (e.g., Wazuh deployment)
  21. Delays or issues encountered

  22. Updated timeline and priorities

  23. Risk Assessment Update:

  24. Changes to threat model
  25. New risks identified
  26. Risk mitigation progress

  27. Accepted risks documentation

  28. Recommendations and Budget:

  29. Security improvements for next quarter
  30. Tool or service requirements
  31. Budget allocation for security initiatives
  32. Resource needs (time, expertise, external help)

Report Distribution

Current (Single Operator): - Weekly report: Personal review and documentation (maintain log for future reference) - Monthly dashboard: Not currently implemented (future with Wazuh) - Quarterly review: Comprehensive document for business planning and compliance

Future (Potential Client Service): - Weekly summary: Opt-in client service (security monitoring package) - Monthly dashboard: Client portal access (premium service) - Quarterly review: Business clients requiring compliance reporting

Appendices

A. Quick Reference Commands

System Status: 

# Check all critical services at once
systemctl status httpd mysqld exim dovecot named fail2ban csf lfd

# Resource monitoring (one-liner)
echo "=== Load ===" && uptime && echo "=== Disk ===" && df -h / /home && echo "=== Memory ===" && free -h

# Network connections
netstat -tunlp | grep LISTEN          # Listening services
netstat -tunp | grep ESTABLISHED | wc -l  # Active connections count

Security Checks: 

# Quick security status check
csf -l | head -20                     # Recent CSF blocks
fail2ban-client status | grep "Total banned"  # Fail2Ban ban counts
grep "FOUND" /var/log/clamav/clamd.log | tail -5  # Recent malware detections
tail -20 /var/log/lfd.log             # Recent LFD alerts

Authentication Monitoring: 

# Failed logins (last 24 hours)
grep "Failed password" /var/log/secure | grep "$(date +%b\ %e)"
grep "FAILED LOGIN" /usr/local/cpanel/logs/login_log | grep "$(date +%Y-%m-%d)"
grep "authentication failed" /var/log/maillog | grep "$(date +%b\ %e)"

# Successful logins (last 24 hours)
grep "Accepted publickey" /var/log/secure | grep "$(date +%b\ %e)"
last -20

Incident Investigation: 

# Investigate specific IP
grep "[IP-ADDRESS]" /var/log/secure
grep "[IP-ADDRESS]" /usr/local/apache/logs/access_log
csf -g [IP-ADDRESS]

# Check for compromised accounts (high email volume)
exim -bp | exiqsumm | head -20

# Find recently modified files (potential backdoors)
find /home/*/public_html/ -type f -mtime -1 -name "*.php" -ls

Log Analysis: 

# Top IPs by request count (web)
awk '{print $1}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -20

# Top blocked IPs (firewall)
grep "Blocked" /var/log/lfd.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -10

# Error rate by hour (web server)
grep "$(date +%d/%b/%Y)" /usr/local/apache/logs/error_log | awk '{print $4}' | cut -d: -f2 | sort | uniq -c

B. Log File Locations Reference

System Logs: 

/var/log/messages          - General system messages
/var/log/secure            - Authentication and authorization
/var/log/cron              - Cron job execution
/var/log/boot.log          - System boot messages

Web Server Logs: 

/usr/local/apache/logs/access_log           - Main server HTTP access
/usr/local/apache/logs/error_log            - Main server HTTP errors
/usr/local/apache/logs/suexec_log           - CGI execution log
/usr/local/apache/domlogs/[domain]          - Per-domain access logs
/usr/local/apache/domlogs/[domain].error    - Per-domain error logs

Email Logs: 

/var/log/exim_mainlog      - SMTP transactions (sent/received email)
/var/log/exim_rejectlog    - Rejected email (spam, policy violations)
/var/log/exim_paniclog     - Critical Exim errors (should be empty)
/var/log/maillog           - IMAP/POP3 access and authentication

Security Tool Logs: 

/var/log/lfd.log                           - Login Failure Daemon (CSF component)
/var/log/fail2ban.log                      - Fail2Ban activity and bans
/var/log/clamav/clamd.log                  - ClamAV daemon and scan results
/var/log/clamav/freshclam.log              - Virus definition updates

cPanel Logs: 

/usr/local/cpanel/logs/access_log          - cPanel/WHM web interface access
/usr/local/cpanel/logs/error_log           - cPanel/WHM errors
/usr/local/cpanel/logs/login_log           - cPanel user logins
/usr/local/cpanel/logs/stats_log           - Statistics generation
/usr/local/cpanel/logs/cphulkd.log         - cPanel brute force protection

Application-Specific Logs: 

/home/[user]/access-logs/[domain]          - User-accessible domain logs
/home/[user]/tmp/                          - PHP error logs (if enabled per-domain)
/var/log/mysqld.log                        - MySQL server log
/var/log/named/                            - DNS server logs (if query logging enabled)

C. Monitoring Checklist (Daily/Weekly/Monthly)

Daily Checklist (15 min):

  • Check overnight LFD alerts: tail -100 /var/log/lfd.log
  • Verify all services running: systemctl status httpd mysqld exim dovecot named fail2ban
  • Check disk space: df -h | grep -vE "tmpfs|devtmpfs"
  • Review mail queue size: exim -bpc (target: <100)
  • Check for malware: grep "FOUND" /var/log/clamav/clamd.log | grep "$(date +%Y-%m-%d)"
  • Review authentication failures: grep "Failed password" /var/log/secure | grep "$(date +%b\ %e)" | wc -l

Weekly Checklist (30 min):

  • Run Security Advisor (WHM → Security Centre)
  • Review CSF/Fail2Ban statistics: csf -s and fail2ban-client status
  • Analyse web attack patterns: Check for SQL injection, XSS, brute force attempts
  • Review SSL certificate status: /scripts/checkcertificates
  • Check for security updates: dnf check-update --security
  • Review client account activity for anomalies
  • Update weekly security report

Monthly Checklist (1-2 hours):

  • Comprehensive user account audit
  • Apply security patches and updates
  • Full system malware scan: clamscan -r -i /home/
  • Review and clean up firewall allow/deny lists
  • Verify backup completion and integrity
  • Test backup restoration (sample files)
  • Review firewall rules alignment with network architecture
  • Update security documentation with any procedure changes
  • Prepare monthly security summary report

Quarterly Checklist (2-4 hours):

  • Comprehensive security posture assessment
  • Threat landscape review and threat model update
  • Security tool effectiveness evaluation
  • GDPR compliance audit
  • Review and test incident response procedures (tabletop exercise)
  • Security roadmap progress review
  • Long-term planning (next quarter security initiatives)
  • Prepare quarterly security review report

D. Contact Information for Escalation

Internal: - Incident Handler: Matthew Dinsdale (Director) - Email: admin@mdhosting.co.uk - After-Hours: Same (single operator, no separate on-call)

External Vendors:

Vendor Service Contact Method Response Time Use Case
Hetzner Support Infrastructure hosting Support portal: https://robot.hetzner.com/ <24h standard, <4h urgent Server issues, network problems, DDoS attacks
cPanel Support Control panel https://support.cpanel.net/ 24/7 (ticket-based, <4h P1) cPanel/WHM issues, security vulnerabilities
AlmaLinux Security Operating system https://wiki.almalinux.org/Contribute.html#help Community (best-effort) Security vulnerabilities, CVE information
Let's Encrypt SSL certificates https://letsencrypt.org/docs/ Community forums Certificate issues, autorenewal failures

Regulatory Authorities:

Authority Purpose Contact Use Case
ICO (Information Commissioner's Office) GDPR compliance, data breaches Report breach: https://ico.org.uk/make-a-complaint/data-protection-complaints/data-protection-complaints/ Data breach notification (72-hour requirement)
Action Fraud (UK) Cybercrime reporting Report online: https://www.actionfraud.police.uk/ Cybercrime incidents, fraud
NCSC (National Cyber Security Centre) Cyber incident reporting Report: https://www.ncsc.gov.uk/section/keep-up-to-date/report-scam-email Significant cyber incidents affecting UK infrastructure

Security Resources:

Resource Purpose URL
OWASP Web application security guidance https://owasp.org
Wazuh Documentation SIEM documentation (future) https://documentation.wazuh.com
CIS Benchmarks Security configuration baselines https://www.cisecurity.org/cis-benchmarks
CVE Database Vulnerability information https://cve.mitre.org
AlmaLinux Security Advisories OS security updates https://errata.almalinux.org

For complete vendor contact details and procedures, see Reference - Contacts.

Document Control

Version History:

Version Date Author Changes
1.0 January 2026 Claude Sonnet 4.5 Initial comprehensive security monitoring documentation

Review Schedule:

  • Quarterly Review: End of Q1, Q2, Q3, Q4 (March, June, September, December)
  • Post-Incident Review: After any security incident (update procedures as needed)
  • Post-Wazuh Deployment: Major revision after Wazuh SIEM deployment (Q1 2025)
  • Annual Review: Comprehensive review and update (January each year)

Next Review Date: March 2026 (or upon Wazuh deployment, whichever comes first)

Related Documentation:

Document Status: ✅ Complete - Comprehensive operational security monitoring procedures Classification: Confidential - Internal Use Only Document Owner: MDHosting Ltd Director (Matthew Dinsdale)

Last updated: January 2026