Re: postgres "on in the internet" - Mailing list pgsql-general
From | Lincoln Yeoh |
---|---|
Subject | Re: postgres "on in the internet" |
Date | |
Msg-id | 5.2.1.1.1.20040903214629.0355a5c8@localhost Whole thread Raw |
In response to | postgres "on in the internet" (Paul Tillotson <pntil@shentel.net>) |
Responses |
Re: postgres "on in the internet"
Re: postgres "on in the internet" |
List | 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 >
pgsql-general by date: