Magnus Hagander PostgreSQL supports several options for securing communications when deployed outside the typical webserver/database combination. This talk will go into some details about the features that make this possible, with some extra focus on the changes in 8.4. The main areas discussed are: * Securing the channel between client and server using SSL, including an overview of the threats and how to secure against them * Securing the login process, using LDAP, Kerberos or SSL certificates, including the use of smartcards to log into the database The talk will not focus on security and access control inside the database once the user is connected and authenticated.

1. Secure PostgreSQL
Deployments
JDCon-East 2010
Philadelphia, PA
Magnus Hagander
Redpill Linpro AB

2. There's much to security
● Identify the threats
● Apply the correct measures
– Don't do things just because you can

3. Not in this talk
● Application security
● Data Access Control
● Data Encryption
● etc
● etc

4. Definitely not in this talk
● Unix vs Windows
● Linux vs BSD
● SELinux/SEPostgreSQL
● Any other religion

5. In this talk!
● Authentication methods
● Connection security

6. Authentication methods
● How do we determine who the
user is
● When do we determine who the
user is

7. pg_hba.conf
● Lets you use different auth
methods from different clients
● Not just limited to
username/password
● For convenience or security
● Internal or external

8. pg_hba.conf
local all all trust
host all all 127.0.0.1/32 trust
host webdb webuser 10.0.0.0/24 md5
host all @dba 192.168.0.0/24 gss

9. Trust Authentication
● Any user can be anyone he/she
claims to be!

10. Trust Authentication
● Any user can be anyone he/she
claims to be!
● Anyone think this is a bad idea?

11. Username/password
● Normally, use md5 method
– crypt has been removed, avoid plaintext
● What everybody does
● What everybody expects

12. LDAP authentication
● To the client, username/password
● Backend verification is off-loaded
to directory server
● Common in enterprise
deployments
● Password policies, expiry, etc

13. LDAP authentication
● Single password not single signon
PostgreSQL
ct Server
onne
1. C sw o
rd
pa s
qu est ord
2. Re assw
e nd p
3. S
Client LDAP
Server

14. LDAP news in 9.0
● search/bind combination
● Can use non-cn fields in login
– Anything that's LDAP searchable
– Common choice: uid

15. RADIUS (new in 9.0)
● Remote Authentication Dial In User
Service
● Simple single-packet UDP service
● Original use-case: ISP dialup
● Common for one-time passwords, etc
● Good policy frameworks

16. Kerberos/GSSAPI/SSPI
● Single signon
● Same benefits as LDAP (mostly)
● Most common: Active Directory
● («krb5» is deprecated)

17. Kerberos/GSSAPI/SSPI
● Single password not single signon
PostgreSQL
t
Server
nt ticke
3. Prese
1. Req
u
est tic
ket
Client 2. Ret
urn tic KDC
ket

18. PAM
● Provided by OS
● Can do password, LDAP, etc
● Can also do Kerberos & friends
● One-time passwords
– RSA SecurID, Vasco, etc
– RADIUS (no need in 9.0)

19. SSL

20. SSL secured connections
● Encryption
● Man-in-the-middle protection
● Authentication

21. SSL secured connections
● Enabled on the server (ssl=yes)
– Platform quirks!
● Optionally required through
pg_hba
● Optionally required in libpq

22. SSL secured connections
● Need to protect data in both
directions
● For example username/password
● Must know before connection is
started
– Unknown equals unprotected

23. SSL encryption
● SSL always requires a server
certificate
● Can be self-signed
● Does not need to be known by
client

24. Certificate chains
Issuer
Root certificate
Issuer
Intermediate certificate
Issuer
Server certificate

25. Certificate chains
Self-signed
certificate
Issuer
Root certificate
Issuer
Intermediate certificate
Issuer
Server certificate

26. SSL secured connections
Client Server

27. Threats handled by SSL:
Eavesdropping
SELECT * FROM secret_stuff
Client Server

28. Eavesdropping
● Prevented by encrypting all data
● Key negotiation is automatic
– On initial connection
– After 512Mb traffic
● Server certificate used but not
verified

29. Key renegotiation
● Broken in the SSL protocol –
OOPS!
● Fixed SSL libraries are available
● Broken fixes were pushed by
vendors
● ssl_renegotiation_limit = 512MB

30. Threats handled by SSL:
Man in the middle
Valid SSL session
Valid SSL session
Fake server
Client Server

31. SSL server verification
● On top of encryption
● Validate that the server is who it
claims to be
● CA issues certificate, can be self-
signed
● CA certificate known by client

32. Threats handled by SSL:
Man in the middle
Valid SSL session
Fake server
Client Server

33. SSL client authentication
● On top of encryption
● Normally on top of server
verificateion, but not necessary
● CA issued certificate on client
● Match CN on certificate to user id
● Protect client certificate!

34. SSL client authentication
PostgreSQL
te
Server
ertifica
esent c
1. Pr
Client

35. SSL client certificates
● Can also be used together with
other authentication
● Require client certificate
● Also require e.g.
username/password

36. SSL in libpq
● Controlled by sslmode parameter
● Or environment PGSSLMODE
● For security, must be set on client
– Remember, unknown = unsecure

37. Summary of libpq SSL modes
Compatible with server set
Protect against Performance
to...
Client Eavesdrop MITM SSL required SSL disabled overhead
Mode
disable no no FAIL works no
allow no no works works If necessary
prefer no no works works If possible
require yes no works FAIL yes
verify-ca yes yes works FAIL yes
verify-full yes yes works FAIL yes

38. Summary of libpq SSL modes
Compatible with server set
Protect against Performance
to...
Client Eavesdrop MITM SSL required SSL disabled overhead
Mode
disable no no FAIL works no
allow no no works works If necessary
prefer no no works works If possible
require yes no works FAIL yes
verify-ca yes yes works FAIL yes
verify-full yes yes works FAIL yes

39. Summary of libpq SSL modes
Compatible with server set
Protect against Performance
to...
Client Eavesdrop MITM SSL required SSL disabled overhead
Mode
disable no no FAIL works no
allow no no works works If necessary
prefer no no works works If possible
require yes no works FAIL yes
verify-ca yes yes works FAIL yes
verify-full yes yes works FAIL yes

40. Summary of libpq SSL modes
Compatible with server set
Protect against Performance
to...
Client Eavesdrop MITM SSL required SSL disabled overhead
Mode
disable no no FAIL works no
allow no no works works If necessary
prefer no no works works If possible
require yes no works FAIL yes
verify-ca yes yes works FAIL yes
verify-full yes yes works FAIL yes

41. Not a bad idea: ipsec
● If already deployed
● Application transparent
● Global policies
● Integrated management
● Somebody Elses Problem?

42. Secure PostgreSQL
Deployments
Questions?
magnus@hagander.net
Twitter: @magnushagander
http://blog.hagander.net