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
