LJK, Firstly thanks for bring this topic up. As many companies have to handle attacks on their network. Adrian thanks for the links specially the one covering connection pooling in the first link. Answered by Pavel Stehule . Definitely something to avoid. I have done a fair bit of work on security issues from Ecommerce perspective. Hope these comment might be of some value. Please avoid giving guarantees on security issues. Rather try to give a level of confidence based on current understanding of known attacks, their purpose, potential solutions, their costs and mitigating issues and very importantly performance issues. These days specially on ecommerce. Search engines penalise site's ranking based on their performance. So a site could be very secure but it could end up losing business. Can I break this question up a little bit. * Repeated security reports indicate that by far the most serious security breaches are insider jobs or lack of adherence to proper internal procedures. * DDOS attacks tend to have two aims. Simply stopping the website or causing stack over flow. Hoping to catch the server on the hop. These are not DB engines job and are best handled elsewhere before the transaction reaches the DB engine. * Man in the middle is a big problem. Too often under estimated. As an example. I live in UK. Tracing a Tcp/Ip transaction going from a UK location to a UK site can end up going to an Eastern block country then US before returning back to UK. Last I heard. AOL's (or now talk talk) traffic still goes to outside UK before returning back to UK. Mitigating potential actions of man in the middle is a collective job of the O/S, network layer, firewall and the DB. *Several years ago there was a research done where during authentication process the tcp/ip traffic was intercepted by a fake man in the middle and fed back to the server with the result of creating a new session. (sorry don't recall the O/S or SSL they used) The potential solution lies at the network layer not the DB engine. *OpenSSL. For a small outlay of few hundred dollars it is safer to have an higher over security of the system by securing the communication layer. I normally use a mid-cost company like Comodo's SSL service. They tie the server, ip address to SSL certificate. *Personally I use a customised encryption techniques on the database. In the event of a failure or security breach at say a cloud computing partner. These will be a lot more difficult to crack but also easier to recover. My past experience is that often DB engines (not postgresql) find it difficult to recover encrypted fields that were encrypted by *DB engine itself*. Please bear in mind this has an impact on searching and indexing and performance so be careful but can be resolved. *Logs files needs to be just as secure as the main db files. *Lastly but certainly not least. Adrian raised a very important point in his post about use of applications for connection pooling. It goes without saying that all application installed on the server needs to be checked for potential security issues but Good luck. I hope these might be of some use to you and others. Farjad Farid -----Original Message----- From: pgsql-general-owner@xxxxxxxxxxxxxx [mailto:pgsql-general-owner@xxxxxxxxxxxxxx] On Behalf Of Albe Laurenz Sent: 15 February 2016 10:48 To: 'John R Pierce *EXTERN*'; pgsql-general@xxxxxxxxxxxxxx Subject: Re: PosgreSQL Security Architecture John R Pierce wrote: > On 2/12/2016 5:20 AM, Lesley Kimmel wrote: >> Thanks for the reply Laurenz. Of course the first thing that I >> thought of to prevent man-in-the-middle was SSL. However, I also like >> to try to address the issue in a way that seems to get at what they >> are intending. It seemed to me that they wanted to do some >> configuration within the database related to session IDs. > > when the connection is broken, the process exits and the session ceases > to exist. there are no 'session IDs' to speak of (they are process > IDs instead, but a new process mandates new authentication, there's no > residual authorizations associated with a PID). I might be misunderstanding, but is there any connection to a man-in-the-middle attack? Without SSL, anybody who can tap into the TCP communication can inject SQL statements. No session ID is required. Yours, Laurenz Albe -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
