Location Research Breakthrough Possible @S-Logix pro@slogix.in

Detecting Unauthorized Remote Access Attempts Against MariaDB Database Servers Through Network Access Restriction and Account-Host Validation

Description

MariaDB is an open-source relational database server that can accept local and remote client connections depending on its network configuration and database-account permissions.

Remote database access introduces a security risk when the database service is reachable from networks that are not required for legitimate application operations or when database accounts permit connections from broader hosts than necessary.

MariaDB provides multiple controls that can be used to restrict remote access. The bind-address setting determines which network addresses the server listens on, while MariaDB account definitions use the form 'username'@'host', allowing access to be restricted according to the connecting host. MariaDB also supports host patterns and network ranges for account matching.

In this use case, a controlled MariaDB database server is deployed on Ubuntu Linux inside an isolated VirtualBox laboratory. Kali Linux is used as the authorized security-testing platform.

The assessment evaluates whether unauthorized remote systems can reach the MariaDB service and whether database accounts are correctly restricted to their approved source hosts.

The security validation combines network-level access restriction, MariaDB account-host validation, least-privilege database accounts, and connection auditing.

A controlled remote-access test is performed from Kali Linux using the MariaDB client and network-connectivity testing. The assessment verifies both cases where the network connection should be blocked and cases where the network connection reaches MariaDB but the database account should reject the source host.

MariaDB's Audit Plugin can record connection activity, including connection and failed-connection events, providing useful evidence for security monitoring and compliance-oriented investigation.

Wazuh monitors the Ubuntu and MariaDB environment, while OpenSearch provides centralized investigation of connection attempts, authentication failures, and access-control events.

Complete Risk Assessment & Compliance Workflow: MariaDB Database Server → Network Exposure Assessment → Remote Access Identification → Firewall / Network Restriction → Account-Host Validation → Unauthorized Remote Access Attempt → Connection / Authentication Result → Audit Logging → Wazuh Monitoring → OpenSearch Investigation → Risk Evaluation → Remediation → Post-Remediation Validation

Existing Security Problem

Application: MariaDB Database Server

The MariaDB server provides database services to authorized applications and users. Remote connectivity can be configured through the server's network binding and firewall rules, while database accounts determine which users can authenticate from which hosts. MariaDB documentation describes remote access configuration through bind-address, firewall rules, and account host restrictions.

Existing Problem:

A MariaDB server may become unnecessarily exposed when the database port is reachable from unauthorized network segments or when database accounts use overly broad host definitions such as '%'.MariaDB documents that an accounts host component controls which client hosts can match the account. Exact host matches take precedence over wildcard matches, and a host of '%' represents a broad wildcard.

The security problem is therefore:

Unauthorized Remote System → MariaDB TCP Port 3306 → Network Access Control → MariaDB Authentication → Account-Host Matching → Overly Broad / Incorrect Host Permission → Unauthorized Remote Database Access → Potential Database Information Exposure

The proposed security architecture introduces network restriction and account-host validation so that a connection must satisfy both the required network-access policy and the appropriate MariaDB account restrictions.

Attack

Specific Attack: Unauthorized Remote MariaDB Access

The controlled attack scenario attempts to connect to the MariaDB database service from an unauthorized laboratory host. The assessment first identifies whether the MariaDB TCP service is reachable from the testing network. The tester then evaluates whether the database account permits connections from the testing host. A controlled database account is configured for an approved source host or laboratory network, and Kali Linux is used to attempt access from a source outside the permitted host definition. The assessment determines whether the request is blocked at the network layer or rejected during MariaDB account authentication. The objective is to identify an access-control gap where an unauthorized host can establish a database session despite the intended network and account-host restrictions.

Attack Behavior:
Kali Linux
→
Identify MariaDB Server
→
Test TCP Port 3306
→
Attempt Remote MariaDB Connection
→
Firewall / Network Access Control
→
MariaDB Authentication
→
Account-Host Matching
→
Unauthorized Source Host
→
Connection Rejected / Potential Unauthorized Access
→
Audit Event Generated
→
Wazuh Detection
→
OpenSearch Investigation

