On 3/05/2010 7:58 PM, Durumdara wrote:
1.) Auth. - password trying. The clients are access PGSQL by Zeos, or by PGDAC. I don't know what auth. methods they are support, but I think that md5 and plain text is not enough here...
Just make sure you have an ssl certificate for your server, and require clients to validate it. Otherwise anyone malicious on the network path (or able to steal packets - think wifi or arp spoofing) can steal the password and/or your data.
You should configure the client to verify the server against a CA cert or a pre-installed copy of the server cert. Unfortunately, by default psql seems to accept self-signed certificates as trustworthy, but that's really not a good idea.
2.) Opened port - PGSQL hack/crack possibilty. I don't know about PGSQL hack/crack on ports, but everything is possible. If they are hack the PGDB without knowing password (with some special code injection), we are in problem...
Remote security holes are rarely reported for PostgreSQL. That doesn't mean they aren't there.
3.) Server overloading with DOS. (Example: many-many requests to login)
Unless I'm badly mistaken PostgreSQL starts a backend to do auth, which is an expensive process. A continuous load-based DoS would therefore probably be very easy to do with relatively little bandwidth.
It's fairly easy with linux iptables and the like to make the database port inaccessible to a particular IP until the application successfully accesses some other more lightweight service. That might help if you're really worried.
Personally I'm not bothering in my deployment. I run Pg on a non-standard port and require ssl connections with an authenticated *client* certificate, but don't worry too much about DoS. I don't have the capacity to resist an even vaguely determined DoS anyway, and Pg won't make that any worse.
4.) Lost connections? How to handle when connection lost on wrong web, or temp. down?
Use tcp keepalives to work around braindead nat routers. Set short timeouts (see postgresql.conf tcp_ settings) so the server notices dead connections quickly. Be robust in the face of dangling dead connections.
-- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
