Details: By KEENCOMPUTER; Category: Enterprise Security; 18 September 2026; Hits: 8

A Defense-in-Depth Security Architecture for an Ubuntu VPS Hosting Joomla and Magento Applications

Small and medium-sized businesses increasingly depend on websites, ecommerce platforms, customer portals, online ordering, content-management systems, APIs, and cloud-connected applications for day-to-day operations.

For many SMEs, a virtual private server (VPS) provides an economical way to host several applications. However, placing multiple Internet-facing applications on the same Ubuntu VPS creates a concentrated security boundary.

A Defense-in-Depth Security Architecture for an Ubuntu VPS Hosting Joomla and Magento Applications

Open-Source Firewall, WAF, Intrusion Detection, Vulnerability Management, Monitoring, Backup, Recovery, and Kali Linux Security Testing

Research White Paper

Strategic Research and Advisory: IAS-Research.com
Security Engineering, Implementation and Operations: KeenComputer.com
Technology and Infrastructure Supply: KeenDirect.com

Executive Summary

1. Executive Decision Context

Small and medium-sized businesses increasingly depend on websites, ecommerce platforms, customer portals, online ordering, content-management systems, APIs, and cloud-connected applications for day-to-day operations.

For many SMEs, a virtual private server (VPS) provides an economical way to host several applications. However, placing multiple Internet-facing applications on the same Ubuntu VPS creates a concentrated security boundary.

The environment considered in this paper contains:

two Joomla websites
one Magento ecommerce website
Ubuntu Linux
Nginx
PHP/PHP-FPM
MariaDB/MySQL
Redis and related services where applicable
administrative SSH access
application extensions and dependencies
scheduled tasks
backups
Internet-facing web services

The fundamental security question is therefore not:

Which security product should an SME install?

It is:

How can an SME construct a layered security architecture that reduces attack surface, protects applications, detects compromise, limits lateral movement, and provides reliable recovery without creating unsustainable cost or operational complexity?

The answer developed in this paper is a defense-in-depth architecture.

The proposed security layers are:

Potential open-source technologies include:

UFW/nftables
Nginx
ModSecurity
OWASP Core Rule Set
Coraza
CrowdSec
Fail2ban
Wazuh
AIDE
auditd
Lynis
Suricata
Kali Linux

The architecture deliberately avoids treating any one tool as a complete security solution.

2. Executive Security Decision

For an SME hosting multiple business-critical applications, the strategic decision is between:

Option A — Basic protection

Ubuntu | Firewall | SSH hardening | Application updates | Backups

and:

Option B — Layered security engineering

Firewall + Reverse Proxy + WAF + Application Isolation + MFA / Authentication Security + Behavioral Detection + File Integrity Monitoring + Vulnerability Management + Centralized Logging + External Backup + Recovery Testing + Authorized Security Testing

The second architecture provides security controls at multiple points in the attack lifecycle.

The important business benefit is not simply additional software.

It is the ability to:

reduce unnecessary exposure
prevent or block known attack patterns
detect suspicious behavior
contain application compromise
identify unauthorized changes
recover from incidents
test whether the controls work
continuously improve the environment

3. Executive Risk View

Business risk	Example exposure	Security response
Server compromise	Weak SSH or vulnerable service	Firewall + SSH hardening
Website compromise	Vulnerable Joomla extension	Patching + WAF + FIM
Ecommerce compromise	Magento vulnerability	Patch management + WAF + MFA
Customer-data exposure	Public database	Network isolation
Credential compromise	Password attack	MFA + rate limiting
Web-shell persistence	Unauthorized PHP file	FIM + Wazuh
Lateral movement	Shared application permissions	Application isolation
Backup destruction	VPS-only backup	External/immutable backup
Delayed response	Local logs only	Centralized monitoring
Unknown vulnerabilities	Outdated dependencies	Vulnerability management
Security-control failure	Untested architecture	Kali/OWASP validation

4. Executive Recommendation

The proposed architecture should be implemented progressively.

The priority should be:

Priority 1 — Reduce attack surface

inventory services
close unnecessary ports
restrict SSH
protect databases
remove unnecessary applications/extensions

Priority 2 — Harden applications

patch Ubuntu
patch Joomla
patch Magento
remove unused extensions
protect administration
implement MFA

Priority 3 — Establish application gateway security

Nginx
TLS
security headers
rate limiting
WAF

Priority 4 — Establish detection

Wazuh
AIDE
auditd
CrowdSec/Fail2ban
centralized logging

Priority 5 — Establish recovery

external backups
backup verification
recovery testing
incident-response procedures

Priority 6 — Validate

vulnerability scanning
Kali testing
OWASP testing
remediation
retesting

5. Executive Management Question

A useful management test is:

If this VPS is compromised tonight, can the organization detect the incident, contain it, determine what happened, restore the affected applications, and prevent recurrence?

A mature security architecture should be able to answer this question with documented procedures and evidence.

6. Abstract

Small and medium-sized businesses increasingly host business-critical websites, ecommerce platforms, customer portals, and internal services on virtual private servers. A single Ubuntu VPS can provide an economical infrastructure platform for multiple Joomla websites and Magento ecommerce applications, but concentrating several applications on one Internet-facing server also creates a significant security challenge.

A compromise of one application can potentially become a pathway to other applications, databases, credentials, scheduled tasks, operating-system resources, or customer information. Consequently, security cannot be treated as a single firewall or antivirus product. A practical architecture must implement defense in depth across the network, operating system, web server, application, identity, monitoring, backup, and testing layers.

This paper develops an open-source security architecture for an Ubuntu VPS hosting two Joomla websites and one Magento website. The architecture combines:

Ubuntu host firewall using UFW or native nftables
Nginx reverse proxy
TLS and security headers
ModSecurity/OWASP Core Rule Set or Coraza
rate limiting
Fail2ban or CrowdSec
SSH hardening
application and database isolation
AIDE or Wazuh file-integrity monitoring
auditd
vulnerability management
centralized logging
backup and recovery validation
Lynis and security configuration assessment
Suricata where resources permit
Kali Linux for authorized security testing
OWASP Web Security Testing Guide methodology

