Web proxy server - CHAPTER 29 SECURING POSTGRESQL template1=# ALTER USER
CHAPTER 29 SECURING POSTGRESQL template1=# ALTER USER postgres PASSWORD ’secret’; ALTER USER template1=# Of course, you should choose a password that is a tad more complicated than secret. PostgreSQL will let you dig your own grave in the sense that passwords such as 123, abc, and your cat s name are perfectly acceptable. However, common security practices suggest choosing a password that is at least eight characters in length, and consists of a mixture of numeric and alphabetical characters of varying case. Securing the PostgreSQL Daemon When you start the postmaster process, several options are available that you can take advantage of to help secure your installation. The first place to look for these options is in the postgresql.conf file. This file also contains settings that are unrelated to security, but in this section, we focus on those related to maintaining good server security: listen_address: Specifies the TCP/IP address or addresses that PostgreSQL listens on for client connections. The default setting is localhost, which means that the installation will listen for connections only from the local machine, via TCP/IP or Unix-domain sockets. Setting the list to empty causes the server to ignore any IP interfaces and connect only via Unix-domain sockets. If your database and application reside on the same machine, you should definitely consider setting the list to empty. port: Sets the port number that PostgreSQL will accept the connection on. Setting this value to something other than the default (5432) can help dodge malicious attempts at scanning for the PostgreSQL service; just be sure to choose a port that is not commonly used for something else. ssl: Enables SSL connections. While configuration of SSL can be tricky, and its use will incur some overhead, it is essential for applications that need to transmit critical data. krb_server_keyfile: Sets the location of the Kerberos server key file. It is only needed when using Kerberos-based authentication, but it does give you another option for secured connections. The PostgreSQL Access Privilege System Protecting your data from unwarranted review, modification, or deletion, accidental or otherwise, should always be your primary concern. Yet balancing a secure database with an expected level of user convenience and flexibility is often a difficult affair. The delicacy of this balance becomes obvious when you consider the wide array of access scenarios that might exist in any given environment. For example, what if a user requires modification privileges, but not insertion privileges? How do you authenticate a user who might need to access the database from a number of different IP addresses? What if you wanted to provide a user with read access to only certain tables, while restricting the rest? You can imagine the nightmarish code that might result from incorporating such features into the application logic. Thankfully, the PostgreSQL
In case you need quality webspace to host and run your web applications, try our personal web hosting services.