Re: postgres "on in the internet"

At 03:55 PM 9/3/2004 -0400, Paul Tillotson wrote:

>How difficult is it to set up VPN?
>
>I know that in the past my company has used VPN tunnels, but this was
>difficult for our remote users to get set up.  I am actually willing to
>trade *some* security for ease of installation and simplicity.  This
>will have to be deployed on  30 to 40 client computers, several of them
>in very (i.e., plane travel) distant locations for non-technical users
>who will work remotely.
>
>Whatever the solution is, the setup needs to be scriptable or else very
>easy to walk someone through by telephone.

In which case I suggest you go with tunnelling over SSL. Bundle the SSL
software and configuration with your client software install, or even build
it into your client software.


>For this reason, it occurred to me that an enemy that can't sniff your
>traffic, postgres untunnelled is probably more secure than postgres
>tunnelled through openssl or openssh.

People can still attack the postgresql server directly. Given that most
people don't expose their database servers to the Internet nor even
consider it, I doubt postgresql has been tested very much in that scenario.

By implication you're assuming the postgresql developers would do a better
job securing postgresql (at least on the initial connection, setup and
authentication stages) than the openssl and openssh developers - who
ironically seem to be having trouble getting their "security oriented"
software secure.

While the Postgresql developers in general do quite high quality work from
the high performance SQL standards compliance DB server perspective, I'm
not so sure how postgresql measures up from the "server exposed to
Internet" security perspective.

Perhaps someone who has done a security audit of postgresql from that
perspective can chime in.

The SSL topology I proposed has the SSL gateway separate from the database
server, this means that even if a hacker successfully exploits the SSL
gateway (using an SSL exploit), the hacker only gains local user/root
access to the SSL gateway and still needs to hack the postgresql server
over the network through the firewall.

Note that once on the SSL gateway the hacker should easily be able to gain
the DB user accounts and passwords from sniffing the traffic :(. e.g. the
hacker would be attacking postgresql as a valid DB user.

This scenario is still better than having the SSL end point being the
database sever. Because if anything happens the attacker gains local
user/root access to the database server, and isn't limited to attacking
postgresql over the network as a valid DB user - the attacker can attack
via the file system level or unix sockets or whatever security loophole
there is.

BUT don't forget a determined hacker is likely to be able to get DB user
accounts and passwords by getting hold of a copy of your client application
- assuming you bundle the user account and password with the app/app config.

Basically the attacker can do whatever the DB account which your client app
uses can do- the attacker can try arbitrary SQL commands and likely tamper
with the data on the database. This could be disastrous.

Whereas if the client application talks to the server and the application
server is the only one talking SQL to the database this would not
necessarily be possible (assuming you don't have SQL injection problems in
your app server ;) ).

Regards,
Link.