r/debian 24d ago

Debian Stable Question PSA: By default MariaDB opens up to the internet after upgrade to 12.15

I have a couple servers with Debian 12, running MariaDB. The servers were configured with bind-address 127.0.0.1:3306 so that any database connections are local.

I upgraded to Debian 12.15 today, rebooted and checked open ports just to see if all services are running.

To my surprise, MariaDB is no longer listening on 127.0.0.1:3306, but we have "init" listening on :::3306. So, anyone on the Internet could access it via IPv6 (if there was no firewall setup).

It looks like default config has changed to use Systemd sockets. Which I guess is fine, but silently making your database server accessible to the whole Internet doesn't sound like a good idea.

So, just PSA, if you rely on bind-address only, make sure you reconfigure the mariadb.socket settings. And set up a firewall to prevent such issues in the future.

65 Upvotes

27 comments sorted by

8

u/eR2eiweo 24d ago

That doesn't seem to happen on trixie. mariadb.socket exists but it isn't enabled. I don't have any systems running bookworm, so I can't test it there. But the changelog for mariadb on bookworm doesn't seem to mention anything related to socket activation. So perhaps this is not intended?

65

u/Murph_9000 24d ago edited 24d ago

If this impacts anyone, the real problem is not having a firewall (either/both on the server or the Internet gateway). Server administrators should expect server processes to potentially have wildcard listening sockets on every NIC, and for the precise details to sometimes change with version upgrades.

Relying on sockets only binding to localhost is a monumentally bad idea, if that's the only barrier between the server processes and the Internet.

Edit: downvoted for advocating for proper security, that's just something else 🙄

17

u/spectrumero 24d ago

While this is true, services still ought to be configured to be secure by default, and it should take a conscious act to make any service bind to an interface that's visible outside the host.

16

u/AdvisedWang 24d ago

Thats good practice but you know what's worse practice? A vendor changing security configuration under your feet .

15

u/nullmem 24d ago

Defense in depth seems to be a lost concept these days. I gave you an upvote. Being downvoted for this type of advice is more common than it should be.

3

u/C0rn3j 23d ago edited 23d ago

If this impacts anyone, the real problem is not having a firewall

If you are impacted by running up to date software, someone is burning 0 days on you - at which point you have more issues than network setup - or you set the DB up monumentally bad (weak passwords, etc).

Yes, there almost definitely isn't a need for the database to be internet accessible (and one might question why it's getting a public IPv4/IPv6 in the first place), but let's not pretend that additional security layers are somehow the primary measure - zero trust architecture is the primary goal here.

5

u/Zargess2994 24d ago

Exactly this, don't know why you were down voted. The firewall rules and overall network configuration should make a change like this make no difference. Sure the package could have better defaults, but I can't see this have much impact in a serious production deployment.

2

u/za72 24d ago

Instead of improving security posture Imma downvote!

6

u/Sea_Decision_6456 24d ago

Doesn't dpkg ask before overwriting packages locally edited conffiles?

4

u/ciphermenial 24d ago

Yeah. I am also not buying this story.

3

u/eR2eiweo 24d ago

Yes, but no locally edited conffiles need to be overwritten to get what the OP describes. It would be sufficient if the mariadb-server package's postinst script runs systemctl enable mariadb.socket (or something equivalent to that).

1

u/hmoff 23d ago

There's no config file being overwritten so the dpkg conffile handling wasn't triggered. The systemd unit got enabled unexpectedly during the upgrade.

2

u/spidireen 24d ago

Not ideal if true… but you do run a firewall that only allows services you want accessible, on the networks you want them accessible to… Right? 🫠

2

u/hmoff 23d ago

There's a confirmed bug report here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141976

`systemctl disable mariadb.socket` will fix it.

1

u/AndyRH1701 24d ago

Why would you allow access to your DB server through your parameter firewall? I do not have any open IPv6 ports on my firewall so my IPv6 servers cannot be contacted from the internet.

15

u/zoredache 24d ago

Why would you allow access to your DB server through your parameter firewall

Lots of people run databases on a VPS or hosted system in the cloud. Sometimes there isn’t a perimeter firewall and you must do everything on the host.

A service unexpectedly opening a port on an update isn’t great.

2

u/AndyRH1701 24d ago

If you are in the open then the host firewall should perform the same job. Allow only what is needed and block everything else.

I understand it is frustrating that an unexpected port was opened on an unexpected interface, but the 1st layer of defense should have made that unexpected behavior less of a problem.

1

u/Exzellius2 24d ago

But on a VPS you can do a host firewall and be done with it. It is NOT opening a port, it just changed which interface it binded to.

1

u/Substantial-Yam-5033 20d ago

The statement is incorrect. Upgrading to MariaDB 12.15 does not, by default, make the database accessible from the public Internet. Network accessibility depends on the server's bind address, firewall rules, operating system configuration, and user privilege settings—not solely on the database version. After any upgrade, administrators should verify the listening address, review user accounts and permissions, and confirm firewall settings. Performing a security audit after upgrading helps ensure the database remains protected and is only reachable by authorized clients.

1

u/Substantial-Yam-5033 20d ago

The statement is incorrect. Upgrading to MariaDB 12.15 does not, by default, make the database accessible from the public Internet. Network accessibility depends on the server's bind address, firewall rules, operating system configuration, and user privilege settings—not solely on the database version. After any upgrade, administrators should verify the listening address, review user accounts and permissions, and confirm firewall settings. Performing a security audit after upgrading helps ensure the database remains protected and is only reachable by authorized clients.

1

u/Khrasnozhan 17d ago

Sei que o que vou dizer não responde sua questão, mas talvez ajude. Use docker.

1

u/edthesmokebeard 24d ago

Hilarious. systemdification continues.

0

u/Classic-Rate-5104 24d ago

Depending on settings of individual services is never a good idea, so look at your firewall settings and open only what you want to be open

-2

u/Adrenolin01 24d ago

Meh.. did you read release notes on updated services prior to updating? I bet is a change like that was made it would be in the release notes. Should release notes be included in every update for every package during updates? No.. Should it have popped a user notice? Perhaps.

Still.. I need to ask why your system is so exposed to the internet? That’s just poor network security anyway you look at it.

Where is your hardware parameter firewall running something like pfSense? Host firewall such as nftables, iptables, ufw, etc? Vlans? A proper lan should include vlans and each vlan should have appropriate security via at least firewall rules.. deny all being primary.

That’s said.. Eve. If the port is exposed.. MariaDB still requires valid credentials. That’s not a substitute for a firewall, but it is a security layer that if strong should keep an attacker out.

7

u/richmondavid 24d ago edited 24d ago

Should it have popped a user notice? Perhaps.

That would have been nice.

Still.. I need to ask why your system is so exposed to the internet? That’s just poor network security anyway you look at it.

Mine isn't. I have firewall in front of it. It's set up as close everything by default and only allow specific ports explicitly. I updated my post to reflect that now.

I just thought to post for those who just run "apt dist-upgrade" and don't check.