The paper proposes practical use cases for SSH attacks, Joomla extension exploitation, Magento administration attacks, malicious uploads, database exposure, web-shell installation, credential compromise, API abuse, lateral movement, scheduled-task persistence, and backup destruction.

The central research question is not simply whether an individual security tool works. It is whether a small organization can construct a measurable, maintainable, open-source security system that substantially reduces attack surface while remaining affordable and operationally practical on a VPS.

7. Introduction

The modern SME website is no longer simply a collection of HTML pages.

A typical business website may contain:

CMS software
ecommerce functionality
databases
customer accounts
administrator accounts
payment integrations
APIs
file uploads
email services
analytics
third-party extensions
JavaScript libraries
scheduled jobs
caches
search services
administrative interfaces

A Magento installation can therefore represent a substantial application platform, while Joomla installations may depend on numerous extensions and templates.

When multiple applications share one VPS, the security architecture must protect both the individual applications and the host environment.

The research problem is therefore:

How can an SME design, implement, measure, and continuously improve a layered open-source security architecture for a multi-application Ubuntu VPS?

A firewall can prevent unwanted network connections, but it cannot determine whether an authorized HTTPS request contains malicious application input.

A WAF can identify attack patterns, but it cannot guarantee that a vulnerable extension has been patched.

File-integrity monitoring can identify unauthorized modifications, but it cannot necessarily prevent the original compromise.

Kali Linux can identify weaknesses, but it should not become the production defense mechanism.

Backups can restore a compromised application, but they do not prevent compromise.

Therefore:

Security is a system rather than a product.

8. Research Objectives

Objective 1 — Reduce external attack surface

Identify unnecessary:

ports
services
administrative interfaces
APIs
databases
development tools
monitoring interfaces

and remove or restrict them.

Objective 2 — Protect Internet-facing applications

Evaluate:

WAF
rate limiting
request filtering
TLS configuration
authentication controls
application hardening

Objective 3 — Improve application isolation

Determine whether compromise of Joomla Site A can be prevented from becoming compromise of Joomla Site B or Magento.

Objective 4 — Detect compromise

Measure the effectiveness of:

Wazuh
AIDE
auditd
web logs
authentication logs
WAF logs
vulnerability monitoring

Objective 5 — Measure operational overhead

Evaluate:

CPU
RAM
disk usage
HTTP latency
log growth
application response time
administrative complexity

Objective 6 — Establish recovery capability

Measure whether a compromised website can be restored to a known-good state.

Objective 7 — Establish repeatable security testing

Develop a repeatable testing methodology using Kali Linux and the OWASP Web Security Testing Guide.

9. Research Questions

RQ1

How much can the externally exposed attack surface of a multi-site VPS be reduced through host firewall and service-isolation controls?

RQ2

How effectively can a WAF detect common malicious requests against Joomla and Magento?

RQ3

What performance overhead is introduced by WAF inspection, logging, file-integrity monitoring, and intrusion detection?

RQ4

Can application isolation limit lateral movement following compromise of one website?

RQ5

How quickly can unauthorized changes to CMS files be detected?

RQ6

How effectively can CrowdSec or Fail2ban reduce repeated authentication attacks?

RQ7

How accurately can vulnerability-management tools identify outdated operating-system and application components?

RQ8

How quickly can a compromised website be restored using tested backups?

RQ9

Can Kali Linux provide a repeatable external assessment methodology without creating unacceptable risk to production?

RQ10

Can the entire architecture be operated economically by a small organization without commercial security appliances?

10. Research Hypothesis

The principal hypothesis is:

A layered open-source security architecture combining network filtering, application-layer inspection, application isolation, behavioral detection, file-integrity monitoring, vulnerability management, backup validation, and authorized security testing can provide substantially greater security coverage than relying on a firewall and CMS patching alone, while remaining practical for an SME-hosted VPS when resource consumption and operational complexity are measured and controlled.

A secondary hypothesis is:

Security effectiveness depends more on integration and operational discipline than on the number of security products installed.

Installing ten security tools does not automatically create a secure system.

Poorly configured security tools can introduce:

false positives
service outages
administrative lockouts
disk exhaustion
excessive CPU usage
conflicting firewall rules
undocumented dependencies
operational complexity

11. Threat Model

The VPS should be assumed to be continuously exposed to automated Internet reconnaissance.

11.1 Threat Actors

Opportunistic automated scanners

These search the Internet for:

SSH
Joomla
Magento
WordPress
exposed databases
outdated software
vulnerable APIs

Credential attackers

These target:

SSH
Joomla administrator accounts
Magento Admin
customer accounts
APIs

Application attackers

These exploit:

vulnerable extensions
vulnerable modules
insecure APIs
upload functions
authentication weaknesses
injection vulnerabilities

Supply-chain threats

These may originate from:

vulnerable extensions
abandoned plugins
compromised libraries
malicious packages
compromised third-party integrations

Post-compromise attackers

Once access is obtained, attackers may attempt:

privilege escalation
credential theft
web-shell installation
persistence
lateral movement
database access
data theft
cryptocurrency mining
spam distribution
SEO manipulation
ransomware

12. Asset Model

Asset	Security concern	Primary controls
Ubuntu host	OS compromise	patching, firewall, least privilege
SSH	credential attack	keys, restricted access, Fail2ban/CrowdSec
Joomla Site 1	application compromise	WAF, patching, isolation
Joomla Site 2	application compromise	WAF, patching, isolation
Magento	ecommerce compromise	WAF, MFA, patching, isolation
MariaDB	data theft	localhost/private binding
Redis	unauthorized access	local/private binding
PHP-FPM	application compromise	separate pools/users
Nginx	web-layer attack	hardening, TLS, WAF
Backups	ransomware/destruction	external/offline copies
Logs	evidence loss	centralized storage
DNS	traffic redirection	DNS security
TLS certificates	impersonation	automated renewal/monitoring

