Posted Apr 4, 2013 18:20 UTC (Thu) by alogghe (subscriber, #6661)
[Link]
Agreed. Restricting connections to a specific network is DBA 101.
You are just bad if you aren't doing that already.
Restricting RDBMS network access
Posted Apr 5, 2013 12:05 UTC (Fri) by tialaramex (subscriber, #21167)
[Link]
Sadly it's made harder than it really needs to be. For example, we have a bunch of MySQL servers that are actually only used by Java processes running on the same machines. There's no need for these MySQL servers to be accessible over the network at all and we could disable that altogether. Except it seems the Java MySQL connector doesn't _do_ Unix sockets, so they have to talk TCP/IP anyway and we're obliged to explicitly firewall the machines off to get where we ought to be from a security POV.
I see that MySQL's TLS/SSL functionality default to "disabled" too. So out of the box you're going to be tempted to do unencrypted, unauthenticated TCP/IP query sessions over the Internet.
Restricting RDBMS network access
Posted Apr 5, 2013 12:14 UTC (Fri) by dskoll (subscriber, #1630)
[Link]
Except it seems the Java MySQL connector doesn't _do_ Unix sockets, so they have to talk TCP/IP anyway
On Debian at any rate, PostgreSQL listens on a TCP socket, but it's bound to 127.0.0.1 by default. Why can't MySQL do the same thing?
Restricting RDBMS network access
Posted Apr 5, 2013 12:48 UTC (Fri) by anselm (subscriber, #2796)
[Link]
MySQL can do this in principle, but it's not completely trivial. You need to specify the host by IP address (127.0.0.1); if you just put »localhost« the client library will go for the Unix-domain socket even though it looks as if it is using TCP/IP.
The other problem is that the MySQL server will listen to either all of its host's IP addresses or else one single IP address. This means that if you configure it to listen on 127.0.0.1 you don't get to specify another address, e.g., of an internal »bridged« network for virtual machines. This is admittedly a minor inconvenience but still a hassle to work around.
Restricting RDBMS network access
Posted Apr 5, 2013 17:59 UTC (Fri) by dskoll (subscriber, #1630)
[Link]
You need to specify the host by IP address (127.0.0.1); if you just put »localhost« the client library will go for the Unix-domain socket even though it looks as if it is using TCP/IP
Not the Java library, surely, which only does TCP sockets?
The other problem is that the MySQL server will listen to either all of its host's IP addresses or else one single IP address.
Well yes, that is a defect. But if MySQL already supports listening on two sockets (TCP and UNIX-domain) I can't imagine it would be that hard to modify it to support a list of bind addresses.
Restricting RDBMS network access
Posted Apr 5, 2013 17:05 UTC (Fri) by butlerm (subscriber, #13312)
[Link]
> Except it seems the Java MySQL connector doesn't _do_ Unix sockets, so they have to talk TCP/IP anyway
That really isn't MySQL's fault. Java doesn't support Unix sockets, and they don't want to, on portability grounds. Several years back they removed support for reading environment variables for the same reason. It is a least common denominator thing.
Restricting connections? Always :-).
Posted Apr 7, 2013 9:40 UTC (Sun) by walex (subscriber, #69836)
[Link]
«Restricting connections to a specific network is DBA 101.»
That's one of the most universally true statements ever:
* Restricting connections to HTTP server port 80 and port 443 to a specific network is webadmin 101.
* Restricting connections to DNS server port 53 to a specific network is hostmaster 101.
And so on! Let's call this Mordac's Rule.
Not allowing the end users to access a DBMS at all, or only indirectly via a front-end application or web UI can be supported by the following arguments:
* Not providing a service is an excellent security idea. The disconnected computer is more "secure", and the powered off one is even more "secure".
* Providing a service via a front-end is much more "secure" than providing it via the base tool itself: because experience shows dramatically how much more "secure" PHP/... based application or web UI front-ends are than their DBMS back-ends.
* Regardless of the above points, insisting that all DBMS instance access be via front-ends and then only allowing those front-ends to connect to DBMS instances means delegating accountability for security issues to the front-end owners, and can be a career-security enhancing measure too for the DBMS owners, not merely enhancing overall system security by protecting a weak DBMS with a strong front-end.
:-) :-) :-)
Restricting connections? Always :-).
Posted Apr 8, 2013 13:26 UTC (Mon) by ortalo (subscriber, #4654)
[Link]
Yep, but this is business 101 (equivalence with career 101).
At security 101, now I teach that an incorrect security measure is worse than no security measure at all. (Demo.hint: every security measure has a cost...)
However, business 201 reacted promptly by adjusting their security requirements to match the mechanisms chosen in first year. I never understood why they did not take advantage of the productivity enhancement offer? (Maybe because, in the end, they know how to treat security the same ways as documentation...)
Restricting connections? Always :-).
Posted Apr 9, 2013 1:24 UTC (Tue) by dskoll (subscriber, #1630)
[Link]
Providing a service via a front-end is much more "secure" than providing it via the base tool itself:
Well of course it isn't. But allowing access via a front-end and direct database access is by definition less secure than only allowing the front-end because there's a larger attack surface to exploit.
A serious PostgreSQL security fix
Posted Apr 5, 2013 13:24 UTC (Fri) by FranTaylor (guest, #80190)
[Link]
How do you interpret the "more true" part other than "they are even worse than we are"?
A serious PostgreSQL security fix
Posted Apr 8, 2013 13:39 UTC (Mon) by ortalo (subscriber, #4654)
[Link]
We understood the same but I did not comment especially on that part; I find that part pretty inelegant...
