Small and medium-sized businesses increasingly operate mission-critical Joomla, WordPress and Magento websites on virtual private servers. These platforms combine public Internet exposure, Linux operating systems, NGINX, PHP, databases, Docker containers, third-party extensions, APIs, administrative interfaces and ecommerce services.

This architecture creates a security problem that cannot be solved by a single firewall, antivirus product or vulnerability scanner.

A website may remain online while malicious files are being inserted. A firewall may block some traffic while compromised credentials are being used. Docker may isolate applications while an exposed Docker daemon creates another attack surface. A vulnerability scanner may identify weaknesses without explaining whether they are being exploited.

Securing Joomla, WordPress and Magento VPS Infrastructure with Wazuh, Docker and AbuseIPDB-A Layered Continuous Security Architecture for SME Ecommerce and Web Infrastructure

Research, Architecture and Implementation Guide

Organizations:
KeenComputer.com — Engineered IT Solutions
IAS-Research.com — Research, Innovation and Engineering
KeenDirect.com — Infrastructure and Technology Supply

Location: INDIA, USA, UK, Canada, Middle East, BRICS Countries

Abstract

Small and medium-sized businesses increasingly operate mission-critical Joomla, WordPress and Magento websites on virtual private servers. These platforms combine public Internet exposure, Linux operating systems, NGINX, PHP, databases, Docker containers, third-party extensions, APIs, administrative interfaces and ecommerce services.

This architecture creates a security problem that cannot be solved by a single firewall, antivirus product or vulnerability scanner.

A website may remain online while malicious files are being inserted. A firewall may block some traffic while compromised credentials are being used. Docker may isolate applications while an exposed Docker daemon creates another attack surface. A vulnerability scanner may identify weaknesses without explaining whether they are being exploited.

This paper proposes a Layered Continuous Security Architecture combining:

• Linux VPS hardening;
• UFW/firewall controls;
• NGINX security;
• Docker isolation;
• Wazuh security monitoring;
• File Integrity Monitoring;
• authentication monitoring;
• NGINX/application log analysis;
• Docker event monitoring;
• Joomla security monitoring;
• WordPress security monitoring;
• Magento security monitoring;
• AbuseIPDB IP reputation;
• controlled Active Response;
• backups and recovery;
• continuous security improvement.

The central research proposition is:

For SME web and ecommerce infrastructure, effective cybersecurity should be engineered as a continuous feedback system in which prevention, isolation, detection, external threat intelligence, response and recovery operate together.

Wazuh provides the local security-monitoring and response platform, while AbuseIPDB adds external IP-reputation context. Docker provides application isolation, but is treated as a security boundary requiring its own monitoring and hardening rather than as a complete security solution.

The resulting model is:

Prevention → Isolation → Detection → Threat Intelligence → Correlation → Response → Recovery → Learning

1. Introduction

Modern SMEs increasingly depend on websites for:

• sales;
• customer communication;
• lead generation;
• ecommerce;
• online payments;
• product catalogues;
• customer accounts;
• business operations;
• marketing;
• APIs;
• internal integrations.

Three particularly important open-source platforms are:

• Joomla;
• WordPress;
• Magento Open Source.

They have different architectures but share many infrastructure dependencies:

Internet | v DNS / CDN / WAF | v NGINX | v PHP-FPM | +----------------+ | | Joomla WordPress | Magento | MariaDB/MySQL | Redis/OpenSearch

When Docker is introduced:

Linux VPS | Docker Engine | +-- NGINX +-- PHP +-- Joomla +-- WordPress +-- Magento +-- MariaDB +-- Redis +-- OpenSearch

The resulting infrastructure contains many layers that can generate security events.

The challenge is therefore not simply:

“How do I stop attacks?”

It is:

How do I continuously understand what is happening, determine what matters, respond appropriately, and recover when prevention fails?

2. Research Problem

The research problem addressed by this paper is:

How can an SME securely operate Joomla, WordPress and Magento applications on VPS infrastructure using Docker while continuously detecting suspicious behavior, correlating local events with external IP reputation, responding to incidents and maintaining recoverability?

The problem contains several subproblems.

2.1 Visibility

Administrators may have logs distributed across:

• Linux;
• SSH;
• NGINX;
• PHP-FPM;
• Joomla;
• WordPress;
• Magento;
• MariaDB;
• Redis;
• OpenSearch;
• Docker;
• UFW.

Without centralized monitoring, these events remain fragmented.

2.2 File Integrity

A compromised application may involve:

• modified PHP files;
• injected JavaScript;
• altered configuration;
• unauthorized plugins;
• malicious cron jobs;
• web shells;
• modified templates.

The administrator needs to know:

What changed?

2.3 Authentication

Security events can originate from:

• SSH;
• CMS administrators;
• Magento administrators;
• WordPress administrators;
• APIs;
• database accounts.

2.4 External Threat Intelligence

A local system may identify:

203.0.113.50

as suspicious.

But the administrator may also want to know whether that IP has a history of reported abuse.

This is where AbuseIPDB can provide additional context.

3. Research Theory

3.1 Layered Continuous Security Theory

This paper proposes the following security model:

Layer 1 — Prevention

Prevent attacks where practical.

Layer 2 — Isolation

Limit the impact of compromise.

Layer 3 — Detection

Detect events that prevention fails to stop.

Layer 4 — Threat Intelligence

Add external context to locally observed events.

Layer 5 — Correlation

Combine multiple security signals.

Layer 6 — Response

Contain and investigate incidents.

Layer 7 — Recovery

Restore trusted operation.

Layer 8 — Learning

Use incidents to improve the architecture.

The model becomes:

THREAT | v PREVENTION | +-----+-----+ | | Blocked Attack | | | v | ISOLATION | | | v | DETECTION | | | v | THREAT INTELLIGENCE | | | v | CORRELATION | | | v | RESPONSE | | | v | RECOVERY | | +-----------+ | v LEARNING | v IMPROVED SECURITY

4. Why This Theory Is Needed

4.1 Prevention Alone Is Insufficient

A firewall cannot detect every application-level attack.

A patched application can still be compromised through:

• stolen credentials;
• vulnerable extensions;
• insecure custom code;
• configuration errors;
• exposed services.

4.2 Detection Alone Is Insufficient

Wazuh may detect a modified file.

But detection does not automatically mean the underlying vulnerability has been fixed.

4.3 Reputation Alone Is Insufficient

AbuseIPDB reputation is useful context but should not be treated as definitive proof of compromise.

An IP can be:

• shared;
• dynamically assigned;
• behind NAT;
• a VPN;
• a cloud address;
• incorrectly reported.

Therefore:

Reputation is evidence, not a verdict.

5. What Problems Does the Architecture Address?

The architecture addresses:

Unauthorized file modification

Wazuh File Integrity Monitoring can identify changes to monitored files.

Suspicious authentication

SSH and application authentication events can be centralized.

Web scanning

NGINX access logs provide visibility into suspicious requests.

Docker changes

Container creation, deletion and other Docker events can be monitored through Wazuh's Docker integration. (Wazuh Documentation)

Vulnerability exposure

Security teams can correlate software vulnerabilities with observed activity.

IP reputation

AbuseIPDB provides external reputation information through its API. (AbuseIPDB Documentation)

Incident response

Wazuh Active Response can support controlled firewall actions. (Wazuh Documentation)

Recovery

Backups and clean rebuild procedures provide the final security layer.

6. What the Architecture Does Not Cure

The system does not automatically cure:

• vulnerable Joomla extensions;
• vulnerable WordPress plugins;
• vulnerable Magento extensions;
• insecure custom PHP;
• stolen passwords;
• weak authentication;
• SQL injection vulnerabilities;
• insecure APIs;
• poor Docker configuration;
• exposed databases;
• compromised developer accounts;
• social engineering;
• poor backup practices.

The architecture improves the organization's ability to prevent, detect, investigate and respond.

7. Defense-in-Depth Architecture

The recommended architecture is:

INTERNET | v DNS / CDN | v WAF / NGINX | v UFW FIREWALL | v LINUX VPS HOST | DOCKER ENGINE | +--------------------+--------------------+ | | | v v v Joomla WordPress Magento | | | +--------------------+--------------------+ | Database Services | +--------+--------+ | | MariaDB Redis | OpenSearch | v WAZUH AGENT | v WAZUH MANAGER | +----------+----------+ | | v v WAZUH INDEXER DASHBOARD | v IP REPUTATION AbuseIPDB | v INVESTIGATION / RESPONSE

8. Recommended Production Architecture

For production, the preferred design is to separate the security infrastructure from the application infrastructure.

Production VPS

Runs:

• NGINX;
• Joomla;
• WordPress;
• Magento;
• PHP;
• databases;
• Redis;
• OpenSearch;
• Docker.

Security VPS

Runs:

• Wazuh manager;
• Wazuh indexer;
• Wazuh dashboard.

Wazuh officially supports Docker deployment of its central components. Its current Docker documentation describes single-node and multi-node deployments. (Wazuh Documentation)

This provides:

Internet | v Production VPS | Wazuh Agent | encrypted link | v Security VPS | +----------+----------+ | | | Manager Indexer Dashboard