13. Defense-in-Depth Architecture

The proposed architecture consists of multiple security zones.

INTERNET | v +----------------------+ | DNS / CDN (optional) | +----------+-----------+ | v +-------------------+ | Ubuntu VPS | | UFW / nftables | +---------+---------+ | v +-------------------+ | Nginx Reverse | | Proxy | +---------+---------+ | v +-------------------+ | TLS / Headers / | | Rate Limiting | +---------+---------+ | v +-------------------+ | WAF | | ModSecurity/CRS | | or Coraza | +---------+---------+ | +-------------+-------------+ | | | v v v Joomla A Joomla B Magento | | | +-------------+-------------+ | Private Services | +----------+----------+ | | v v MariaDB Redis | v Security Monitoring | +---------+---------+ | | | v v v Wazuh AIDE auditd | v External Alerts / Storage | v External Backup | v Recovery Environment

14. Network Security Layer

14.1 Minimum Exposure

The public Internet should normally reach only:

TCP 80 TCP 443

SSH should ideally be restricted to:

VPN Trusted administrator IP Management network

Internal services should not be public.

These include:

3306 MariaDB 6379 Redis 9200 OpenSearch 9000 PHP-FPM Docker API Monitoring dashboards Database administration tools

The principle is:

If a service does not need to be public, it should not be public.

15. UFW Versus nftables

Ubuntu provides UFW as a simplified firewall-management mechanism while nftables provides a more granular native Linux packet-filtering framework.

UFW

Advantages:

simple
easy to understand
suitable for common VPS configurations
appropriate for many SMEs

nftables

Advantages:

powerful rule structures
native modern Linux firewall framework
detailed filtering
suitable for advanced architectures

For an SME:

UFW may be easier to operate.

For an advanced environment:

nftables provides greater control.

The important requirement is consistency.

Multiple independent firewall managers should not be allowed to create conflicting rules.

16. SSH Security

SSH represents the administrative gateway to the server.

Recommended controls include:

Disable root login.
Use individual administrator accounts.
Use SSH keys.
Disable password authentication where practical.
Restrict SSH source addresses.
Use VPN access where possible.
Monitor authentication logs.
Deploy Fail2ban or CrowdSec.
Alert on unexpected successful authentication.
Maintain an emergency administrative session when changing firewall rules.

A firewall configuration error can otherwise turn a security improvement into an availability incident.

17. Reverse Proxy Architecture

Nginx should become the controlled public entry point.

Instead of exposing each application independently:

Internet | v Nginx | +--> Joomla A +--> Joomla B +--> Magento

Nginx can provide:

TLS termination
virtual-host routing
request-size limits
connection limits
rate limiting
security headers
access logging
upstream isolation
WAF integration

This creates a centralized policy enforcement point.

18. Web Application Firewall

The WAF is the application-layer security boundary.

Potential technologies include:

ModSecurity
OWASP Core Rule Set
Coraza
CrowdSec WAF integrations
Nginx request controls

A WAF should complement rather than replace:

patching
secure coding
MFA
access control
application configuration
vulnerability management

19. WAF Deployment Strategy

Phase 1 — Detection

Run the WAF in detection mode.

Objectives:

understand legitimate traffic
identify false positives
tune rules
establish a baseline

Phase 2 — Selective Blocking

Block high-confidence attacks.

Phase 3 — Production Enforcement

Enable stable blocking policies and maintain exceptions where legitimate application behavior requires them.

Magento requires particular care because ecommerce workflows may involve:

POST requests
checkout
customer authentication
REST APIs
GraphQL
search
catalog functions
payment-related requests

Joomla requires attention to:

/administrator
authentication
extension endpoints
media management
APIs
third-party components

20. Joomla Security Model

Each Joomla installation should be treated as an independent application.

Recommended controls include:

supported Joomla version
current extensions
removal of unused extensions
administrator protection
strong authentication
MFA where supported
restricted administrator access
WAF
file-integrity monitoring
secure permissions
external backups

A useful principle is:

An unused extension is unnecessary attack surface.

Extension inventory should therefore become part of regular security operations.

21. Magento Security Model

Magento combines:

ecommerce
customer accounts
payment workflows
administrative functions
APIs
catalog functionality
checkout
database transactions

Security controls should include:

supported Magento release
current security patches
supported PHP
trusted extensions
Admin protection
MFA
WAF
API monitoring
rate limiting
FIM
database protection
tested backups

The Magento Admin interface should ideally be restricted through mechanisms such as:

VPN IP allowlisting additional authentication reverse-proxy restrictions MFA

Changing the administrator URL alone should not be treated as a primary security control.

22. Application Isolation

Isolation is particularly important when multiple applications share one VPS.

If:

Joomla A

is compromised, the attacker should not automatically obtain access to:

Joomla B Magento other databases backup files SSH credentials other PHP-FPM pools

Each application should ideally have:

separate Linux user
separate document root
separate PHP-FPM pool
separate database credentials
separate writable directories
separate backup paths

For stronger isolation, containers can be considered.

However:

Containers are not automatically a security boundary.

Docker itself must be securely configured.

The Docker socket should not be exposed to applications.

23. Database Security

Databases should not normally be publicly accessible.

Preferred model:

Internet X | MariaDB ^ | Private interface / localhost ^ | Applications

Each application should have separate credentials and minimum required privileges.

For example:

joomla_a_db joomla_b_db magento_db

24. Redis and Internal Services

Redis can become a serious exposure if accidentally bound to a public interface.

The same principle applies to:

Redis
OpenSearch
Elasticsearch
RabbitMQ
internal APIs
PHP-FPM
Docker management services

Private services should remain private.

25. CrowdSec and Fail2ban

Fail2ban

Useful for:

SSH
authentication logs
Nginx
repeated login failures

CrowdSec

Can provide broader behavioral detection and remediation.

Conceptually:

