Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

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 ?

share|improve this question
I would imagine that the top two answers for that question would hold true here, too since it's ultimately about the networking setup of the server. –  swasheck Aug 19 '12 at 0:57
Changing the port of the database (be it PostgreSQL or SQL Server) does not add any security to your installation. –  a_horse_with_no_name Aug 19 '12 at 15:42
@a_horse_with_no_name It absolutely does. It doesn't make it secure, but it'll potentially help against simple worms and other automated, least-effort scanning. Stupid to rely on, but reasonable to do as a tweak. –  Craig Ringer Aug 20 '12 at 1:50
add comment

3 Answers

up vote 5 down vote accepted

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.

share|improve this answer
many thanx for your introduction to the real security issues, and the other reasons for still continuing to change the port number. –  Stephane Rolland Aug 20 '12 at 9:23
add comment

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.

share|improve this answer
What tips it to "yes" for me is worms. Look at what happened to SQL Server. Since today's modern viruses and worms use multiple exploits to get around I could easily see a worm on some user's laptop/desktop/etc scanning for Pg on 5432 and whacking a pre-auth vuln, but not bothering to do detailed probing to find Pg on other ports. Not that there are any known vulnerabilities, but IMO a port change is a very small effort that's worth it even for probably very small gains. Of course I VLAN desktops and laptops off from the DB server so in practice it's unlikely, but not everyone does/can. –  Craig Ringer Aug 31 '12 at 0:14
add comment

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.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.