This separation helps prevent an application compromise from simultaneously compromising the monitoring infrastructure.

9. Docker as a Security Boundary

Docker provides process and filesystem isolation using Linux kernel capabilities such as namespaces and control groups. Docker's own security documentation emphasizes that the Docker daemon and container configuration remain part of the attack surface. (Docker Documentation)

Therefore:

Docker is an isolation technology, not a complete security strategy.

Security controls must include:

• least privilege;
• minimal images;
• controlled networks;
• secrets management;
• restricted mounts;
• resource limits;
• image updates;
• Docker daemon protection;
• host monitoring;
• container monitoring.

Docker Rootless mode can further reduce risk by allowing the daemon and containers to run without root privileges where the environment supports it. (Docker Documentation)

10. Wazuh Architecture

Wazuh consists of:

1. Wazuh agent;
2. Wazuh server/manager;
3. Wazuh indexer;
4. Wazuh dashboard.

The Wazuh agent runs on monitored endpoints and collects security information.

The manager analyzes events.

The indexer stores security data.

The dashboard provides centralized analysis.

Wazuh currently provides official Docker images for its central components and agents. (Wazuh Documentation)

11. AbuseIPDB Architecture

AbuseIPDB becomes the external intelligence layer.

Wazuh Alert | v Source IP | v AbuseIPDB CHECK API | v Reputation Information | v Wazuh / Analyst | v Decision

The AbuseIPDB API provides an IP check endpoint and an endpoint for submitting reports. (AbuseIPDB Documentation)

12. Security Decision Model

The recommended model is:

Wazuh Alert | v Source IP | v Trusted IP? / \ YES NO | | Allow Reputation /Log Check | +-------+-------+ | | Low High | | Monitor Investigate | v Correlate Events | +---------+---------+ | | Insufficient Strong evidence | | Monitor Block | v Review / Report

This avoids indiscriminate blocking.

13. Hands-On Laboratory

13.1 Lab Objectives

The laboratory will implement:

• Ubuntu VPS;
• Docker;
• Wazuh;
• Wazuh agent;
• NGINX;
• UFW;
• Joomla;
• WordPress;
• Magento;
• Docker monitoring;
• File Integrity Monitoring;
• AbuseIPDB;
• Active Response;
• backup and recovery.

14. Prerequisites

Recommended environment:

Application VPS

• Ubuntu LTS;
• 4+ CPU cores;
• 8–16 GB RAM depending on workload;
• SSD/NVMe;
• static public IP;
• Docker;
• NGINX;
• UFW.

Security VPS

For a small laboratory:

• 4 CPU cores;
• 8–16 GB RAM;
• SSD;
• static IP.

Production sizing should be determined from:

• event rate;
• number of agents;
• retention;
• index size;
• search workload.

15. Step 1 — Update the Application VPS

sudo apt update sudo apt upgrade -y sudo apt autoremove -y

Reboot when required:

sudo reboot

Verify:

uname -a lsb_release -a

16. Step 2 — Configure UFW

Install:

sudo apt install ufw -y

Allow SSH:

sudo ufw allow 22/tcp

Allow HTTPS:

sudo ufw allow 443/tcp

Allow HTTP where required:

sudo ufw allow 80/tcp

Enable:

sudo ufw enable

Check:

sudo ufw status verbose

Only expose services that are genuinely required.

Do not expose:

• MariaDB;
• Redis;
• OpenSearch;
• Docker daemon;
• internal application ports.

17. Step 3 — SSH Hardening

Use SSH keys.

After confirming key-based access works, disable password authentication where operationally appropriate.

Example:

/etc/ssh/sshd_config

Relevant settings may include:

PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes

Validate:

sudo sshd -t

Restart:

sudo systemctl restart ssh

Always keep an existing administrative session open while testing SSH changes.

18. Step 4 — Install Docker

Use Docker's official installation procedure rather than an unofficial package source.

After installation:

docker version docker compose version

Verify:

docker ps

Docker security must include review of the daemon attack surface and container configuration. (Docker Documentation)

19. Step 5 — Docker Network Design

Create a private application network:

docker network create webnet

Example conceptual architecture:

Internet | NGINX | webnet | +-------+---------+ | | | PHP Joomla WordPress | Magento | Database

Database containers should not be published directly to the Internet.

20. Step 6 — Deploy Wazuh Security Infrastructure

For the security VPS, use the official Wazuh Docker deployment.

Wazuh provides a Docker deployment repository and current versioned Compose configurations. The current documentation shows the Wazuh Docker repository and versioned releases; at the time of this paper's preparation the documentation references Wazuh 4.14.7. Always verify the current release before deployment. (Wazuh Documentation)