Logs | v Detection | v Decision | +--> Firewall blocking | +--> WAF blocking

Behavioral controls complement the WAF.

26. File Integrity Monitoring

File-integrity monitoring is particularly valuable for CMS and ecommerce applications.

Potential targets include:

Joomla document roots Magento application directories configuration files Nginx configuration PHP configuration SSH configuration cron directories systemd service definitions

The objective is to detect:

unexpected PHP files
modified application files
changed configuration
deleted files
suspicious persistence mechanisms

27. Wazuh

Wazuh can act as a centralized security-monitoring platform.

Potential capabilities include:

file-integrity monitoring
vulnerability detection
log analysis
security alerts
endpoint inventory
compliance-oriented monitoring

Conceptually:

Ubuntu VPS | +--> SSH logs +--> Nginx logs +--> WAF logs +--> Joomla logs +--> Magento logs +--> system logs +--> FIM events | v Wazuh | +--> Correlation +--> Detection +--> Alerting +--> Vulnerability inventory

28. Vulnerability Management

Vulnerability management should be continuous.

The inventory should include:

Ubuntu packages
PHP
Nginx
MariaDB
Redis
Joomla
Joomla extensions
Magento
Magento modules
Composer dependencies
Docker images

29. Lynis and Security Configuration Assessment

Lynis can provide a useful host-hardening assessment.

The review should examine:

SSH
users
permissions
services
kernel configuration
networking
authentication
logging
software configuration

Automated scores should not be treated as the final security decision.

A finding should be evaluated as:

Tool recommendation | v Actual exposure | v Business impact | v Risk decision | v Remediation

30. Suricata

Suricata can be considered where VPS resources permit.

A resource-constrained VPS may not have sufficient:

CPU
RAM
disk I/O

for extensive packet inspection.

Therefore the research should measure resource impact.

Possible architecture:

Network Traffic | v Suricata | v Security Events | v Wazuh / Central Logging

31. Kali Linux

Kali Linux should be treated as an authorized security-assessment platform.

It is not:

the firewall
the WAF
the permanent IDS
the backup system
the production security platform

Its role is:

Assess | Test | Validate | Document | Retest

Potential testing includes:

Nmap
service enumeration
TLS assessment
web reconnaissance
vulnerability scanning
authentication testing
WAF validation
application testing
controlled exploitation

All testing must be authorized.

32. Kali Testing Architecture

A safe approach is:

Production testing should initially emphasize:

passive discovery
low-rate requests
non-destructive testing
controlled validation

33. Security Use Case 1 — SSH Brute Force

Scenario

An attacker repeatedly attempts SSH authentication.

Controls

SSH keys
no root login
restricted access
Fail2ban/CrowdSec
logging
alerting

Metrics

failed attempts
blocked attempts
successful attempts
detection time
block time
false positives

34. Security Use Case 2 — Joomla Extension Attack

Scenario

An attacker targets a vulnerable Joomla extension.

Expected architecture:

Internet | v Nginx | v WAF | v Joomla

Desired outcome:

malicious request is detected
request is blocked where appropriate
application remains operational
no unauthorized file is created
FIM detects unexpected modification

35. Security Use Case 3 — Magento Admin Attack

Scenario

An attacker attempts repeated Magento administrator authentication.

Controls:

Metrics include:

attempts per minute
rejected attempts
blocked IPs
legitimate administrator impact
detection latency

36. Security Use Case 4 — Malicious File Upload

Scenario

An attacker attempts to upload an executable payload.

Controls:

restrict upload types
prevent script execution in upload directories
separate writable directories
scan appropriate content
monitor executable-file creation
inspect multipart requests

Desired result:

Upload Attempt | v WAF | v Application Validation | v Rejected

Unexpected creation should generate:

FIM Alert

37. Security Use Case 5 — Web Shell

Scenario

An attacker exploits a vulnerability and creates a PHP web shell.

Detection path:

A principal measurement is:

Time to detection.

38. Security Use Case 6 — Database Exposure

Scenario

An external scan discovers:

3306/tcp

open to the Internet.

Remediation:

restrict MariaDB
update firewall
rotate credentials if exposure was significant
inspect logs
investigate possible access

Then repeat the external test.

Expected result:

3306/tcp CLOSED / FILTERED

39. Security Use Case 7 — Lateral Movement

This is one of the most important experiments for a multi-site VPS.

Scenario

Assume Joomla A is compromised.

Determine whether the compromised application can reach:

Joomla B Magento other databases other document roots backup directories SSH credentials other PHP-FPM pools

Security objective:

A compromise should remain contained as far as technically practical.

40. Security Use Case 8 — Credential Compromise

A compromised administrator account can provide substantial application access.

Controls:

MFA
strong unique passwords
restricted administrator access
login monitoring
rate limiting
suspicious-login alerts

41. Security Use Case 9 — Unauthorized Scheduled Task

Attackers may attempt persistence through:

cron systemd timers user crontabs application schedulers

Monitoring should detect unexpected:

cron entries
systemd services
startup scripts
scheduled application jobs

42. Security Use Case 10 — Backup Destruction

An attacker may attempt to destroy backups.

Therefore:

Backups stored only on the production VPS are not sufficient for disaster recovery.

Recommended architecture:

Production VPS | +----> External Backup | +----> Offline / Immutable Copy | +----> Recovery Environment

Backup success should be defined by:

Successful restoration, not merely successful backup execution.

43. Security Use Case 11 — API Abuse

Magento and Joomla environments may expose APIs.

Potential attack patterns include:

repeated authentication
automated enumeration
abusive requests
malformed requests
unauthorized access
excessive API consumption

Controls:

Metrics should include:

requests per minute
rejected requests
authentication failures
unusual source addresses
response latency

44. Security Use Case 12 — Resource Exhaustion

A malicious or badly behaved client may consume:

CPU
memory
PHP-FPM workers
database connections
disk space
network bandwidth

Protection can include:

request limits
connection limits
PHP-FPM worker limits
Nginx rate limiting
application caching
database controls
disk monitoring

