Re: libpq heartbeat

Merlin:

On Thu, Oct 27, 2016 at 7:29 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Thu, Oct 27, 2016 at 11:18 AM, Francisco Olarte
> <folarte@peoplecall.com> wrote:
>> It is, but handling them is not easy, and you have to deal with things
>> like DoS which are not trivial on the server ( as it is a heavy
>> service ). It can be done, and sometimes needs to be done, but is not
>> a thing to take over lightly.
>>> This could be over ssh tunnel for example.
>> In which case it is NOT exposed to the internet. What are you trying to say?
>
> what?   ssh can most certainly convey over the internet.   I said ssh
> *tunnel*; not ssh.   With tunneling the ssh endpoint is the client
> application.   When I built a libpq based intenet facing application
> we used a modified pgbouncer to whitelist the parameterized query
> strings and to force the auth.  We had zero issues.

I'm not a native English speaker, so I have some problem understanding
the finer details....

I said libpq service/protocols are tricky to put on the internet.

You replied, among other things, it could be over an ssh tunnel ( I
use ssh tunnels continuously, to the point I routinely open/close them
on live connections via escape, so I know  they are ).

The I said in that case it is NOT exposed to the internet, trying to
mean libp/postgres is NOT exposed to the internet. They are exposed to
the SSH tunnel endpoint. Of course, payload still goes through the
interrnet, but they are not directly exposed.

As an example, leaving potential SSL and encryption usage in postgres
aside. If I expose postgres on the internet you can mount a DoS attack
against me, and postmaster will have to defend against it. IIRC
postmaster does not fork until client is authenticated, but even then
I suspect its accepting code is not dessigned with the same care to
deal with hostile connection attempts as the one in ssh, or even on a
web server. So you may be able to DoS me with much less resources than
you would need to DoS the ssh server.

And, also, if you are exposing the postmaster directly I think client
and server certificates are a must, aside from passwords. But I doubt
someone who does not know about the keepalive stuff like the OP uses
more than server certs and passwords, although I hope I'm proven wrong
by him. In general I use the tunneling approach for postgres, as I my
security guys continuously monitor and patches the ssh servers. But,
if he were dealing with that kind of stuff and told me I would have
pointed him in the direction of ssh[d]_config to enable ssh keepalives
for his firewall problems and not said a word about the non-existent
perils of exposing the postmaster.

Francisco Olarte.