Clone the official repository:

git clone https://github.com/wazuh/wazuh-docker.git cd wazuh-docker

Select the appropriate current release according to the Wazuh documentation.

For example:

git checkout v4.14.7

Then enter the single-node deployment directory:

cd single-node

Generate certificates using the official procedure.

Start:

docker compose up -d

Verify:

docker compose ps

Wazuh documents docker compose ps as a method of checking the deployed services. (Wazuh Documentation)

21. Do Not Expose the Wazuh Dashboard Unnecessarily

The dashboard should not simply be placed on the open Internet.

Preferred options include:

• VPN;
• restricted firewall rules;
• trusted administrator IP ranges;
• reverse proxy with TLS;
• private network.

The security dashboard is administrative infrastructure and should be treated accordingly.

22. Step 7 — Install Wazuh Agent

Install the Wazuh agent on the application VPS.

The agent communicates with the Wazuh manager.

For a Docker host, the preferred production design is generally to run the Wazuh agent on the host rather than only inside an application container.

Wazuh explicitly notes that a containerized agent cannot directly monitor the host system. (Wazuh Documentation)

Therefore:

Docker Host | +-- Wazuh Agent | +-- Docker Engine | +-- Joomla +-- WordPress +-- Magento

23. Step 8 — Monitor Linux Authentication

The Wazuh agent should collect authentication/security logs.

Typical sources include:

/var/log/auth.log /var/log/syslog

Depending on the Linux distribution and logging configuration, exact paths may differ.

The objective is to detect:

• failed SSH authentication;
• successful login;
• privilege escalation;
• suspicious user creation;
• authentication anomalies.

24. Step 9 — File Integrity Monitoring

Critical directories should be monitored.

Examples:

Joomla

/var/www/joomla

WordPress

/var/www/wordpress

Magento

/var/www/magento

Important Magento configuration includes:

app/etc/env.php app/etc/config.php

Critical web-server configuration should also be monitored.

FIM should focus on high-value locations rather than blindly monitoring the entire filesystem.

25. Step 10 — Establish a Baseline

A fundamental research principle is:

A security system must understand normal change before it can reliably identify abnormal change.

Therefore, record:

• deployment dates;
• software updates;
• plugin installations;
• theme updates;
• Magento Composer updates;
• configuration changes;
• Docker image changes;
• administrator changes.

This reduces false positives.

26. Step 11 — Monitor NGINX

NGINX logs are among the most valuable sources of web security information.

Typical locations:

/var/log/nginx/access.log /var/log/nginx/error.log

Monitor:

• HTTP status;
• source IP;
• URI;
• request method;
• user agent;
• frequency;
• repeated errors.

Potential indicators include repeated requests for:

/wp-login.php /xmlrpc.php /administrator/ /.env /.git/ /vendor/ /app/etc/env.php

A single request is not necessarily evidence of compromise.

Repeated patterns provide stronger evidence.

27. Step 12 — Joomla Monitoring

Monitor:

configuration.php administrator/ components/ plugins/ modules/ templates/ media/

Security events include:

• administrator login failures;
• unauthorized file changes;
• new PHP files;
• extension changes;
• template changes;
• suspicious uploads.

The goal is not to assume every modification is malicious.

The objective is:

Detect unexpected changes quickly enough to investigate them.

28. Step 13 — WordPress Monitoring

Monitor:

wp-config.php wp-admin/ wp-content/plugins/ wp-content/themes/ wp-content/uploads/

Pay particular attention to:

• plugin installation;
• plugin modification;
• theme modification;
• PHP files in upload directories;
• administrator accounts;
• repeated login failures;
• XML-RPC traffic.

WordPress security should follow the platform's official hardening and security guidance in addition to infrastructure monitoring.

29. Step 14 — Magento Monitoring

Magento deserves special treatment because ecommerce systems process business-critical transactions.

Monitor:

app/ app/etc/ app/etc/env.php pub/ var/ generated/ vendor/ composer.json composer.lock

Also monitor:

• NGINX;
• PHP-FPM;
• MariaDB;
• Redis;
• OpenSearch;
• cron;
• queue consumers.

Adobe's current Commerce security guidance emphasizes patching, secure Admin access, MFA, secure extensions/custom code, WAF protection and backup/rollback procedures. (Experience League)

30. Magento Security Principles

Adobe currently recommends, among other controls:

• MFA;
• secure SSH;
• non-default Admin URLs;
• strong password controls;
• secure extensions;
• regular updates;
• WAF;
• HTTPS;
• backups and rollback. (Experience League)

Therefore Wazuh should complement—not replace—Magento security controls.