Resource monitoring therefore forms part of both security and availability engineering.

45. Backup Strategy

The architecture should maintain:

Daily backups

application files
databases
configurations

Frequent database backups

Especially for ecommerce.

External storage

Do not rely solely on the VPS.

Retention

Example:

7 daily 4 weekly 3 monthly

Encryption

Protect backups containing business or customer information.

Recovery testing

Perform periodic restoration.

46. Disaster Recovery

The recovery process should be:

47. Incident Response

A small organization should maintain a written incident-response procedure.

Detection

Identify:

suspicious login
WAF event
file change
vulnerability
malware alert

Containment

Possible actions:

block source
disable account
isolate application
disable vulnerable extension
restrict public access

Investigation

Collect:

access logs
authentication logs
WAF logs
file changes
process information
scheduled tasks
network connections

Recovery

Restore clean components.

Lessons Learned

Determine:

initial access
exploited weakness
detection performance
containment performance
recovery performance

48. Logging Architecture

Security logs should not exist only on the server being attacked.

If an attacker obtains administrative access, local logs could be:

deleted
modified
encrypted

Therefore:

VPS | +--> Local Logs | +--> Wazuh | +--> External / Centralized Storage

Important sources include:

SSH
Nginx
WAF
Joomla
Magento
PHP-FPM
MariaDB
systemd
firewall
CrowdSec/Fail2ban
FIM

49. Log Retention and Disk Protection

Security logs must be rotated and monitored.

Excessive log growth can itself become an availability problem.

A full filesystem may cause:

database failures
website failures
authentication problems
certificate-renewal failures
application crashes

Therefore:

Disk monitoring is a security control as well as an availability control.

50. Performance Evaluation

Security controls introduce overhead.

Measure:

CPU

Baseline + Firewall + WAF + CrowdSec + Wazuh + Suricata

RAM

Measure average and peak consumption.

Disk

Measure:

logs
monitoring databases
FIM data
backups
application data

Web performance

Measure:

latency
throughput
requests/second
TTFB

51. Experimental Design

The strongest research methodology is a staged before-and-after experiment.

Phase A — Baseline

Record:

ports
services
CPU
RAM
disk
latency
vulnerabilities
TLS configuration

Phase B — Host Hardening

Add:

SSH controls
firewall

Measure again.

Phase C — Reverse Proxy

Add:

Nginx
TLS
headers
rate limiting

Phase D — WAF Detection

Deploy WAF in detection mode.

Measure:

detection
false positives
latency

Phase E — WAF Blocking

Enable selected blocking rules.

Repeat testing.

Phase F — Behavioral Protection

Add:

CrowdSec
Fail2ban

Phase G — Monitoring

Add:

Wazuh
AIDE
auditd

Phase H — Security Testing

Use Kali Linux.

Phase I — Recovery

Perform controlled restoration.

52. Test Matrix

Test	Expected result	Evidence
Port scan	Only intended ports visible	Nmap
SSH brute force	Rate limited/blocked	Auth logs
Joomla attack pattern	WAF detection/block	WAF logs
Magento attack	WAF detection	WAF logs
Malicious upload	Rejected	WAF/application logs
PHP shell creation	FIM alert	Wazuh
Database scan	Port inaccessible	Nmap
Unauthorized cron	Alert	audit/FIM
Admin login abuse	Rate limited	Application logs
TLS assessment	Strong configuration	TLS report
Backup restore	Successful	Recovery record
Cross-site access	Access denied	Test evidence
API abuse	Rate limited/blocked	API/WAF logs
Resource exhaustion	Controlled	Performance data

53. Evaluation Metrics

Metric	Baseline	Hardened
Public ports	Record	Record
High-risk services exposed	Record	Record
WAF detection rate	—	%
WAF false-positive rate	—	%
SSH attacks blocked	Record	%
Mean detection time	Record	Seconds/minutes
Mean response time	Record	Seconds/minutes
CPU utilization	%	%
RAM utilization	MB	MB
Disk growth	GB/day	GB/day
Unauthorized file changes detected	Record	Record
Vulnerabilities	Record	Record
Backup restoration time	Record	Record
Cross-site access attempts blocked	Record	%
API abuse blocked	Record	%

54. Detection Rate

A simple metric is:

Detection Rate=Detected Test AttacksAuthorized Test Attacks×100Detection\ Rate = \frac{Detected\ Test\ Attacks} {Authorized\ Test\ Attacks} \times100

For example:

40 authorized tests 34 detected

gives:

85%85\%

Detection must not be confused with prevention.

An attack can be:

detected but not blocked

or:

blocked without being detected by a particular monitoring layer

Therefore multiple metrics are required.

55. Mean Time to Detect

MTTD=Detection Time−Attack TimeMTTD = Detection\ Time - Attack\ Time

Example:

Attack: 10:00:00 Detection: 10:00:12 MTTD = 12 seconds

Measure this for:

SSH attacks
WAF attacks
file modification
suspicious processes
account manipulation

56. Mean Time to Respond

Measure:

Security alert | v Threat contained

and separately:

Threat contained | v Service restored

This distinguishes security response from business recovery.

57. False Positives

A WAF that blocks legitimate Magento checkout traffic can create an availability problem.

Therefore:

False Positive Rate=Legitimate Requests BlockedLegitimate Requests Evaluated×100False\ Positive\ Rate = \frac{Legitimate\ Requests\ Blocked} {Legitimate\ Requests\ Evaluated} \times100

Testing should include:

Magento checkout
customer login
APIs
GraphQL
Joomla administrator
media uploads
search
catalog functions

58. Security Versus Performance

The research should explicitly recognize the security/performance trade-off.

More Inspection | v Potentially Better Detection | v More CPU / RAM | v Potentially Higher Latency

The objective is not to maximize the number of security tools.

The objective is to find a sustainable security architecture.

59. Security Maturity Model

Level 1 — Basic

SSH hardening Firewall TLS Updates Backups

