Firewall Security Requirements for Postgresql Access

[Randy Yates]

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?
--
% Randy Yates % "My Shangri-la has gone away, fading like
%% Fuquay-Varina, NC % the Beatles on 'Hey Jude'"
%%% 919-577-9882 %
%%%% <ya***@ieee.org> % 'Shangri-La', *A New World Record*, ELO
http://home.earthlink.net/~yatescr

[Gaetano Mendola]

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

[Gaetano Mendola]

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?

I forgot, don't open only the 5432 and sleep well. Don't forget the
antispoofing rules.
Regards
Gaetano Mendola

[Ben]

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 ma*******@postgresql.org)

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Tom Lane]

Gaetano Mendola <me*****@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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Greg Stark]

Tom Lane <tg*@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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Randy Yates]

be***@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..."
%%%% <ya***@ieee.org> % 'One Summer Dream', *Face The Music*, ELO
http://home.earthlink.net/~yatescr

[Bruno Wolff III]

On Wed, Sep 08, 2004 at 03:12:29 +0000,
Randy Yates <ya***@ieee.org> wrote:

be***@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.

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings