Merlin: On Thu, Oct 27, 2016 at 7:29 PM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: > On Thu, Oct 27, 2016 at 11:18 AM, Francisco Olarte > <folarte@xxxxxxxxxxxxxx> 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