Level 2 — Application Protection

Nginx WAF Rate limiting MFA

Level 3 — Detection

CrowdSec AIDE auditd Centralized logs

Level 4 — Security Operations

Wazuh Vulnerability management Incident response Recovery testing

Level 5 — Continuous Security Engineering

Kali Automated testing Staging environment Patch validation Security regression testing Metrics Continuous improvement

60. KeenComputer.com Strategic Role

60.1 From Research to Implementation

The architecture developed in this paper provides the foundation for an SME cybersecurity engineering methodology.

KeenComputer.com (KCS) can serve as the engineering and implementation partner that converts the architecture into an operational security capability.

The role extends beyond installing a firewall.

KeenComputer can integrate:

cybersecurity
Linux engineering
VPS administration
web-server engineering
Joomla administration
Magento engineering
WAF deployment
monitoring
backup
vulnerability management
security testing
incident response

The lifecycle becomes:

61. KeenComputer as SME Security Engineering Partner

KeenComputer can provide the bridge between:

security research
infrastructure engineering
application engineering
website management
ecommerce engineering
system administration
security testing
monitoring
recovery

This is especially valuable for SMEs that do not have a dedicated internal security engineering team.

62. KeenComputer Security Assessment Role

KCS can begin with a documented security baseline.

Assessment areas include:

Infrastructure

Ubuntu
CPU/RAM/storage
network configuration
firewall
SSH
running services

Applications

Joomla
Magento
extensions
modules
themes
dependencies

Data

databases
Redis
credentials
backup systems

Operations

cron
systemd
monitoring
logging
patch management

Security

WAF
MFA
vulnerability management
FIM
incident response

The result becomes a security baseline and risk register.

63. KeenComputer Architecture Role

KCS can convert the assessment into a risk-based architecture.

The architecture should be selected according to:

business requirements
risk
application architecture
VPS resources
budget
operational capability
recovery requirements

64. KeenComputer Implementation Role

KCS can implement:

VPS security

Ubuntu hardening
UFW/nftables
SSH
permissions
service isolation

Web infrastructure

Nginx
TLS
security headers
rate limiting
reverse proxy

WAF

ModSecurity
OWASP CRS
Coraza
rule tuning

Behavioral security

CrowdSec
Fail2ban

Monitoring

Wazuh
AIDE
auditd
centralized logs

Vulnerability management

application inventory
package inventory
extension inventory
vulnerability review
patch management

Backup

database backup
application backup
external backup
restoration testing

65. KeenComputer Joomla and Magento Security Engineering

KeenComputer can integrate infrastructure security with application security.

Joomla services

version assessment
extension inventory
vulnerability review
extension removal
administrator protection
MFA
permissions
WAF tuning
suspicious-file investigation
backup validation

Magento services

security-patch review
PHP compatibility
Composer dependency review
extension assessment
Admin protection
MFA
API security
WAF tuning
checkout protection
file-integrity monitoring
database protection
recovery testing

This creates an application-aware security service rather than an infrastructure-only service.

66. KeenComputer Security Testing Role

KCS can establish repeatable authorized security validation using Kali Linux and OWASP methodology.

The lifecycle becomes:

Possible assessments include:

port scanning
service enumeration
TLS testing
web application testing
authentication testing
WAF validation
firewall validation
Joomla attack-surface testing
Magento attack-surface testing
file-upload testing
access-control testing
vulnerability validation

67. KeenComputer Managed Security Role

Security should not end after deployment.

KCS can provide recurring operations.

Daily/automated

security alerts
backup status
disk monitoring
suspicious authentication events

Weekly

WAF review
vulnerability review
application inventory review
unusual traffic review
FIM review

Monthly

patch management
firewall review
administrator review
backup verification

Quarterly

security assessment
controlled penetration testing
recovery testing
architecture review

Incident

68. KeenComputer Security Assessment Deliverable

A KCS security report can contain:

Executive Summary

Business-level description of significant findings.

Attack-Surface Assessment

public ports
public services
administrative interfaces
APIs

Application Assessment

Joomla
Magento
extensions
modules
dependencies

Infrastructure Assessment

Ubuntu
SSH
Nginx
PHP
MariaDB
Redis
Docker

Security-Control Assessment

firewall
WAF
MFA
FIM
IDS
logging
backup

Risk Register

Finding	Business impact	Technical risk	Recommended action	Priority
Public database	Data exposure	High	Restrict access	Immediate
Weak SSH	Unauthorized access	High	Harden SSH	Immediate
Outdated extension	Application compromise	High	Patch/remove	Immediate
No external backup	Recovery risk	High	Implement backup	Immediate
No FIM	Delayed detection	Medium	Deploy FIM	Planned

69. KeenComputer Security Engineering Packages

The methodology can be offered progressively.

Package A — VPS Security Assessment

Includes:

port scan
service inventory
SSH review
firewall review
Joomla/Magento review
vulnerability assessment
backup review
security report

Package B — VPS Hardening

Includes Package A plus:

firewall
SSH hardening
Nginx hardening
TLS
application isolation
database protection
security headers

Package C — Managed Web Security

Includes Package B plus:

WAF
CrowdSec/Fail2ban
Wazuh/FIM
security monitoring
vulnerability monitoring
alerting
recurring reviews

Package D — Security Engineering and Validation

Includes Package C plus:

Kali-based testing
OWASP testing
staging testing
production validation
remediation
retesting
recovery testing
security documentation

70. KeenComputer Security KPIs

Security can be turned into measurable engineering indicators.

KPI	Example measurement
Public attack surface	Number of exposed services
Critical vulnerabilities	Count
WAF detection	%
WAF false positives	%
Blocked attacks	Count
MTTD	Minutes
MTTR	Hours
Unauthorized file changes	Count
Backup success	%
Restore success	%
Restore time	Minutes/hours
Patch compliance	%
Security-test remediation	%
VPS overhead	CPU/RAM %

This creates evidence-based security management.

71. IAS-Research.com and KeenComputer.com