Security Concept

Network Access Restriction and Account-Host Validation:

The primary security concept is defense-in-depth for database remote access.

Network controls determine whether a remote host can reach the MariaDB service, while MariaDB account-host definitions determine whether a particular database account can authenticate from that source host. The bind-address setting controls the addresses on which the server listens, while remote access also requires appropriate database-account permissions and firewall configuration. The account definition provides an additional access-control boundary because MariaDB accounts contain both a username and host component.

The secure processing flow is:

Network Reachability
→
Firewall / Interface Restriction
→
MariaDB Connection
→
Account Authentication
→
Account-Host Validation
→
Authorized Host?
→

Yes → Database Access
→
No → Connection Rejected
→
Audit Event
→
Security Monitoring

Defensive Mechanism

Network Access Restriction

The MariaDB TCP service is restricted to the network or hosts that require database access.

Purpose

Prevent unauthorized systems from reaching the MariaDB service.

Controlled bind-address Configuration

MariaDB is configured to listen only on the required network interface rather than unnecessarily exposing the database service on all interfaces.

Purpose

Reduce the network exposure of the MariaDB server.

Firewall Port Restriction

The firewall permits MariaDB traffic only from the approved laboratory source network or application host.

Purpose

Block unauthorized remote connections before they reach MariaDB.

Account-Host Validation

MariaDB accounts are configured with explicit host restrictions.

Purpose

Prevent a valid database username from being used from an unauthorized source host.

Wildcard Host Reduction

Overly broad host definitions such as '%' are identified and replaced with narrower host definitions where remote access is genuinely required.

Purpose

Reduce unnecessary database-account exposure.

Least-Privilege Database Accounts

Application-specific accounts receive only the privileges required for their intended database operations.

Purpose

Limit the impact of an unauthorized or compromised database account.

Local Administrative Access Restriction

Administrative accounts are restricted to appropriate local or explicitly approved management sources.

Purpose

Reduce exposure of privileged database accounts.

Connection Auditing

MariaDB auditing is configured to record connection-related activity, including failed connections where supported by the selected audit configuration.

Purpose

Provide evidence of remote-access attempts and authentication activity.

Security Event Monitoring

Wazuh monitors MariaDB and Ubuntu security activity.

Purpose

Detect suspicious remote connection and authentication activity.

Centralized Security Investigation

OpenSearch stores and correlates security events from the MariaDB environment.

Purpose

Support investigation of unauthorized access attempts and access-control violations.

Periodic Access-Control Validation

The configured network and account-host restrictions are repeatedly tested from authorized and unauthorized laboratory sources.

Purpose

Verify that database access controls remain effective after configuration changes.

Security Tools

Database Server: MariaDB

MariaDB provides the controlled relational database environment.

Purpose
  • Host the laboratory database.
  • Provide controlled remote-access functionality.
  • Enforce database authentication.
  • Apply account-host restrictions.
  • Generate database security events.

Database Client: MariaDB Client

The MariaDB command-line client is used from authorized and unauthorized laboratory sources to validate database connectivity and authentication behavior.

Purpose
  • Test legitimate database access.
  • Test unauthorized remote connections.
  • Validate account-host restrictions.
  • Record connection results.

Network Security Tool: UFW

UFW is used as the host firewall on Ubuntu where appropriate.

Purpose
  • Restrict TCP port 3306.
  • Allow only approved laboratory sources.
  • Block unauthorized network access.
  • Validate network-level access restrictions.

Network Discovery Tool: Nmap

Nmap is used from Kali Linux to identify the controlled MariaDB service exposure.

Purpose
  • Identify whether TCP port 3306 is reachable.
  • Validate firewall behavior.
  • Compare pre-remediation and post-remediation exposure.