31. Step 15 — Docker Monitoring

Wazuh provides a Docker listener for monitoring Docker activity.

The official documentation describes monitoring:

• Docker server;
• containers;
• network activity;
• filesystem changes;
• process activity;
• container events.

The Wazuh agent runs on the Docker host and forwards Docker events to the Wazuh server. (Wazuh Documentation)

Enable:

<wodle name="docker-listener"> <disabled>no</disabled> </wodle>

Then restart:

sudo systemctl restart wazuh-agent

The exact Python Docker dependency should follow the current Wazuh documentation for the installed Wazuh version. (Wazuh Documentation)

32. What Docker Events Should Be Investigated?

Examples:

container created container started container stopped container deleted image pulled network changed unexpected process unexpected mount

For example:

Production | +-- Magento container | +-- MariaDB | +-- Redis

If an unknown container appears:

unknown container | v Wazuh alert | v investigation

This is considerably more useful than simply monitoring whether Docker is "up."

33. Step 16 — AbuseIPDB Integration

Create an AbuseIPDB account and obtain an API key according to its current API documentation.

The API provides an IP check endpoint.

Example documented API pattern:

curl -G https://api.abuseipdb.com/api/v2/check \ --data-urlencode "ipAddress=IP_ADDRESS" \ -d maxAgeInDays=90 \ -H "Key: YOUR_API_KEY" \ -H "Accept: application/json"

The official AbuseIPDB API documentation documents the /check endpoint and the /report endpoint. (AbuseIPDB Documentation)

Do not put API keys directly into:

• public Git repositories;
• Docker images;
• website source code;
• publicly readable configuration.

Use protected secrets.

34. Step 17 — AbuseIPDB Investigation Workflow

When Wazuh identifies suspicious activity:

Wazuh Alert | v Extract IP | v AbuseIPDB Check | v Review Reputation | v Correlate Local Events

Investigate:

• number of requests;
• time window;
• targeted URLs;
• HTTP methods;
• authentication failures;
• FIM events;
• container events.

35. Step 18 — Automated Blocking

Automated blocking should be introduced gradually.

Recommended maturity model:

Phase 1

Log only.

Phase 2

Reputation lookup.

Phase 3

Alert correlation.

Phase 4

Manual blocking.

Phase 5

Temporary automated blocking.

Phase 6

Automated response with allowlists and rollback.

This reduces the danger of false positives.

36. Wazuh Active Response

Wazuh provides Active Response mechanisms including firewall-based response scripts. (Wazuh Documentation)

A conceptual workflow is:

High-confidence alert | v Source IP identified | v Allowlist check | v Temporary firewall block | v Incident investigation | v Expire / maintain / remove block

The block should be proportional to the evidence.

37. Step 19 — AbuseIPDB Reporting

If local evidence demonstrates abusive behavior, the IP can be reported through the AbuseIPDB API.

The documented API uses the /report endpoint. (AbuseIPDB Documentation)

Conceptual command:

curl https://api.abuseipdb.com/api/v2/report \ --data-urlencode "ip=ATTACKER_IP" \ -d categories=CATEGORIES \ --data-urlencode "comment=Observed abusive activity" \ -H "Key: YOUR_API_KEY" \ -H "Accept: application/json"

Only report activity that has actually been observed.

Maintain internal evidence for the report.

38. Evidence Collection

For every significant incident, preserve:

timestamp source IP destination hostname URI HTTP method HTTP status user agent Wazuh rule authentication events FIM events Docker events system changes administrator actions

This provides a defensible incident record.

39. Incident Response Theory

The response model is:

Phase 1 — Detect

Identify the event.

Phase 2 — Validate

Determine whether it is:

• expected;
• suspicious;
• malicious;
• false positive.

Phase 3 — Contain

Examples:

• block IP;
• disable account;
• isolate container;
• remove public exposure.

Phase 4 — Investigate

Determine:

• entry point;
• affected system;
• persistence;
• changed files;
• stolen credentials;
• lateral movement.

Phase 5 — Eradicate

Remove:

• malicious files;
• unauthorized accounts;
• persistence;
• compromised containers;
• vulnerable software.

Phase 6 — Recover

Restore trusted infrastructure.

Phase 7 — Learn

Update:

• rules;
• firewall;
• WAF;
• passwords;
• patches;
• Docker configuration;
• monitoring.

40. Compromise Response for Joomla

If Joomla is suspected to be compromised:

