Below is my pg_hba.conf entry.
host dbname username 0.0.0.0/0 radius radiusserver=xyz radiussecret=xyz
My understanding here is that when client is trying to establish connection to postgres, the password is sent to postgres which in turns passes it to radius to perform authentication. Once okayed from Radius, the connection will be established. Please correct me if this is not right.
Now when the password is sent to db, will it be unencrypted? I think so.
When password is sent to Radius, is it encrypted?
If I covert host entry to hostssl, then when the client sends the password it would be encrypted correct?
Yes, the password is plain text to the PostgreSQL server, provided the connection itself is unencrypted.
Yes, apparently it is encrypted/hashed between the PostgreSQL server and the radius server, but apparently just with a md5 hash, so not the greatest. There might be additional ways to protect it, but I think that would be a radius question, not a postgresql question.
Yes, ssl will protect it between the client and PostgreSQL, but using hostssl in pg_hba is the wrong way to do it if you are worried about sending the plain-text password to a compromised server. The person who compromised the server will just change "hostssl" back to "host", if they are any good. Instead, you want to enforce this on the client end, with PGSSLMODE=verify-full or the equivalent. (Actually they don't need to turn ssl off, as it will be encrypted for them to decrypt anyway)
Related
Right now I have the following, which works:
host all all all ldap ldapserver=ldap.server.name ldapprefix="DOMAIN\"
but to my understanding the connection between the ldap server and pg db isn't encrypted and I need it to be. So i change to:
host all all all ldap ldapserver=ldap.server.name ldapprefix="DOMAIN\" ldaptls=1
this give me an error saying "could not start ldap tls session connect error".
What are the steps that Im missing in order to get this working? I have a feeling I need to be dropping certs either somewhere on my ldap instance or pg instance (or both) but I don't really have any experience configuring any of this.
If you are looking to use ldaptls=1, then please make sure that you are using the correct certs to connect to the LDAP server. Also, depending on how LDAP is set up, you may need to add ldapport=389 to tell Postgres to use the TLS port on the LDAP side.
More information at https://richyen.com/postgres/2018/02/09/making_postgres_talk_to_ldap_with_starttls.html
I am installing DSPACE which needs PostgresSQL.
Please see this link: DSPACE INSTALL
It says:
Then tighten up security a bit by editing pg_hba.conf and adding this line:
host dspace dspace 127.0.0.1 255.255.255.255 md5.
I have read on the internet as to how the above line works. It needs a connection type followed by database name/user name followed by IP address and the authentication scheme.
My question is: Should this not be a local (in place of host) connection since the dspace user is running locally?
Can someone show me step by step as to what happens when a request comes in?
Where are the instructions that the dspace user will submit a request using md5?
DSpace uses JDBC, so local won't work for it. Here local means a completely different kind of inter-process connection that has nothing to do with IP and can only address local processes: Unix sockets. JDBC uses only IP, so DSpace needs a host descriptor.
That period at the end of the line is not supposed to be part of it. The documentation was unclear there -- I've fixed it.
As Laurenz Albe noted, DSpace doesn't specify that MD5 password hashes be used. The PostgreSQL server controls which methods will be tried, based on what you specify in pg_hba.conf.
First, there is a . at the end of your pg_hba.conf line. That is a syntax error.
Whether to use local or host depends on
what API this DSPACE is using (JDBC, for example, allows no UNIX socket connections)
what connection string DSPACE is using
If you can specify a socket directory as host name, you can probably use UNIX sockets, which would be more efficient.
If DSPACE uses a driver that supports md5 authentication, the procedure is like this:
client sends server a connect packet with user and database
server requests md5 authentication and sends a random "salt" string
client computes an MD5 hash of the password with the salt from the server and sends the result to the server
server verifies that the hash is correct
I have a postgresql 11 instance that need to share with the client, it's ok to let the client do whatever they want except the accounts.
if the client modifies the pg_hba.conf, they can connect without password, is there any way to disable pg_hba, making it no way to connect without password?
PS: the client has the host access
I have two databases set up as part of the same Postgresql 9.4 database cluster, and I'm trying to access a table in one of them from the other using a postgres_fdw. I have it all set up and working as a superuser, however when I try to access the foreign table as a normal user, I get the following error:
ERROR: password is required
DETAIL: Non-superuser cannot connect if the server does not request a password.
HINT: Target server's authentication method must be changed.
Now I understand that this is because I have the server set up with trust authentication for certain subnets, including Its own. However, in the 1 USER MAPPING I created, I did specify a password, with the hope that doing so would force it to use password authentication. No such luck apparently.
As such, my question is if there is any way around this somewhat onerous requirement? Is there a way to force this connection, or a specific user, or the like to use password authentication? Or some way to disable the requirement? Or is my only option to change the configuration to require passwords, and deal with whatever that breaks?
As Nick Barnes pointed out in a comment, pg_hba allows different authentication rules for specific users. As such, the solution to this issue was to simply create a user specifically for these FDW connections, and set that user in the pg_hba.conf to require a password. That way my trusted web apps on the trusted network can continue connecting as usual, but the FDW can get the password request it requires.
You can't force FDW to use a password: the server on the other end must request the password. the usual default for local socket connections is no password.
Try connecting via TCP instead of using local sockets: add host=localhost to the connection parameters, that will usually fix it.
I have a mongodb running in my server, for local connections to the db I don't need any password to protect it(that is within the same physical machine, meaning connect to the server thru the 127.0.0.1 ip address).
But I don't want other people in the network be able connect to my database without password, only the authorized user. So I want to do password protection for the remote user.
How to do it?
Right now monogdb does not support authentication mode based on the user location. So that means if you run mongod with --auth that will apply to everyone.
There are no (yet) advanced authentication schemas like IP, protocol source, etc. For now you can only define if the user has read only or write permissions on a database. So basically the only thing mongodb cares is if you typed the right password for the right user.
Personally in all production environment I would recommend to use the secure mode, because even if you allow only connection from a localhost any users who has access to the local server or any malicious script on the host can easily wipe all your data.
The MongoDB Security and Authentication page has information on configuring user authentication and firewall settings.
Note that when you enable password authentication for a database, the authentication requirement will apply to both local and remote users (so you will also need to connect with a password through the local IP).
MongoDb does not offer an easy way to protect the database. I assume this is the reason why there are tens of thousands of mongodb instances on the net that are unprotected for hackers