Changing the port of the postgresql server for security reasons

Question

For security reasons, it is common to change the port of Microsoft Sql Server. The subject is discussed here in Is changing the SQL Server port really that much safer?

my question is: does this apply also to PostgreSQL ? Or is it unrelated ?

Answer 1

Opinions vary, but in my view it's mildly useful to use a non-default port on any Internet-exposed service that isn't for general public use. Changing your port is not security. It adds absolutely no security in normal operation, and is only minimally useful if your security is already compromised by the discovery of a remotely exploitable security hole. At best it's a delaying and mitigation option to give you a slightly higher chance of patching a security hole before a worm exploits it.

Using a non-default port will not protect you from having vulnerabilities exploited, or from any kind of targeted attack. It may help reduce the chances that a simple worm or casual broad-based scanning effort will attempt to exploit a security hole in your service, but it won't slow anyone who's interested in your system specifically down for a heartbeat.

Note that PostgreSQL doesn't have the same kind of history of severe remotely-exploitable security holes that MS SQL Server does. That doesn't mean it won't ever have remotely exploitable holes in it or in plug-in authentication mechanisms like Kerberos, so you should always be ready for the possibility.

For actual security, you want to be thinking about:

• Limiting connections to trusted machines. If your DB is on a VLAN that only contains its self and the application server there's no point playing with ports. Similarly, if you don't need the DB exposed to the Internet, make sure it doesn't run on a public host or at least set it to bind only to an internal IP address and firewall it off too.

• Banning clear-text auth. Use at least SSL, if not Kerberos or other moderately strong protocol.

• Strong or multi-factor authentication; none of this username-the-same-as-password business.

• Ensure your apps never use superuser roles and they only have the least required priveleges on the database objects they interact with. Your apps shouldn't connect with the user/role that owns the database or its tables unless absolutely necessary. GRANT them the minimum rights required.

• Disallow remote connection by superuser roles in pg_hba.conf

• IP connection limits. If all the machine's clients use a particular ISP, use a firewall to drop connections from outside the IP netblocks you know may be used. You can do it with pg_hba.conf too, but if you do it in the firewall you're preventing them from even handshaking with Pg.

• ... and lots more. There's lots on the 'net about locking down and securing Pg. See, eg, Depesz's article, Bruce Momjian's presentation, and this DeveloperWorks article.

I change the public SSH port on all my machines for a similar reason. It won't stop anybody, but it might slow automated attacks and worms down slightly. More importantly, it reduces the enormous volume of scanning spam in my system logs to the point where the logs become useful again.

Answer 2

I'd say No, though of course this is not so much an answer as a principle. The main result is probably a false sense of extra security.

The question you need to ask is "what am I trying to protect myself from?".

In general on a database that is exposed to the public internet, you would not be opening a port to the database at all - the world would only see your application layer.

On databases that only need to be accessed by users on your LAN (and VPN), often you do need direct access to the database, and this is probably the case you have in mind? Security on the LAN is a balance of convenience and protection, and I think you have to choose whether you either:

1. trust your clients
2. do not trust your clients

In the first case there is no need to change the port number, in the second, changing the port number is not enough.

Answer 3

Personally I would look at this only after every other option. For example firewalls, locking down the pg_hba.conf appropriately, etc. It might be useful but it is so far down the list of useful tools, I would be concerned about it being a bit of a distraction from the rest.