MySQL on port 3306 is the default port for MySQL and MariaDB database servers. MySQL is one of the most-deployed open-source databases in the world — used as backend for countless web applications, embedded in WordPress, common in LAMP-stack deployments. Direct database access via port 3306 is intended for application servers, not for end users.
The single biggest MySQL security pattern is internet-exposed databases. Every year, security researchers discover hundreds of thousands of MySQL instances directly reachable from the public internet — often with default or weak credentials, frequently containing production data. Shodan continuously indexes these; ransomware groups actively target them. Beyond the exposure issue, MySQL has had its share of historical CVEs in authentication, query parsing, and storage engines.
For defenders, the standard MySQL security architecture: never expose port 3306 to the internet (firewall block at perimeter), application servers connect via private network (or local socket if same host), strong unique passwords for all accounts (especially the root account), dedicated database users per application with minimum required privileges (no application using the root account), require TLS for connections (encrypts in transit), regular patching, and audit logging for sensitive operations.
Standard external recon includes scanning for database ports — port 3306 (MySQL), 5432 (PostgreSQL), 1433 (MS-SQL), 27017 (MongoDB), 6379 (Redis), 9200 (Elasticsearch). Internet-exposed database is always a critical finding. Tools: nmap -p 3306,5432,1433,27017,6379,9200 target_range, masscan, Shodan queries.
Pentest — MySQL credential brute force
When MySQL is in scope, brute force common credentials (root/empty, root/root, root/password, application-name as both user and password). Tools: hydra, medusa, custom scripts. Successful login often grants full database access — read all data, modify or delete records, sometimes execute system commands via UDFs (User Defined Functions) or file_priv operations.
Web application pentest — SQL injection escalation
When SQL injection is found in a web application, the database privileges of the application user determine impact. Apps connecting as root can do anything; apps with dedicated minimum-privilege users have constrained impact. Always assess application database user privileges; recommend dedicated users with minimum permissions during reporting.
Database compromise investigation focuses on: connection logs (who connected when, from where), query logs (what was queried, especially data-modifying queries), file_priv operations (file reads/writes via SQL), and unusual user creation. Many MySQL deployments have minimal logging by default; enabling general_log or audit plugin retroactively does not help if the compromise already happened.
Backup security — encrypted backups and restricted restore
MySQL backup files (mysqldump output, binary backups) often contain the entire database including sensitive data. Encrypt backups at rest, restrict restore privileges, audit backup access. Compromised backup access equals compromised production database.
Common mistakes & edge cases
Binding MySQL to 0.0.0.0 (all interfaces) when only local access needed
Default in some installations is bind-address = 0.0.0.0 — listens on all network interfaces. If the host has a public IP, MySQL is internet-exposed by default. Set bind-address = 127.0.0.1 for local-only access, or specific private network IP for app-server-only access.
Using root account for application connections
Applications should never connect as root. Create dedicated users per application (e.g. wordpress_user, analytics_app), grant only required privileges (typically SELECT/INSERT/UPDATE/DELETE on specific tables), no GRANT, no FILE, no SUPER. Constrains impact of credential compromise or SQL injection.
No TLS for MySQL connections
Default MySQL connections are cleartext — credentials and query results observable on network path. Configure MySQL with TLS (server certificate, optional client certificates), require TLS for sensitive accounts (REQUIRE SSL on user creation). Application connection strings updated to enable TLS verification.
Default passwords or empty root password
Fresh MySQL installs sometimes leave root password empty or as default. mysql_secure_installation script sets root password and removes anonymous users — run it after every install. Audit existing instances with SELECT user, host, authentication_string FROM mysql.user; — empty authentication_string means no password.
No audit logging
MySQL Enterprise has audit plugin; community edition has general_log (verbose) and Percona/MariaDB audit plugins (production-grade). Without audit logging, compromise investigation is severely limited. At minimum, log connections, login failures, and DDL statements. Pre-incident is the only time to deploy this; retrofitting after compromise does not help.
Sharing accounts across applications
Shared accounts (multiple applications using the same MySQL user) prevent isolation — compromise of one application grants access to all data the shared user can access. Per-application accounts allow proper privilege separation and cleaner audit trails.
Frequently Asked Questions about port 3306
MySQL is one of the most-deployed open-source relational databases. Powers WordPress, much of the LAMP stack, many SaaS applications, and countless internal tools. Default port 3306. MariaDB is a MySQL fork with enhanced features and similar default configuration. Both use port 3306 by default.
Three reasons: (1) automated scanning continuously discovers exposed instances, (2) credential brute force is highly automated and effective against weak passwords, (3) successful access typically gives full database access — read all data, modify records, sometimes execute system commands via SQL features. Combined: predictable breach pipeline from exposure to compromise.
External: nmap -p 3306 your.public.ip from outside your network. Internal: check bind-address in MySQL config (SHOW VARIABLES LIKE "bind_address") — should be 127.0.0.1 or specific private IP, not 0.0.0.0. Plus firewall rules confirming port 3306 blocked at perimeter.
Both are excellent open-source databases. MySQL is more common for web applications and has wider community support for that use case. PostgreSQL is more SQL-standard-compliant and has stronger features for complex queries and data integrity. Pick based on application requirements; security configuration patterns are similar for both.
MariaDB was forked from MySQL in 2009 over concerns about Oracle's acquisition of MySQL. The two have diverged over time — different features, slightly different SQL extensions, different administrative tools. For most applications they are interchangeable. Both use port 3306 by default and follow similar security configuration patterns.
SQL: CREATE USER 'webapp'@'localhost' IDENTIFIED BY 'strong_password'; then GRANT SELECT, INSERT, UPDATE, DELETE ON app_db.* TO 'webapp'@'localhost'; then FLUSH PRIVILEGES;. Specify host ('localhost' or specific IP) to restrict where the user can connect from.
Generate or obtain server certificate, configure MySQL with cert paths (ssl-cert, ssl-key, ssl-ca), restart MySQL. Verify with SHOW VARIABLES LIKE '%ssl%';. For specific user accounts to require SSL: ALTER USER 'webapp'@'localhost' REQUIRE SSL;. Update application connection strings to enable TLS verification.
A script bundled with MySQL that walks through basic security setup: set root password, remove anonymous users, disable remote root login, remove test database. Run it after every fresh MySQL install. Takes one minute; addresses the most common default-config security issues.
Enable connection logging (general_log selectively or audit plugin), forward logs to SIEM, alert on: failed login spikes, successful logins from unusual sources, GRANT/REVOKE statements, file_priv operations, schema changes outside maintenance windows. Most environments have minimal MySQL logging by default; investing in logging before incidents is what matters.
SQL injection exploits application code that constructs queries by concatenating user input. The vulnerability is in the application, not MySQL itself. MySQL executes the queries it receives. Mitigations are at the application layer (parameterised queries, ORMs, input validation). Database-side: ensure application user has minimum required privileges so SQL injection cannot escalate to DROP TABLE or extract data outside the app's scope.