Thread: Re: Firewall Security Requirements for Postgresql Access
Randy Yates wrote: > Is opening up port 5432 (R/W both directions) all that is required > of a firewall in order to access a postgres database outside the > firewall? Yes it is. Regards Gaetano Mendola
Well, R/W doesn't make much sense for TCP.... incoming/outgoing SYN packets make more sense, and if the database is located outside the firewall, you really only need to allow outgoing SYN packets on the port (as well as packets related to that session, of course). On Wed, 8 Sep 2004, Gaetano Mendola wrote: > Randy Yates wrote: > > > Is opening up port 5432 (R/W both directions) all that is required > > of a firewall in order to access a postgres database outside the > > firewall? > > Yes it is. > > > Regards > Gaetano Mendola > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
Gaetano Mendola <mendola@bigfoot.com> writes:
> Randy Yates wrote:
>> Is opening up port 5432 (R/W both directions) all that is required
>> of a firewall in order to access a postgres database outside the
>> firewall?
> Yes it is.
If it's a stateful firewall (eg something doing NAT translation) you
will also want to ask hard questions about how quickly it drops idle
connections. If the answer is "less than an hour, and you can't change
it" then you may want to think about buying a different firewall.
Else, idle database connections are likely to disappear from under your
clients.
Postgres does enable TCP "keepalive" to prevent idle connections from
dying, but most kernels only send keepalive probes every hour or so.
(The TCP RFCs actually specify how often to do this, IIRC.) If the
firewall drops idle connections after less than the TCP keepalive interval,
you got trouble.
You can of course work around this in any number of ways, but it's
better not to use a standards-challenged firewall in the first place.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Postgres does enable TCP "keepalive" to prevent idle connections from dying,
> but most kernels only send keepalive probes every hour or so. (The TCP RFCs
> actually specify how often to do this, IIRC.)
RFC 1122 4.2.3.6:
Keep-alive packets MUST only be sent when no data or
acknowledgement packets have been received for the
connection within an interval. This interval MUST be
configurable and MUST default to no less than two hours.
> If the firewall drops idle connections after less than the TCP keepalive
> interval, you got trouble.
Of course it really ought to wait at least some reasonable multiple of the
keepalive interval since either the data or the ack could get dropped. In fact
dropping connections after only a single keepalive being dropped is explicitly
prohibited:
It is extremely important to remember that ACK segments that
contain no data are not reliably transmitted by TCP.
Consequently, if a keep-alive mechanism is implemented it
MUST NOT interpret failure to respond to any specific probe
as a dead connection.
Of course NAT violates uncounted RFCs in the first place. But if you're going
to do NAT you usually really want the timeouts to be on the order of days, not
hours.
--
greg
bench@silentmedia.com (Ben) writes: > Well, R/W doesn't make much sense for TCP.... incoming/outgoing SYN > packets make more sense, and if the database is located outside the > firewall, you really only need to allow outgoing SYN packets on the port > (as well as packets related to that session, of course). Are you suggesting that the firewall be configured so that the only outgoing packets allowed through are ones with the SYN bit set in the CODE BITS field of the TCP header? I'm fairly ignorant on protocol matters, and I don't understand why one would single out these types of TCP segments. Could you please expound? -- % Randy Yates % "Bird, on the wing, %% Fuquay-Varina, NC % goes floating by %%% 919-577-9882 % but there's a teardrop in his eye..." %%%% <yates@ieee.org> % 'One Summer Dream', *Face The Music*, ELO http://home.earthlink.net/~yatescr
On Wed, Sep 08, 2004 at 03:12:29 +0000, Randy Yates <yates@ieee.org> wrote: > bench@silentmedia.com (Ben) writes: > > > Well, R/W doesn't make much sense for TCP.... incoming/outgoing SYN > > packets make more sense, and if the database is located outside the > > firewall, you really only need to allow outgoing SYN packets on the port > > (as well as packets related to that session, of course). > > Are you suggesting that the firewall be configured so that the only > outgoing packets allowed through are ones with the SYN bit set in the > CODE BITS field of the TCP header? I'm fairly ignorant on protocol > matters, and I don't understand why one would single out these types > of TCP segments. Could you please expound? Blocking SYN packets can be used to prevent the set up of a TCP connection. One way to block inbound connections to ports, but allow outbound connections to them is to block incoming SYN packets. This has the advantage that no state needs to be maintained about the connection. The normal situation is that inbound SYN packets are blocked except for the few ports to which you want to allow connections to.