Database Audit Tool: MariaDB Audit Plugin

The MariaDB Audit Plugin provides connection and database-activity auditing. It documents CONNECT, QUERY, and TABLE event categories and supports output to a local file or syslog depending on configuration.

Purpose
  • Record connection events.
  • Record failed connection activity where configured.
  • Support security investigation.
  • Provide compliance-oriented audit evidence.

Security Testing Platform: Kali Linux

Kali Linux provides the authorized remote-access testing environment.

Purpose
  • Test MariaDB network exposure.
  • Generate controlled remote connection attempts.
  • Validate account-host restrictions.
  • Perform pre- and post-remediation testing.

Network Analysis Tool: Wireshark

Wireshark is used to inspect controlled database-network traffic.

Purpose
  • Observe connection attempts.
  • Correlate network activity with MariaDB events.
  • Validate whether traffic reaches the database host.
  • Preserve network-level testing evidence.

Security Monitoring Tool: Wazuh

Wazuh monitors Ubuntu and MariaDB security activity.

Purpose
  • Monitor database logs.
  • Detect authentication failures.
  • Monitor repeated remote-access attempts.
  • Generate security alerts.
  • Support security monitoring.

Security Analytics Tool: OpenSearch

OpenSearch provides centralized investigation of MariaDB security telemetry.

Purpose
  • Search database connection events.
  • Correlate failed authentication attempts.
  • Review source-host information.
  • Investigate access-control violations.
  • Preserve the security timeline.

Operating System: Ubuntu Linux

Ubuntu provides the controlled MariaDB server environment.

Purpose
  • Host MariaDB.
  • Apply firewall controls.
  • Store database logs.
  • Execute security monitoring.
  • Provide host-level security telemetry.

Virtualization Platform: VirtualBox

VirtualBox provides the isolated laboratory environment.

Purpose
  • Host Ubuntu and Kali Linux.
  • Provide controlled network segments.
  • Support repeatable access-control testing.
  • Isolate database-security experiments.

Process

STEP 01

Step 1: Prepare the Isolated Database Security Laboratory

  • Create the Ubuntu Linux virtual machine for the MariaDB server.
  • Prepare the Kali Linux security-testing virtual machine.
  • Configure an isolated laboratory network.
  • Assign controlled IP addresses to the laboratory systems.
  • Verify communication between the required hosts.
  • Confirm that all MariaDB testing remains inside the authorized laboratory.
Tools: VirtualBox + Ubuntu + Kali Linux
STEP 02

Step 2: Install and Configure MariaDB

  • Install MariaDB Server on Ubuntu.
  • Start the MariaDB service.
  • Verify that the database service is running.
  • Record the installed MariaDB version.
  • Confirm that local database access works.
  • Preserve the initial configuration for security assessment.
Tools: MariaDB + Ubuntu
STEP 03

Step 3: Establish the Database Baseline

  • Create a synthetic laboratory database.
  • Create sample tables containing non-sensitive test information.
  • Verify local database connectivity.
  • Record the current listening configuration.
  • Record the current firewall state.
  • Record the existing database-account configuration.
Tools: MariaDB + Ubuntu
STEP 04

Step 4: Identify MariaDB Network Exposure

  • Determine the effective MariaDB bind-address.
  • Identify the network interfaces on which MariaDB is listening.
  • Identify whether TCP port 3306 is reachable.
  • Review the server's network configuration.
  • Identify the approved application or administration source.
  • Document the expected remote-access boundary.
Tools: MariaDB + ss + Ubuntu
STEP 05

Step 5: Assess the Database Firewall Boundary

  • Review the Ubuntu firewall configuration.
  • Identify existing rules for TCP port 3306.
  • Determine whether the port is reachable from Kali Linux.
  • Record allowed and denied network sources.
  • Identify unnecessary network exposure.
  • Preserve the pre-remediation firewall state.