The broader organization can separate research and implementation responsibilities.

IAS-Research.com

Research and strategic functions:

cybersecurity research
threat modeling
architecture research
technology evaluation
experimental methodology
white papers
advanced AI/security research
engineering analysis

KeenComputer.com

Engineering and operational functions:

security implementation
VPS engineering
application engineering
WAF deployment
monitoring
backup
maintenance
managed security
testing
incident response

KeenDirect.com

Technology and supply functions where appropriate:

hardware
networking equipment
server components
technology procurement
infrastructure equipment

The resulting model is:

IAS-Research Research / Strategy | v KeenComputer Engineering / Execution | v KeenDirect Technology / Supply

This connects:

Research → Architecture → Engineering → Deployment → Operations

72. SME Security Transformation Model

KeenComputer can apply the architecture through eight phases.

Phase 1 — Discover

What do we have?

Phase 2 — Assess

What is exposed and what can go wrong?

Phase 3 — Protect

What can be patched, restricted, isolated, or blocked?

Phase 4 — Detect

How will we know something has happened?

Phase 5 — Respond

How quickly can we contain it?

Phase 6 — Recover

Can we restore operations?

Phase 7 — Verify

Can we demonstrate that controls work?

Phase 8 — Improve

What should change next?

73. Strategic Value of the KeenComputer Model

The strategic proposition is not:

"We install a firewall."

It is:

"KeenComputer helps SMEs design, implement, monitor, test, recover, and continuously improve a practical security architecture for their business-critical IT infrastructure."

This model is particularly relevant to SMEs that need professional security engineering without maintaining a large internal security organization.

74. 90-Day SME Security Roadmap

Days 1–15 — Discovery and Recovery

inventory systems
verify backups
identify exposed services
document applications
review administrators
establish baseline

Days 16–30 — Infrastructure Hardening

SSH hardening
firewall
service isolation
database protection
Nginx configuration

Days 31–45 — Application Security

Joomla patching
Magento patching
extension review
MFA
administrator protection

Days 46–60 — WAF

ModSecurity/CRS or Coraza
detection mode
rule tuning
selective blocking
rate limiting

Days 61–75 — Monitoring

Wazuh
AIDE
auditd
CrowdSec/Fail2ban
centralized logging

Days 76–90 — Validation

vulnerability scan
Kali assessment
OWASP testing
recovery exercise
remediation
retesting
final report

75. Security Operations Calendar

Daily

review critical alerts
review authentication events
check backup status
check disk space

Weekly

review WAF events
review vulnerabilities
review application extensions
review unusual traffic
review FIM

Monthly

patching
firewall review
administrator review
backup restoration sample

Quarterly

penetration testing
disaster recovery testing
credential review
WAF review
architecture review

Annually

complete security assessment
business-continuity exercise
security policy review
threat-model review

76. Security Documentation

A professional environment should maintain:

Network architecture

Internet Firewall Reverse Proxy Applications Databases Monitoring Backup

Port inventory

Port	Service	Public?	Reason
22	SSH	Restricted	Administration
80	HTTP	Yes	Redirect/certificate
443	HTTPS	Yes	Web
3306	MariaDB	No	Internal
6379	Redis	No	Internal

Application inventory

Application	Version	Extensions	Update status
Joomla A	Record	Record	Record
Joomla B	Record	Record	Record
Magento	Record	Record	Record

77. Security as a Continuous Engineering Process

The architecture should become a continuous engineering cycle:

+----------------+ | Threat Model | +-------+--------+ | v +----------------+ | Design | +-------+--------+ | v +----------------+ | Implement | +-------+--------+ | v +----------------+ | Test | +-------+--------+ | v +----------------+ | Measure | +-------+--------+ | v +----------------+ | Improve | +-------+--------+ | +---------> Threat Model

This transforms cybersecurity from a one-time installation project into an engineering discipline.

78. Research Contribution

The contribution of this research is not the invention of a new firewall or WAF.

The contribution is the integration and measurement of freely available security technologies into a coherent SME architecture.

The research evaluates:

Firewall + Reverse Proxy + WAF + Behavioral Detection + FIM + Vulnerability Management + Logging + Backup + Penetration Testing

The research therefore emphasizes measurable outcomes rather than the number of products installed.

79. Expected Findings

The experimental program is intended to evaluate several propositions.

First, reducing exposed services should reduce unnecessary attack surface.

Second, application-layer controls are necessary because network firewalls cannot inspect all application-level attacks.

Third, application isolation should reduce the potential impact of a compromised website.

Fourth, monitoring and FIM should provide detection capabilities that preventive controls alone cannot provide.

Fifth, backup validation should improve recovery capability.

Sixth, security tooling introduces resource and operational costs that must be measured.

Finally, continuous testing is required because:

applications change
extensions change
dependencies change
configurations change
threats change

These should remain research propositions to be measured, rather than assumed experimental results.

80. Limitations

WAF limitations

A WAF cannot reliably prevent every:

business-logic attack
authenticated abuse
compromised extension
zero-day vulnerability
insider threat

Firewall limitations

A firewall cannot prevent malicious HTTPS requests that legitimately reach port 443.

FIM limitations

FIM detects changes but may not identify the original vulnerability.

Vulnerability scanner limitations

Automated scanners may miss:

business-logic vulnerabilities
custom vulnerabilities
authentication weaknesses
configuration-specific problems

Kali limitations

Kali is an assessment platform rather than a complete security architecture.

Backup limitations

Backups are useful only if:

available
intact
recoverable
accessible
understood
combined with remediation of the original vulnerability

81. Ethical and Legal Considerations

Security testing must be authorized.

The organization should define:

systems in scope
IP addresses
domains
testing dates
permitted tools
prohibited tests
rate limits
emergency contacts
evidence-handling requirements

Production ecommerce systems should not be subjected to destructive tests simply to demonstrate security capability.

Avoid:

denial-of-service attacks
destructive exploitation
uncontrolled password spraying
destructive database extraction
malware deployment
unauthorized persistence

Use staging environments whenever possible.

82. Complete SME Security Architecture

The complete model is:

83. Final Strategic Model

The three-part organizational model can be summarized as:

IAS-Research.com

Research → Strategy → Architecture → Innovation

KeenComputer.com

Engineering → Implementation → Security Operations → Testing → Support

KeenDirect.com

Technology → Hardware → Components → Supply

Together:

The strategic model therefore connects:

Research → Design → Engineering → Technology → Deployment → Operations → Measurement → Improvement

84. Conclusion

A VPS hosting two Joomla websites and one Magento ecommerce application can be protected using a substantial open-source security architecture without immediately requiring expensive commercial security appliances.

However, the correct architecture is not:

Kali Linux + firewall.

It is:

Firewall + reverse proxy + WAF + application isolation + authentication security + behavioral protection + vulnerability management + file-integrity monitoring + logging + backups + authorized security testing.

The host firewall establishes the network boundary.

Nginx establishes a controlled application gateway.

The WAF provides application-layer inspection.

CrowdSec or Fail2ban provides behavioral protection.

Wazuh, AIDE, and audit mechanisms provide visibility into changes and suspicious activity.

Vulnerability management identifies weaknesses before they become incidents.

Backups provide recovery capability.

Kali Linux and OWASP methodology provide controlled verification.

The strongest research opportunity is therefore to measure the complete system.

The proposed experiment should compare:

and measure:

attack-surface reduction
detection rate
prevention rate
false-positive rate
mean time to detect
mean time to respond
application latency
CPU utilization
memory utilization
disk consumption
backup restoration time
cross-site isolation

For SMEs, the objective should not be to deploy the largest possible number of security products.

The objective should be to establish a:

repeatable, measurable, affordable, maintainable, and continuously improving security lifecycle.

KeenComputer's role is to turn this architecture into an operational engineering capability.

IAS-Research provides the research, strategic analysis, architecture methodology, and experimental foundation.

KeenComputer provides the engineering, implementation, security operations, testing, and ongoing improvement.

KeenDirect can provide the technology and infrastructure supply capability where required.

Together, this establishes a complete SME technology-security lifecycle:

Research → Strategy → Architecture → Implementation → Operations → Security Testing → Recovery → Continuous Improvement.

The resulting approach positions security not as a product purchase, but as an engineered business capability.

References

OWASP Foundation. Web Security Testing Guide.
OWASP Foundation. OWASP Testing Framework.
OWASP Foundation. OWASP Core Rule Set.
Ubuntu Documentation. Firewall and Network Security Documentation.
Ubuntu Documentation. nftables.
Wazuh Documentation. File Integrity Monitoring.
Wazuh Documentation. Vulnerability Detection.
CrowdSec Documentation. Firewall Bouncer and Remediation Components.
Kali Linux Project Documentation. Penetration Testing and Security Assessment Platform.
Linux Audit Project. auditd Documentation.
Lynis Project. Linux Security Auditing and Hardening.
AIDE Project. Advanced Intrusion Detection Environment.
Suricata Project. Open-Source Network Threat Detection Engine.
The original research draft supplied for this paper, establishing the multi-site Ubuntu VPS threat model, open-source security stack, Kali role, use cases, experimental methodology, and evaluation metrics.

Appendix A — Recommended SME Security Checklist

Infrastructure

Ubuntu patched
unnecessary services removed
firewall enabled
default-deny inbound policy
SSH restricted
root SSH disabled
SSH keys configured
databases private
Redis private
Docker management protected

Joomla

Joomla supported
extensions inventoried
extensions patched
unused extensions removed
administrator protected
MFA enabled where available
file permissions reviewed
backups verified

Magento

Magento supported
security patches applied
PHP supported
extensions reviewed
Admin restricted
MFA enabled
APIs monitored
checkout tested after WAF deployment
backups tested

WAF

WAF installed
detection baseline established
false positives measured
rules tuned
blocking enabled selectively
Magento traffic tested
Joomla traffic tested

Monitoring

Wazuh
AIDE
auditd
CrowdSec/Fail2ban
centralized logs
disk monitoring
alerting

Recovery

external backup
encrypted backup
retention policy
restore procedure
restoration tested
incident-response plan

Testing

authorized scope defined
staging environment
Kali assessment
OWASP methodology
vulnerability scan
WAF validation
firewall validation
isolation testing
remediation
[retest]

Appendix B — Management Dashboard

A monthly security report can summarize:

SECURITY STATUS Public Services: ___ Critical Vulnerabilities: ___ High Vulnerabilities: ___ WAF Events: ___ Blocked Attacks: ___ Failed SSH Attempts: ___ FIM Alerts: ___ Patch Compliance: ___% Backup Success: ___% Restore Test: PASS / FAIL WAF False Positives: ___% Average MTTD: ___ Average MTTR: ___ CPU Overhead: ___% RAM Overhead: ___ Last Security Test: ___ Next Security Review: ___

This provides management with a concise view of whether the security architecture is functioning and where further engineering work is required.

Appendix C — Core Principle

The complete philosophy of the paper can be reduced to one engineering principle:

Do not assume that the server is secure because security software has been installed. Measure exposure, implement layered controls, monitor the environment, test the controls, verify recovery, and continuously improve the architecture.

KeenComputer's strategic role is to make that security lifecycle practical for SMEs.

This version now treats KeenComputer as an integral security-engineering partner throughout the paper, rather than adding KCS only as a concluding service section. It also establishes the complementary IAS-Research → KeenComputer → KeenDirect model and connects the research architecture to a practical SME service methodology.

Keen Computer Solutions

5-955 Summerside Avn

Winnipeg, Manitoba,

Canada R2X 4N1

Start a Conversation

CDN 204-480-3393 (CDT)

USA-408-668-9062 (WhatsApp)
info@keencomputer.com

Main Menu

Applied Network Security and Offensive Defense for SMEs, Schools, and Municipalities

Enterprise Security