Network Security for Databases

Database Security

Chapter 4 · Network Security for Databases

Chapter 1's warning box described a wave of ransomware attacks against databases exposed directly to the internet — no exploit, no injection, just a reachable port with nothing guarding it. This chapter is the deep dive on exactly that failure mode: making sure the network itself never gives an attacker a path to the database in the first place.

Binding to Localhost / Private Networks Only

A database's own configuration controls which network interfaces it listens on. Binding to 127.0.0.1 (localhost only) or a private network address means the database is physically unreachable from the public internet, regardless of any firewall — there's no route to it at all from outside.

# MySQL — my.cnf
[mysqld]
bind-address = 127.0.0.1

# PostgreSQL — postgresql.conf
listen_addresses = 'localhost'

When the application and the database run on genuinely separate machines, "localhost only" isn't an option — bind instead to the private network interface (a VPC-internal IP) that only other machines on that same private network can reach, never a public IP.

Firewall Rules

Binding to a private interface handles reachability from the public internet — a firewall handles reachability from everything else, including other machines on the same private network that still shouldn't have a path to the database port. The rule to apply: allowlist only the specific hosts (application servers, a bastion host) that genuinely need to connect, and deny everything else by default.

# ufw — only this one application server's IP may reach MySQL's port
sudo ufw allow from 10.0.1.15 to any port 3306
sudo ufw deny 3306

VPN & Bastion Host Access Patterns

Developers and DBAs still legitimately need occasional direct access — but that doesn't mean opening the database port itself to their laptops. The standard pattern: route human access through a VPN (the vpn1 course covers setup) or a bastion/jump host — a single, tightly monitored server that itself is allowed to reach the database, which a person tunnels through via SSH.

# SSH local port forwarding through a bastion host
# (the exact mechanism remote_lesson_05 covers in the SSH course)
ssh -L 3306:db-internal-host:3306 user@bastion-host

# now connecting to localhost:3306 actually reaches the private database,
# tunnelled through the bastion — the DB port itself is never exposed

The database only ever needs to trust the bastion host's own IP in its firewall rules — individual developers' laptops, on changing IPs from home or a coffee shop, never need direct network access at all.

Never Expose a DB Port Directly to the Public Internet

Every rule above serves one central conclusion: a database port reachable from 0.0.0.0/0 (anywhere on the internet) is a mistake, full stop, regardless of whether authentication is enabled. It's not a matter of "probably fine since there's a password" — it's an unnecessary, entirely avoidable exposure of a valuable target to every scanner on the internet.

	Public-Facing DB Port	Private Network + Bastion
Who can even attempt to connect	anyone on the internet	only the application server(s) and the bastion host
Discovered by automated scanners?	routinely, often within minutes to hours	never — there's no public route to find
A leaked/weak password's impact	immediately exploitable by anyone who finds the port	useless without also being on the private network or through the bastion

Internet-wide scanners find exposed database ports within minutes

Automated internet-wide scanning tools continuously probe the entire public IP space for open, well-known database ports — this isn't a targeted attack against a specific organization, it's a standing background process constantly sweeping the internet. A database port opened to 0.0.0.0/0, even briefly during setup or testing, gets discovered far faster than most people expect — often before anyone even finishes configuring it. Chapter 1's ransomware example is the second half of this exact story: the scanner finds the open port first; whether authentication was ever properly configured is what determines what happens next. This chapter's job is making sure the first half — the port even being findable — never happens at all.

"We'll restrict it later" is how exposure becomes permanent

A database port opened to everywhere "just for initial setup, we'll lock it down after" is exactly the kind of shortcut — like Chapter 2's "temporary" shared account — that quietly becomes the permanent configuration once the setup task is marked done and attention moves elsewhere. Configure the bind address and firewall rule correctly from the very first deployment, not as a follow-up task.

Hands-On Exercises

Exercise 1

Explain the difference between binding a database to 127.0.0.1, binding it to a private network IP, and binding it to 0.0.0.0. Which of these, on its own, makes a database reachable from the public internet?

📄 View solution

Exercise 2

A developer wants occasional direct access to a production database for debugging. Describe the bastion-host access pattern that lets them do this without ever opening the database's port to the public internet.

📄 View solution

Exercise 3

A teammate argues "our database has a strong password, so exposing the port publicly for convenience is fine." Using this chapter's material, explain what's wrong with that reasoning.

📄 View solution

Chapter 4 Quick Reference

Bind address controls which network interfaces the database listens on at all — 127.0.0.1 (localhost) or a private IP is safe; 0.0.0.0 without a firewall is not
Firewall rules allowlist only the specific hosts that genuinely need to connect — deny by default
VPN or bastion host access lets humans reach the database without ever opening its port directly — tunnel via SSH (ssh -L, per the SSH course's remote_lesson_05) or a VPN (vpn1 course)
A database port reachable from anywhere on the internet is a mistake regardless of password strength — automated scanners find exposed ports within minutes to hours
Configure network security from first deployment — "restrict it later" reliably becomes permanent, the same as Chapter 2's shared-account shortcut
Next chapter: Encryption at Rest — full-disk encryption, transparent data encryption (TDE), column-level encryption, key management basics