Tools: UFW + Nmap + Kali Linux + Ubuntu
STEP 06

Step 6: Create the Controlled Database Accounts

  • Create a dedicated application database account.
  • Create a separate controlled administrative account.
  • Assign strong laboratory credentials.
  • Avoid using the administrative account for application testing.
  • Record the account definitions.
  • Ensure that all accounts use synthetic laboratory data only.
Tools: MariaDB + Ubuntu
STEP 07

Step 7: Configure Account-Host Restrictions

  • Configure the application account with the approved source host.
  • Avoid unnecessary wildcard host definitions.
  • Review existing 'user'@'host' account entries.
  • Identify accounts using broad host patterns.
  • Record the expected source-host policy.
  • Verify the resulting account definitions.
Tools: MariaDB + Ubuntu
STEP 08

Step 8: Establish the Authorized Remote-Access Baseline

  • Configure the approved laboratory application host for remote database access.
  • Verify that the MariaDB service is reachable from the approved source.
  • Authenticate using the dedicated application account.
  • Verify that the account can access only the required database resources.
  • Record the successful connection.
  • Preserve the authorized-access baseline.
Tools: MariaDB Client + Ubuntu + Kali Linux
STEP 09

Step 9: Establish the Unauthorized-Host Baseline

  • Use the Kali Linux system as the controlled unauthorized source.
  • Attempt to connect to TCP port 3306.
  • Attempt to authenticate using the controlled database account.
  • Record the network-level result.
  • Record the database authentication result.
  • Determine whether the account-host policy rejects the source.
Tools: Kali Linux + Nmap + MariaDB Client
STEP 10

Step 10: Perform Controlled Remote-Access Testing

  • Test TCP port 3306 from the unauthorized laboratory source.
  • Attempt a MariaDB connection using the designated account.
  • Test a source host outside the permitted account-host definition.
  • Record whether the request reaches MariaDB.
  • Record whether authentication succeeds or fails.
  • Preserve the complete test results.
Tools: Kali Linux + MariaDB Client + Wireshark
STEP 11

Step 11: Validate Account-Host Matching

  • Review the account's configured host component.
  • Submit a connection from the approved source.
  • Submit a connection from the unauthorized source.
  • Compare the authentication results.
  • Identify whether the expected account is selected for each source.
  • Confirm that unauthorized source hosts do not receive the intended account privileges.
Tools: MariaDB + MariaDB Client + Ubuntu + Kali Linux
STEP 12

Step 12: Validate Network-Level Restriction

  • Configure the firewall to permit MariaDB only from the approved source.
  • Test TCP port 3306 from the approved source.
  • Test TCP port 3306 from the unauthorized source.
  • Verify that the unauthorized source cannot reach the service.
  • Review the firewall logs where available.
  • Record the network-level access-control result.
Tools: UFW + Nmap + Kali Linux + Ubuntu
STEP 13

Step 13: Configure MariaDB Connection Auditing

  • Verify whether the MariaDB Audit Plugin is available in the laboratory deployment.
  • Enable the required connection-audit events according to the deployed version.
  • Configure appropriate audit output.
  • Generate controlled successful and failed connection attempts.
  • Verify that the corresponding events are recorded.
  • Preserve the audit evidence.
Tools: MariaDB Audit Plugin + Ubuntu
STEP 14

Step 14: Configure Wazuh Monitoring

  • Configure Wazuh to monitor relevant MariaDB logs.
  • Monitor failed database connections.
  • Monitor repeated remote-access attempts.
  • Monitor relevant Ubuntu firewall events.
  • Generate a controlled unauthorized-access event.
  • Verify that Wazuh receives the corresponding telemetry.
  • Preserve the resulting security alert.
Tools: Wazuh + MariaDB + Ubuntu
STEP 15

Step 15: Perform Security Risk Assessment

  • Identify the database interfaces exposed to remote systems.
  • Identify database accounts with remote host permissions.
  • Identify wildcard host definitions.
  • Identify unnecessary remote-access paths.
  • Document the affected security-control boundary.
  • Record the likelihood and potential impact within the laboratory risk-assessment framework.
  • Map the identified weakness to the relevant internal access-control requirement.
Tools: MariaDB + Ubuntu + Risk Assessment Documentation
STEP 16

Step 16: Perform Access-Control Remediation

  • Restrict the MariaDB bind-address to the required interface where appropriate.
  • Restrict TCP port 3306 through the Ubuntu firewall.
  • Remove unnecessary remote account definitions.
  • Replace unnecessarily broad host patterns with approved source hosts or networks.
  • Review database privileges for remote accounts.
  • Restart or reload MariaDB where configuration changes require it.
  • Verify that the database service remains available to the approved source.
Tools: MariaDB + UFW + Ubuntu
STEP 17

Step 17: Investigate Security Events Through OpenSearch

  • Forward relevant Wazuh events to OpenSearch.
  • Search for MariaDB authentication failures.
  • Search for unauthorized source-host activity.
  • Correlate network-access events with MariaDB audit events.
  • Review the timestamps of controlled access attempts.
  • Verify the relationship between the testing source and database response.
  • Preserve the investigation timeline.
Tools: Wazuh + OpenSearch + MariaDB
STEP 18

Step 18: Perform Post-Remediation Remote-Access Validation

  • Repeat the authorized connection from the approved source.
  • Verify that legitimate database access remains functional.
  • Repeat the unauthorized connection from Kali Linux.
  • Verify that the unauthorized source is blocked at the appropriate security layer.
  • Review the MariaDB account-host matching result.
  • Review firewall behavior.
  • Confirm that the database is not unnecessarily exposed.
Tools: Kali Linux + MariaDB Client + UFW + MariaDB
STEP 19

Step 19: Perform Final Risk and Compliance Validation

  • Review the final MariaDB network configuration.
  • Review the final firewall configuration.
  • Review database account-host definitions.
  • Verify that unnecessary wildcard remote accounts are not present.
  • Review successful and failed connection audit evidence.
  • Review Wazuh security alerts.
  • Review OpenSearch investigation records.
  • Compare pre-remediation and post-remediation exposure.
  • Confirm that authorized remote database access continues to function where required.
  • Confirm that unauthorized remote access attempts are appropriately blocked or rejected.
  • Preserve the final risk-assessment evidence and security-validation results.
Tools: MariaDB + UFW + Wazuh + OpenSearch + Kali Linux + Ubuntu

Outcome

  1. MariaDB remote-access exposure is assessed within a controlled Ubuntu and Kali Linux security laboratory.
  2. Network-level database exposure is identified and validated through interface, firewall, and TCP port 3306 testing.
  3. MariaDB account-host restrictions are implemented and validated, ensuring that database accounts are associated with explicitly approved source hosts or networks.
  4. Unauthorized remote-access attempts are tested from a controlled source outside the permitted database-access boundary.
  5. Firewall and MariaDB access controls operate as separate security layers, allowing legitimate application connectivity while restricting unauthorized sources.
  6. MariaDB connection auditing provides security evidence for successful and failed connection activity and supports investigation of unauthorized access attempts.
  7. Wazuh provides continuous security monitoring for MariaDB and Ubuntu activity associated with remote-access attempts and authentication failures.
  8. OpenSearch provides centralized investigation and correlation of database audit events, firewall activity, and security alerts.
  9. Post-remediation validation confirms the final access-control boundary, including network restrictions, account-host validation, and continued authorized database functionality.
  10. The complete MariaDB unauthorized remote-access risk-assessment and compliance-validation workflow is demonstrated, covering database deployment, network exposure assessment, firewall restriction, account-host validation, controlled unauthorized-access testing, connection auditing, Wazuh monitoring, OpenSearch investigation, risk assessment, remediation, and final security validation.