Re: postgres "on in the internet"

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: Paul Tillotson <pntil(at)shentel(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: postgres "on in the internet"
Date: 2004-09-03 14:10:30
Message-ID: 5.2.1.1.1.20040903214629.0355a5c8@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I doubt it's a good idea to make your postgres server internet accessible.
You'll be using postgresql in what I'd consider to be a less tested
scenario. Most people don't expose their database servers to the Internet.

You could use the following configuration:

client (with IPSEC VPN)
|
Internet
|
Firewall #1 (VPN endpoint)
|
Staging network (for VPN clients)
|
Firewall #2
|
Database server

The clients with VPN access get access to whatever the staging network has
access to - which may be the postgresql db port and other services, but
nothing else not explicitly permitted by Firewall #2, or Firewall #1.

You can combine Firewall #1 and #2 - this example is just to make the
concept clear. However combining the firewalls increases the risk in event
the firewall is somehow subverted (e.g. prob with IPSEC implementation).
Whereas keeping the firewalls separate means you can simplify what features
the Firewall #2 needs - e.g. no IPSEC, and thus reduce the exposure to
potential bugs.

If you don't want to or can't use IPSEC VPNs, you could try SSL and drop
connections from clients with unrecognized certs. You may wish to put the
SSL endpoint on another server (openssl's security track record hasn't been
that good, neither has openssh for that matter).
e.g.

client (using SSL)
|
Internet
|
Firewall #1
|
Staging network---SSL endpoint server
(for SSL clients)
|
Firewall #2
|
Database server

Another factor to consider: you may wish to test out Postgresql's network
performance over higher latency connections first - what would the typical
and bad case network latencies be for your scenario? My guess is roundtrip
latencies would be about 50-150ms good case (same continent broadband), and
200-700 msec bad case - inter-continent or dial up. Depending on your
application, it may be OK. However if your client has to make 10 queries in
series (nonparallelizable) where the results of a query affects what is the
subsequent query, latency could be an issue.

Regards,
Link.

At 07:35 PM 9/2/2004 -0400, Paul Tillotson wrote:

>At my company we are looking at deploying clients for our client/server
>app outside our firewall, which will then require our postgres box to be
>internet-accessible.
>Does anyone out there have experience with this or recommended best
>practices? We have been looking at either (a) tunnelling everything over
>ssh, or (b) just making sure that users have "strong" passwords and
>requiring "md5" authentication in pg_hba.conf.
>
>Our client app is in C# using the postgresql .net data provider.
>
>Regards,
>Paul Tillotson
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Shelby Cain 2004-09-03 14:11:24 pl/pgsql exceptions
Previous Message Barry S 2004-09-03 14:02:52 Re: Gentoo for production DB server?