1. Preserve evidence.
2. Record current system state.
3. Restrict access.
4. Review administrator accounts.
5. Review extensions.
6. Review recently modified files.
7. Review NGINX logs.
8. Review Wazuh FIM alerts.
9. Search for unauthorized PHP files.
10. Review scheduled tasks.
11. Reinstall trusted core files.
12. Remove compromised extensions.
13. Reset credentials.
14. Restore clean content where necessary.
15. Rebuild if trust cannot be established.

41. Compromise Response for WordPress

Review:

wp-admin wp-content/plugins wp-content/themes wp-content/uploads wp-config.php

Look for:

• unknown administrators;
• modified plugins;
• modified themes;
• PHP files in uploads;
• malicious JavaScript;
• suspicious scheduled tasks;
• unusual database users.

If system integrity cannot be established, a clean rebuild may be safer than attempting to repair every modified file.

42. Compromise Response for Magento

Adobe's current incident-response guidance recommends diagnosing the installation, cleaning malicious code, removing unknown Admin users, resetting credentials, protecting/updating the installation and following an upgrade/recovery process. (Experience League)

For Magento:

1. Put the store into controlled maintenance.
2. Preserve evidence.
3. Review Admin accounts.
4. Review env.php.
5. Review Composer dependencies.
6. Review app/.
7. Review pub/.
8. Review media uploads.
9. Review cron.
10. Review database changes.
11. Review NGINX/PHP logs.
12. Review Wazuh alerts.
13. Remove unauthorized code.
14. Patch vulnerabilities.
15. Rotate credentials.
16. Restore from trusted backup where appropriate.
17. Validate checkout and payment integration.
18. Return to production only after verification.

43. Backups Are Part of Security

A security system without recovery is incomplete.

Recommended backup model:

Production | +--> Daily database backup | +--> File backup | +--> Configuration backup | +--> Docker configuration | +--> Off-site backup

Use multiple generations:

Daily Weekly Monthly

Backups must be protected from the production server.

44. Backup Testing

A backup is not proven until it has been restored.

Test:

Backup | v Restore | v Database validation | v Application validation | v Login | v Test transaction

Record the result.

45. Clean Rebuild Strategy

When compromise is extensive:

Compromised VPS | v Evidence | v New VPS | v Harden OS | v Install Docker | v Deploy clean applications | v Restore trusted data | v Patch | v Wazuh enrollment | v Security validation | v Production

A clean rebuild is often preferable to attempting to establish trust in an extensively compromised operating environment.

46. Security Testing

The laboratory should test detection without performing destructive attacks.

Test 1 — File modification

Create a benign test file in a monitored directory.

Expected:

FIM event | v Wazuh alert

Test 2 — Failed authentication

Perform controlled failed SSH authentication from a test system.

Expected:

authentication event | v Wazuh

Test 3 — Docker event

Create a harmless test container:

docker run --rm hello-world

Expected:

Docker event | v Wazuh

Test 4 — Web request

Generate controlled requests to known test paths.

Expected:

NGINX log | v Wazuh

Test 5 — IP reputation

Use a known test IP or authorized laboratory IP when evaluating the AbuseIPDB workflow.

Never test against third-party systems without authorization.

47. False Positive Management

Security monitoring produces noise.

Examples:

WordPress update Magento deployment Joomla extension installation Docker image update administrator login security scan backup job

These may look suspicious to a monitoring system.

Therefore maintain:

Change calendar

Record:

• deployment;
• update;
• maintenance;
• administrator activity.

Allowlist

Record trusted IPs and services.

Baseline

Document expected behavior.

Rule tuning

Adjust thresholds carefully.

48. Security Metrics

The SME should measure:

Mean Time to Detect — MTTD

Detection time - attack time

Mean Time to Respond — MTTR

Response completion - detection

Monitoring Coverage

Monitored assets / total assets

FIM Coverage

Critical directories monitored / critical directories identified

Backup Recovery Rate

Successful restores / restore tests

Alert Fidelity

Useful alerts / total alerts

These metrics help management determine whether the security program is improving.

49. Security Maturity Model

Level 1 — Basic

• UFW;
• SSH keys;
• HTTPS;
• backups.

Level 2 — Hardened

• Docker isolation;
• NGINX hardening;
• patching;
• MFA;
• secure configuration.

Level 3 — Monitored

• Wazuh;
• FIM;
• authentication monitoring;
• log collection.

Level 4 — Intelligence-Driven

• AbuseIPDB;
• threat intelligence;
• correlation;
• automated enrichment.

Level 5 — Continuous Security Operations

• automated response;
• incident management;
• tested recovery;
• security metrics;
• continuous improvement.

50. SME Security Operating Model

The recommended operational cycle is:

PLAN | v HARDEN | v DEPLOY | v MONITOR | v DETECT | v INVESTIGATE | v RESPOND | v RECOVER | v REVIEW | +-------------> PLAN

