Re: PosgreSQL Security Architecture - Mailing list pgsql-general

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
understandingof known attacks, their purpose, potential solutions, their costs and mitigating issues and very
importantlyperformance 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
adherenceto proper internal procedures.  
* DDOS attacks tend to have two aims. Simply stopping the website or causing stack over flow. Hoping to catch the
serveron 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
anEastern block country then US before returning back to UK.  Last I heard. AOL's (or now talk talk) traffic still goes
tooutside 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
afake man in the middle and fed back to the server with the result of creating a new session. (sorry don't recall the
O/Sor 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
securingthe communication layer. I normally use a mid-cost company like Comodo's SSL service. They tie the server, ip
addressto SSL certificate.  
*Personally I use a customised encryption techniques on the database. In the event of a failure or security breach at
saya cloud computing partner. These will be a lot more difficult to crack but also easier to recover. My past
experienceis 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
butcan 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
connectionpooling. It goes without saying that all application installed on the server needs to be checked for
potentialsecurity issues but 

Good luck. I hope these might be of some use to you and others.



Farjad Farid


-----Original Message-----
From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Albe Laurenz
Sent: 15 February 2016 10:48
To: 'John R Pierce *EXTERN*'; pgsql-general@postgresql.org
Subject: Re: [GENERAL] 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@postgresql.org) To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general