Edit init script or start command (/etc/rc.d/init.d/postgresql-9.0)
This setting should be done if you install postgre almost in Linux Distribution, i use CentOs.
One of the key security controls for PostgreSQL, and indeed many other applications, is to ensure the database server daemon, called postmaster, is being run as an appropriate user. On these distributions PostgreSQL should run as a normal user, usually the Postgre user. You can confirm that the daemon is running as an appropriate user by checking the process.
# ps – aux | grep ‘postmaster’
postgres 12934 0.0 1.2 20896 3156 ? S 02:16 0:00 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data
If it isn’t being run as a nonroot user, you should create an appropriate user. You can then change your init script or start command to start PostgreSQL with this user. You can use su to then run PostgreSQL as the appropriate user.
To extend this, you can also run PostgreSQL under SELinux or AppArmor. For example, the SELinux “targeted” policy on Red Hat Enterprise Linux includes support for running PostgreSQL.
Edit postgresql configuration file (/var/lib/pgsql/9.0/data/postgresql.conf)
Each of these modes are configured in the postgresql.conf configuration file, usually located in your data directory. In Red Hat, for example, it is in the /var/lib/pgsql/data directory.
Control of network bindings is handled by the listen_addresses configuration option (you can also change the port number if you’d like). You can specify an address, addresses or blank to not bind to the network at all.
You can also only bind the network to the localhost.
listen_addresses = ‘localhost’, it will reject all connection from other tcp/ip.
do not set
listen_addresses = ‘*’
because it will alow all connection to your DB Server, please set
listen_addresses = ‘Your DB Server IP’, ex listen_addresses = ’10.10.100.5′
it will allow connection from other tcp/ip in same subnet
Edit iptables configuration file (/etc/sysconfig/iptables)
If you do bind to an external interface, you will need to ensure that port 5432 is open on your firewall. It is a good idea to lock down incoming connections to all hosts except those hosts who need to access the database. For example:
# iptables -A INPUT -p tcp -s 10.10.0.10 -d 10.10.0.20 –dport 5432 -m state –state NEW,ESTABLISHED -j ACCEPT # iptables -A INPUT -p tcp –I lo –dport 5432 -m state –state NEW,ESTABLISHED -j ACCEPT # iptables –A INPUT –p tcp –dport 5432 –m state NEW,ESTABLISHED –j DROP
The first rule tells iptables to allow connections from the 10.10.0.10 host to the 10.10.0.20 host (our database host) on port 5432 – PostgreSQL’s default port. The second rule allows access from the localhost. The last rule drops any other PostgreSQL connections. You would then also need to create appropriate outgoing rules.
Edit Client Authentication Configuration File (/var/lib/pgsql/9.0/data/pg_hba.conf)
# Disable all trust connections, its easy to set but it will be very difficult if you have some Backup DB Application which must be allowed do pg_dump without password, my suggestion is create other super user besides postgres and set trust connections at local only.
# Use strong authentication (md5/kerberos etc)
# Limit connections only from allowed IP, don’t forget to set *.*.*.*/32 or /24
After configuring how clients connect to PostgreSQL, we need to specify which clients can connect to PostgreSQL. This is done using host-based client access control and is configured in the pg_hba.conf configuration file. The pg_hba.conf configuration file is usually located in the PostgreSQL data directory, for example /var/lib/pgsql.
PostgreSQL has a wide collection of authentication and access mechanisms including password authentication, PAM, LDAP and Kerberos and others. With the pg_hba.conf file you can control connections to local or network sockets, where they connect from and what authentication methods are allowed. The authentication is also sufficiently granular to control which databases can be accessed. Let’s look at some simple examples: # Type DB User Network Mechanism local all all pam host sameuser all 127.0.0.1/32 pam host www www 10.10.0.10/32 md5
Each configuration line in the pg_hba.conf file is made up a number of fields. The first field tells PostgreSQL what type of connection we are securing. The two most common types are “local” for local file socket connections and “host” for network connections. You can specify multiple authentication mechanisms for each type.
The DB field specifies which database you can connect to and includes two special options values: “all” and “sameuser”. The “all” option indicates that incoming users on this connection type can connect to all databases. The “sameuser” option will only allow an incoming user to connect to a database with the same name as the connecting user.
So the second line in our example above would allow the user “ben” to connect to a database called “ben” but not to a database named “jerry”. You can also specify multiple databases by separating each with a comma.
The user field controls which user ids are allowed to connect. Again, we can use the “all” value for all user ids to connect or the name of a specific user. You can also specify multiple users by separating each with a comma.
For network connections — though obviously not local sockets — we can specify which hosts and network can connect in the form of an IP address and subnet. In the second line above we limit connections to the loopback address and in the third line to the IP address 10.10.0.10.


Recent Comments