Changing the port of the postgresql server for security reasons 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 ?
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.