This converts security from a one-time project into an operational discipline.

51. Role of KeenComputer.com

KeenComputer can serve as the implementation and managed-operations partner.

Potential responsibilities include:

Infrastructure

• VPS deployment;
• Linux hardening;
• Docker;
• NGINX;
• UFW;
• SSL/TLS.

Applications

• Joomla;
• WordPress;
• Magento;
• PHP;
• databases;
• Redis;
• OpenSearch.

Security

• Wazuh;
• FIM;
• AbuseIPDB;
• Active Response;
• incident response;
• backups;
• disaster recovery.

Operations

• monitoring;
• patch management;
• security reviews;
• alert tuning;
• documentation.

52. Role of IAS-Research.com

IAS-Research can provide the research and engineering framework.

Activities include:

• security architecture research;
• threat modelling;
• SIEM evaluation;
• Docker security research;
• Wazuh rule development;
• threat-intelligence research;
• security automation;
• incident-response methodology;
• SME cybersecurity research;
• white papers;
• technical feasibility studies.

IAS-Research can also investigate advanced security automation using:

• RAG;
• GraphRAG;
• LLM agents;
• knowledge graphs;
• MCP;
• Python;
• OpenTelemetry;
• SIEM/SOAR integration.

53. Role of KeenDirect.com

KeenDirect can provide the infrastructure supply layer.

Potential products include:

• servers;
• SSD/NVMe storage;
• networking;
• backup hardware;
• UPS;
• firewall appliances;
• edge devices;
• security infrastructure.

The combined model is:

IAS-Research Research / Architecture | v KeenComputer Implementation / Operations | v KeenDirect Infrastructure / Supply

54. Strategic Partnership Model

The three organizations can be positioned as:

Research → Engineering → Deployment → Infrastructure → Operations

This creates a lifecycle rather than a single consulting engagement.

55. Business Value for SMEs

The proposed architecture can help SMEs:

• reduce security blind spots;
• centralize security monitoring;
• improve incident response;
• protect ecommerce infrastructure;
• improve operational visibility;
• create documented security procedures;
• improve recovery capability;
• support compliance activities;
• reduce dependence on manual log inspection.

The business objective is not to eliminate every attack.

The objective is to make the organization:

harder to compromise, faster to detect, faster to contain and easier to recover.

56. PCI DSS Considerations

For ecommerce organizations, security architecture should be mapped to the organization's actual PCI DSS scope.

Important controls include:

• access control;
• authentication;
• logging;
• monitoring;
• vulnerability management;
• secure configuration;
• incident response;
• backup/recovery;
• network segmentation.

Wazuh can provide evidence and monitoring capabilities, but deploying Wazuh does not itself make an organization PCI DSS compliant.

Compliance remains a broader organizational responsibility.

57. Research Findings

The research supports several architectural findings.

Finding 1

Firewall protection is necessary but insufficient.

Finding 2

Docker improves isolation but introduces additional infrastructure requiring monitoring.

Finding 3

Centralized monitoring significantly improves security visibility.

Finding 4

File Integrity Monitoring is particularly important for CMS environments.

Finding 5

Application logs and infrastructure logs must be correlated.

Finding 6

External IP reputation can provide useful investigative context.

Finding 7

AbuseIPDB should supplement, not replace, local evidence.

Finding 8

Automated blocking should be introduced gradually.

Finding 9

Backups are part of security architecture.

Finding 10

Security must operate as a continuous feedback loop.

58. Central Research Proposition

The central proposition of this paper is:

SME web security is more effective when prevention, isolation, local detection, external threat intelligence, response and recovery are engineered as one continuous security system rather than as independent security products.

This can be expressed mathematically as:

Effective Security = Prevention + Isolation + Visibility + Detection + Threat Intelligence + Response + Recovery + Continuous Improvement

The individual components are complementary rather than interchangeable.

59. Reference Architecture Summary

INTERNET | DNS/CDN | WAF | NGINX | UFW | Ubuntu VPS Host | Docker Engine | +--------------------+--------------------+ | | | Joomla WordPress Magento | | | +--------------------+--------------------+ | MariaDB / Redis / OpenSearch | Wazuh Agent | Secure Connection | SECURITY VPS | +-----------+-----------+ | | | Manager Indexer Dashboard | v Security Rules | v Source IP | v AbuseIPDB | v Threat Intelligence | v Correlation / Response | +-----+-----+ | | Alert Firewall | v UFW | v Recovery

60. Practical Implementation Checklist

VPS

• Ubuntu updated
• SSH hardened
• UFW configured
• HTTPS enabled
• unnecessary ports closed
• backups configured

Docker

• official Docker installation
• private networks
• no unnecessary published ports
• minimal images
• image updates
• container monitoring
• Docker daemon protected

Wazuh

• Wazuh Manager
• Wazuh Indexer
• Wazuh Dashboard
• agents enrolled
• authentication monitoring
• FIM
• NGINX logs
• Docker listener
• alert tuning

Joomla

• core updated
• extensions reviewed
• administrator protected
• configuration monitored
• FIM enabled
• logs monitored

WordPress

• core updated
• plugins reviewed
• themes reviewed
• administrator protected
• uploads monitored
• FIM enabled

Magento

• current supported release
• security patches applied
• MFA
• secure Admin
• extensions reviewed
• Composer dependencies reviewed
• env.php monitored
• logs monitored
• backup tested

AbuseIPDB

• account created
• API key protected
• IP lookup implemented
• local evidence correlated
• trusted IP allowlist
• response thresholds defined
• reporting procedure documented

Recovery

• daily backup
• off-site backup
• database backup
• configuration backup
• restore test
• clean rebuild procedure

61. Conclusion

Securing Joomla, WordPress and Magento on VPS infrastructure requires more than installing a firewall or a security plugin.

The modern SME web stack contains:

• operating systems;
• networks;
• web servers;
• PHP;
• CMS platforms;
• extensions;
• databases;
• Docker;
• APIs;
• administrative interfaces;
• external services.

A security architecture must therefore observe the entire system.

The proposed approach combines:

Ubuntu + UFW + NGINX + Docker + Wazuh + FIM + application logs + Docker monitoring + AbuseIPDB + Active Response + backups.

Wazuh supplies centralized detection, monitoring and response capabilities.

AbuseIPDB supplies external IP-reputation and reporting capabilities.

Docker provides application isolation.

UFW and NGINX provide foundational network and web controls.

Joomla, WordPress and Magento require platform-specific security practices.

Backups provide recovery.

Human investigation provides judgment.

The most important architectural principle is therefore:

Do not build a security system around a single security product. Build a continuous security process around multiple layers of evidence, control and recovery.

For SMEs, this creates a practical path from basic VPS hardening toward a more mature security-operations capability.

The strategic lifecycle can be summarized as:

RESEARCH ↓ THREAT MODEL ↓ ARCHITECTURE ↓ HARDENING ↓ DOCKER ISOLATION ↓ WAZUH MONITORING ↓ ABUSEIPDB INTELLIGENCE ↓ CORRELATION ↓ RESPONSE ↓ RECOVERY ↓ CONTINUOUS IMPROVEMENT

62. References and Further Reading

Wazuh

1. Wazuh Documentation — Deployment on Docker. Official Docker deployment architecture and deployment options. (Wazuh Documentation)
2. Wazuh Documentation — Wazuh Docker Utilities. Container administration and deployment management. (Wazuh Documentation)
3. Wazuh Documentation — Monitoring Docker. Docker host and container monitoring using the Wazuh agent and Docker listener. (Wazuh Documentation)
4. Wazuh Documentation — Monitoring Docker Events. Docker event monitoring and security use cases. (Wazuh Documentation)
5. Wazuh Documentation — Active Response. Automated security response capabilities. (Wazuh Documentation)

AbuseIPDB

6. AbuseIPDB — About AbuseIPDB. Background and purpose of the IP reputation service.
7. AbuseIPDB API v2 Documentation. Official API documentation covering IP checks, reports and API integration. (AbuseIPDB Documentation)

Docker

8. Docker Documentation — Docker Engine Security. Docker daemon, namespaces, capabilities and container security considerations. (Docker Documentation)
9. Docker Documentation — Rootless Mode. Rootless Docker security model. (Docker Documentation)

Magento / Adobe Commerce

10. Adobe Commerce — Secure Your Commerce Site and Infrastructure. Current security recommendations covering MFA, SSH, Admin security, extensions, updates, WAF and backups. (Experience League)
11. Adobe Commerce — Security. Magento Open Source/Adobe Commerce security controls and incident-response guidance. (Experience League)
12. Adobe Commerce — Respond to a Security Incident. Current incident-response and remediation guidance. (Experience League)
13. Adobe Commerce — Security and Compliance. Security and compliance resources. (Experience League)

Additional Platform References

14. Joomla Security Documentation and Security Centre.
15. WordPress Developer Documentation — Hardening WordPress.
16. OWASP Application Security Verification Standard.
17. OWASP Top 10.
18. NIST Cybersecurity Framework.
19. CIS Benchmarks.
20. PCI Security Standards Council — PCI DSS.